TILEMASTER2004 DATA V1

# Dungeon room map 278 turn script

# Notes:
# - This script is used to implement the walls moving once the entirely separate trigger to do so has been activated
# - The start script could have been included here as with some other turn scripts (by checking the script type), but in this particular case it was more consistent to include it with a shared start script file used by multiple rooms in this dungeon
# - This script depends on 2 triggers (implemented separately, of course), although there is actually also a third one involved (not directly referenced here).  They are the trigger to activate the walls moving, the separate trigger to deactivate the walls moving, and a trigger that closes the W entrance.
# - This was originally going to instead have a lowering ceiling, but that would have required textual descriptions due to the OH perspective so the moving walls that could be shown visually seemed like a better choice
# - The TurnResults command and Damage command "-DEATHCONT" option were added with this script because it was not displaying the end of game menu when the PC was killed by the walls (except when there were delays afterwards due to terrain); the interface would instead wait for an action with the PC at 0 HP and nowhere to move.  The root problem is that turn scripts are currently done AFTER the end of turn check for some reason and so such checks must currently be done manually with TurnResults ("turn" in the name referencing "turn-related results", not "turn scripts").  The -DEATHCONT option (which means "upon death continue") is necessary because otherwise the Damage command sets the script to done upon death (no other commands do this aside from the parallel Trap command) and so the TurnResults command could never get called without the new option.  Note that task notes were added to the engine to investigate an alternative solution to the order of turn scripts (if they have to actually be after the end of turn check) and for if the Damage command setting the script to done is actually necessary (investigating these before considering any changes is very important so as to not break other existing content).
# - The trigger to close the west entrance originally seemed a necessary part of the basic design of the walls moving, but during development it became clear that it is only really necessary to support the trigger that stops the walls from moving (and opens the entrance).  Without it, the PC could walk around the trigger to start the walls moving as usual, but then simple exit without any need for turning the moving walls off (making it so that the trigger to stop the walls from moving shouldn't be included, either).  With it, the PC must figure out to walk further to the trigger to stop the walls from moving.  The later trigger makes the overall puzzle of the room a little more complicated and interesting so the decision was to keep it.  In fact, the room would probably be a bit too simple without it and it seems a nice touch when the wall suddenly slams shut.
# - The trigger to stop the walls from moving was originally going to also stop them once they were already moving, but it turns out that due to positioning this was not necessary (it is not possible to step on a trigger to start the walls moving then get to the trigger to stop them before the later is covered up).  Therefore, it is only preventative, meaning, the walls will not start moving once this trigger has been activated (effectively, it disables the trigger to start the walls moving).  It would even have been possible to skip deactivating the walls from moving and just make it so it only opens the W entrance, but keeping it so it would also prevent the walls from moving seemed more interesting (allows walking across the room normally and such) and is more conducive to any future changes.
# - Although the trigger to stop the walls from moving deactivates the trigger to start the walls moving (by setting it to done), this does NOT mean that the pre-activation check here that the walls are deactivated (checking the trigger to stop the walls from moving) is unnecessary.  What the former accomplishes is only to stop the message, but the trigger to start thw walls moving is still simply set to done.  This turn script can only detect that the trigger is done, not that this is due to deactivation rather than having stepped on it.  The only way to differentiate between these is by also checking that the separate deactivation trigger (the trigger to stop the walls moving) was also done.
# - The check of the trigger to stop the walls from moving is currently only done in the pre-activation loop, not AFTER they are already activated.  This is because it is not currently possible to stop them once activated due to trigger positioning vs. PC movement (as mentioned earlier) so no check for that is currently needed.  If that ever changes, then a second check in the activated walls loop may be needed.
# - The walls that moved were originally erased with tile 0, but this was changed so that it simply adds new walls.  The reason for this was that it is possible to see behind the walls in several cases such as if the PC is crushed or if the PC moves off to the side (at the entrance) and seeing a wall makes much more sense than the empty tile.  It is a little unclear what would actually be behind the walls, but something solid makes much more sense than empty space.  Note that this seems to look fine for VM.
# - The commented-out debug messages used during development were analyzed, the result (including some minor changes that were made here and there) being that it seems best to leave them for any future use, it seems best to leave them as commented-out messages rather than converted to DBG commands (like some other turn scripts), they seem to be correctly structured and placed, and no others need to be added at this time given that they are currently really just for tracing pre-activation processing.
# - The start script replaces the bones tile with a crushed bones temp tile.  Although it would be logical to reduce the terrain cost, this is NOT done because the cost is currently at the minimum slow terrain cost of 1 so cannot be reduced further without it becoming non-slow terrain.  Note that while it may seem that no cost would make PC movement more synch'd with the the walls moving, actually the slow movement works fine; it is expected, necessary, and logical that the walls will move more than one increment at a time, and it looks fine when they do so.
# - Although all the important information should be contained in the notes here, it should be mentioned that the external doc 210308-Dungeons.txt contains some development details (although covers a vastly larger subject; the first reference found in a search for "walls" is in the 210624 entry, although much more focus begins in the 220927 entry)
# - A temp development note included a statement that ought not be lost for the sake of humor related to work on comments needing to be done at that time (the work itself is done, to be clear): [... all comments done except] the quick heading comments with the code itself (as in "# Process the tabby").

