Dear community, have BETTER tri-directional moving floors

So. Another tech demo WAD from me. Has it really been that long since STARBOX.WAD?

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.
THE WAY FORWARD FROM HERE
  • 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?

Share this post


Link to post

Impressive!

I've been messing around with Walkabletexture polyobjects too at the time when they were made possible in zdoom. I came to the point where i could stand on it etc, but wouldn't move along with its moving. The script you made seem to work pretty well, only problem i noticed was if you went too close to the edge, it would activate the "off the platform" script, and cause me to stop moving a long the platform. Moving back in didn't always reactivate the platform script either, you might want to place the script activation lines a bit farther away from the platform than the actual visible platform lines are. Not sure if that is possible the way you've set up the polyobject atm without changing the actual walkable radius of the platform. But if you manage to change it to bridgeactors that make up the polyobject it would be easy to do.

GJ

Share this post


Link to post

I made it better! Here's the reference WAD.

So I solved the walking under it problem. Not by using bridge things. No, that would remove the arbitrary nature of polyobjects. I got to thinking - if the polyobject I was using was just transferring sector heights, what would happen if I applied a 3D floor to the polyobject control sector? The answer was that SHIT WOULD JUST WORK!

You can now walk over and under the walking floors. I've cleaned the scripts up a tiny bit, and applied the texture offsetting I was talking about. The polyobject's control sector height no longer changes one bit, however the 3D floor applied to it does. Textures are offset to match that 3D floor.

However, the linedef method is now starting to show its horrible flaws. Namely, if a polyobject moves and an actor crosses above/below it while standing still it doesn't trigger the line crossed behaviour. Not that anyone's had to care about such things before.

This is almost "right". I want to solve the hop on/hop off stuff. To do that, I need to remove the linedef triggers. Which means I need to have the transferred heights trigger the "Actor hits floor" thing specials. Feel free to experiment and contribute, anyone who can map and knows ZDoom well.

Share this post


Link to post

Dude, that's fucking boss. Kudos for that.

And now we need to wait horrible platforming sections in future wads. D:

Share this post


Link to post
CorSair said:

And now we need to wait horrible platforming sections in future wads. D:

not as horrible as platforming sections with platforms that don't actually carry you (Sonic Doom).

Share this post


Link to post

I'd like to hope they're used in a similar fashion to how Quake did it. Rather than going nuts creating jump puzzles.

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