Jump Pad [ThrustThing(z)] Sets Player's Momentum

[Siberian Tiger]

Accuracy with jump pad's is crucial - as it is predetermined as to where the player should land and reach their destination target with enough efficient accuracy. However, it seems that jump pads in the modern era ZDoom, ThrustThing(z) merely appends the force along with the player's current momentum. With the player's momentum added into ThrustThing(z), this will leave inaccuracy as to where the player will land. For example, here's a demonstration using the Destination Unknown: .

What I would like to see is that the player's momentum is set accordingly and not appended when using ThrustThing(z). This will allow the player - regardless of their current speed wither walking, running, or step by step (tapping the +forward key) - to always land at the desired spot accurately.

Here's another demonstration of inaccuracy using an internal build of TGRDM3, public builds are available here:



EDIT:
Below is TGRDM3's demonstration Jump Pad logic:

ThrustThing:

ThrustThing_JMPAD.png

ThrustThingZ:

ThrustThingZ_JMPAD.png

[AlexMax]

There is more going on with Destination Unknown than just the thrust being constant. Since thrusting is additive, it stands to reason that hitting the mark should be easier (as long as you're accurate), yet as you can tell from the video I made it's actually nearly impossible.

My previous thread on the subject is here: http://forum.zdoom.org/viewtopic.php?f=4&t=48215

[Tribeam3rd]

If this is an issue with setting/adding momentum to the actor than a simple and easy fix would probably be to add an optional argument to thrustthing for set/add, thrustthingz has this already.

[Graf Zahl]

What I would like to see is that the player's momentum is set accordingly and not appended when using ThrustThing(z). This will allow the player - regardless of their current speed wither walking, running, or step by step (tapping the +forward key) - to always land at the desired spot accurately.

Obviously changing established behavior is a no-go, so it'd have to be an option.
But wait: That already exists! Just call Thing_Stop before ThrustThing!

As for 1.23.x: It is well known that these old versions had some bugs with velocity handling, so it's hardly surprising that some stuff that exploits this doesn't work anymore. Sorry, it's 10 years too late to do something about it. Too much has changed since then.

[AlexMax]

Obviously changing established behavior is a no-go, so it'd have to be an option.

I think what Tiger is asking for is for ThrustThing to get the same optional fourth argument that ThrustThingZ has.

[Siberian Tiger]

I think what Tiger is asking for is for ThrustThing to get the same optional fourth argument that ThrustThingZ has.

That would be nice to have as it would be clear as to what ThrustThing is doing with the player's current momentum.

Just call Thing_Stop before ThrustThing!

As I am merely using THING's 'Actor Hits Floor' action properties and not a ACS script, would this guarantee that Thing_Stop will always execute first before ThrustThing(z) takes effect or is it a coin toss and unpredictable as to what starts first?

[Siberian Tiger]

I seem to have hit a nice issue where - if I add two THING's with "Actor Hits Floor" using the action 'Thing_Stop's at two different sector locations, it can cause one sector to completely ignore the ThrustThing(z) instructions. If I remove the THING that contains 'Thing_Stop' and re-add it, the other sector containing the 'THING_STOP' THING will then ignore the ThrustThing(z) instructions - despite that it previously worked.

Will I need to abandoned THING's containing "Actor hits floor" sector and go hope that ACS resolves this issue?



EDIT:
The ACS idea will not suffice as I would need more arguments than what is allowed, which it seems to be three. I would need these types of arguments: Force for ThrustThing, direction for ThrustThing, force for ThrustThingZ, Sound toggle, and lastly THING tag for host sound, atleast this is what I can think of at the present moment of what I would need - if I switched from THING actions to ACS. ACS would not suffice for this sort of task.

I have uploaded a gutted version of TGRDM3 which only contains one map with the affected issues with the jump pads not working correctly. Perhaps I am doing something wrong and made a mistake somewhere. However, it is better to have additional pair of eyes and check my work and make sure that everything is okay.

TGRDM3: LETS MAKE JUMP PADS GREAT AGAIN!!! edition

Directions:

• ---

• Once GZDoom loads the PK7, go to the console and goto map 'AMISERY'

  Code: Select all

  map amisery

• From start, go to the outside and head towards the other building.
• In the building, go to your left and you should see the orange jump pads.
  • These jumping pads are broken and should be examined.

EDIT: Links expired

[Siberian Tiger]

Following with the previous post, I removed all of the THING's that contain the THING_STOP instruction and re-added them back to the map, now everything works. I don't understand as to why, and I don't know if this is a bug that I should report or a human error on my part. If the Dev's could take a peak at this and let me know what is wrong or if I should make a post somewhere, I would appreciate it.