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

[Fishytza]

Ok, so one thing I'm noticing is @ 1:14 when a cube tries to move but can't because of the 3D floor interaction, and when it finally gets going it loses one of its passengers. I'll try to do something about that.

@ 9:12 upper-left cube with the revenant and 3 zombies. I don't know why one of the zombies just falls off as the cube starts moving away. It's a mystery...

Just a general thing, having solid decorations like torches and candelabras on the edges of those pillars can and will mess up how actors get on/off the cubes, or block those cubes entirely. (Which is more obvious if the cubes have 0 crush damage)
Because the cube gets blocked by a monster which in turn is pushed against a solid torch.

[Fishytza]

[youtube]https://youtu.be/ry5AEbSWP6w[/youtube] (HD is still processing)

I'm curious about something. Does that mod with the D2016 monsters use extra actors as headshot hitboxes per chance?

I'd be great if you could link the mod.

EDIT: I don't think I'll crack the falling passengers bug by tomorrow, especially not the kind I'm seeing in the video. Oh well.

[doomzie]

[youtube]https://youtu.be/ry5AEbSWP6w[/youtube] (HD is still processing)

I'm curious about something. Does that mod with the D2016 monsters use extra actors as headshot hitboxes per chance?

I'd be great if you could link the mod.

EDIT: I don't think I'll crack the falling passengers bug by tomorrow, especially not the kind I'm seeing in the video. Oh well.

EOA zdoom.org topic:
viewtopic.php?t=68111
https://github.com/DoomKrakken/Embers-Of-Armageddon

EOA moddb page:
https://www.moddb.com/mods/embers-of-ar ... armageddon

Doom 2016 monsters add-on:
https://www.moddb.com/mods/embers-of-ar ... oa-version

Load in this order: EOA Assets, EOA Code, Doom 2016 monsters (if you would want to test).

I've checked "EOA Code" and I see some "headshot" references. Not sure if there's anything in the Doom 2016 monsters DECORATE.

[Fishytza]

Ok, I got some good news/bad news depending on how you want to interpret it.

Just loading the base EOA mod without the D2016 monsters causes one of my platforms in TEST01 to not move at all.
That's because of those EOA_WeakPoint actors used as headshot hitboxes.

When a platform tries to move a whole group of actors, all those actors are temporarily non-solid (by being excluded from the blockmap) so they don't collide with each other when moved one by one.
Since the weakpoint actors won't be detected as passengers they won't get this treatment so they remain solid and what ends up happening is either the passengers or the platform get stuck.

I need some time to think about how best to handle this, the release is likely gonna have to wait until tomorrow (Monday).

EDIT: And I've managed to reproduce the condition where a passenger simply "won't move" and be left behind by a platform. And yes, it's because of EOA.

[doomzie]

Ok, I got some good news/bad news depending on how you want to interpret it.

Just loading the base EOA mod without the D2016 monsters causes one of my platforms in TEST01 to not move at all.
That's because of those EOA_WeakPoint actors used as headshot hitboxes.

When a platform tries to move a whole group of actors, all those actors are temporarily non-solid (by being excluded from the blockmap) so they don't collide with each other when moved one by one.
Since the weakpoint actors won't be detected as passengers they won't get this treatment so they remain solid and what ends up happening is either the passengers or the platform get stuck.

I need some time to think about how best to handle this, the release is likely gonna have to wait until tomorrow (Monday).

EDIT: And I've managed to reproduce the condition where a passenger simply "won't move" and be left behind by a platform. And yes, it's because of EOA.

It's good news that it clarifies what is going on. I'm pleased to hear you understand what is going on.

Since your remark, browsing through the EOA code for headshot stuff and sort of knowing how that works (2 actors/hitboxes) I realized it was probably a source of problems for 3D Platform. The 'staggering' code is probably a little nifty too when it comes to 3D platforms. It's totally okay if you not deal with it at all. I'm really sorry for the trouble it has caused you.

Knowing this, I should make the time to make a clean pure vanilla level and assess 3D Platform as such. I'll record it too.

Currently distracted with some advanced model and texture complexities.

[Fishytza]

It's totally okay if you not deal with it at all. I'm really sorry for the trouble it has caused you.

Eh, it's the headache that comes when you try to combine mods that aren't exactly compatible with one another.

For platforms, I'm thinking of adding some empty virtual functions for cases as such as this one, when dealing with non-generic actors. Right now, there's two such functions in the repo and I'm thinking of adding a third.

[doomzie]

It's probably not possible, but I just wanna know, is there any way to trigger an action (a script) when the player steps/lands onto a 3D Platform?

It would be really great to have.

[Fishytza]

I'll try to implement that tomorrow. It shouldn't be that difficult. (I take it back.) It actually might get really tricky if what you want is to trigger a special every time something lands on a platform, even an idle platform.


Ok, I've added a third empty virtual function that allows you to handle special actors as they are detected in a BlockThingsIterator search. And with it I've managed to get around the EOA_WeakPoint actors.
Those actors always make themselves solid if their owner is solid which works for us just fine.
All we have to do is clear its bSolid flag so it doesn't get in the way of other passengers.

