Rideable Moving 3D Platforms

[scroton]

I was working on moving platforms a while ago and then dropped it after getting a hacky version working. I worked on it again tonight and the result is the first demo release version. Might need some tweaks, but here it is:

GZDoom Version:
https://drive.google.com/file/d/0BxbbtKR5bll_VjBwWlJWYjFsdlk/view?usp=sharing

Note that this requires GZDoom with models enabled to see Map01, Map02 and Map04 correctly. Old version without new opengl runs it just fine.

Here's a rundown of what is featured in each demo level:

Map01 - model platforms and moving method 1
Map02 - model platforms and moving method 2
Map03 - sprite platforms and moving method 2
map04 - model platforms used as 3D floors, includes monsters

Zandronum versions also exist, though only map01 and map04 are functional. Models must be enabled to view them correctly. In 2.0 everything looks good online and offline, and it 1.3 stuff mostly works good except occasionally the platforms will ding you for 1 damage. This has been solved with a script that negates that occasional health loss, and won't be an issue unless there are things in your map that can cause exactly 1 damage.

Zandronum 2.0 Version:
https://drive.google.com/file/d/0BxbbtKR5bll_ZWJ2ZnZMN3Q4dW8/view?usp=sharing

Zandronum 1.3 Version:
https://drive.google.com/file/d/0BxbbtKR5bll_bDVoaU9jSmZZVmM/view?usp=sharing

There is a model skin template included in the file, marked so you know which side ends up where and what other sides it borders. The largest possible dimensions at standard Doom texture resolution are 128x128x128, and making a new platform is as easy as a couple of minutes in paint (or other editing program of your choice) and a tiny bit of math.

Future planned demo releases will include:

--Voxel versions of model used in Map01 (doesn't add functionality, and less easy for people to get different appearances than models with skins, but pretty for ZDoom)
--A couple more levels showcasing how existing functionality this can be used (trams, monsters on flying platforms, items on moving platforms, etc)
--Some more tweaking of numbers to make moving on a moving platform a little easier in method 1 (method 2 is pretty much they way it's gonna be.)
--While it should be pretty easy to follow in its current state, more documentation for those using this in projects.

/////////
//CREDITS
/////////

Model made by Revae, using obj. converted from voxel made by scroton
Model converted to .md3 from .obj by torridGristle
All other stuff by scroton

Feel free to use for whatever project you want; in fact you're encouraged to do so!
Please gibe credit (especially to Revae and torridGristle)!

/////////

Anyway hope you guys enjoy and put to good use.

[SyntherAugustus]

Method 1 seems a lot more natural. Method 2 has a weird forcefield effect when I try to get on when the object doesn't want me to.

This is pretty cool. Can you make an example with a swinging door?

[scroton]

Fiddled with them some more, method one is now even smoother. LInks in the OP have been updated.

BlackFish said:

Method 1 seems a lot more natural. Method 2 has a weird forcefield effect when I try to get on when the object doesn't want me to.

Yeah, method 2 is the earlier, less advanced version. Makes the player stay on by basically creating explosions all around the platform.

BlackFish said:

This is pretty cool. Can you make an example with a swinging door?

I can but it would be worse in every way compared to a polyobject door; for instance monsters could see through them without hacky workarounds.

BlackFish said:

Edit: Is the model determining the collision with the polygons or am I just imagining things?

The model is just there as a visual aid for the player, but it is exactly the same dimensions as the solid thing its actor spawns every tic. The stationary platforms just have a solid actor, and that's how the player can stand on them. For the moving actors, it actually uses a combination of decorate and ACS to constantly update the player's relevant directional velocities to simulate friction between the player and the platform.

[scroton]

Uploaded a fix to the GZDoom version involving a minor oversight of A_RadiusGive using a circular radius by default rather than a square radius. Link in OP has been updated.

[Jaxxoon R]

Script error, "platform_demo_5.pk3:decorate" line 216:
Unexpected token ','

Ooh no...

[scroton]

whoops, that will teach me to upload fixes without testing them first!

One moment.

EDIT: Aight, fix has been fixed and tested this time.

EDIT2: Also forgot to mention that there is a model skin template included in the file, marked so you know which side ends up where and what other sides it borders. The largest possible dimensions at standard Doom texture resolution are 128x128x128, and making a new platform is as easy as a couple of minutes in paint (or other editing program of your choice) and a tiny bit of math. OP has been updated.

[Ed]

I always fiddled around with the idea of having a short collection of model primitives with some basic animations / decorate included (door swing, rotate left/right ect). Then create some Doombuilder plugin with a basic skin coordinates editor that pulled textures from the existing map resources that generates a new MODELDEF entry for whatever model based effect you inserted into your map.

Of course, I can't code my way out of a wet paper bag, so I guess I'll keep dreaming.

[scroton]

Updated Zandronum 1.3 version with a script that checks if the player lost exactly one health (no more) and if so gives them back that one health to negate the occasional damage caused by the platforms. Link in OP has been updated.

[gemini09]

How complex can the platform models be?

Can it be a moving train, for instance? :)

I thought GZDoom/ ZDoom and Zandronum were perfectly compatible with each other, but it seems like that may have been a misconception on my part?

[scroton]

Updated these guys again. Things are now even smoother with regard to being able to move in the opposite direction the platform is traveling, moving while a platform is going up or down, and moving right when a platform stops moving.

Also scripts run by the player from items/painstates have changed; rather than the script needing a case which specifies the exact movement the script is instead passed the x, y, and z velocities of the platform the player is standing on and handles it from there. Script 200 handles movement from integers, script 201 handles stopping from integers (passed the same arguments as the movement one to stop that movement.) Old stopping cases have been retained in script 202 under cases 1 and 2. Scripts 300 and 301 act the same as 200 and 201 except that they accept fixed points by inputting the fixed point number you want * 65536. So for instance if you wanted to have -2.5, you would input -163840.

This means that, while it's really easy to control the platform movement via ACS, if you wanted you could now implement these platforms using only decorate (via A_ChangeVelocity, inventory counters and the above mentioned scripts) and copypasting the relevant scripts into your project.

Links in the OP have been updated.

gemini09 said:

How complex can the platform models be?
Can it be a moving train, for instance? :)

