Ceiling not moving to value after stopping a crusher

[Nevander]

So I have this code

Code: Select all

Ceiling_CrushAndRaiseA(12, 16, 16, 5);
Delay(35 * 8);
Ceiling_CrushStop(12);
Delay(1);
Ceiling_MoveToValue(12, 16, 144, 0);

and instead of stopping then moving to absolute height 144, it stops crushing and then that's it. It never moves to that height despite the crusher being stopped and it being told to go to that height. I want a smooth transition of the crusher stopping, then moving to that height but the ceiling never moves to the value.

This is on GZDoom 2.2.0

[Enjay]

OK, I think I know what's going on - but I don't know if it's a bug or not.

I tried the following test script:

Code: Select all

script 1 (void)
{
	print (s:"Moving tag 14.");
	delay(35);
	Ceiling_MoveToValue(14, 16, 144, 0);
	print (s:"Start crusher 12.");
	Ceiling_CrushAndRaiseA(12, 16, 16, 5);
	Delay(35 * 8);
	print (s:"Stop crusher 12.");
	Ceiling_CrushStop(12);
	//tagwait(12);
	Delay(35);
	print (s:"Move sectors 12 and 13 to 144.");
	Ceiling_MoveToValue(12, 16, 144, 0);
	Ceiling_MoveToValue(13, 16, 144, 0);
}

The first few lines work as expected. However, once the crusher has started, things get interesting.

The informative thing is that tagwait(12); in there. That tells GZDoom to wait until sector tag 12 (the crusher) has stopped moving before going on to the next step. With the script like it is above, the crusher ceiling never moves to 144 but the print message about moving sectors 12 and 13 gets shown and the sectors tagged 13 do move. In other words, the entire script works except the moving of the crusher to 144.

Now, here's the interesting part. If I uncomment the tagwait, the script never shows the "Move sectors 12 and 13 to 144" message and none of the ceilings move after the crusher stops. So it seems that, even though the crusher has stopped moving, GZDoom is still counting it as moving and is waiting for it to stop. If that is the case, it explains why you have been unable to move it after stopping it; moving sectors need to finish their move before they can be told to do a different movement. If the engine believes the ceiling is still moving, it cannot be moved to a new height.

Is this a bug? Maybe. Perhaps crushers need to remember that they are crushers once they have moved once? Frankly, I don't know.

[Nevander]

That is interesting... and I think you're right. I feel like it's not a bug, but rather the engine keeping that sector as a crushing sector and the script is only telling it to stop, not removing the "crusher property" from the sector. The only way to move it again is probably with another crush action.

For now I decided to find a delay that works well to always come close to the 144 absolute height in my script. A delay of 21 seconds seems to do the job, it crushes 4 times and then ends up at the exact height if nothing was crushed during the 21 seconds. If something was crushed, it ends up about 8 higher than 144. Not sure what could cause the height difference since this crusher moves at 16 speed up and down always regardless of something in the sector being crushed. Somehow being crushed speeds up the crusher ever so slightly so it's able to reach 8 more height before stopping.

Doom engine is weird.

[Enjay]

The only way to move it again is probably with another crush action.

Interesting thought and, after testing; yes, and no. I tried giving the ceiling a different crush action in the script after everything else had stopped happening. I set it up to have very different values to the speed of the original crusher (and I also tried a couple of different crusher types) so that I could tell if it had worked or not. It did start the crusher moving again but it looked like it was just moving according to the original crusher values, not the new ones.

[Graf Zahl]

The actual parameters for Ceiling_CrushStop are

// Ceiling_CrushStop (tag, remove)

If you add 1 as the second parameter, the thinker will be removed entirely.

[Enjay]

Hmmm... I just tried this:

Code: Select all

#include "zcommon.acs"

script 1 (void)
{
	print (s:"Moving tag 14.");
	delay(35);
	Ceiling_MoveToValue(14, 16, 144, 0);
	print (s:"Start crusher 12.");
	Ceiling_CrushAndRaiseA(12, 16, 16, 5);
	Delay(35 * 8);
	print (s:"Stop crusher 12 with extra parameter.");
	Ceiling_CrushStop(12, 1);
	delay(35);
	print (s:"Tagwait now.");
	tagwait(12);
	Delay(35);
	print (s:"Move sectors 12 and 13 to 144.");
	Ceiling_MoveToValue(12, 16, 144, 0);
	Ceiling_MoveToValue(13, 16, 144, 0);
}

And the script still stopped at the point where the crusher stops and did not progress on to the next stuff. (I had to edit my copy of ZSpecial.acs to get it to work too when doing it in DeePsea, I repeated it in GZDB with a UDMF map, it didn't complain about the number of parameters but the end result was the same; the script stopped at the tagwait.)

[Graf Zahl]

I checked again. 'Remove' is a game dependent parameter, because in Hexen this worked differently. So:

0: remain in Doom, remove in Hexen.
1: always remain
2: always remove.

[Enjay]

Nope, this still sticks at the tagwait:

Code: Select all

#include "zcommon.acs"

script 1 (void)
{
	print (s:"Moving tag 14.");
	delay(35);
	Ceiling_MoveToValue(14, 16, 144, 0);
	print (s:"Start crusher 12.");
	Ceiling_CrushAndRaiseA(12, 16, 16, 5);
	Delay(35 * 8);
	print (s:"Stop crusher 12 with extra parameter set at 2.");
	Ceiling_CrushStop(12, 2);
	delay(35);
	print (s:"Tagwait now.");
	tagwait(12);
	Delay(35);
	print (s:"Move sectors 12 and 13 to 144.");
	Ceiling_MoveToValue(12, 16, 144, 0);
	Ceiling_MoveToValue(13, 16, 144, 0);
}

[edit] However, it does work if I load the map into Hexen.[/edit]

[edit] Although I've just noticed that even though the crusher has stopped in Hexen, it still makes a noise while stationary. Once it has moved to ceiling height 144, the noise stops [/edit2]

[Graf Zahl]

Yes, I see. The function is broken due to a typo. Sorry. It says 'arg3' instead of 'arg1', but of course that will be changed now.

If you target 2.4.0, Ceiling_Stop should also work.

[Enjay]

No problem, glad it's been uncovered (please note my last edit above that I typed while you were replying: don't know if that's a problem or not).

Funny that the extra parameter was never in the Wiki. Was it added later?

[Enjay]

Hmmm... I can't get Ceiling_Stop to work either. It's not in ZSpecial.acs and I've tried adding it but the compiler balks because it has special number 276, according to the Wiki and it doesn't like number above 255. Am I doing it wrong?

I added this to my zspecials.acs:

Code: Select all

276:Ceiling_Stop(1),

And the version I have installed with DeePsea didn't like the high number (so wouldn't compile).

I tried again with the Zspecials.acs that comes with GZDB and the map saved but when the command was run by the map, GZDoom hung.

[Nevander]

Good god what did I just do.

[Enjay]

Got a bug squished, that's what.

https://github.com/coelckers/gzdoom/com ... 4a455d65e1

Thanks for fixing it Graf.

[Graf Zahl]

DeePsea

Don't use obsolete software!

Can you post the map that hung?

[Enjay]

Don't use obsolete software!

Can you post the map that hung?

1: I'm working on it... slowly.

2: Sure, attached. Hangs for me every time.