Author Topic: Standing On Something [Solved]  (Read 1035 times)

Is there a way to detect if the player is standing on top of something?
« Last Edit: October 12, 2012, 07:12:34 AM by jes00 »

A *somewhat* hacky way of doing this is to check if the vertical velocity of the player is 0, because if it is 0 then they aren't moving up and down, ie standing on something.

It won't work on ramps and possibly if they somehow manage to jet in the same place with incredibly accuracy, though.

Shoot a raycast from the player's feet, check the vector distance, and then check their velocity.

Ipquarx's way is the fastest way.

Ipquarx's way is the fastest way.

But it's not 100 percent accurate. If i jump, and hit the peak of my jump, my z velocity will be at 0 for a split second.

But it's not 100 percent accurate. If i jump, and hit the peak of my jump, my z velocity will be at 0 for a split second.
It more than likely never will be. The chances of the gravity equations actually crossing zero exactly are infinitesimal. Your velocity would way more likely be between 0.00001 and 0.05.

Unless the person is falling down some ramps, my method is fine. in real life your velocity in mid-air would only be 0 for quite literally an infinitely short period of time. faster than an instant. It's no different here.

Although I am fairly certain there is a default way to check if a player is on an object, I am unsure of it at this time.

Unless the person is falling down some ramps, my method is fine. in real life your velocity in mid-air would only be 0 for quite literally an infinitely short period of time. faster than an instant. It's no different here.

Although I am fairly certain there is a default way to check if a player is on an object, I am unsure of it at this time.

If he is running a constant check for whatever reason, he'll need another check (my check). If he is calling it once, then he should be fine. Trust me, i know what i'm talking about.

It's no different here.
Unless you've tailored blockland gravity to apply the minimum possible downward force per tick as allowed by a float value, it's different here. Imagine this:

You have a z speed value of 50. Gravity is 3 per tick.
Tick 1: 47
Tick 2: 44
Tick 3: 41
..
Tick 15: 5
Tick 16: 2
Tick 17: -1

See how it skipped over 0?

Or a more relevant example:

Your velocity is 8.21529 with 0.003 gravity per tick.

After 2738 ticks, your velocity has been reduced to 0.00129. After the next tick, your velocity is -0.00171. It skipped over zero. It will almost exclusively always skip over zero. There will probably never be a situation where the initial velocity is divisible by the gravity factor.
« Last Edit: October 11, 2012, 09:18:08 PM by Trinick »

Slick has a valid argument, but nothing can be proven for sure until it has actually been proven. Arbitrarily assigning gravity a deceleration of 3 units/second^2 and the initial speed to be a number not divisible by 3 doesn't prove much but a concept. Jes should use ipquarx's method and report back whether or not the raycast needs to be added for accuracy

Slick has a valid argument, but nothing can be proven for sure until it has actually been proven. Arbitrarily assigning gravity a deceleration of 3 units/second^2 and the initial speed to be a number not divisible by 3 doesn't prove much but a concept. Jes should use ipquarx's method and report back whether or not the raycast needs to be added for accuracy
See my second example. It proves why it's not an issue. The only reason it would be an issue is if it was the absolute smallest value a float could hold-- because then every number would be divisible by it. But I know for a fact it isn't, because gravity can be slowed using physical zones, and since that's the smallest possible value there's clearly an issue. That won't stop velocities from using up every possible point value in a float, and if your velocity occupies more place values than the gravity factor it will never be divisible.
« Last Edit: October 11, 2012, 09:22:21 PM by Trinick »

My method will work unless the player is moving up/down a plane, as in a ramp.

About elm's argument, if you do a 50ms loop echoing the vertical velocity (which I just did to test it out), then start jumping, the closest it will ever get to 0 is 0.0100002. You see how many decimal places that is? you'd need to be running a loop at less than a tenth of a millisecond in order to get even half close to that many decimal places. It just won't happen.

If you don't believe me, try it yourself.