The ones included in the demo can only ever be cubes, but you could easily make a train out of several cubes, and the cube dimensions can be whatever you want per each so long as they are smaller than 128x128x128 (though you can actually go above this, the resolution of the skin will just be lower than vanilla texture resolution.) They can also be reskinned to appear differently very very easily with the template included in the file; pretty much a couple of minutes in paint is all that is required.

gemini09 said:

I thought GZDoom/ ZDoom and Zandronum were perfectly compatible with each other, but it seems like that may have been a misconception on my part?

ZDoom and GZDoom are perfectly compatible with each other except as far as some rendering things go and a couple of actor flags and properties associated with the differences in rendering. For instance GZDoom has dynamic lights and brightmaps, neither of which ZDoom supports (though it will run files that contain these, just without actually doing anything with them.) More relevantly to this project: GZDoom supports 3d models while ZDoom does not; ZDoom supports voxels and so does GZDoom, but only by converting the voxels into models on the fly.

Zandronum is a multiplayer focused port of ZDoom that has both software and hardware modes. The hardware mode supports 3d models while the software mode does not. Zandronum does not have any voxel support at all. It is based on an older version of ZDoom and so many of the newer decorate, acs and other features available in GZDoom and ZDoom are not available in Zandronum. So for instance with this demo, part of method 1 is accomplished in (G)ZDoom with the A_RadiusGive decorate action function but in the Zandronum versions this same functionality is approximated by spawning ripping projectiles which send players to a particular painstate.

[boris]

Ed said:

I always fiddled around with the idea of having a short collection of model primitives with some basic animations / decorate included (door swing, rotate left/right ect). Then create some Doombuilder plugin with a basic skin coordinates editor that pulled textures from the existing map resources that generates a new MODELDEF entry for whatever model based effect you inserted into your map.

Of course, I can't code my way out of a wet paper bag, so I guess I'll keep dreaming.

Been thinking about that, too. But I'd skip the model primitives, and put everything right into DB2. So you'd just select a bunch of 3D floors, hit a "export to model" button and everything gets created automatically: model, texture, and other files required by GZDoom.

[SyntherAugustus]

Are you going to create a tutorial regarding how to put these platforms in our own levels? I tried modifying the direction of the platform moving (setactorvelocity) and the player slipped off.

[scroton]

BlackFish said:

Are you going to create a tutorial regarding how to put these platforms in our own levels? I tried modifying the direction of the platform moving (setactorvelocity) and the player slipped off.

Yeah, there will be a full tutorial with comments in the code probably the next release, which will be sometime after I finish working on the next update for a mod I'm working on.

I can do a quick rundown though. It's a pretty simple process once you know how it works. I probably should have included some comments pointing people to things instead of just leaving it for them to go hunting for.

EDIT: This is for the GZDoom version, if you want a rundown for the Zandronum versions go here.

So once you modify the actor velocities for the platform in acs, then set it to a new (or existing since you're probably not gonna use the ones from the test) state where it will give the player the item it needs to keep them on (or spawn the projectile, in zandronum's case.)

For instance let's change this part in ACS

