A PortaZone is an object that has a doid but mainly exists to hold a pre-built collection of add-on objects, like furniture. If a PortaZone is laid on a perfectly flat surface such as the ocean, it encompasses a 3-dimensional volume that has a particular square footprint and extends vertically for a given distance.
A PortaZone is dropped in front of you, with its nearest edge 1.5m from your current position:
- A Large PortaZone is 40m x 40m on the ground, and 50m high. Its center is dropped 21.5m in front of you. This applies to the shop Large, and to the two kinds of freebie Basic as well.
- A Medium PortaZone is 15m x 15m on the ground, and 50m high. Its center is dropped 9m in front of you.
- A Casual PortaZone is 8m x 8m on the ground, and 10m high. Its center is dropped 5.5m in front of you.
When you teleport to a PortaZone, or use the “Exit this place” toolbar button to exit from it, you are teleported to a point on the back boundary of the zone opposite the drop point. Your avatar will arrive facing back across the centre of the zone towards the drop point.
In function, the various portazones are nearly identical. The only one that has any difference of significance is the casual portazone, which is free to refill, has a limit on the extent to which it can be refilled and of course fewer available drops (5 vs. 30 for the other types).
If you drop a portazone, there is a parameter (ObstacleDasp code=38 under activobExtras) called dropMinutesRemaining. This appears to “stick” at the number of minutes left on the zone when it was dropped; it does not appear to decrease. An adjacent parameter dropPaidThrough seems to be the retrieval time. I dropped a fully-charged casual zone twice, two minutes apart, and got a difference of around 3600 in retrieval times. This implies a scale of 30 ticks (simulation steps?) per second.
Recharging the casual in-world results in the dropMinutesRemaining sticking at 240 and the dropPaidThrough incrementing. Dividing the tick-based simulation deadlines by 30 appears to give Unix UTC “seconds since the epoch” with no timezone adjustments (i.e., I get the right answer even though I am eight time zones away from the server).
A newly planted scroll shows dropMinutesRemaining of 0 and dropPaidThrough an hour in the future. Perhaps documents are only scanned for retrieval every so often? A book that has been sitting around for a bit longer shows up as having a dropPaidThrough several hours in the future but still short of the real deadline. I haven’t seen a number for that window being larger than 64800 on a document… maybe they are trying to keep it in 16-bits worth of seconds?
Interestingly, a portazone always shows the correct timeout date/time even if it is many days in the future.
Charging an in-world medium portazone results in the appropriate incrementing of dropPaidThrough and the setting of dropMinutesRemaining to the number of minutes from the recharge time to the expiry time.
The expiry time for a PortaZone is extended when the system is down. For example, if a PortaZone is in-world when the system goes down for an hour, its dropPaidThrough will be appear to have been extended by an hour when examined after the system comes up. We are told that “different servers can have different amounts of downtime, even for portazones in the same sector” but it isn’t clear exactly what that means.