Formula for a crate dropping into the water

[Tormentor667]

Okay guys, now I need someone who is quite skilled in physics and maths. What I actually need is an enhanced version of this script:

Code: Select all • Expand view

//Dropping crate
script 69 (void)
{
if (GameSkill () == 1)
    {
    floor_lowerbyvalue(309, 200, 288);
    ceiling_lowerbyvalue(309, 200, 288);
    }
}

As of now, this script gets activated as soon as the player enters a room. If that happens, a crate drops from the ceiling to the ground, directly into a nukage pool. As of now, the whole thing is too linear and obviously not very realistic. What I would like is to have an accelerated drop-movement, the crate drops to the ground, and as soon as it hits the water, there will be splashes and the crate will just waggle for 5-6 times (the longer the slower) after it dropped into the nukage - actually some kind of movement that's realistic.

I have ideas how to do this mathematically but I am missing the knowledge how to combine this with ACS. So if there is someone who is skilled enough and knows what I want to achieve, I'd be very happy

Thanks already,
cheers,
Dan

[FDARI]

Maybe you can work something out from this...

Spoiler:

Code: Select all • Expand view

#include "zcommon.acs"

#define sec_crate 1 // sector containing 3d-floor
#define sec_3d_crate 2 // sector defining 3d-floor (has line-special)

/* Not used, need to scale down for zdoom specials

#define grav_accel 8.969142857142857
#define terminal_velocity 1920.0
#define linear_drag 0.0046714285714286 // grav_accel / terminal_velocity
*/

// Lower instant goes 8-by-8, so I made simple approximations of previous approximations


#define grav_accel 1.85
#define terminal_velocity 500.0
#define linear_drag 0.0037


script 1 open
{
    int velocity = 0, v;
    delay(90);
   
    v = GetSectorFloorZ(sec_crate,0,0) - GetSectorFloorZ(sec_3d_crate,0,0);
    while (v > 0)
    {
        velocity = velocity + grav_accel - FixedMul(linear_drag, velocity);

        if (v > 8 * velocity) v = (velocity + 0.5)>>16;
        else v = (v >>16)/8;
       
        printbold(s:"C = ",f:getsectorfloorz(sec_crate,0,0),s:" F = ",f:getsectorfloorz(sec_3d_crate,0,0),s:"\nLower: ",i:v);

       
        Floor_LowerInstant(sec_crate, 0, v);
        Ceiling_LowerInstant(sec_crate, 0, v);
        delay(1);
       
        v = GetSectorFloorZ(sec_crate,0,0) - GetSectorFloorZ(sec_3d_crate,0,0);
    }
}

