player turned into lion by conveyor

NOTE: I HATE A LOT OF YOUR ZZT GAMES, SO WATCH OUT!

Moderators: Commodore, Zenith Nadir

Post Reply
User avatar
H1~~
1 full minit uv 1 secend mesiges
Posts: 72
Joined: Fri Apr 05, 2013 9:34 am
Location: Northeast Ohio

player turned into lion by conveyor

Post by H1~~ »

I was playing through an older, vintage-style advenute world-- part 2 of a series of 3 games, but I can't remember the name-- and going west through a small conveyor tunnel with conveyors on both sides when I bumped into a lion, and my player's char was replaced with the lion's char but in the same colors as the player-- I can't remember if it moved like the lion or just stood still-- and I got stuck as there was no input being taken from the keyboard.

I have not been able to replicate this bug.

Can anyone here explain to me what happened?
User avatar
Quantum P.
Level 17 Accordion Thief
Posts: 1433
Joined: Fri Sep 12, 2003 1:41 am
Location: Edmonds, WA
Contact:

Re: player turned into lion by conveyor

Post by Quantum P. »

Conveyors are known to be buggy, and under certain circumstances (around which I'm fuzzy) they can do things like delete stat objects.

Since keyboard input wasn't working at all, your end result must have been a player-colored lion (as opposed to a lion-charred player), because the player is what actually reads keyboard input. I've previously heard of conveyors deleting the player, but this is the first time I've heard of the player's color being transferred to something else.

I can think of a couple of plausible explanations:
  • When the conveyor moves tiles from one location to another, it's possible there's a bug in which the color is copied but not the element type.
  • Completely separate from conveyors, I know that ZZT will force the player's color to be 0x1F white-on-blue. It's possible that when this player-lion-conveyor interaction occurred, ZZT mistook the lion for the player for some reason (e.g., the lion's stat was at the player's stat index), and so ZZT reset the lion's color.
...but those are just speculation. Conveyors are weird.
User avatar
Dr. Dos
OH YES! USE VINE WHIP! <3
Posts: 1772
Joined: Tue Mar 11, 2003 12:00 am
Location: Washington

Re: player turned into lion by conveyor

Post by Dr. Dos »

Okay, thanks to reading up on Asie's Reconstruction of ZZT and some experimenting with KevEdit I have a much better idea of how conveyors work and break.

Image

Firstly, there's a bug with conveyors and drawing. Conveyors iterate over their neighboring elements to work on starting with the southwest and working counterclockwise around the conveyor. This is the same regardless of which direction the conveyor itself plans to rotate things.

When an element with stats is rotated, ZZT temporarily creates an empty in the tile the stat element was originally in. This causes an issue when you reach the end of that list of neighboring elements where that temporary empty won't be updated with whatever else should have been rotated to that tile.

Image

(The cyan conveyor is clockwise and the purple conveyor is counterclockwise.)

Visually, the two non-green gems seem to disappear when the bomb (or any stat element that can be conveyed) is rotated to these two points. However the red and yellow gems are still there. I have objects in the top left corner of the board endlessly checing #if any red/yellow gem and changing to a Y/N character appropriately. They always read "Y".

The visual error only makes it harder to figure out what's happening visually because while this display bug is happening, the two stats are always being swapped!

Image

Looking at this setup, as soon as the conveyor ticks, the bomb will be moved to the northwest and the lion to the west (but will be made invisible due to the display bug causing the temporary empty to be drawn instead). The two stats will flip. So our cycle 6 inactive bomb will instead be a bomb at cycle 2 with its fuse set to the lion's intelligence value. Similarly, the lion will now be at cycle 6 and with 0 intelligence as the bomb was inactive.

You can tweak these settings around and play with the results. Make the lion cycle 0 and the bomb will change characters to match its fuse but never tick down. (The gem is placed there so the lion doesn't wander away if it isn't cycle 0).

The stat order is actually relevant as the bomb must come after the lion for the swap to occur. Because of this, the swap can only happen once so there's no way to make the two switch brains repeatedly with each orbit around the conveyor.

You can also observe the stat swap with the fact that this can make the first element on the board something other than the player.

Image

Here the swap has occurred, lighting the bomb and making it the first stat. The cyan objects here are displaying Y/N based on the results of a #if alligned check. You can see that the two yeses intersect with the bomb element and not the player element.

Which leads to two things, player destruction, and TFing into a lion.

The player destruction bug is easy enough from this. A lot of ZZT's code assumes the first stat is a player. When the bomb goes off, the player caught in the explosion isn't seen as the first stat and so it's destroyed as a default behavior (which is why you can shoot and destroy player clones as well). The bomb of course is also destroyed and you're left with a softlock if you don't have a spare player in a corner somewhere.

For the lion, an easy setup is this:

Image

For reliability the lion is set to cycle 50 here.

By starting the game like this, unpausing by moving west, the conveyor kicks in before the lion can wander away. The stats are swapped and now the first stat will be a lion. The lion will do its lion thing and wander around pretty aimlessly since its new param1 is going be match the original player's param1 and be 0. Not that it matters if you manually adjust it because it's going to try and seek the first stat which is itself.

Eventually though, the wandering lion will decide to move onto the tile that has a player on it. ZZT will see this as a lion attacking the player and run the player hurt code, which runs on the first stat, which is the lion thanks to the conveyor. Part of that code is to force the first stat to change colors to the player element's default color. Thus you wind up with a white lion. If this happens with a normal player, that cycle 1 lion has a reasonable chance of immediately moving into the player at the start of the next cycle which will be when the actual player is invisible due to the display bug causing it to look like the player becomes a lion rather than a lion becomes a white lion.

Despite being very easy to purposely cause this bug, it ends up being a lot more rare in normal gameplay. It requires the player to be standing on a specific tile adjacent to the conveyor, a pushable stat element to also be on a specific spot, and for it to be a gametick where the conveyor gets to act (cycle 3 for clockwise, cycle 2 for ccw by default). In practice, the lion is going to be moving at cycle 2 and having a hard time getting it to land in the right tile just before the conveyor activates.

Sadly, despite being easy to reproduce by hand, it doesn't seem very exploitable. Swapping stats sounds pretty great, but you can only swap stats with stat elements that can be conveyed, which doesn't include objects (where changing code might be powerful) or passages (where changing destinations might be powerful).

tl;dr - Try not to move southwest of a clockwise conveyor or south of a counterclockwise conveyor: you may die.
Visit the Museum of ZZT
Follow Worlds of ZZT on Twitter

Apologies for the old post you may have just read.
zzo38
newcomer
Posts: 22
Joined: Sun Dec 15, 2019 11:25 pm

Re: player turned into lion by conveyor

Post by zzo38 »

Dr. Dos wrote: Mon Jul 13, 2020 9:20 pmSadly, despite being easy to reproduce by hand, it doesn't seem very exploitable. Swapping stats sounds pretty great, but you can only swap stats with stat elements that can be conveyed, which doesn't include objects (where changing code might be powerful) or passages (where changing destinations might be powerful).
I have figured out ways to set destinations of passages, described in ZZTPTT, but here are they written here:
  • Change the colour of the passage; it leads to the same board, but can lead to a different place on that board.
  • If there is initially no passage, you can create one by firing a bullet over stat water which has the passage destination and changes direction, leading into another stat water which again changes direction to the bullet dissipate into a wall and has a passage underneath; you can have more than one way to get there to make it dynamic. However, you can only set the destiniation once in this way.
  • If you have an existing passage, add another passage with the new destination, and set its direction to point to the old one, and make the new passage's stat index one after that of an object, and the old passage to have a lower stat number. Program the object then to get rid of the old passage (overwriting it with a fake wall), causing the new passage to move to its location (since the new passage now has the object's old stat number (because the old passage's stat number was lower than that of the object), causing it to move). With the correct colours and stuff, this can even be made unseen.
  • If a player is standing on a passage due to arrival and then walks into a transporter next to it, the passage will move but the stats won't move with it; if there is a stat fake on the other side, then the passage will inherit its stat, and if the player steps off and back on, now the destination is changed.
  • Fake it, by making two boards which are same except the destination of the passage.
(ZZTQED has "exchange stat" and "vector from stat" commands which are useful to implement the above; I think KevEdit doesn't, but maybe someone who uses KevEdit might add those commands if they find them useful. I know rabbitboots has added ZZTQED's "boardwalk" feature (and others) into KevEdit, so other features could also be added, too.)
I have set up a NNTP to discuss ZZT and other stuff.
asie
1 full minit uv 1 secend mesiges
Posts: 67
Joined: Sun Mar 17, 2019 4:55 pm

Re: player turned into lion by conveyor

Post by asie »

WiL asked for it, so here's a set of patches to the RoZ source code to fix both the "visual glitch" and "stat swapping/player turned into lion" bugs.
User avatar
H1~~
1 full minit uv 1 secend mesiges
Posts: 72
Joined: Fri Apr 05, 2013 9:34 am
Location: Northeast Ohio

Re: player turned into lion by conveyor

Post by H1~~ »

Thank you for your responses.
These are very detailed!
Post Reply