How do I know when a Jump is done?

Quote:

Originally Posted by Korvacs ...right, do you have a point?

no point :)

@yuki
add a timer to jumping handlers and do 2 plain normal speed jumping, first packet will set timer and second packet will stop it
disconnect the internet connection and hamachi ip will loop back causing no latency or delay for the packets, easy and pretty accurate

Quote:

Originally Posted by asdfghjklwertyuiopzxcvbnm no point :) @yuki add a timer to jumping handlers and do 2 plain normal speed jumping, first packet will set timer and second packet will stop it disconnect the internet connection and hamachi ip will loop back causing no latency or delay for the packets, easy and pretty accurate

No.

Quote:

Originally Posted by Y u k i No.

no as in it won't get the job done or no as in i won't do that cuz it was your idea ?

Quote:

Originally Posted by asdfghjklwertyuiopzxcvbnm no as in it won't get the job done or no as in i won't do that cuz it was your idea ?

No, as in read what I said I want, and no, because Timers aren´t the medicine for everything.

As I already stated, that was my current approach, however using timestamps instead. Second of all, hamachi? Where did that come from...

Quote:

Originally Posted by asdfghjklwertyuiopzxcvbnm no as in it won't get the job done or no as in i won't do that cuz it was your idea ?

The way you described that approach is really, overly complex and to be blunt really dumb.

You don't need to do most of what you described, the packets that contain the jump request contain a timestamp so you can compare those to determine the interval. Furthermore you have no need to use hamachi as there is no delay to connect to a locally hosted server anyway, it already uses the loopback mechanism.

it is kinda the same, i rather add 2 lines of code to get the result on console than do it manually with timestamp considering that their is no delay at looping back it should be the same right ?

and well about hamachi, in egypt it cost money to get static ip which i ain't going to pay, but if their another way other than hamachi and static ip please feel free to mention it

and i don't know how hamachi fully works that's why i've said you should disconnect from internet to guarantee that it will loop back

and @yuki that would get you the time for jump animation, try it from x to x + 1 then from x to x + 2 , that would get you the jump animation time and time added per tile , won't that get the job done o-0

How would timing the packets get you the time for the jump animation?
Someone feel free to correct me if I am wrong here but....
The jump animation starts regardless of the packet, that is controlled completely client sided. (Your own jumps at least).
So by putting timers in, you aren't measuring the jump animation, you are measuring how long it takes for the server to process the packet. Which isn't even what Yuki asked for. Not to mention it is completely subjective to how jumping is coded. While this is a complete exaggeration, but if there is a loop that is executed 1000 times, I am pretty sure the time you get isn't going to be accurate.

But as Korvacs stated, if you are checking for speedhacks then yes you want to check the time intervals between jump packets, because that tells you how often a user is jumping, which also gives you a decent indication of how fast they are jumping.

Making sure you cannot execute an attack midair among other things will require a different approach
But all of this is pointless anyway because Yuki says he has what he has asked for.

Quote:

Originally Posted by Aceking How would timing the packets get you the time for the jump animation? Someone feel free to correct me if I am wrong here but.... The jump animation starts regardless of the packet, that is controlled completely client sided. (Your own jumps at least). So by putting timers in, you aren't measuring the jump animation, you are measuring how long it takes for the server to process the packet. Which isn't even what Yuki asked for. Not to mention it is completely subjective to how jumping is coded. While this is a complete exaggeration, but if there is a loop that is executed 1000 times, I am pretty sure the time you get isn't going to be accurate. But as Korvacs stated, if you are checking for speedhacks then yes you want to check the time intervals between jump packets, because that tells you how often a user is jumping, which also gives you a decent indication of how fast they are jumping. Making sure you cannot execute an attack midair among other things will require a different approach But all of this is pointless anyway because Yuki says he has what he has asked for.

2 sequential jumps should have the same errors, same delays ,same socket looping, what so ever but if you still didn't get the point
TL;DR
assume each packet is sent 50 ms after the jump is done at client, and assume that the socket loops does loop each 100 ms which will sum up to 150 second delay at each which won't still matter because it's relative to the first packet which had those delays too not absolute
but still time stamp would have errors aswell as it may also get into some check while jumping in the first jump which it didn't in the second jump
so all in all both will have errors and it won't really matters as it's all matters of milli seconds

but yeah i should say it's more clean to be done with timestamp

The packet is send before the jump animation.

Quote:

Originally Posted by Super Aids The packet is send before the jump animation.

i know this isn't worth the argument but i meant this as relative which mean that
assume packet is sent 500 ms before the actual animation in both jumps, the equations would be something like
time received first jump = time first jump is applied - 500 ms
time received second jump = time second jump is applied - 500 ms
so delta times (time it took to jump and land) = (time second jump is applied - 500 ms) - (time first jump is applied - 500 ms)
= time second jump is applied - time first jump is applied

but yeah their is more reasons just to use time stamp, ex. if client is using packet queue (aka sending packets in order, it will send more packets before the second than before the first request which delay some more ms(s))