I think blade of Agony is an amazing achievement - IMO, the only real successor to the original Wolfenstein 3D. I love playing it simply for the enjoyment of the game, but also I love unpicking it, trying to learn some of the tricks or just marvelling at the architecture or the amazing things that the game does with the GZDoom engine. Sure, it has some inconsistencies that are inherent with an amateur project; different resources obviously coming from different types of sources and having different styles is probably the most obvious, but that's the nature of a project like this, and it doesn't detract from my awed appreciation of the game.
Anyway, I was playing C1M4 - the one where you have to destroy the air defence weapons on a dam. It's a stunning map with lots of cunning stuff going on. It's one of my favourites from an aesthetic, story and technical standpoint. Even though, once you enter the area below the dam, it is (in essence) a fairly straight forward typical "base map", there is still something to marvel at around every corner (sort of a Wolfenstein music track reference).
So, the glitch - while playing the map, one of the lifts glitched out after riding it to an upper floor and it wouldn't move, effectively soft-locking the game. How did I cause the problem? I was riding up on the lift and decided that I wanted to go into a room on the lower floor before continuing on. So, as the lift was rising, I turned around 180° and as soon as the switch for lowering the lift came into view, I hit it - and that caused the problem.
On digging into it, the lift in question is raised by one script and lowered by another (script 7 lowers the lift, script 8 raises it) - and that is part of the problem. A script that has been run with ACS_Execute can only run one instance, but two separate scripts can both run at the same time. However, that wouldn't be a problem if if a slight change was made to the scripts.
These scripts rely on sharing a variable (down4) to "know" whether the lift should be allowed to move or not - i.e. if it is at the top and you try to raise it again by using script 8, the script reads the variable effectively does nothing. (Another lift uses the same kind of logic and presumably can exhibit the same problem.)
Spoiler:So, obviously what had happened was that I was running script 8 that was in the process of moving the lift up, and when I turned and hit the other switch, I ran script 7. Script 7 read that the down4 variable had already been changed by script 8 and "thought": "the lift is up, I'm allowed to do stuff". So, script 7 changed the down4 variable but couldn't reverse the direction of the floor because it was still moving (moving floors have to finish moving before they can be moved again). When the lift got to the top, it was in the upper position, but the down4 variable was set to the "the lift is in the lower position" state. So, when I pressed the down switch again to try to get the lift to go back to the lower floor, the logic (from reading the down4 variable) was saying "nuh uh, we're already on the lower floor" and wouldn't move. So, I was trapped on the upper floor with a lift that thought I was on the lower floor.
There are several ways to fix it but the simplest is where the "tagwait" instructions are in relation to the changing of the variable. The way that the scripts are set up, they change the variable, and then wait for the lift to complete its move (making the tagwait pretty redundant because all that can happen at that point is for the lift to complete its movement anyway). If, however, the tagwait came before the down4++; and the down4--; then the variable wouldn't change until the floor had stopped moving. So, if an attempt to run the opposite script was made while the floor was moving, the variable would not yet have changed and the logic would say "we're not at the top (or bottom in the other direction), so I'm going to do nothing". That would remain the case until the the floor reached its destination and then, and only then, would the variable change and allow travel in the opposite direction.
Of course, other fixes/changes are possible - the scripts could also be combined into one. A simple combination (still changing the tagwait/down++ order) would mean either button always reversed the position of the lift rather than having dedicated "always up" and "always down" switches. An additional variable (probably as an argument on the script line)could also be used to identify whether a switch was an "up switch" or a "down switch" and thereby retain the current dedicated direction switches. I'm sure that other options are available too. The main advantage of combining the scripts (with appropriate tagwaits) is that the switches wouldn't even try to run the scrips until the floor had stopped moving.
However, the simplest way to clumsy-lift-rider-proof the scripts does just seem to be to move the changing of the variable to after the tagwait (and I suspect that may have been the original intention, with a minor typo making the glitch possible).
I realise that Blade of Agony is unlikely to receive any updating , and this is in no way intended to be critical of anyone. It was just something that I noticed and I thought that it was worth digging into and reporting what I have found in case the principle, the information (and the point of using tagwait) might be useful to someone.