+DONTSINK

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

Moderator: GZDoom Developers

+DONTSINK

Postby Cedric Sunnerbury » Sat Jan 05, 2019 8:52 am

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

Re: +DONTSINK

Postby ZzZombo » Sat Jan 12, 2019 10:08 am

Better implement a `buoyancy` variable, with `+DONTSINK` being an edge case for that.
ZzZombo
 
Joined: 16 Jul 2012

Re: +DONTSINK

Postby Graf Zahl » Sat Jan 12, 2019 10:39 am

Yeah, that's precisely why I haven't done anything with it yet. The idea itself is fine but this is too limited.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: +DONTSINK

Postby Cedric Sunnerbury » Sat Jan 12, 2019 7:49 pm

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

Re: +DONTSINK

Postby Cedric Sunnerbury » Sat Jan 12, 2019 8:53 pm

(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.
Cedric Sunnerbury
 

Re: +DONTSINK

Postby Apeirogon » Sun Jan 13, 2019 3:59 am

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.
Apeirogon
I have a strange sense of humour
 
Joined: 12 Jun 2017

Re: +DONTSINK

Postby Cedric Sunnerbury » Sun Jan 13, 2019 5:39 pm

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; }".
Cedric Sunnerbury
 

Re: +DONTSINK

Postby Cedric Sunnerbury » Tue Jan 15, 2019 9:36 pm

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

Re: +DONTSINK

Postby Nash » Tue Jan 15, 2019 9:48 pm

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!
User avatar
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes
Operating System: Windows 10/8.1/8 64-bit
Graphics Processor: nVidia with Vulkan support

Re: +DONTSINK

Postby Gez » Wed Jan 16, 2019 5:51 am

It'd be great if, contrarily to waterlevel, it did take into account Heretic-style floor clipping.
Gez
 
 
 
Joined: 06 Jul 2007

Re: +DONTSINK

Postby Cedric Sunnerbury » Wed Jan 16, 2019 6:24 pm

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

Re: +DONTSINK

Postby Cedric Sunnerbury » Mon Jan 21, 2019 3:38 am

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
Cedric Sunnerbury
 


Return to Feature Suggestions

Who is online

Users browsing this forum: No registered users and 2 guests