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

[Fishytza]

Ok, I feel like I need to quickly post my thoughts here; I'm still checking out the map you sent me.

First of all, TIL when you change a model user's roll or pitch (in UDB's visual mode) notice how the collision box stays above the actor? I did not know that.It explains why actors and players get higher than the cube suggests they should be.
Holy crap, what a discovery.
So I wouldn't recommend doing a 180 on pitch and roll for big and tall models like that. This is related to the odd player jumping issue.

About that "force feedback", you're trying to push a no-clip cube into the 3D floor with the zombiemen, the one whose interpolation point is right next to one of the 3D floor's lines. and while the cube will not collide with geometry, it's still colliding with the zombiemen, they're obstacles. A platform will always try to push away a non-platform (unless that non-platform has the DONTTHRUST flag). I know why you're doing it, changing the pitch/roll rotates the cube around the actor's feet.

The cube getting actually stuck in the 3D floor is something I'm gonna have to look into. That's a legit bug.


As for 3D floors not being where you want them to, try [wiki]TagWait[/wiki]
Like so:

Code: Select all

	while (bolSC == true) {
		FloorAndCeiling_LowerByValue(1572,32,612);
		Delay(175);
		TagWait(1572); //Make sure it has finished moving
		FloorAndCeiling_RaiseByValue(1572,32,612);
		Delay(175);
		TagWait(1572); //Make sure it has finished moving
	}

[Fishytza]

So, I have some very bad news. And it's related to the ACTLIKEBRIDGE flag.
I've been told before that ACTLIKEBRIDGE disables sectors from (mostly lifts) from affecting actors with that flag. That's apparently deliberate in order to remain compatible with some old mod.

This has to do with the cube getting stuck in the 3D floor. If I remove that flag A) it no longer gets stuck but instead can get pushed upward by the 3D floor and B) monsters can no longer walk on the platform it's as if they're stuck in place. Not to mention inventory items start to fall through.
The other idea I had on how to fix this doesn't work, I'm so sorry.

--

I have to make a confession. I am super burned out on this project and I really don't have the will to work on it for the foreseeable future. At least a good 3/4 months maybe.

[doomzie]

Ok, I feel like I need to quickly post my thoughts here; I'm still checking out the map you sent me.

First of all, TIL when you change a model user's roll or pitch (in UDB's visual mode) notice how the collision box stays above the actor? I did not know that.It explains why actors and players get higher than the cube suggests they should be. Holy crap, what a discovery. So I wouldn't recommend doing a 180 on pitch and roll for big and tall models like that. This is related to the odd player jumping issue. I've tested it with the EOA mod which has 'Dash' and I can even manage to jump and dash through the model when it's rolling/pitching. This must be the same problem.

Yes, I noticed it must be something like that, the actors on the platform are about "model height" higher than the model ceiling. I'm new to editing. So I simply don't know enough to know what is currently understood to be normal (buggy) behaviour by models and what might be caused by FCW_Platform. In either case it was immediately clear there's a bug here somewhere. It's quite obvious.

About that "force feedback", you're trying to push a no-clip cube into the 3D floor with the zombiemen, the one whose interpolation point is right next to one of the 3D floor's lines. and while the cube will not collide with geometry, it's still colliding with the zombiemen, they're obstacles. A platform will always try to push away a non-platform (unless that non-platform has the DONTTHRUST flag). I know why you're doing it, changing the pitch/roll rotates the cube around the actor's feet.

I see, so it's to be expected (normal behaviour). So my setup is not correct I suppose to avoid this? I'll have a second look to understand it better.

The cube getting actually stuck in the 3D floor is something I'm gonna have to look into. That's a legit bug.

Yeah I thought so. It's a very common/simple setup.

As for 3D floors not being where you want them to, try [wiki]TagWait[/wiki]
Like so:

Code: Select all

	while (bolSC == true) {
		FloorAndCeiling_LowerByValue(1572,32,612);
		Delay(175);
		TagWait(1572); //Make sure it has finished moving
		FloorAndCeiling_RaiseByValue(1572,32,612);
		Delay(175);
		TagWait(1572); //Make sure it has finished moving
	}

That's great! I didn't know how to work around it. Thanks so much for this. =)

[doomzie]

