[ZScript] 3D Platform Actor (v2.2b)

[Fishytza]

The getting "cut open" part is a known visual bug that happens independently of the platform code. I've reported it a while ago.
viewtopic.php?f=2&t=75529

I find it more troubling you seem to be getting stuck somehow when pushing the crate? I guess it's still a little rough.
EDIT: It could be that that particular line portal is badly set up. I managed to get stuck in the wall while hugging it when crossing that portal. Also, pushing any +PUSHABLE actor through that line can get you stuck while pushing it. Oh, boy.

[Fishytza]

[EDIT: July 15]
It might get buggy at this point, I recommend you wait until the next release. Trying to get this to work isn't easy.
[EDIT: July 26]
Try it out if you like.
[/EDIT]

Okie-dokie. We now have platforms that can carry other platforms and/or be pushed around by players.
In other words, pushable crates that can carry things and other crates.

The testmap's line portals should be less problematic as well. There are two stacks of crates with monsters on top with more crates on top of those etc. Try pushing them through the portals. (I managed to get the arachnotron stuck in the wall trying to push them through but I consider that negligible).

In order for a platform to be carried by others, give it the +FCW_Platform.CARRIABLE flag.
So for a crate, the code should be like this:

Code: Select all

class TESTPushCrate : FCW_Platform
{
	Default
	{
		Radius 48;
		Height 80;
		+PUSHABLE;
		-NOGRAVITY;
		+FCW_Platform.CARRIABLE;
	}

	States
	{
	Spawn:
		MODL A -1;
		Stop;
	}
}

[Fishytza]

At the moment it should be stable enough, we have platforms (crates) that can carry other platforms (also crates).
We have platforms (crates) that respond to velocity based movement - meaning they can be pushed around.
Platforms in general can be gravity bound (like the crates) and if it's following a path of interpolation points, can be pushed around by the player and it will course correct itself.

What's not perfect is having a stack of crates and other passengers being pushed through non-static line portals.
Static ones work flawlessly.

Oh yeah, I'm dropping the "faux 3D polyobjects" in the title since we're past that point.

[Fishytza]

Released v1.1.0

In addition to all aforementioned stuff, there's a new property "AirFriction" for nogravity-pushable platforms, so that they don't fly forever until hitting a wall. And four util functions for ACS.
SetAirFriction(), GetAirFriction(), GetOptions() and GetCrushDamage().

The last two I added for the hell of it.

[22alpha22]

Alright, I've tested out the new update and most everything is working well, just a couple of small issues I've found with pushable platforms (crates).

1: They don't seem to respect their friction property, when pushed, they slide across the floor and lose velocity rather slowly regardless of what I set their friction to. For now I worked around this by overriding Tick() and adding an XY velocity scale function, not perfect but it works as a stopgap for now.
2: For some reason I can't push the crates off of edges, I've tried adding the DROPOFF flag and it didn't help, they just will not go over an edge at all. I can push them off of each other and other actors but not sector edges.

Aside from the two issues I found above, everything seems to be working well, amazing effort and job overall, well done!

[Fishytza]

The ground friction logic should be the same as with any actor. (By ground friction, I mean when they lack the NOGRAVITY flag that's when Actor's Friction property should do something, if they have NOGRAVITY, it's the platform's AirFriction instead.)

It works on my end; I just tested it. Keep in mind that for ground friction the sector's own friction (which can come from a [wiki]TERRAIN[/wiki] lump definition or through [wiki]Sector_SetFriction[/wiki]) also factors into it.

As for the dropoff issue: How? The testmap's pushable crates can be pushed off of tall ledges (like the pool test)
And I can go to the demo map (MAP01), summon a TESTPushCrate actor and push it into the water below.
Or better yet Doom 2's MAP24 The Chasm, summon a TESTPushCrate and push it into the slime pit below.
And just to be sure, I loaded this with Doom as the IWAD, started E1M1, and pushed the test crate up and down the stairs where the green armor is. And off one of its ledges.
So, I have no idea how you're even having that issue.

I'm sorry, I can't reproduce those issues you mentioned.

[Fishytza]

Okay, I might have an idea about what's going on with the dropoff issue.