# Optional TODO:
# - An option that was originally considered was to have spikes come out of the moving walls as shown by a temp tile and have them cause damage if standing adjacent to them.  The first turn prior to actually moving would have been the tile change with the spikes and the damage if standing next to them.  The damage by being adjacent would have still happened each time the wall moved, but the wall would still move the same way it is right now (along with pushing the PC).  So this idea wasn't instead of the main moving walls approach, but rather an addition to it.  Note that there are some tile idea files with some possibilities for the temp tile.  That said, it may be better to keep the implementation more simple as it is now rather than adding this complexity.  But I do still like the idea quite a bit, one of the tile possbilities is pretty good and could be used, and it would help further differentiate this room from a certain famous scene in a certain famous movie :) (other existing differentiations being how to turn it off and such, the bones hint, no water, no creature, etc.)
# - An option that was originally considered for the trigger that turns the moving walls off and opens the W entrance was for it to be a more involved interaction about something to use on the wall (such as a small stone part to push in or as per the movies a lever in a bug-filled hole, possible abil check vs. damage/poison) with an abil check to find and/or use it.  Or another possibility was needing to know something like a code from somewhere else in the dungeon or a part of the statues story.  Whatever the method, a failure could lead to the walls being activated but maybe another attempt being possible before it was too late due to the position being 1 space further N or the walls taking an extra turn before they started moving.  In any case, this overall option is still a possibility to consider, but it is also likely to be better to just keep it the more simple, traditional "step here" trigger.  Note that another part of this idea was making the wall a temp tile with a little difference in it (refer to the external doc 210308-Dungeons.txt for details and to the tile idea files for some possibilities, at least one of which is fairly good).  And another part of the later was the possibility of a trigger to help notice that different wall (based on an abil check) (rather than just being up to the player managing to see the difference in the tile), possibly even from across the room (maybe when entering or maybe anywhere in the room, at least while it is still visible).
# - A lighter version of the previous would be to have the "step here" trigger include a message that you do something with the wall which would then mean the temp tile for the wall could be used (maybe along with a trigger to help notice it).  The most important benefit of this is that how to test the puzzle without the PC being killed becomes a little murky once the W entrance closes; testing positions earlier to get around the moving walls trigger positions is survivable (you may get pushed by the walls if they start moving but can exit E) whereas testing positions to find out how to open the W entrance is not (there's no way to get out when on this side of the room and the walls start moving).  Another lighter version of previous ideas would be to move the trigger 1 space N which opens up the possibility of potentially needing to deactivate the walls after they start moving (because then there'd be time to need to do so) or (for the same reason) having the walls take an extra turn before they started moving (maybe make an additional sound, maybe even a real sound rather than just a message).  Yet another would be the interesting matter of abil checks to use the trigger on the wall, which would mean even more if the player was having to try more than once when the walls were already moving or making noises.

