z2

Trying to debug world 1 of Adventure of Sam before moving on to world 2, but I'm having the weirdest problem with transporters, and was wondering if anyone could figure this out.



The dungeons all have transporters that are useless going in but functional once "activated" by a switch on the other side of the room, to make backtracking (getting back out again once you're done, or even leaving halfway through to go heal, then getting back to where you were again) less of a pain. This works by the fact that transporters with a clear space in front of them will just transport you to the next space over (in this screenshot, going through the transporter on the left there will just move you one space to the right, between the transporter and the block) but a transporter that's blocked in that immediate direction but has an opposite transporter will move the player over to that, like transporters are usually supposed to. In this screenshot, the blocks are set to move in front of the transporters once you throw the switch (that white upside-down T near the south exit) and block them, thus "activating" them and making them functional, thus making return trips and backtracking easier.

Here's the thing, though. Every time I play-test this board, one of the transporters (the one on the left) "activates" prematurely by the fact that the transporter moves to the right, in front of the block. Yes, rather than it being a coding issue in one of my objects, the transporter itself, a regular premade transporter, moves toward the block. This usually happens in the middle of the combat script with any of those enemies you see there, but I have no idea what could be triggering that...it's not like I built the battles around the #move premade transporters one space to the right command or anything.

Further compounding the weirdness: from what I have seen in my playtesting so far, it is only that particular transporter in that particular room (and one other one in the room directly south.) Other rooms in this dungeon and other dungeons appear to work fine. None of the others do that. It's always just those particular two.

Just...why?

Transporters store the direction of transportation in the same place objects store the direction they're #walking. I bet ZZT is somehow getting confused, mistakenly thinking that the transporter is #walking.

This bug seems to be triggered when an object dies, and when that object's stat index is one less than the stat index of the transporter. In other words, if you place an object on the board, then place a transporter on the board, the transporter will move if the object dies.

Solutions: Place transporters before placing objects that can die. Alternatively, (1) erase all transporters, (2) add something with stats (if it's an object, it can't die during the course of the game), and (3) re-add all transporters.

This bug also happens with blink walls. In City of ZZT, a blinkwall moves when you pick up the train ticket.

That is the stupidest fucking bug I have ever heard of.

Now tell me why the passage appears in Link's Adventure 1 on this board:

Was trying to figure this one out with DavidN. We haven't cracked it yet but he made some fairly good observations, hopefully from which someone else here can get to the bottom of this.

[19:00] DavidN: Well, it appears that it only happens if you come at them from the right... it isn't to do with any one object, because you can walk around and shoot them from the left and nothing ever happens - but either the top or bottom rows work, when you're trying.
[19:01] DavidN: And it's not always the first, sometimes you can be hurt by the first and shoot the second, sometimes you can shoot them two or three deep before you get a passage... this is a good one!

...

[19:03] DavidN: It seems to. In fact, this time I stood right at the edge of the bottom line and shot happily to the left for a while, then took a couple of steps back and continued, and that formed a passage... perhaps it's due to shooting a lion when it's on a certain column?
[19:04] DavidN: I now have two passages :)
[19:04] DavidN: Trying it again, I'm going to see if I can reproduce it...
[19:07] DavidN: Yes, it's to do with the position that you shoot them in. There are nine "bad squares", in the column two steps away from the right edge of the lions, that turn into passages if a lion is shot on them! Why that is, I don't know enough about the inner workings of ZZT to say... but it's to do with those tiles specifically.
[19:08] DavidN: I imagine you usually get them because it's a common reaction to clear the forest, then step away a bit and start shooting, they're in the perfect position for that. Only two squares on that column don't have the problem, the middle and bottom ones...

...

[19:15] DavidN: The bad tiles are... object-Forest, KevEdit opens a window when they're selected (unlike the other tiles which are just plain and go into the rotator-thing like normal walls and things). Data 3 is 57. I don't know what that means. I don't know what alignment of the moon caused ZZT to put them down like that in the first place, but that would appear to be the problem.