The not-used values are based on wikipedia (gravitational constant, or approximate acceleration per second). I should probably have used proper (what's that in english; integration/derivation), which would probably have resulted in a lower acceleration per tick. I also didn't closely represent a meter. (I think I used 30.0 as a little more than half of the very common height 56.0)

The "terminal_velocity" constant is not actively used, because I prefer to precalculate my drag-factor on the side if I'm going to have one.

But the concept is there. Even if it was really frustrating to work in increments of 8.0 what I can calculate at zdoom fixed point precision. So you might need to tweak a bit, unless you know a sector-adjusting function that lets you work with the full precision of the engine.

You can experiment with values (calculate on the side, input as fixed point):
#define grav_accel -- acceleration per tick --
#define terminal_velocity -- not used, but good to have noted --
#define linear_drag -- grav_accel / terminal_velocity --

[ibm5155]

I would just put a zero speed, add a loop and up the speed one by one and he just get out the loop when the floor/ceilling be where it should be ^^

[Tormentor667]

@FDARI - Thanks for the script, this is the way I implemented it

Code: Select all • Expand view

//Dropping crate

#define sec_crate 308 // sector containing 3d-floor
#define sec_3d_crate 309 // sector defining 3d-floor (has line-special)

#define grav_accel 1.85
#define terminal_velocity 500.0
#define linear_drag 0.0037

script 69 (void)
{
if (GameSkill () == 0)
    {
        delay(1);
    }
    else if (GameSkill () == 1)
    {
        int velocity = 0, v;
        delay(90);
   
        v = GetSectorFloorZ(sec_crate,0,0) - GetSectorFloorZ(sec_3d_crate,0,0);
        while (v > 0)
        {
            velocity = velocity + grav_accel - FixedMul(linear_drag, velocity);
   
            if (v > 8 * velocity) v = (velocity + 0.5)>>16;
            else v = (v >>16)/8;
       
            printbold(s:"C = ",f:getsectorfloorz(sec_crate,0,0),s:" F = ",f:getsectorfloorz(sec_3d_crate,0,0),s:"\nLower: ",i:v);
   
       
            Floor_LowerInstant(sec_crate, 0, v);
            Ceiling_LowerInstant(sec_crate, 0, v);
            delay(1);
       
            v = GetSectorFloorZ(sec_crate,0,0) - GetSectorFloorZ(sec_3d_crate,0,0);
        }   
    }
}

...but unfortunately nothing happens at all, the 3D crate doesn't drop even though the sector ids are correct and I didn't change a single value. Is there something else I forgot to take care of?

[FDARI]

Is the printbold-statement happening? If it isn't, then then v is not greater than 0 (the bottom of the crate is already at or below the true line).
However... did I really do that? I seem to have mixed up sec_crate and sec_3d_crate semantically and "corrected" it in my local testmap by assigning the wrong numbers.

The best correction would probably to take every use of sec_crate/sec_3d_crate and swap them. I'd have to load my map to verify, but a quick correction looks like this

Code: Select all • Expand view

        int velocity = 0, v;
        delay(90);
   
        v = GetSectorFloorZ(sec_3d_crate,0,0) - GetSectorFloorZ(sec_crate,0,0);
        while (v > 0)
        {
            velocity = velocity + grav_accel - FixedMul(linear_drag, velocity);
   
            if (v > 8 * velocity) v = (velocity + 0.5)>>16;
            else v = (v >>16)/8;
       
            printbold(s:"C = ",f:getsectorfloorz(sec_3d_crate,0,0),s:" F = ",f:getsectorfloorz(sec_crate,0,0),s:"\nLower: ",i:v);
   
       
            Floor_LowerInstant(sec_3d_crate, 0, v);
            Ceiling_LowerInstant(sec_3d_crate, 0, v);
            delay(1);
       
            v = GetSectorFloorZ(sec_3d_crate,0,0) - GetSectorFloorZ(sec_crate,0,0);
        }

[ibm5155]

shouldn´t have a delay at the end of the while for it works? or the v = GetSectorFloorZ(sec_3d_crate,0,0) - GetSectorFloorZ(sec_crate,0,0); works there?
and getactor only works with enter scripts, I don´t know about this one so i don´t know if it´s that

[Tormentor667]

@FDARI - The "Printbold" statement isn't happening, so that might mean something. Though what do you mean with "If it isn't, then then v is not greater than 0 (the bottom of the crate is already at or below the true line)."?

Do I need to define the "goal height" of the crate somewhere? I absolutely do not understand how things are working here that's why I ask

[FDARI]

You may not even have realized that the reposted code contains a probable fix.
sec_3d_crate should be the sector that defines the 3d-floor (heights, flats and textures)
sec_crate should be the sector that puts the 3d-floor into the map

In my original code, the two were reversed. The original code used sec_3d_crate where it needed sec_crate, and used sec_crate where it needed sec_3d_crate. (I had not noticed during testing, because I had mistakenly assigned the value of sec_3d_crate to sec_crate, and vice versa.)

Aside from that, let's see if we can help your understanding.

Spoiler: Understand?

"int velocity": Keeps an updated velocity for the falling object. Every tick, floor and ceiling is lowered by this amount. Every tick, the velocity is increased.

"delay(90)": I put it there to get a little time before things happen.

"v = GetSectorFloorZ(sec_3d_crate,0,0) - GetSectorFloorZ(sec_crate,0,0);"
sec_3d_crate floor z: the floor (lowest surface) of the crate
sec_crate floor z: the floor (lowest surface) of the sector containing the crate

"sec_3d_crate floor z" - "sec_crate floor z": distance from bottom of crate to the floor that will stop it. If v is 0, the crate has hit the floor. If v is less than 0, the crate has gone through the floor (the code tries to prevent that from happening).

"while (v > 0)..." as long as the crate is still above the floor

"velocity = velocity + grav_accel - FixedMul(linear_drag, velocity);" ... math. Increase velocity by a fixed amount (grav_accel). Reduce acceleration by a value that increases the faster you are falling. (When acceleration is 100% reduced, the crate falls at constant speed; terminal velocity) This is a rough mathematical approximation of stuff as it happens in the real world.

"if (v > 8 * velocity) v = (velocity + 0.5)>>16;"
"else v = (v >>16)/8;"

8: Several specials multiply height changes by 8, which means they go 8 times too fast. The grav_accel and linear_drag have been divided by 8 to correct for this.
"velocity" holds the distance to be traveled, in fixed point / map units. This distance will be multiplied by 8 in Floor_LowerInstant.
Movement towards the floor = 8 * velocity.

"v" holds the remaining distance to the floor. If movement towards the floor is more than remaining distance, the crate should instead move to the floor and stop there. (v is actual distance, but would be multiplied by 8 in Floor_LowerInstant. We must therefore divide it by 8 if we use it.)

Review that one again. We assign to v in this statement. After this statement, v holds the distance to be traveled (or actually, that distance divided by 8).
"if (v > 8 * velocity) v = (velocity + 0.5)>>16;"
--- IF remaining actual distance (v) IS GREATER THAN distance to be traveled (8 * velocity): v = (velocity + 0.5)>>16;
--- (velocity + 0.5)>>16: convert from fixed point to integer and round to nearest

-- ELSE (if remaining actual distance is less than the crate would travel at its current velocity): v = (v >>16)/8;
--- actual remaining distance, converted to int and divided by 8

Spoiler: Too advanced, performance potential

Could probably use "v = v >> 19;". Really, pay it no mind for now. I doubt there will be a noteable performance gain.

-- Then there's a print for debugging purposes

-- And we lower floor and ceiling by v. v is determined by velocity or remaining distance to the ground, whichever is less.
-- Then we delay so that time gets to pass in the game.

-- Then "v = GetSectorFloorZ(sec_3d_crate,0,0) - GetSectorFloorZ(sec_crate,0,0);"
-- we calculate the distance from crate to ground again. If we are above the ground, we keep moving down, from the top of the loop.

Goal height in my script: The floor of the sector the crate drops into. If you want a goal height that is not the floor of the actual sector, you will need to change something.

[Tormentor667]

Okay, got it so far. It avtually works, though it doesn't seem to work correctly at the moment.

The crate drops too fast at the moment, it accelerates too fast. How can I decrease the acceleration and speed that the crate drops? Which variable is the right one to edit here?

[FDARI]

#define grav_accel 1.85
- This is the acceleration, set it to a lower value. (Try 1.0, try 0.5; and write them like that, do NOT write "1", write "1.0".)
- 0.5 would probably result in 0 units drop at first, 1.0 will probably be a bit more even, and still slower than what you have right now.

#define linear_drag 0.0037
- This is the "drag"; it reduces acceleration when speed gets higher. ( new speed = old speed + acceleration - old speed * drag );
- Most likely you won't note much the effect of this unless you have things falling slowly or set it to a very high value
- Higher drag causes acceleration to drop off sooner, stabilizing the fall at a lower top speed.
- Drag around 1.0 will just about negate gravity. (Probably not a good idea with my script)
- Drag around 0.5 is high.
- You can always try 0.005 or 0.01

I found this kinda decent:

#define grav_accel 1.0
#define linear_drag 0.005

It's still quite fast, but any slower doesn't feel much like a gravity-driven drop.

[Tormentor667]

Thanks again for the explanation, that does the job