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

[doomzie]

Ok, so I've updated my "3D Platform.pk3" with your updated 1.2.0 platform-base.zs.

First off, I had several warnings related to "Path Follower" things that I connected to the first Platform Interpolation Point, on an unmodified map.
The models using those particular pathways did not move and remained at their initial position.
I removed all the Path Followers and the warnings were gone and the models followed their path again.

Preliminary results regarding the "3D floor bug" (actually model collision with any moving floor/ceiling) look good.

So, indeed the 3D floor now pushes the model cube higher when it collides with the floor of the 3D floor. This seems to happen halfway over the 3D floor. The model is no longer going through the floor (halfway through it's pushed up). I agree that it doesn't look buggy anymore like this. 3D floor and model are no longer overlapping. So it's certainly an improvement.

I've only just started testing and the only thing that stands out regarding this, is that there is like a delay somewhere in the new movement that I'm seeing. It's like a second or so that the model is static and then it moves again.

I've been thinking however, that to achieve what I intended, I would probably have to use model to model collision/clipping with this 3D Platform Actor (and not use a 3D floor). So only use models for horizontal and vertical movement (with pathways that cross). As far as I can tell that should work, but then it's all models and you have to deal with all the issues that come with that. I'll try to make a section in my test map where I try that.

[doomzie]

By the way, regarding the model pitching and rolling. ...

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

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)

Ok, I'm very glad to report this resolved the issues/problems I was having with introcate pathways and correctly setting the interpolation points when using roll and pitch. I could hardly believe it was so complicated. I had to reposition all my interpolation points that used roll and pitch, but now it is straightforward. Awesome. This obviously also resolves the "actors walking above model", "player is blocked trying to jump off". Interaction between player/enemies and rolling/pitching models looks so much better. It's now basically what I expect it should be with 3D Platform Actor. So no bug after all? You just have to set the Z coordinate for Rotation-Center of your model to half the height of the model. Confirmed, this is working in game. As you said, UDB still displays "misalignment" between model and hitbox (when pitched or rolled), but that's a minor thing.

So I'm going to presume everything is normal after all ?

By the way, for some reason SLADE does not recognize USEROTATIONCENTER, but it does work.

edit: Ok, I figured out that you need to work with the updated RadiusDebug that was posted. This is such a great tool! FPS is ok in updated version.

[Fishytza]

First off, I had several warnings related to "Path Follower" things that I connected to the first Platform Interpolation Point, on an unmodified map.
The models using those particular pathways did not move and remained at their initial position.
I removed all the Path Followers and the warnings were gone and the models followed their path again.

Odd. Are you implying those errors didn't happen before you took the updated platfom-base.zs file?

...there is like a delay somewhere in the new movement that I'm seeing. It's like a second or so that the model is static and then it moves again.

How subtle is that delay? Does it make any difference if you comment-out or remove "ChangeStatNum(STAT_SECTOREFFECT +1);"? It should be near the beginning of the BeginPlay() override.

By the way, for some reason SLADE does not recognize USEROTATIONCENTER, but it does work.

edit: Ok, I figured out that you need to work with the updated RadiusDebug that was posted. This is such a great tool! FPS is ok in updated version.