So, I have some very bad news. And it's related to the ACTLIKEBRIDGE flag.
I've been told before that ACTLIKEBRIDGE disables sectors from (mostly lifts) from affecting actors with that flag. That's apparently deliberate in order to remain compatible with some old mod.

This has to do with the cube getting stuck in the 3D platform. If I remove that flag A) it no longer gets stuck but instead can get pushed upward by the 3D floor and B) monsters can no longer walk on the platform it's as if they're stuck in place. Not to mention inventory items start to fall through.
The other idea I had on how to fix this doesn't work, I'm so sorry.

Ok, that's very unfortunate. You never experienced the issue that I showed?

Yeah I don't know anything about ACTLIKEBRIDGE.

This is a deep engine setting for an old mod? That is just weird.

I have to make a confession. I am super burned out on this project and I really don't have the will to work on it for the foreseeable future. At least a good 3/4 months maybe.

I understand. In either case, I hope you still appreciate the effort I've done in testing your FCW_Platform class and don't worry, I've seen the extent of the code. It's totally ok if you don't want to work on it for a long while.

So much good work has been done on this. I had a lot of fun testing it out.

Thanks again, and I hope that somehow some day we will see an update here. I'll be one the first to do further testing =) It's a missing element imho.

PS: For the people who might be worrying that this is buggy. It really isn't. It basically works. I've also had zero crashes using it. Movement is smooth and actors stay properly on the platform. All easy/common setups seem to work absolutely fine. It can be used for your project if you do proper testing and be aware that enemies don't see the platform as a regular floor. The only thing that is a shame is the visual jitter, but I only have that with OpenGL it seems. No clue why.

[Fishytza]

Oh, I completely forgot.

I don't get whatever visual jitter you mentioned. I tested it with OpenGL and Vulkan. EDIT: With a GTX 970

But yeah, I'm taking a deliberate long break from this. Hacking this whole thing together was both fun and a bit of a nightmare.

[doomzie]

Oh, I completely forgot.
I don't get whatever visual jitter you mentioned. I tested it with OpenGL and Vulkan.

I see, then it's entirely an issue on my side I guess. Maybe need to update my gfx drivers. I'll see, cause Vulkan is giving me troubles in the latest gzdoom. The texture flashes heavily when the player looks down at the platform he's standing on. That's it basically. Tested with Nvidia 1080Ti fyi.

But yeah, I'm taking a deliberate long break from this. Hacking this whole thing together was both fun and a bit of a nightmare.

I can't even begin to imagine how hard this must've been.

Even though you're taking a break, I'll play around with it some more, especially since you have no visual jitter at all. Very interesting.

[Fishytza]

I've managed to reproduce the 3D floor bug in my test map for future reference. So, I guess thanks for bringing that to my attention.

[Major Cooke]

So, I have some very bad news. And it's related to the ACTLIKEBRIDGE flag.
I've been told before that ACTLIKEBRIDGE disables sectors from (mostly lifts) from affecting actors with that flag. That's apparently deliberate in order to remain compatible with some old mod.

Well I have some good news for you, for some time I've been working on a work-around for this. Thankfully, we have sector's PlaneMoving(int pos) boolean. I can take a crack at this sometime and see if I can give you something to use soon.

I just need to figure out all the rules first, replicating it isn't all too difficult. Mainly just tedious.

[Fishytza]

I appreciate the help, but I've had another idea on how to tackle this and it looks to be promising!
Looks like I needed to call FindFloorCeiling()
Still need to thoroughly test this against regular moving floors and ceilings (no 3D floors).
I'll keep y'all updated.

[Fishytza]

Turns out it wasn't just 3D floors but also moving ceilings that were problematic.
Anyway, instead of being stuck in a 3D floor/ceiling when it moves down, the platform will move along with it.
I understand this is not ideal, but it's a step in the right direction.
(Specifically, when the platform is stationary, it will block the moving 3D floor, but when it tries to move and gets stuck in it, the 3D floor will push it down.)

