Welcome to the ZDoom Forums!

[quote="randi"]Scripting is the only way to guarantee ordering.[/quote]

Thank you for clarifying.

Scripting is the only way to guarantee ordering.

[quote="Graf Zahl"]To me this looks at least that your actions are performed out of order so this is the first thing that needs to be checked.[/quote]

What I did was create a script '[url=https://github.com/SibTiger/TGRDM3/blob/master/Scripts/JumpPad.acs]JumpPad[/url]' which will handle the jumping pads that needs 'Thing Stop'. So far, this has solved all of my troubles with the jumping pads on (G)ZDoom's recent builds. I am still having a bit of difficulty with [url=https://zandronum.com/tracker/view.php?id=2697#c14692]Zandronum[/url] at the present moment, but - I am confident a resolution will happen soon.

Thank you for helping me :)

(this report can be closed)


[quote="Graf Zahl"]To me this looks at least that your actions are performed out of order so this is the first thing that needs to be checked.[/quote]
By chance, is there a way to have THING's perform on a sequential order or is scripting the only way?

To me this looks at least that your actions are performed out of order so this is the first thing that needs to be checked.

[quote="Graf Zahl"]If you refuse to use scripts and insist to depend on a defined order in which the sector actions are fired, you are in for trouble. I'm not surprised that this causes problems.
You really should do this in one single ACS script called from ONE sector action and not with such a messy setup.[/quote]

Alright, so I'll need to shift to a script rather than thing triggers.

I'll start looking into this soon; thank you for the help.

If you refuse to use scripts and insist to depend on a defined order in which the sector actions are fired, you are in for trouble. I'm not surprised that this causes problems.
You really should do this in one single ACS script called from ONE sector action and not with such a messy setup.

[quote="Graf Zahl"]Has this worked before?[/quote]
Yes, that is - if the map is [i]NEVER[/i] changed - at all. For example, once the jump pads are working, they can easily break once the map is changed. For example, the map presented in this topic, is a modified version of MAP03 in TGRDM3. All but one jump pad worked perfectly fine (though everything worked fine with GZD 2.1), but after I originally shrunk the map for a [url=http://zandronum.com/tracker/view.php?id=2697]bug report with Zandronum[/url], all but one jump pad broke. I don't know nor understand as to why this happens, the sector references containing such triggers never changed, yet - breaks.

EDIT:
I really wish I had something more useful to provide instead of a vague response, but this complication I have been having with using that function, I am merely left confused.

Has this worked before?

But whatever this is, Thing_Stop only does one thing: It sets the actor's velocity to zero. And that's all it does.

ZDoom.exe -iwad doom2 -file TGRDM3_v1-4a94ba4.pk7 MAP03.wad

Following up with [url=http://forum.zdoom.org/viewtopic.php?p=893996#p893996]this[/url] thread, I have ran into a lot of trouble with using 'THING_STOP' function. When ever I make a modification to a map that contains a THING trigger [Sector Actions >> Actor Hits Floor >> THING_STOP], they simply will not work correctly. I have attached a PWAD that contains an edited version of a map that demonstrates this very issue.
I am not exactly sure why this bug happens and what causes it to happen exactly.

[spoiler="Demonstration Jump Pad"][img]http://tiger.rfc1337.net/tmp/JumpPadBug.jpg[/img][/spoiler]

[b][u]Jump Pad Logic:[/u][/b]
[list]
[*] THING_STOP
[*] PLAYSOUND (jump pad sound)
[*] ThrustThingZ
[*] ThrustThing (Optional)[/list]

[b][u]Load Order example:[/u][/b]
[code]ZDoom.exe -iwad doom2 -file TGRDM3_v1-4a94ba4.pk7 MAP03.wad[/code]

[b][u]Required:[/u][/b]
[url=http://tiger.rfc1337.net/downloads/zdoom/morgenstern/devbuilds/TGRDM3_v1-4a94ba4.pk7]TGRDM3 Dev. Build[/url]
[attachment=0]MAP03.7z[/attachment]