Confirmed Moving intangible from bottom FOF can launch players

[sims]

I wasn't quite sure how to title this one so bear with me.

I created a continuously moving FOF that's intangible from the bottom. If the player walks into the bottom of the FOF when it's on the ground and jumps, they'll be launched high into the air.

The forum's uploader isn't working for some reason so here's an imgur gif:

edit: now imgur's failing to work but after doing a quick test it does happen in 3D mode as well.

 

[SANICBOOM644]

Aren't intangible Fofs not supposed to touch the ground?

 

[Mystic]

Well this bug makes it obvious that the situation clearly wasn't checked for when implementing it. That doesn't mean it's not a clear bug and shouldn't be fixed.

 

[wolfs]

For reference: this bug was caused by this merge request. Reverting it fixes the issue, though I still have no idea which part caused this.

 

[toaster]

Hey Wolfy! Try not to say you don't understand something on the forums, because that's very good bait for me to get hooked on a problem and forget to shower.

This is the first time I've ever looked closely at the code. Line 2068 of p.map.c seems to stand out pretty hard - that "if (onfloor && !(thing->flags & MF_NOGRAVITY) && floormoved)" check is too lenient for pmomz to be applied, considering the fact that the section of code just beneath it allows you to "step up" inside FOFs once your vertical midpoint is above their vertical midpoint, which is caused by whatever function adjusts floorz and ceilingz for FOFs, which is somewhere in p_mobj.c and has a fairly obvious name I can't remember right now.

The thing is that because this check is so lenient - and doesn't prohibit being stepped up, which will technically register you as onfloor - the step up slingshots you. I have no idea how to make a more lenient check that doesn't allow for you to fall through the FOF, though, without avoiding the pmomz-setting hack done there and instead adding struct variables to sectors that handle the dy/dt of the movement of their planes.

 

[Monster Iestyn]

Actually it might be more simple than that - by my own examination, P_IsObjectOnGround returns true if the Object is on or below the ground (or rather, the Object's last calculated "floor" z position, which is assumed to be the ground). When inside such an FOF and above the middle your floorz becomes the FOF's top, so you could be counted as "on ground" in the pmomz handling function, in which case your pmomz then becomes the difference between your position and the top of the FOF (this is how it normally tries to calculate how much the floor you're standing on has moved, but because you're below the actual ground to begin with the assumptions used fail entirely). Depending on how large this difference is, your momz could well be increased greatly, which is no wonder you get thrown upwards like a rocket.

I'm still convinced the pmomz fixes don't actually work except when you least want them to, such as being crushed by the floor crushers in ERZ1 (resulting in you rocketing into the ceiling during your dying "jump").

 

[toaster]

No, that's part of the issue. If P_IsObjectOnGround returned false unless z == floorz (or z + height == floorz), you'd clip through anything that was going upwards. Try it yourself and see!

 

[Monster Iestyn]

I wasn't saying P_IsObjectOnGround was at fault necessarily, though I probably didn't make that clear. What I do think is up is that the pmomz is supposed to be set to the difference between the old and new positions of a plane, but is actually set indirectly via the Object's floorz and actual z. When the Object wasn't actually standing on the plane in the first place this doesn't give the expected result though.

 

[Monster Iestyn]

Hey Simsmagic, does this bug still occur at all as of 2.1.17? I think we included a fix for it, but I don't know what level's being tested in the gif so I can't check for myself.