Are you using any compatibility options? Because when I set compatibility mode to "Doom" or "Doom (strict)" I can't push the test crate over any edges. Specifically, inside the "Actor behavior" submenu it's the "Monsters cannot cross dropoffs" option set to "yes". Set that to "no" and try again?

[22alpha22]

I've done some more extensive testing and I've been able to determine that the crates only ignore ground friction when summoned via the console (which is how I had been testing them), when placed on the map with a map editor, their friction works as expected.

I'm still having trouble pushing crates off of edges. I've attached an extremely stripped down version of my project that only includes the crates and tiny cut out portion of a map I'm working on. If you load it up, try to push the crates off the edge into the water. You can summon more crates by summoning "AlphaUACCrate1". Any summoned crates via the console will demonstrate the friction bug.

[Fishytza]

Ok! For some reason the culprit was this line in the "AlphaCrate" actor

Code: Select all

MaxStepHeight 0

Comment out or remove that and the dropoff and friction issues should be resolved.
(And I know it's that because setting "MaxStepHeight 0;" in my test crate produced the exact same issues.)

[22alpha22]

Yep that fixed it, everything seems to be working properly now, thanks so much!

[Fishytza]

You're welcome.

[doomzie]

First off, this is really cool and I admire the work you've done. Quite a bit of coding I see.

I enjoyed digging through your demo map trying to see how this magic works. I could not really figure out the test map, that one was totally weird and not working for me (not really). The demo map is clear though. Those Archviles on those skull cubes. Nasty. Sweet demo map. Thanks for taking the time to demonstrate your Actor in a demo map.


I'm now at a point where I've really digged into the features, without looking at the ACS functions. Just through the editor. There's really a lot that I like and that's why I tried to test it extensively. I mean, it basically works! Meanwhile learned about MODELDEF, .obj models and pitch/roll rotation.

I'm still quite new and in full learning mode, but if I understand this correctly, the main difference here is that your Platform Interpolation Point provides the ability to put enemies and items on models. Without your actor class this is not possible, right?

This is really cool.


I do have some questions and some feedback for you, if you don't mind.

Is there any advantage using your actor in the editor itself, since the lack of a visible pathway between the Platform Interpolation Points is quite a problems for elaborate paths. As far as I can tell, you can do every type of path (pitch/roll/point) with the standard Interpolation point as well, right? Or is there a situation where you have to use your actor in the editor (for pathways)? As long as the model inherits from your class, you can use regular interpolation points, right?

Take below feedback as an appreciation for the work you've done, and I hope maybe you want to have a second look at some things (or provide some feedback at least).


I've played around with this for several days to see how well it works and I've noticed the following issues:

- Player/enemies/items do not fall off gracefully when a model is pitched or rolled. It looks very weird.
e.g. player trying to jump off a rolling/pitching cube causes the player to suddenly stand higher, slightly being blocked even for a while, instead of falling

- When a cube is pitched towards another cube, it seems to cause some force feedback making it difficult to get on or blocking enemies from getting on the cube
it's quite a significant effect, this does not happen when a cube is rolled (or point angled) towards another cube (model)

- Enemies seems to walk slightly outside of the model boundaries, which looks wrong, but also causes them to be thrown off or picked up if another model passes along the boundaries

- Sometimes enemies are no longer on the model, but just walking around in the air wherever they lost connection to the model somehow (most likely from some interaction somewhere)

- It seems that even when models are set to not clip issues still arise when interacting with crossing 3D floor sectors that move up and down
is it advised to only use models when pathways cross ? sometimes the model gets partly stuck in the 3D floor and then moves on, it's just weird
I personally experience issues as soon as clipping is set and models fly around a pathway that crosses with other models.
Sometimes it clips well, other times weird stuff happens.

- I've noticed there's probably specific code that allows a model to "hop/jump over" a crossing 3D floor sector when the pathway is almost clear
the model does not stay blocked until the last pixel is cleared, it already forces itself over when the 3D floor is almost gone. Is there any way to disable this behaviour? It only happens when the path is linear and on the same height, if you slide a cube diagonally against each other it waits until the last pixel to move forward.

- It seems enemies do walk onto platform (models) that connect to their floor, but I'm not sure if they are really aware there's a platform there. I seem to get the impression that they walk on there only by accident/sporadically (possibly related to sometimes walking outside the boundaries of the model ceiling). It would be good to get a confirmation from your side that they do see the platform and will walk on it to get closer to you. It's just not very clear. I suspect there's an issue.

- I've learned how difficult it is to have perfect placement of (Platform) Interpolation points to makes models move to a pixel perfect exact location (with clipping on), but I'm managing better now. I wonder how to pros are doing this. The first interpolation point is supposed to be at the center floor of the model? I suffered quite bit to find out where to position interpolation points when using roll/pitch/point angle.

These are the things that are most noticable to me after testing your Actor class for several days.

So, basically to have regular items (like torches) stand on your model, could you do it via a work-around, like define a new actor based on the torch actor, but add the necessary flags to it (CANPASS, ...)?

Also one more note, I've done some testing with enemies on flying models and damn those b*tches are incredibly accurate no matter the speed, rotation and distance (as long as you don't pitch or roll of course)

