[r4129] Polyobject + 3d floor shenanigans

[GooberMan]

Alright, so another use case for the 3d floor/polyobject research I did is a small spinning fan puzzle. I've set the polyobject up as you'd expect - poly lines are explicit, don't block anything, and have their blocking heights defined by a 3D floor control sector. It's being placed inside some 3D architecture in the world. The spawn spot is in one sector, and the polyobject extends out and rotates through four other sectors.

The player's height checks are getting confused. Sometimes, you're blocked by mid air. Other times, you're standing on it. Other times still, you can jump right through the poly object.

Why is this a bug instead of a "Just keep the polyobject in one sector you moron"? Well, try shooting at the fan blade. Give all and use more than your pistol. None of the weapons have an issue impacting with the fan in the right place. A restriction is one thing, but inconsistent behaviour is another.

IMPORTANT NOTE: The enter script alters your jump height. You can jump up in to the fan with ease.

[Blzut3]

This is exactly the same reason why standing on midtex polyobjs is not supported. If you have no x/y velocity the floorz (and I guess ceilingz) is never updated since the geometry is assumed to be static. I can't find how to force an update without the player falling through, so that's why the patch was never finished.

Edit: And actually, some time after I made the changes I noticed you can still get the broken behavior on mid tex poly objects by flying over them, waiting for your velocity to drop to zero and then falling. I just decided this case is probably rare enough that it isn't worth removing the existing feature over.

[GooberMan]

I dug through the code, and finally found the offending block in P_XYMovement in p_mobj.cpp:

Code: Select all

	if ((xmove | ymove) == 0)
	{
		if (mo->flags & MF_SKULLFLY)
		{
			// the skull slammed into something
			mo->flags &= ~MF_SKULLFLY;
			mo->velx = mo->vely = mo->velz = 0;
			if (!(mo->flags2 & MF2_DORMANT))
			{
				if (mo->SeeState != NULL) mo->SetState (mo->SeeState);
				else mo->SetIdle();
			}
			else
			{
				mo->SetIdle();
				mo->tics = -1;
			}
		}
		return oldfloorz;
	}

Commenting out the return there lets the code fall through to the normal X/Y velocity checks.

However, that sounds like a bad idea to just blanket do that for everything. It seems to me that it'd be better served by an actor flag that says it should always perform those checks - put the check in that if condition and it won't even need to go in that block. And also it means that anyone that wants that functionality needs to go in to DECORATE to do it - no need for whacky compatibility options later on down the line. I don't know what other behaviour would be exposed by always performing movement code on something with 0 velocity, but my initial checks show off nothing out of the ordinary (except for the obvious slower code execution time).

I assume 3D midtex would be an entirely different solution. But honestly, I won't ever find a need for polyobjects with walkable midtex. This sector height transfer method solves something 3D midtex doesn't - every gap inside a polyobject has a solid floor.

[randi]

Fixed/added in r4192.

[GooberMan]

This makes me happy in the pants.

[Blzut3]

Looks like I need to add finishing the 3d mid tex polyobj support to my list of things to do.

[Graf Zahl]

Bumping this to say that this (Un-)fix was the cause of an endless amount of misplaced items I recently experienced in some maps.
I finally was lucky to have found a map where the effect was controlled enough to debug.