script 107 enter
{
SetActorState(1896,"MovingStop8");
SetActorVelocity(1896,0,0,0,FALSE,FALSE);
Delay(128);
SetActorState(1896,"Moving5");
SetActorVelocity(1896,-4.0,0,0,FALSE,FALSE);
Delay(128);
SetActorState(1896,"MovingStop5");
SetActorVelocity(1896,0,0,0,FALSE,FALSE);
Delay(128);

to

script 107 enter
{
SetActorState(1896,"MovingStop8");
SetActorVelocity(1896,0,0,0,FALSE,FALSE);
Delay(128);
SetActorState(1896,"Moving5");
SetActorVelocity(1896,-6.0,0,1.0,FALSE,FALSE);
Delay(128);
SetActorState(1896,"MovingStop5");
SetActorVelocity(1896,0,0,0,FALSE,FALSE);
Delay(128);

Once that's done, we go into decorate to the actor PlatformMobileModelMethod1 and find the Moving5 and MovingStop5 states, which look like this:

Moving5:
TNT1 A 0 A_RadiusGive("Mover5",36,RGF_PLAYERS|RGF_CUBE,1)
TNT1 A 0 A_SpawnItemEx("PlatformThing",0,0,0,0,0,0,0,SXF_NOCHECKPOSITION)
TEST A 1
Loop

MovingStop5:
TNT1 A 0 A_RadiusGive("Stopper5",36,RGF_PLAYERS|RGF_CUBE,1)
TNT1 A 0 A_SpawnItemEx("PlatformThing",0,0,0,0,0,0,0,SXF_NOCHECKPOSITION)
TEST A 1
TNT1 A 0 A_RadiusGive("Stopper5",36,RGF_PLAYERS|RGF_CUBE,1)
TNT1 A 0 A_SpawnItemEx("PlatformThing",0,0,0,0,0,0,0,SXF_NOCHECKPOSITION)
TEST A 1
TNT1 A 0 A_RadiusGive("Stopper5",36,RGF_PLAYERS|RGF_CUBE,1)
TNT1 A 0 A_SpawnItemEx("PlatformThing",0,0,0,0,0,0,0,SXF_NOCHECKPOSITION)
TEST A 1
TNT1 A 0 A_RadiusGive("Stopper5",36,RGF_PLAYERS|RGF_CUBE,1)
TNT1 A 0 A_SpawnItemEx("PlatformThing",0,0,0,0,0,0,0,SXF_NOCHECKPOSITION)
TEST A 1
Goto Spawn

You don't actually need to do anything here, since they exist already, but if not you would have to create them and give them an item to give to the player if one didn't exist already.

From the states it shows the items it's giving to the player are Moving5 and Stopper5, so go to them:

Actor Mover5 : HardStopper
{
States
{
Pickup:
TNT1 A 0 ACS_ExecuteWithResult(200,-4,0,0)
Stop
Use:
TNT1 A 0 ACS_ExecuteWithResult(200,-4,0,0)
Stop
}
}

Actor Stopper5 : HardStopper
{
States
{
Pickup:
TNT1 A 0 ACS_ExecuteWithResult(201,-4,0,0)
Stop
Use:
TNT1 A 0 ACS_ExecuteWithResult(201,-4,0,0)
Stop
}
}

The only thing that needs to be changed with these guys is the arguments they're passing on to their scripts, which are for the old velocities. So let's change those to the new velocities.


Actor Mover5 : HardStopper
{
States
{
Pickup:
TNT1 A 0 ACS_ExecuteWithResult(200,-6,0,1)
Stop
Use:
TNT1 A 0 ACS_ExecuteWithResult(200,-6,0,1)
Stop
}
}

Actor Stopper5 : HardStopper
{
States
{
Pickup:
TNT1 A 0 ACS_ExecuteWithResult(201,-6,0,1)
Stop
Use:
TNT1 A 0 ACS_ExecuteWithResult(201,-6,0,1)
Stop
}
}


And that's it! You'd need to do the same for all the other states that correspond in the changes to velocities you've made, but after that you're pretty much done.

Things get more complicated if you have to have it change direction without it going to a stop state (which you can definitely do with a new script) but if you don't want to mess with ACS much you can always just have a short 4 tic stop state before changing velocity.

Hope that helps. If you (or anyone else) has any other questions about this feel free to ask.

[SyntherAugustus]

I just did some more messing around and I'm close to adding it to my level I'm making. I figured out a formula that would come in handy to whatever tutorial you're making.

Formula: Movement speed X Delay = Units of travel.

Example.
Movement speed 4 + delay 128 = 512 units traveled.
Movement speed 8 + delay 64 = 512 units traveled.

In ACS the example would be.

Spoiler

script 107 (Void)
{
SetActorState(1896,"MovingOne");
SetActorVelocity(1896,-8.0,0,0,FALSE,FALSE);
Delay(64);
SetActorState(1896,"StoppingOne");
SetActorVelocity(1896,0,0,0,FALSE,FALSE);
Delay(128);
SetActorState(1896,"MovingTwo");
SetActorVelocity(1896,0,5.0,0,FALSE,FALSE);
Delay(128);
SetActorState(1896,"StoppingTwo");
SetActorVelocity(1896,0,0,0,FALSE,FALSE);
Delay(128);
}

In Decorate it would look like this.

Spoiler

Actor MoverTEST1 : HardStopper
{
States
{
Pickup:
TNT1 A 0 ACS_ExecuteWithResult(200,-8,0,0)
Stop
Use:
TNT1 A 0 ACS_ExecuteWithResult(200,-8,0,0)
Stop
}
}

Actor StopperTEST1 : HardStopper
{
States
{
Pickup:
TNT1 A 0 ACS_ExecuteWithResult(201,-8,0,0)
Stop
Use:
TNT1 A 0 ACS_ExecuteWithResult(201,-8,0,0)
Stop
}
}