Skip to main content
added 290 characters in body
Source Link

What I suggest you do is to simulate the change client-side, using the same calculation on server-side, and send request to the server at the same time, using a timestamp to know what value it is. Then, when the server answers, with its own, checked value, compare it to the value you had computed at that timestamp, and if it is incorrect, change it.

You can perform the check only when the stamina has stopped being used, to avoid having multiple check requests, and to avoid to have to store their values.

== EDIT ==

You're effectively right about the stamina being in constant use. There is indeed no point in making the checks when it stops going down/up, so you can simply make checks something like every 30-40-50 ms, depending on the rate you send packets to server.

== END EDIT ==

As it is very improbable that the results are different (if you use the same calculation...), there would be therefore no jumpy behaviours, except if someone modifies its own client (but then it's his fault if he makes everything bug out :D)

What I suggest you do is to simulate the change client-side, using the same calculation on server-side, and send request to the server at the same time, using a timestamp to know what value it is. Then, when the server answers, with its own, checked value, compare it to the value you had computed at that timestamp, and if it is incorrect, change it.

You can perform the check only when the stamina has stopped being used, to avoid having multiple check requests, and to avoid to have to store their values.

As it is very improbable that the results are different (if you use the same calculation...), there would be therefore no jumpy behaviours, except if someone modifies its own client (but then it's his fault if he makes everything bug out :D)

What I suggest you do is to simulate the change client-side, using the same calculation on server-side, and send request to the server at the same time, using a timestamp to know what value it is. Then, when the server answers, with its own, checked value, compare it to the value you had computed at that timestamp, and if it is incorrect, change it.

You can perform the check only when the stamina has stopped being used, to avoid having multiple check requests, and to avoid to have to store their values.

== EDIT ==

You're effectively right about the stamina being in constant use. There is indeed no point in making the checks when it stops going down/up, so you can simply make checks something like every 30-40-50 ms, depending on the rate you send packets to server.

== END EDIT ==

As it is very improbable that the results are different (if you use the same calculation...), there would be therefore no jumpy behaviours, except if someone modifies its own client (but then it's his fault if he makes everything bug out :D)

Source Link

What I suggest you do is to simulate the change client-side, using the same calculation on server-side, and send request to the server at the same time, using a timestamp to know what value it is. Then, when the server answers, with its own, checked value, compare it to the value you had computed at that timestamp, and if it is incorrect, change it.

You can perform the check only when the stamina has stopped being used, to avoid having multiple check requests, and to avoid to have to store their values.

As it is very improbable that the results are different (if you use the same calculation...), there would be therefore no jumpy behaviours, except if someone modifies its own client (but then it's his fault if he makes everything bug out :D)