+DONTSINK

Remember, just because you request it, that doesn't mean you'll get it.

Moderator: GZDoom Developers

Guest

+DONTSINK

Post by Guest »

https://github.com/coelckers/gzdoom/pull/693

Simply put, it disables the mostly hardcoded sink-in-water physics when set (including the part where Z velocity slowly gets matched with the sink speed on top of regular friction), letting you implement your own sinking/buoyancy behavior, or have a monster swim around without needing to worry about Z velocity getting adjusted in strange ways, or what have you.
ZzZombo
Posts: 315
Joined: Mon Jul 16, 2012 2:02 am

Re: +DONTSINK

Post by ZzZombo »

Better implement a `buoyancy` variable, with `+DONTSINK` being an edge case for that.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: +DONTSINK

Post by Graf Zahl »

Yeah, that's precisely why I haven't done anything with it yet. The idea itself is fine but this is too limited.
Guest

Re: +DONTSINK

Post by Guest »

In my opinion, it'd be better if the modder implemented their own buoyancy with ZScript so that they can decide themselves how to handle cases like how an object bumping into another one - should it stop, should it push the other object up (and have the object push it down to compensate), should their buoyancies average out so that they move/sink as a unit while colliding, or something else, I don't know. Better for the modders to decide than the engine to decide for them.

That, and a buoyancy of 0 based off the current sinking logic would mean "tend towards no Z velocity in water", not "don't do anything to Z velocity" as +DONTSINK does, so you'd end up either needing a +NOBUOYANCY flag anyway.
Guest

Re: +DONTSINK

Post by Guest »

(haha double posting)

Thinking about it some more, maybe it'd work out if the current sinking code is kept on most of the time, but a +BUOYANT flag is added that enables use of new buoyancy code, which would apply Z acceleration when in water, scaled by how far into the water it is, or by water level if that would be more consistent with how the rest of the physics works. The property would be in units/tic^2. Gravity would be factored into this, except for +NOGRAVITY +BUOYANT actors. Actors colliding with each other because of buoyancy would handle the same as if they collided any other way.

For example, an actor with a Buoyancy of 1.5 would, when completely submerged in water, accelerate upward at a rate of (1.5 unit/tic^2 - [gravity] units/tic^2) = usually 0.5 units/tic^2. When only half-submerged, only half its buoyancy would apply (the net Z acceleration would be -0.25 units/tic^2). If going by waterlevel, then waterlevel 1 uses 33% of the buoyancy property, and waterlevel 2 uses 67% of the buoyancy property. An actor with a buoyancy of 0 would sink in water exactly like it would sink in air. The default buoyancy would be 1.

+DONTSINK would still be useful to completely disable all of that if you want - for example (and this is the example that prompted it in the first place), if you want to implement a different game's swimming physics.
User avatar
Apeirogon
Posts: 1605
Joined: Mon Jun 12, 2017 12:57 am

Re: +DONTSINK

Post by Apeirogon »

Cedric Sunnerbury wrote:In my opinion, it'd be better if the modder implemented their own buoyancy with ZScript so that they can decide themselves how to handle cases like how an object bumping into another one - should it stop, should it push the other object up (and have the object push it down to compensate), should their buoyancies average out so that they move/sink as a unit while colliding, or something else, I don't know. Better for the modders to decide than the engine to decide for them.
Make it virtual than, like tick or damage mobj,so that it can be simply overridden by modders to make desired buoyancy, without tricks and crutches with/for hardcoded function.
Guest

Re: +DONTSINK

Post by Guest »

Could do that, yeah.

Here's what I'm thinking now: By default, the Buoyancy property would control the target Z velocity for sinking, replacing WATER_SINK_SPEED in the code. It would be 0 by default, and 0.5 would be subtracted from it, so it'd act exactly the same as it does currently. The behavior I described above would still be activated with the flag, but it'd be renamed something like +ADDITIVEBUOYANCY, and the current gravity would be added to the buoyancy property in the calculations, meaning a Buoyancy of 0 would exactly counteract gravity when fully submerged, no matter what.

The sinking and gravity would be handled in a virtual function called FallAndSink(double g) (or HandleGravity or w/e), so if you want, you could just replace the entire function with "if (!waterlevel) { vel.z -= g; }".
Guest

Re: +DONTSINK

Post by Guest »

Would anyone object to a new Actor class member called "waterdepth"? It'd tell you how many units deep you are inside any body of water, and it'd be done in the same place as the current waterlevel calculations.
User avatar
Nash
 
 
Posts: 17433
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia
Contact:

Re: +DONTSINK

Post by Nash »

Cedric Sunnerbury wrote:Would anyone object to a new Actor class member called "waterdepth"? It'd tell you how many units deep you are inside any body of water, and it'd be done in the same place as the current waterlevel calculations.
This is actually waaaaaaaaaaaaaaay more useful than "waterlevel". I like!
Gez
 
 
Posts: 17833
Joined: Fri Jul 06, 2007 3:22 pm

Re: +DONTSINK

Post by Gez »

It'd be great if, contrarily to waterlevel, it did take into account Heretic-style floor clipping.
Guest

Re: +DONTSINK

Post by Guest »

Floor clipping is purely visual though, and really shouldn't be conflated with actual affects-how-you-move water. The last thing I'd want to deal with is trying to figure out if a waterdepth of 8 is from actually being 8 units deep into a body of water, from standing on a water flat with a TERRAIN definition applied to it, or from a combination of both.
Guest

Re: +DONTSINK

Post by Guest »

I took a crack at implementing the Buoyancy property, but I'm not happy with how it handles at high values (over half the actor's height for non-players, the actor's height for players), and I have a feeling that I'm only going to be satisfied with it by breaking the water movement into multiple pieces, so I'm shelving that for now. Still, no reason to hold back FallAndSink and waterdepth.

Made a pull request for FallAndSink/waterdepth, which would let me do what I needed with +DONTSINK: https://github.com/coelckers/gzdoom/pull/715
Post Reply

Return to “Feature Suggestions [GZDoom]”