# Script: Buffers
# LineID Command Arg1...N

SCRIPT: 75

# Start
0 DBG "DBG: Starting turn script"

# Pre-activation loop
10 NOOP

# Check walls activated
#0 M "DBG: Checking walls activated"
0 CheckTriggerDone 1 20

# Wait
#0 M "DBG: Trigger 1 not done; waiting"
0 WaitTurns 1

# Check walls deactivated
# - This was previously checked in the activated loop, but there is no way to get to the deactivation trigger once activated plus this needed to be checked here in any case
# - To be clear, the purpose of a separate deactivation check is that the trigger to deactivate is separate from the one to activate and there are really 3 overall states checked in this loop: activated (the above check), not activated but can be (keep looping), and not activated and cannot be because deactivated (the one handled here).
#0 M "DBG: Checking walls deactivated"
0 CheckTriggerDone 3 0

# Next iteration
#0 M "DBG: Trigger 3 not done; looping"
0 GOTO 10

# Walls activated
# - This skips into the loop at a later point to skip over actions that should not be done yet (e.g., "SetRedraw 1")
# - The only point of this section is to allow the debug message or the code could simply instead go directly to the line this does.  That said, it does also allow a little abstraction for the prior note and also allows other code to be added for any future purposes.
20 NOOP
#0 M "DBG: Walls activated"
0 GOTO 31

# Activated walls loop
# - Redraw is included as the end of the previous draw action
30 NOOP
0 SetRedraw 1

# Wait
31 WaitTurns 1

# Move based on current wall position
0 SetRedraw 0
0 CheckTile 28 1 1 40 -NOT
0 CheckTile 28 1 2 41 -NOT
0 CheckTile 28 1 3 42 -NOT
0 CheckTile 28 1 4 43 -NOT
0 GOTO 44

# Move 1
40 AlterTiles 28 1 1 9 1
0 AlterTiles 28 1 9 9 9
0 CCheckPos -POS 1-9 1 -TAG 50
0 CCheckPos -POS 1-9 9 -TAG 51
0 GOTO 30

# Move 2
41 AlterTiles 28 1 2 9 2
0 AlterTiles 28 1 8 9 8
0 CCheckPos -POS 1-9 2 -TAG 50
0 CCheckPos -POS 1-9 8 -TAG 51
0 GOTO 30

# Move 3
42 AlterTiles 28 1 3 9 3
0 AlterTiles 28 1 7 9 7
0 CCheckPos -POS 1-9 3 -TAG 50
0 CCheckPos -POS 1-9 7 -TAG 51
0 GOTO 30

# Move 3
43 AlterTiles 28 1 4 9 4
0 AlterTiles 28 1 6 9 6
0 CCheckPos -POS 1-9 4 -TAG 50
0 CCheckPos -POS 1-9 6 -TAG 51
0 GOTO 30

# Move 4
# - This is the last move and checks if the PC is crushed.  If not, the turn script simply ends (via the "BREAK").
44 AlterTiles 28 1 5 9 5
0 CCheckPos -POS 1-9 5 -TAG 60
0 DBG "DBG: Walls done moving, script done"
0 BREAK

# Move PC S
50 M "The wall pushes you south!"
0 Move S -SIMPLE
0 GOTO 30

# Move PC N
51 M "The wall pushes you north!"
0 Move N -SIMPLE
0 GOTO 30

# PC crushed
# - The TurnResults command and the -DEATHCONT option are necessary because turn scripts are currently run AFTER the standard end turn; refer to the header notes for more details
60 M "You have been crushed!"
0 Damage DEATH -DEATHCONT
0 TurnResults -DEATH
0 DBG "DBG: PC killed, script done"
