Earlier this morning, I got an idea on how I could implement moving 3D floors. Except they wouldn't be 3D floors as such. They'd be a use of polyobjects with walkable mid textures. A bit of experimenting (and finding a Doomworld thread from last year) soon showed me the futility of my idea - that being that impassable polyobjects will push you out of the way. However, since I'd also planned on implemting height variation effectively, I'd also been playing around with sector heights in my polygon control sector. This gave me an interesting discovery - if I set my texture offsets to lower than the control sector's floor height, I didn't need walkable mid textures. The polygon would spawn with that sector's height. Or, in other words, it was entirely possible to replicate oldschool 3D floors purely with polyobjects.
So, the only line flags I set on my polyobject lines were doublesided, lower unpegged, and clip middle texture. This made my polyobject completely unblocking while moving. Combined with the texture offset and a control sector floor height set higher than the target sector floor height, I had a polyobject that would push me out of the way if I got in front of it but not if I stood on top of it.
Now, some might call that mission success. But from the start, I was programming some scripts with friction in mind. Being on a moving floor that slides away from me isn't good enough. I have to move with the floor. And this is the tricky part. To know if you're on a floor, generally these days you'd use an "Actor Hits Floor" thing. But that doesn't work. So you need to refer to linedefs. The script expects all exterior linedefs of your polyobject to be facing out. The script that activates on crossing it then checks which side it was activated from before determining if the player is on or off. Next, you need to know if the player's Z value matches the floor's Z value. To do this, I check against a dummy thing inside the control sector. You could use GetSectorFloorZ in the same manner, but you still need a dummy thing inside that control sector for reference. If the Z height matches, the player is on the floor and thus friction should be applied.
Using SetActorPosition was bad. It removed all freedom of moving on a platform. To implement friction, I needed to alter the player's velocity. Finding the correct velocity value was trial and error. I'm sure there's some mathematically correct way to find out the correct velocity to apply based on referring to the Doom movement code and plugging it in to an equation, but as it stands dividing the difference of the floor's previous position to it's current position by 10.7 gets something very close to the correct friction on the platform.
All that remains is to set up your polyobject's move path. The path I've set up moves tri-directionally - it moves on X and Y as a polyobject does, and it moves along Z at the same time thanks to altering the control sector.
Oh, and because I don't like showing off anywhere near enough, it is also multiplayer compatible.
The example WAD can be found here.
LIMITATIONS
- You can't walk under the floor.
- Things get screwy if your polyobject goes below the normal floor.
- Rotational friction is not currently supported. There is no GetPolyobjAngle to compare against.
- I'm disabling view bob when setting the velocity. I quite simply haven't checked if leaving it enabled will bob your view as the platform moves.
- Removing the sector height modification and simply changing the texture offsets.
- To account for the now-missing height, anchor some invisible bridge things to the poly object.
- See if we can't get a flat rendering over that 3D floor. Transfer_Heights trickery? Non-solid 3D floor trickery?
