Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
printz

Preventing line-trigger hopping

Recommended Posts

I know that if a player runs fast enough, he can cross over walkover trigger linedefs without activating them. Under some cases these triggers could run a critical ACS script that mustn't be ignored. Here, in case the player hops over one linedef, I'll make sure there's another just beyond, so he trips on that and triggers that.

If the player is a vanilla Hexen Fighter with strafe-running aided by the mouse, how far apart do I have to put two similar walkover triggers, considering they're on straight directions (e.g. not slanted), to ensure the script's activation?

Does ZDoom fix this? Note that I'm making this Hexen map for vanilla, however.

Also, as for the spechits being overrun, I wouldn't worry, because here we have only 2 relevant lines...

Share this post


Link to post
printz said:

Does ZDoom fix this? Note that I'm making this Hexen map for vanilla, however.


ZDoom splits fast moves into more smaller sub-moves so it's much less likely that this happens - but in rare occasions with very fast moving objects it still can - not with players though.

As for the distance, it has to be larger than half the maximum running speed minus the player's radius at least. I can't say what's the max. speed of the Fighter is. 'I'm not sure if 8 is enough but 16 should do.

Share this post


Link to post

Thanks. Interesting topic.

I've looked up the FighterPlayer ZDoom wiki article and observed this part of code:

  Player.ForwardMove 1.08, 1.2
  Player.SideMove 1.125, 1.475
Here, and maybe in other places, I see that the running speed is multiplied by a greater factor than the walking speed (the strafed run is quite large btw), so fighter's running will be more than twice as fast as walking, right?

How fast is the base PlayerPawn max side running speed? I know that the max forward speed is 17 or 17.5, but the strafing speed could be different. If I consider the PlayerPawn side running speed 17 like the forward one, and decide to strafe-run with the Fighter, who's all faster, I'd get an effective speed of sqrt((1.2*17)^2 + (1.475*17)^2) = 32.325 which is larger than the player size! If the unmultiplied actual strafing speed is in fact always lower than 17 though, then there'd be no risk to get the fighter out of the level bounds...

Share this post


Link to post

All those values are acceleration, not speed so it's hard to tell. The fastest I ever got the DoomPlayer was more than 40 while testing some old wallrunning effect that's no longer present in ZDoom.

Share this post


Link to post

If you really want to be safe... Put a wall or something, 16 units behind the trigger linedef. Make the script-that-needs-to-be-run clear the way. No possibility to bypass the object then. Ah!

Alternatively, you could use obstacles that you can't jump above to make a little maze, forcing the player to twist and turn and preventing SR50+wallrunning accelerations.

Alternatively alternatively, spawn a Heresiarch within the player if he gets in a sector he shouldn't get into without having first activated the linedef. :p

Share this post


Link to post

Have Zedek materialize in :)

Some of the tips are cool, tho.

The concern for this was caused by the fighter, with whom it is quite easy to glide over portals, for example.

How does walkover triggering work anyway? When exactly does it fail? When it never intersects itself with the bounding box?

Share this post


Link to post
printz said:

How does walkover triggering work anyway? When exactly does it fail?



A line is triggered when the center of the player is in front of the line before the move and behind the line after the move and (and this is the important point!) the player actor touches the line.

So if the player is in front of the line and then moves across it but fast enough so that the resulting position does no longer touch the line no action is triggered.

In the end just another consequence of Doom's shitty movement code that didn't do anything right...

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
×