https://imgur.com/a/HnbsBKG

[Fishytza]

...the main difference here is that your Platform Interpolation Point provides the ability to put enemies and items on models.

No, that would be the "FCW_Platform" class. -- Carrying/moving those other actors, that is.

Is there any advantage using your actor in the editor itself, since the lack of a visible pathway between the Platform Interpolation Points is quite a problems for elaborate paths.
As far as I can tell, you can do every type of path (pitch/roll/point) with the standard Interpolation point as well, right? Or is there a situation where you have to use your actor in the editor (for pathways)?
As long as the model inherits from your class, you can use regular interpolation points, right?

The "Platform Interpolation Point" is more there for convenience than anything else really. It allows time units in seconds and tics (because I don't like octics) and also setting angle, pitch and roll is all under one tab; with the old Interpolation Point class the "pitch" argument overrides the pitch you set in the "Properties" tab.
The downside, as you noted, is that there is no automatically projected path for all of them at once. I don't know if it's even possible to do that with custom classes in UDB.

But you can still use the old Interpolation Point class just fine.

- Player/enemies/items do not fall off gracefully when a model is pitched or rolled. It looks very weird.
e.g. player trying to jump off a rolling/pitching cube causes the player to suddenly stand higher, slightly being blocked even for a while, instead of falling

There is a "Pitch/roll changes don't affect passengers" option if it's causing trouble for player jumps in your setup.

- When a cube is pitched towards another cube, it seems to cause some force feedback making it difficult to get on or blocking enemies from getting on the cube
it's quite a significant effect, this does not happen when a cube is rolled (or point angled) towards another cube (model)

I'm not sure I understand what you mean here.

- Enemies seems to walk slightly outside of the model boundaries, which looks wrong, but also causes them to be thrown off or picked up if another model passes along the boundaries

GZDoom's actor collision is still box-shaped. And that box doesn't rotate when an actor changes its angle, this is true for all actors. If eg. you're using sphere-esque models of course it's going to look wrong.
Also, it's intentional that a platform can pick up actors from another platform if close by.

- Sometimes enemies are no longer on the model, but just walking around in the air wherever they lost connection to the model somehow (most likely from some interaction somewhere)

Yes, that can happen when there are passengers on top of each other. When the platform loses track of them they can get stuck in each other in midair. I'm not sure how to handle that.

- It seems that even when models are set to not clip issues still arise when interacting with crossing 3D floor sectors that move up and down

I can't reproduce this issue on my end.

is it advised to only use models when pathways cross ? sometimes the model gets partly stuck in the 3D floor and then moves on, it's just weird
I personally experience issues as soon as clipping is set and models fly around a pathway that crosses with other models.
Sometimes it clips well, other times weird stuff happens.

To be honest, without a small test sample I'm not sure what I can do about that. -- I guess it's for future considerations.

- I've noticed there's probably specific code that allows a model to "hop/jump over" a crossing 3D floor sector when the pathway is almost clear
the model does not stay blocked until the last pixel is cleared, it already forces itself over when the 3D floor is almost gone. Is there any way to disable this behaviour?
It only happens when the path is linear and on the same height, if you slide a cube diagonally against each other it waits until the last pixel to move forward.

Try setting "MaxStepHeight 1;" in your subclass. That seems to do the trick for me.

- It seems enemies do walk onto platform (models) that connect to their floor, but I'm not sure if they are really aware there's a platform there,
I seem to get the impression that they walk on there only by accident/sporadically (possibly related to sometimes walking outside the boundaries of the model ceiling).
It would be good to get a confirmation from your side that they do see the platform and will walk on it to get closer to you. It's just not very clear. I suspect there's an issue.

The platforms are just actors as far as your typical monster is concerned. They can't step on a platform in the same way they can walk up some stairs. If they come across a platform, they bump into it like bumping into a barrel. I used to have a workaround that involved even more once-per-tic BlockThingsIterator searches - they were expensive and didn't work half the time so I cut it. I didn't consider it a priority.

The first interpolation point is supposed to be at the center floor of the model?

Yes because when activated the platform will warp to the first point before moving normally to the next one. This behavior was copied from GZDoom's PathFollower classes.
However there is a "Interpolation point is destination" option that makes the platform travel normally to its targeted point instead of warping to it.

So, basically to have regular items (like torches) stand on your model, could you do it via a work-around, like define a new actor based on the torch actor, but add the necessary flags to it (CANPASS, ...)?

Yes, decorations need CANPASS or they will fall through the platform, (literally vertically noclip through it) and this is an engine quirk.
You don't really need to define a subclass, you can use [wiki]SetActorFlag[/wiki] to give actors of interest on your map the CANPASS flag.

[doomzie]

Thanks for your feedback.

I quickly cut out my 3d platform testing from my map and made it into a seperate vanilla map, so you can have a look yourself at the issues I'm seeing.

I incorporated your feedback already in the comments in my test map, to show I'm aware of what you're saying. However for some issues, as you requested, you will need to have a look in the map. If you take some time to walk around and watch the behaviour of the skull cube (model) versus 3D floors or how enemies behave on them or against them, et cetera, you should fairly quickly notice oddities.

I'm using two .obj models. A basic 200 pixel cube (with skull texture) and an actual skull (with pink/white texture). The pink skull is mostly for show and some testing. I understand it has a cube hitbox around it and is basically the same as the actual cube model, so it looks like enemies walk on a cube (this is fine). Anyhow, the main model of interest is the simple cube that I exported from UDB itself. The skull is from some 3D site.

The intention is to have perfect control over the moving/rotating cube model with/without enemies, clipping or no clipping against models/3D floors and so on for introcate pathways. The cube is basically a dynamic platform that needs to move to regular floors in different ways. Some really nice dynamic effects can be achieved. I love it. This works really well, except for the mentioned issues that are displayed in my test map.

I recommend to change player start around the map so you can see initial behaviour of the 3D platform (with enemies) in that area. Otherwise you'll likely miss it.

I do not know how to attach a file here, so I had to resort to this:
<link removed>

Thanks so much for taking the time. I welcome any input you have on this.

[doomzie]

I forgot to mention some other issue I'm experiencing.

Visual jitter when standing on the moving platform.

I first tested two days with your initial posted version. My settings were standard AFAIK and OpenGL.
There's no visual jitter watching the moving platforms, but when you're standing on them, heavy visual jitter was visible all the time.
Sometimes moving around on the platform stopped the jitter, but it was inconsistent.
I hadn't seen this problem before, so I assumed it must've been the platform actor itself.

I continued testing and then noticed the new version you made, I grabbed it, switched to the new gzdoom 4.8.2 as required and thought it would be solved, but no, the visual jitter was still there (for the most part I think).

For unrelated reasons, yesterday I switched to Vulkan to test if it results in higher fps, but instead immediately noticed the visual jitter was gone when standing on a platform! To the point where I couldn't say if there was still an issue or not. I forgot to mention this yesterday. I do not know at all what the issue is.

Unfortunately today I'm experiencing constant "connection to device lost" errors in gzdoom 4.8.2 and I reverted back to OpenGL and the jitter is back.

doomzie wrote:
- It seems that even when models are set to not clip issues still arise when interacting with crossing 3D floor sectors that move up and down

I can't reproduce this issue on my end.

Apologies, I meant the other way around, I meant to say when models are set to "clip", issues still arise with 3D floors. See my map. Normally, as far as I can tell, I have not noticed issues when models are set to "not clip". They just fly through models/3D floors, but this is not very desirable. I want them to clip and stay clipped if the logic of the pathway says so, in other words until a model or 3d floor moves and the pathway becomes clear and then it moves again.

I've added comments in the map and the SCRIPTS lump with additional info.