I don't use SLADE at all for dev purposes. I believe the USEROTATIONCENTER stuff is pretty new? I just learned about it yesterday.
(I'm not too familiar with MODELDEF tbh.)

EDIT

1.2.0

I was thinking it should be 1.1.1 since it's the same as before just trying to address/fix the 3D floor bug.

[doomzie]

First off, I had several warnings related to "Path Follower" things that I connected to the first Platform Interpolation Point, on an unmodified map.
The models using those particular pathways did not move and remained at their initial position.
I removed all the Path Followers and the warnings were gone and the models followed their path again.

Odd. Are you implying those errors didn't happen before you took the updated platfom-base.zs file?

Yes. Unchanged map 1.1.0 to 1.1.1. No warnings for 1.1.0. Warnings for 1.1.1.

---

Can't find target for camera node 2651
PathFollower 3143: Path needs at least 4 nodes

Can't find target for camera node 3238
PathFollower 3237: Path needs at least 4 nodes

Can't find target for camera node 3299
PathFollower 0 : Path needs at least 4 nodes

Can't find target for camera node 3362
PathFollower 0: Path needs at least 4 nodes


Platform class 'SkullCube200px' with tid 0 at position (2316.00000, 1308.00000, 300.00000):
Path needs at least 4 nodes. (Interpolation point tid: 2651.)

Platform class 'SkullCube200px' with tid 0 at position (2316.00000, 476.00000, 300.00000):
Path needs at least 4 nodes. (Interpolation point tid: 2660.)

Platform class 'SkullCube200px' with tid 0 at position (2316.00000, -1156.00000, 300.00000):
Path needs at least 2 nodes. (Interpolation point tid: 3238.)

Platform class 'SkullCube200px' with tid 0 at position (7200.00000, 3448.00000, 300.00000):
Path needs at least 4 nodes. (Interpolation point tid: 3299.)

Platform class 'SkullCube200px' with tid 0 at position (11344.00000, -224.00000, 300.00000):
Path needs at least 4 nodes. (Interpolation point tid: 3362.)

...there is like a delay somewhere in the new movement that I'm seeing. It's like a second or so that the model is static and then it moves again.

How subtle is that delay? Does it make any difference if you comment-out or remove "ChangeStatNum(STAT_SECTOREFFECT +1);"? It should be near the beginning of the BeginPlay() override.

It's not subtle. It's very visible.

Ok, I'll try with that change.

By the way, for some reason SLADE does not recognize USEROTATIONCENTER, but it does work.

edit: Ok, I figured out that you need to work with the updated RadiusDebug that was posted. This is such a great tool! FPS is ok in updated version.

I don't use SLADE at all for dev purposes. I believe the USEROTATIONCENTER stuff is pretty new? I just learned about it yesterday.
(I'm not too familiar with MODELDEF tbh.)

Seeing the limited information available on this, including the official wiki ("more info required"). I guess you're right.

EDIT

1.2.0

I was thinking it should be 1.1.1 since it's the same as before just trying to address/fix the 3D floor bug.

Yeah, you didn't specify it yet, I just chose something. Ok.

[Fishytza]

Yes. Unchanged map 1.1.0 to 1.1.1. No warnings for 1.1.0. Warnings for 1.1.1.

Ok, my hunch tells me it's still something to do with the statnum change.

---

Can't find target for camera node 2651
PathFollower 3143: Path needs at least 4 nodes
....
Platform class 'SkullCube200px' with tid 0 at position (2316.00000, 1308.00000, 300.00000):
Path needs at least 4 nodes. (Interpolation point tid: 2651.)

The cube is trying to use a curved spline path (non-linear), that needs 4 interpolation points. But what's really mind boggling is why the path follower is spewwing errors.
No, scratch that, it doesn't make sense why these errors show up out of the blue like that.

It's like an interpolation point got deleted along the way somehow...?

[Fishytza]

Let's get specific. Find the interpolation point with tid 2651 and check what its next point is, then confirm if that next point exists.

If it does not exist then it makes sense why you're getting those errors, both for the pathfollower and the cube.


Also

I removed all the Path Followers and the warnings were gone and the models followed their path again.

This is so bizzare that it shouldn't be happening.

[doomzie]

Let's get specific. Find the interpolation point with tid 2651 and check what its next point is, then confirm if that next point exists.

If it does not exist then it makes sense why you're getting those errors, both for the pathfollower and the cube.

Also

I removed all the Path Followers and the warnings were gone and the models followed their path again.

This is so bizzare that it shouldn't be happening.

Ok, don't worry about this for now, I'll check this later on again and confirm it. I'm pretty sure I didn't accidentally delete an Interpolation point. I checked all points and everything seemed fine. I had no other solution apparently than to delete them. The problem occured for spliced paths iirc, the ones with two models that are moving synchronously. I would have to check again in detail. It was pretty late already.

Regarding the other point, I've now been testing for two hours more or less and I'm not seeing the delay anymore. So I don't get it. I'll blame late hours and optical illusions There's no delay as far as I can tell (it's not fluent either, but ok) and I didn't update the stratnum thing you provided. So, I'll continue to check and provide feedback later.

I'm liking the update so far. I don't understand the root cause of the clipping issue, but I presume there is currently no better way to have moving floor/ceiling collision/clipping with 3D Platform class models, so this update is definitely better. I'm just thinking that it's going to push the model through a ceiling probably in certain conditions. I presume you are well aware.

I'd love to start testing with grouped models, like in your demo map, it's on my todo list. As well as model to model collision pathways, and the effect of the "add velocity" flag.


Questions/requests:
- Do you know what the cause is of enemies losing their connection with the model? Is this a point that can be improved?
- Any way to disable the enemies walking slightly outside their model (or some way to reduce it to minimum)?
- Is there any way to set a global travel time for an entire path, problem now is for elaborate pathways with different lengths, each time you can only set a travel time between two points and the end result is slowing down or speeding up between points, instead of a constant speed over the entire path

[Fishytza]

- Do you know what the cause is of enemies losing their connection with the model? Is this a point that can be improved?

Sadly this is one of those things I'm not really sure how to improve. There is code specific to trying to get walking monsters away from the platform's edge (what you call "model") but it's not foolproof. Especially with multiple monsters on it.
I remember that one skull with 4 zombiemen on it and how when it rotates really fast, 2 of them would fall off.
If I ever decide to rework some things, this would be on the to-do list.

- Any way to disable the enemies walking slightly outside their model (or some way to reduce it to minimum)?

Same answer as to the first question.

- Is there any way to set a global travel time for an entire path, problem now is for elaborate pathways with different lengths, each time you can only set a travel time between two points and the end result is slowing down or speeding up between points, instead of a constant speed over the entire path

I guess this is for future considerations.

I'm pretty sure I didn't accidentally delete an Interpolation point

I'm trying to rule out any accidental mapping mistakes. I doesn't make sense why all of a sudden certain interpolation points can't be found. It also makes no sense why deleting all the path followers allows the cubes to work as intended and without error messages.
The only suspect I have is the ChangeStatNum() function and even that's a *huge* stretch and grasping at straws. Nothing between v1.1.0 and now could be responsible in my mind besides ChangeStatNum(). So maybe it's something crazy like maybe it screws up the ActorIterator (it's what looks for actors by TID). But that's just baseless speculation.

I can't reproduce it on my end.

[doomzie]

I'm pretty sure I didn't accidentally delete an Interpolation point

I'm trying to rule out any accidental mapping mistakes. I doesn't make sense why all of a sudden certain interpolation points can't be found. It also makes no sense why deleting all the path followers allows the cubes to work as intended and without error messages.
The only suspect I have is the ChangeStatNum() function and even that's a *huge* stretch and grasping at straws. Nothing between v1.1.0 and now could be responsible in my mind besides ChangeStatNum(). So maybe it's something crazy like maybe it screws up the ActorIterator (it's what looks for actors by TID). But that's just baseless speculation.

I can't reproduce it on my end.

Ok, I don't understand then, if you can't reproduce it. I guess I'm doing something wrong.

I just re-added "Path Follower" things to a few paths (spliced and regular) and it immediately gives the beforementioned warning and the path is not functional. I remove the "Path Followers" and everything is normal again. No changes to path or interpolation point tags or anything. I obviously set the "Path Follower" to the first Platform Interpolation point of the path. Like in the demo map. Anyhow, for me this doesn't really matter, I didn't use them, they were just attached to the paths to see if it worked to display a path in UDB, which it doesn't. So path follower or not, doesn't matter as far as I can tell. I'm using the Platform Interpolation Points now, but for elaborate pathways I'll use the regular tbh. You can't see the sprite either, unless you select it. In my test map I've hit some points where the invisible path leads to confusion/making mistakes.

[Fishytza]

Ok, one little test. Put all the path followers back.

Then within platform-base.zs find and remove

Code: Select all

ChangeStatNum(STAT_SECTOREFFECT + 1);

and run the map again. I really, really want to know if the errors come out again. This is important.

[doomzie]

Ok, one little test. Put all the path followers back.

Then within platform-base.zs find and remove

Code: Select all

ChangeStatNum(STAT_SECTOREFFECT + 1);

and run the map again. I really, really want to know if the errors come out again. This is important.

I confirm this statement is the cause. Without it, the Path Followers don't generate warnings (that don't make sense). I double checked.

[Fishytza]

I'm stunned.

Okay, then, without ChangeStatNum() the platforms that get pushed by a 3D floor will appear just a little bit stuck in it as it moves down/up, but I guess that's acceptable compared to... I don't even know what this is.

If you can isolate that bug somehow in a test map, I'd love to look at it myself. It sounds unbelievable.

[doomzie]

Ok, so some preliminary feedback after today's testing.

So regarding the so called 3D floor bug. I had several setups in my test map where I tested collision, but with different movement.
There was one skull cube that moved diagonally along the 3D floor before moving over it. Before, this caused no issues. The bug was not present here.
Movement was basically perfect. I've now noticed that with 1.1.1, when the model clips against the 3D floor that is moving downwards, it actually drags the model all the way down as well, before releasing it. In this case the model gets way out of its projected path. It doesn't get stuck however. I didn't notice it at first, because the clipping happened rarely in that particular pathway. I've now added several more skull cubes and the issue is consistent.

I've also tested Model (FCW_Platform) to Model (FCW_Platform) collision, to see if it avoids all these particular issues and I can confirm that it does (as you would expect I guess). It achieves the clipping I expect to see as editor, except one noticable detail which is weird. Clipping in the direction east <-> west is ok. Models collide at the exact edge (on the pixel). However in the other direction (north <-> south) the model is clipping with a gap of 10 pixels or so (I don't know) consistently and there is nothing blocking it. Very weird. I'll need to test it with RadiusDebug maybe. Everything else looks and works great. Models clip just as expected, no buggy behaviour that I can see, but it was just a first test. Still need to do more advanced movement clipping, but the basics are ok. Of course the more all the enemies are placed on model platforms, the more the little issues become visible with regards to enemy behavior. I'd love to avoid working with models altogether, and keep it more traditional from an editing pov, but at least this works.

I tried to do some testing of flags I hadn't used yet, as they are quite important.

I've now added a section with several skull cubes (platforms) moving horizontally with flags "add velocity when jumping" and/or "add velocity when stopping". This will need to be tested further. I'm not sure how exactly it works, but I'm supposed to get "extra velocity" right when I jump off? I've made a set up where the player needs to try to bridge a large gap using a fast moving cube with "add velocity when jumping" and I didn't really manage to succeed in this. For the speed the cube has it should launch the player far enough to bridge the gap, I assume. I need to do more testing to understand what is happening. I'm testing using the EOA mod also, so who knows.

Same for the flag "crush obstacles". What should happen when I use this flag? If two cubes collide and some monster is between them, the monster should be crushed right? From every direction? As quick feedback, I can say though that it seems that models get stuck when they move vertically down and there are monsters below it. The monsters hold the model down until I deal with them.

I'll see in the coming days if I have some more time.

Take care.

[Fishytza]

I've now added a section with several skull cubes (platforms) moving horizontally with flags "add velocity when jumping" and/or "add velocity when stopping". This will need to be tested further. I'm not sure how exactly it works, but I'm supposed to get "extra velocity" right when I jump off? I've made a set up where the player needs to try to bridge a large gap using a fast moving cube with "add velocity when jumping" and I didn't really manage to succeed in this. For the speed the cube has it should launch the player far enough to bridge the gap, I assume. I need to do more testing to understand what is happening. I'm testing using the EOA mod also, so who knows.

Ok, "add velocity when jumping away" was added because a friend of mine wanted somewhat realistic velocity physics. In this case, with that flag enabled, if you attempt to jump away in the opposite direction of where a platform is moving, what would happen is your velocity becomes 0 as soon as you lose contact with the platform. Technically what's going on is for every actor a platform loses, add some velocity based on the platform's movement to the lost actor. This is what it's supposed to mimic.


"Add velocity when stopping" was meant for things that move rather fast then "stop abruptly".
Please not that "stopping" means either A) reaching the last interpolation point or B) reaching a point with a defined "hold time" (to wait). When it "stops" it will add velocity to all its passengers based on its prior motion.
The effect this is supposed to achieve is throw off everything it was carrying if a very fast platform comes to a sudden stop.


As for the "crush obstacles" flag. It does nothing unless you give your platforms a defined crush damage (argument 4 under "Action / Tag / Misc." tab)
Normally when pushing away obstacles and they can't be pushed because the obstacle is against a wall it will receive crush damage.
If "always crush obstacles" is enabled crush damage is applied every time the obstacle is pushed away. That's the difference.
Think of a speeding truck (platform) hitting something. You'd want the truck to not only push away but also hurt whatever it's pushing away, right?

[Fishytza]

Regarding the mysterious pathfollower/interpolation point errors bug that apparently ChangeStatNum() is causing.
I can't reproduce it.
Here's a PK3 with a very simple testmap, and with the platform-base.zs file that's currently on the repo.
The testmap has 4 interpolation point paths, each targeted by the "pinky platform" and a pathfollower.
I don't get errors for it. Feel free to screw around, trying to reproduce the conditions if you can.

iwantbug.pk3

I did notice something interesting. When you delete an interpolation point UDB will make the other point that was targeting this one target the deleted point's next point.
And when you undo the deletion, it won't undo the retargeting.