Setting Player::mRot.z
by Daniel Buckmaster · in Torque Game Engine · 09/08/2008 (4:42 am) · 3 replies
I'm using Derk Adams' Do the Twist resource as a base for my own torso-twist modifications to Player. However, I'm experiencing some problems when setting a Player's mRot.z member. It gets set to just about the right value, but there's some sort of 'whiplash' effect for a fraction of a second afterwards - the player turns further than he should, then snaps back to the right direction.
I turned the timescale variable down to see if I could get a better look at this behaviour - and it goes away! I believe this indicates that the problem is somewhere in Torque's prediction of mRot.z. It overpredicts, then gets straightened out next tick. What should I do to debug and solve this? I don't know where to begin debugging prediction/interpolation :P
I turned the timescale variable down to see if I could get a better look at this behaviour - and it goes away! I believe this indicates that the problem is somewhere in Torque's prediction of mRot.z. It overpredicts, then gets straightened out next tick. What should I do to debug and solve this? I don't know where to begin debugging prediction/interpolation :P
About the author
Studying mechatronic engineering and computer science at the University of Sydney. Game development is probably my most time-consuming hobby!
#2
09/08/2008 (8:29 am)
Thanks for the information. I don't really feel up to figuring this out, though :P. I solved my 'whiplash' problem with a workaround that actually isn't really a workaround. I'm just making the change gradual instead of instant - that way, buy the time the issue (whatever it was) becomes an issue, the numbers are too small to produce a noticable effect. It also makes character movement more natural - characters turn their bodies instead of just popping to the correct direction. 
#3
09/08/2008 (11:52 am)
Have you tried changing sMinWarpTicks to something higher than 0.5? 
Associate James Ford
Sickhead Games
Torque doesn't really do any prediction that I'm aware of. Well it "sortof" does in that the move is generated on the client side, and it is processed there (updateMove) first before sending it to the server. So you could say that is the client side prediction of what will happen on the server.
Then the move is sent to the server and processed there (updateMove again). The server also receives a CRC from the client containing all "correctable" player data, like position, rotation, (maybe health), the stuff you see in writePackedData. If that data does not match on the server after processing the move, then the client object will be corrected with the server data in the next readPackedData on the client side.
You can see where the move is sent from client to server in packUpdate if you look for something that starts like this:
if ( stream->writeFlag( mask & MoveMask ) ) { // writing delta.pos, etc..Another complexity is that when the client does receive a correction from the server (after a CRC check fail) it does not happen immediately, it occurs over several "warp-ticks". Search for warpTicks in player.cpp and .h to find more.
So for example, what "could" be happening, is that the client object (the one you are seeing rendered) is turning farther than the server one for some reason and then the whiplash is the server correcting it.