Transporter: Difference between revisions

From Wiki of ZZT
Jump to navigation Jump to search
(Transporter function)
No edit summary
 
Line 14: Line 14:
The '''transporter''' is device that moves the player or a pushable element to another location. Transporters can be used as a convenience (to shorten travel distance) or to create navigational puzzles.
The '''transporter''' is device that moves the player or a pushable element to another location. Transporters can be used as a convenience (to shorten travel distance) or to create navigational puzzles.


Transporters have three different basic arrangements:
The destination of an element entering the transporter is evaluated in the following order:  


* '''One-Way''': If it has nothing directly in front of it.
* '''One-Way''': If nothing is blocking the opposite side of the transformer, the element appears there.
* '''Long-Distance''': If there is a matching (opposite-faced) transporter in its line of sight.
* '''Long-Distance''': If nothing is blocking a matching (opposite-faced) transporter in its line of sight, the element appears at the location of its entrance.  
* '''Unusable''': If the transporter has something in front of it, and no matching transporter in its line of sight.
Failing that, the transporter is deemed unusable and the element is not moved.


To be able to use a transporter in the first place, the element must enter it in the same direction (x/y-step) as it is pointed. Transporters then iteratively scan every tile in front of them to check for a valid destination. This scanning process only stops when the [[edge|board edge]] element is encountered or a valid destination transporter is encountered.
Transporters can unblock destinations by moving pushables, but not by touching elements - for example, a [[boulder]] will be pushed out of the way of a player, but a [[gem]] will not be collected and instead treated as a blocking element.
 
== Detailed behavior ==
To be able to use a transporter in the first place, the element must enter it in the same direction (X/Y step) as it is pointed. Transporters then iteratively scan every tile in front of them to check for a valid destination. This scanning process only stops when the [[edge|board edge]] element is encountered or a valid destination transporter is encountered.


The first tile in front of a transporter is a special case. The transporter assumes that it might be a valid destination, and attempts to push any blockages out of the way, and either the transportation happens (if the way is clear) or it begins its search in earnest for a matching transporter. The checking process from that point on is essentially the same: if there's a matching transporter, it tries to clear the way, and then either the transportation happens or it continues its search. Repeat until a board edge is encountered.
The first tile in front of a transporter is a special case. The transporter assumes that it might be a valid destination, and attempts to push any blockages out of the way, and either the transportation happens (if the way is clear) or it begins its search in earnest for a matching transporter. The checking process from that point on is essentially the same: if there's a matching transporter, it tries to clear the way, and then either the transportation happens or it continues its search. Repeat until a board edge is encountered.


Transporters with non-standard x/y-steps can be used, but the player cannot just walk into them. Another object or pusher with the proper x/y-step must push them through it.
Transporters with non-standard X/Y steps can be used, but the player cannot just walk into them. Another object or pusher with the proper X/Y step must push them through it.


Note that because transporters use their x/y-step values as parameters, that they are especially prone to the [[diemove]] bug. This generally only happens with one-way transporter setups.
Note that because transporters use their X/Y step values as parameters, they are especially prone to the [[diemove]] bug. This generally only happens with one-way transporter setups.


== Draw Procedure ==
== Display logic ==


For standardly oriented transporters, the transporters cycle through the following frames of animation depending on their direction:
For standard transporter orientations, the transporters cycle through the following frames of animation depending on their direction:


{| class="wikitable"
{| class="wikitable"
Line 46: Line 49:
|}
|}


The animation rate is controlled by the code <code>(CurrentTick div Cycle) mod 4</code>. Be aware that '''a cycle 0 transporter will crash the game''' due to a division-by-zero error if the transporter is drawn on-screen. This can be used as a particularly cruel form of anti-cheat in dark rooms if you can guarantee the transporter is always outside the torch-viewable area.
The animation rate is controlled by the code <code>(CurrentTick div Cycle) mod 4</code>. Be aware that '''a cycle 0 transporter will crash the game''' due to a division-by-zero error if the transporter is drawn on-screen. This can be used as a particularly cruel form of anti-cheat in dark rooms if you can ensure the transporter is always outside the torch-viewable area.


When using non-standard x/y-step values, transporters may use characters outside of the array bounds.
When using non-standard X/Y step values, transporters may use characters outside of the array bounds, displaying anything from empty characters to random ones.


{{ElementsNavbox}}
{{ElementsNavbox}}

Latest revision as of 21:38, 23 December 2025

Transporter
ZZT-OOP nameTransporter
Internal ID30 (0x1E)
Character#char 197 (0xC5)
CategoryTerrain
Stats
X/Y-stepDirection
Default cycle2
Other traits
Effect on movementTransportation or Wall
Destructible?No
Uses ZZT-OOP color names?Yes

The transporter is device that moves the player or a pushable element to another location. Transporters can be used as a convenience (to shorten travel distance) or to create navigational puzzles.

The destination of an element entering the transporter is evaluated in the following order:

  • One-Way: If nothing is blocking the opposite side of the transformer, the element appears there.
  • Long-Distance: If nothing is blocking a matching (opposite-faced) transporter in its line of sight, the element appears at the location of its entrance.

Failing that, the transporter is deemed unusable and the element is not moved.

Transporters can unblock destinations by moving pushables, but not by touching elements - for example, a boulder will be pushed out of the way of a player, but a gem will not be collected and instead treated as a blocking element.

Detailed behavior

To be able to use a transporter in the first place, the element must enter it in the same direction (X/Y step) as it is pointed. Transporters then iteratively scan every tile in front of them to check for a valid destination. This scanning process only stops when the board edge element is encountered or a valid destination transporter is encountered.

The first tile in front of a transporter is a special case. The transporter assumes that it might be a valid destination, and attempts to push any blockages out of the way, and either the transportation happens (if the way is clear) or it begins its search in earnest for a matching transporter. The checking process from that point on is essentially the same: if there's a matching transporter, it tries to clear the way, and then either the transportation happens or it continues its search. Repeat until a board edge is encountered.

Transporters with non-standard X/Y steps can be used, but the player cannot just walk into them. Another object or pusher with the proper X/Y step must push them through it.

Note that because transporters use their X/Y step values as parameters, they are especially prone to the diemove bug. This generally only happens with one-way transporter setups.

Display logic

For standard transporter orientations, the transporters cycle through the following frames of animation depending on their direction:

Animation frames
Frame N S E W
1 #char 94 ^ (0x5E) #char 118 v (0x76) #char 40 ( (0x28) #char 41 ) (0x29)
2 #char 126 ~ (0x7E) #char 95 _ (0x5F) #char 60 < (0x3C) #char 62 > (0x3E)
3 #char 94 ^ (0x5E) #char 118 v (0x76) #char 40 ( (0x28) #char 41 ) (0x29)
4 #char 45 - (0x2D) #char 45 - (0x2D) #char 179 (0xB3) #char 179 (0xB3)

The animation rate is controlled by the code (CurrentTick div Cycle) mod 4. Be aware that a cycle 0 transporter will crash the game due to a division-by-zero error if the transporter is drawn on-screen. This can be used as a particularly cruel form of anti-cheat in dark rooms if you can ensure the transporter is always outside the torch-viewable area.

When using non-standard X/Y step values, transporters may use characters outside of the array bounds, displaying anything from empty characters to random ones.