Fetch the last commit, and then either find the function SpecialBTIActor and fill it out
or make a subclass of FCW_Platform and override it, like so

Code: Select all

override bool SpecialBTIActor (Actor mo)
{
	if (mo.GetClassName() == "EOA_WeakPoint")
	{
		mo.bSolid = false;
		return true;
	}
	return false;
}

and test it out with your map. Granted, this isn't fool proof but I'm curious if it makes a difference with things falling off.

In my case, it solves the "passenger getting left behind" problem with one platform in TEST01, but another one still gets stuck half-way on its path. I'm gonna need to investigate that tomorrow.

[doomzie]

Ok, I've added a third empty virtual function that allows you to handle special actors as they are detected in a BlockThingsIterator search. And with it I've managed to get around the EOA_WeakPoint actors.
Those actors always make themselves solid if their owner is solid which works for us just fine.
All we have to do is clear its bSolid flag so it doesn't get in the way of other passengers.

Quick feedback:

I've done a quick 30 min test with the updated files and addition of the 'SpecialBTIActor' function for EOA.

At first glance it's a big difference. I think it solves some primary problem with EOA enemies. I'm very pleased with the result.

Over time, the number of fallen actors does still increase quite a bit, so I still need to do some further testing. I think most are falling off 'as expected', but need to look closer.

It certainly takes a lot more time to have a swarm of (fallen) enemies on the floor (in the water). The enemies stay on the platform much longer.

I'll get back on this this evening, probably.

[Fishytza]

v1.1.1 release is out

To summarize what's changed since v1.1.0:

---

-Address buggy interaction with moving 3D floors and moving ceilings/floors.
Previously a floor/ceiling/3D floor that pushes down/up on a platform that attempts a perfect
horizontal move (especially a fast one) would get stuck and clip through
the moving floor/ceiling/3D floor. This has changed so the platform goes along with it instead.
It's not perfect, but it's an improvement.

-Do a VM abort if one of the old PathFollower classes (including MovingCamera and ActorMover)
attempt to use the platform-centric interpolation point (aka FCW_PlatformNode).
The abort will also happen if the old InterpolationPoint class points to a FCW_PlatformNode
or if a FCW_PlatformNode points to a InterpolationPoint. (You can't mix those two in a path.)

-A workaround has been added to counteract the engine's rigid actor bounding box.
("Rigid" meaning it won't rotate when an actor's yaw, pitch or roll changes.)
Previously if you placed passengers on the corners of a rotating platform,
those passengers would fall off. Now it makes sure that during a yaw/angle
rotation it will try to keep passengers that overlap on the XY plane to remain
overlapped. This has the side effect of passengers on corners being pulled inward.
But I think that's acceptable.

-Three empty virtual functions for modders to ease up making special actors
work with platforms:
void PassengerPreMove(Actor mo) - which is always called before attempting to move a passenger.
void PassengerPostMove(Actor mo, bool moved) - which is always called after attempting to move a passenger.
And
bool SpecialBTIActor(Actor mo) - which allows intercepting actors detected in the platform's BlockThingIterator searches.
Return "true" to skip processing this actor (mo) and go to the next blockmap result.
Return "false" to do the usual checks (Is it within range, is it carriable, etc).

----------------------------------

Quick feedback:

I've done a quick 30 min test with the updated files and addition of the 'SpecialBTIActor' function for EOA.

At first glance it's a big difference. I think it solves some primary problem with EOA enemies. I'm very pleased with the result.

Over time, the number of fallen actors does still increase quite a bit, so I still need to do some further testing. I think most are falling off 'as expected', but need to look closer.

It certainly takes a lot more time to have a swarm of (fallen) enemies on the floor (in the water). The enemies stay on the platform much longer.

I'll get back on this this evening, probably.

That's good news.


I'm sorry if this comes off as selfish or lazy, but the burnout and sleep deprivation are beginning to creep in again so I've decided to make the release now and take a break from this. At least for the next 5 days or so. Or longer, much longer.

I've added your "trigger special when landing on 3D platform" feature on the to-do list for when I come back to this.

[doomzie]

v1.1.1 release is out

Congrats. Please take plenty rest. Thanks so much for all your efforts.

[Major Cooke]

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

Apologies, I had to take a break because of a massive heat wave. It killed any desire to want to do anything productive, but thankfully that's passed. Mostly...

First, have you already solved the issue then? If you have, then there's no need for me to elaborate, but I will put it in spoilers if you haven't gotten around to investigating it yet.

---

PlaneMoving() is a simple way to determine if a sector floor is actually in the process of moving. The position indicated is either the floor or ceiling that you can pass in, and it'll tell whatever called it if it's moving (true) or not (false).

This is a better way to tell if the floor is actually moving instead of doing a pos.z - floorz check, especially if the actor crosses into another sector with a different floor height.

[Fishytza]

The issue has been taken care of, sort of. Platforms no longer clip thru moving 3D floors but move with them instead until the 3D floor is out of the way.

[Major Cooke]

What's left to address then?

[Fishytza]

I guess nothing?