Rideable Moving 3D Platforms

[scroton]

Ah. I'm not very well versed in ZDoom netplay so I'll take Edward850's word for it. Hopefully a workaround is possible; if not there's two other great options to choose from.

[GooberMan]

It only clamps it hard for the first 2-3 tics (I forget which off the top of my head) and after that it only sets it to the velocity within a narrow window of velocity, allowing free movement.

That is not free movement. That is restricted movement. That method allows the player to move in any direction at a restricted speed.

but as Edward850 told me and looking at your example again, this seems a bit more multiplayer (as in Zdoom at least) friendly.

Velocity is a fair sight more predictable than a player's inventory state, especially when the inventory state is determined through script. There's still predictability issues as there's no formal way in the codebase for an actor to inherit something else's velocity (conveyors aside), but there's much less that can go wrong with just a velocity change.

I was just thinking have the model (being 2 flat planes representing the top and bottom) be spawned on top of the platform with no blockmap (I think) and have the script make it move along with the polyobject via SetVelocity. This would create a "3d polyobject" that can be shot and have decals.

As I said, thanks to inertia there will be drag and the model will not be synced correctly (especially after a stop/direction change). It would need to SetPosition every frame to ensure being synced, as well as SetVelocity to handle frame interpolation for rendering. Predictability for networking goes up in difficulty as a result of SetPosition though.

The 3D floor/polyobject combo should be perfectly fine for decals anyway, as long as there's a 3D floor to collide with the polyobject tends to do the decals correctly (although I haven't tested it with changing heights). The only thing that stops the polyobject looking completely solid is that there is no code to do a flat fill on the 3D floor collisions. This theoretically is simple enough as the source polyobject sector should already have ssegs created for the polyobject's interior, but rendering ranges from a bit involved in software mode to trivial in GZDoom.

[scroton]

That is not free movement. That is restricted movement. That method allows the player to move in any direction at a restricted speed.

No, unless the player's velocity is within a narrow window of the target velocity, the script does nothing--it does not alter their velocity. The window is narrow enough that as soon as they start moving they are out of the window and their velocity is not affected.

[ReX]

GooberMan has tweaked the code to allow the use of models that "ride" atop the polyobjects. As such, the visual limitations imposed by the polyobject's linedefs can be virtually eliminated. In effect, easily-implementable moving platforms have arrived on the DooM modding scene.

The floating & revolving islands in Half-Life Xen Chapter 15 are now eminently possible [skip to 4:05 of the video to see what I'm talking about].

[GooberMan]

I'll package up a third iteration for /idgames soon showing what ReX talks of.