doomzie, if you want to check it out, please fetch the latest commit/clone the repo. (The relevant changes are in platform-base.zs file.)
I don't have your map anymore so I'm curious if this improves your setup.
(Quick reminder: set your platform's MaxStepHeight to 1 to avoid the "hop on" behaviour.)

Cooke, I'm still interested about what you have in mind with PlaneMoving().

EDIT: Ok, it seems even when it goes down with the 3D floor, it's still a little bit stuck in it. I have a workaround for that but I first I need to make sure it's not a [Don't do that] thing.
I'm thinking to set the platform's statnum to STAT_SECTOREFFECT + 1, so that it ticks after every floor/ceiling thinker has ticked (Those would be doors/crushers/lifts etc.)

[Fishytza]

Alright, so I went ahead and changed the statnum. This doesn't seem to be causing any issues as far as I can tell on my end.

Unless something else gets in the way I'm thinking of making a bugfix-release in two weeks time from this moment.
That's 28th August.

If anyone has any more issues/bugs to report, please do so.

[doomzie]

Looks like I missed the notification for your reply. Didn't expect any more updates tbh. Sweet !

Currently busy on something else, but I'll check this out asap and see how it differs from the previous version.

Thanks!!

By the way, regarding the model pitching and rolling. Just for my understanding, that is a bug in gzdoom then. After your comment, I took the time to see what the hitbox is doing (visualized) in the editor. So indeed, any value between 0 and 180, and 180 and 360 results in the hitbox no longer being aligned with the model. This renders it very clear why the pitching model cube is pushing into the static 3D floor and is pushing player/enemies back. The hitbox becomes (model size/2) misaligned for two coordinates. This wasn't clear cause I didn't set the initial value of my model cubes to anything else than 0 (so hitbox is aligned in editor), during the level it changed however, but you can't see the hitbox. So wasn't clear. Now it is.

So is this something that should be reported as a bug to gzdoom, is anyone aware of this or how do I need to interpret this?

[imgur]https://imgur.com/a/24rybJN[/imgur]

[doomzie]

- 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.

(Quick reminder: set your platform's MaxStepHeight to 1 to avoid the "hop on" behaviour.)

Confirmed. This removes the hopping over behavior and makes movement look clean (~stays at the pathway height that I have in mind as editor).

[doomzie]

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 SetActorFlag to give actors of interest on your map the CANPASS flag.

Confirmed. Decorations like candles and torches no longer fall through =)

Like so?

Code: Select all

Script "LevelStartCanPass" OPEN
 {
	// Set CANPASS is true for all items/things/actors (that are not weapons/ammo/armor/health items), like decorations
	// Give all items in UDB a tag = 10000
   	SetActorFlag(10000, "CANPASS", TRUE);
 }
 

[Fishytza]

Like so?

Yes, that should do the trick.

By the way, regarding the model pitching and rolling. Just for my understanding, that is a bug in gzdoom then. After your comment, I took the time to see what the hitbox is doing (visualized) in the editor. So indeed, any value between 0 and 180, and 180 and 360 results in the hitbox no longer being aligned with the model. This renders it very clear why the pitching model cube is pushing into the static 3D floor and is pushing player/enemies back. The hitbox becomes (model size/2) misaligned for two coordinates. This wasn't clear cause I didn't set the inital value of my model cubes to anything else than 0 (so hitbox is aligned in editor), during the level it changed however, but you can't see the hitbox. So wasn't clear. Now it is.

So is this something that should be reported as a bug to gzdoom, is anyone aware of this or how do I need to interpret this?

I think I have a solution. Within your MODELDEF entry set the USEROTATIONCENTER flag.
Then set the following propertly "Rotation-Center 0 0 x" where x is the half of your actor's height.
So if the skull box's height is 256 (or whatever) that would be Rotation-Center 0 0 128

For example

Code: Select all

Model TESTFloaty
{
	USEACTORPITCH
	USEACTORROLL
	USEROTATIONCENTER //This

	Path "models"
	Model 0 "Floaty.obj"
	AngleOffset 90
	Rotation-Center 0 0 40 //And this
	FrameIndex MODL A 0 0
}

It seems to work with my TESTFloaty actor.
Keep in mind however that in UDB it still seems to rotate it around the actor's feet, but I used Nash's Radius Debug tool to draw the collision box in-game, and indeed, the model's rotation origin is no longer at the actor's feet but its center!

Try it out with your skull boxes, do the same tests again and see if the oddities still happen (things getting higher than the skull box etc)


Oh, one more thing. Is the 3D floor bug is still happening for you?