GetUpdatePriority problem - jumping/jerking AI ships
by Thomas \"Man of Ice\" Lund · in Torque Game Engine · 01/22/2007 (2:16 pm) · 31 replies
First
Today (again) I learned something new about the Torque engine!
The engine has a priority system for sending ghosted info over the network, and its available for you too to manipulate! Look for getUpdatePriority() in the engine + examples of its use in GameBase and ShapeBase.
Amazing how many small nifty things there are in the engine once you poke around.
Well - the reason I learned the above it, because I got an issue with Air Ace.
I've been working on AI for Air Ace, and as a basis I've been using my old ships from the unfinished/unreleased Steel Sentinels game I was working on earlier. I ported the ship code and AI to TGEA and got them running.
I noticed a strange update problem (one we also has in Steel Sentinels, but never found the root cause), and now I found it. getUpdatePriority ;-)
First a little movie to show the problem.
airaceonline.arcadersplanet.com/movies/ShipUpdateProblem.wmv (~15 MB)
My ships are AI controlled, but without a AI connection - its basically some scheduled scripts that set rudder+throttle based on a steering behaviour implementation I did.
When you see the movie, you will notice how the ships do a "jerking/warping" motion. I have been up/down and re-read the interpolation code over and over again without finding any bug. So I started doing some interesting experiments with the camera by accident.
When the camera doesnt look at the ships directly, they start moving as expected!!! Its 100% reproducable as you see in the movie.
Also notice something interesting in the end (sorry for the lengthy movie - camera didnt move fast enough until i speed it up).
Once the ships get "far away" they also start to move as expected. Move the camera in, and they start to jump again.
After digging around in the engine, I found the above mentioned getUpdatePriority() and started fiddling with it. But I cant seem to find a good setting. Tried 0.01 (no good ships didnt even appear as a shape) and a value close to 1. When around 1 or over 1, the ships stopped moving completely when looked at!! When camera then moved away the ships jumped to their calculated positions 100-200 meters ahead.
Crazy!!
So this leads me to thinking there must be some bug in there regarding moving shapes that are not player controlled! I dont know why or how, but as I cant find a good priority value, I could surely need some ideas from GG or the community :-)
I basicaly just want my ships to move smoothly as expected when lookup upon. When no one looks, they can jump all they want, hehe.
In exchange you today learned about getUpdatePriority() too ;-)
-----
Bonus info.
Just tried adding a AIconnection as the control object, but the same is observable. Ships jerking.
Additional bonus info is, that it seems to only happen with more than 1 ship!
Today (again) I learned something new about the Torque engine!
The engine has a priority system for sending ghosted info over the network, and its available for you too to manipulate! Look for getUpdatePriority() in the engine + examples of its use in GameBase and ShapeBase.
Amazing how many small nifty things there are in the engine once you poke around.
Well - the reason I learned the above it, because I got an issue with Air Ace.
I've been working on AI for Air Ace, and as a basis I've been using my old ships from the unfinished/unreleased Steel Sentinels game I was working on earlier. I ported the ship code and AI to TGEA and got them running.
I noticed a strange update problem (one we also has in Steel Sentinels, but never found the root cause), and now I found it. getUpdatePriority ;-)
First a little movie to show the problem.
airaceonline.arcadersplanet.com/movies/ShipUpdateProblem.wmv (~15 MB)
My ships are AI controlled, but without a AI connection - its basically some scheduled scripts that set rudder+throttle based on a steering behaviour implementation I did.
When you see the movie, you will notice how the ships do a "jerking/warping" motion. I have been up/down and re-read the interpolation code over and over again without finding any bug. So I started doing some interesting experiments with the camera by accident.
When the camera doesnt look at the ships directly, they start moving as expected!!! Its 100% reproducable as you see in the movie.
Also notice something interesting in the end (sorry for the lengthy movie - camera didnt move fast enough until i speed it up).
Once the ships get "far away" they also start to move as expected. Move the camera in, and they start to jump again.
After digging around in the engine, I found the above mentioned getUpdatePriority() and started fiddling with it. But I cant seem to find a good setting. Tried 0.01 (no good ships didnt even appear as a shape) and a value close to 1. When around 1 or over 1, the ships stopped moving completely when looked at!! When camera then moved away the ships jumped to their calculated positions 100-200 meters ahead.
Crazy!!
So this leads me to thinking there must be some bug in there regarding moving shapes that are not player controlled! I dont know why or how, but as I cant find a good priority value, I could surely need some ideas from GG or the community :-)
I basicaly just want my ships to move smoothly as expected when lookup upon. When no one looks, they can jump all they want, hehe.
In exchange you today learned about getUpdatePriority() too ;-)
-----
Bonus info.
Just tried adding a AIconnection as the control object, but the same is observable. Ships jerking.
Additional bonus info is, that it seems to only happen with more than 1 ship!
#22
BTW, when you ghost the turrets, did you set up some sort of dependency on the object they are mounted to? Sometime similar to how a player mounting a vehicle works? You could be throwing yourself into an usual state there as well, especially if you ghost the turrets down before the initialUpdate for the ship itself arrives, and then you try to mount the turret on the client to a ship that isn't there yet.
01/23/2007 (12:17 pm)
I honestly don't know why the camera distance seems to be a factor.BTW, when you ghost the turrets, did you set up some sort of dependency on the object they are mounted to? Sometime similar to how a player mounting a vehicle works? You could be throwing yourself into an usual state there as well, especially if you ghost the turrets down before the initialUpdate for the ship itself arrives, and then you try to mount the turret on the client to a ship that isn't there yet.
#23
In my case, I have vehicles that are being controlled by AIPlayers mounted as a driver. I am telling the mounted AIPlayer to move using setmovedestination(). As I explained before if the vehicle moves and it is the only vehicle on the screen then the movement is very smooth. However, if the vehicle is displayed on the screen with other vehicles that have AIPlayers mounted on them, the jerky movement becomes quite obvious.
I do have a couple of unrelated customizations in the Torque code (though it is possible that nothing is unrelated in source code!). I'll try it on stock Torque 1.5 and see if the same issue crops up.
01/23/2007 (1:23 pm)
Wow. This thread certainly got big! Thanks to everyone for their input.In my case, I have vehicles that are being controlled by AIPlayers mounted as a driver. I am telling the mounted AIPlayer to move using setmovedestination(). As I explained before if the vehicle moves and it is the only vehicle on the screen then the movement is very smooth. However, if the vehicle is displayed on the screen with other vehicles that have AIPlayers mounted on them, the jerky movement becomes quite obvious.
I do have a couple of unrelated customizations in the Torque code (though it is possible that nothing is unrelated in source code!). I'll try it on stock Torque 1.5 and see if the same issue crops up.
#24
Will be exciting to hear what you come up with Robert!
01/23/2007 (2:15 pm)
So if thats true and showing in stock 1.5 too, then its a deeper issue than wrong interpolation code. Hmmmmm.Will be exciting to hear what you come up with Robert!
#25
01/23/2007 (2:38 pm)
Are both of you making sure that your AI code is only running on the server side?
#26
01/23/2007 (2:48 pm)
From my end - yes. Only on server - absolutely certain
#27
01/23/2007 (5:55 pm)
I am running this as a SingleUser game and everything is taking place only in the "server-side" scripts. I'll be testing this in stock 1.5 tonight. Updates to follow.
#28
The jerky movement is actually worse in stock Torque 1.5.
Making the code change I suggested [if (getType() & (PlayerObjectType || VehicleObjectType))] actually helps to mitigate the issue somewhat.
-Robert
01/23/2007 (8:01 pm)
Just FYI.The jerky movement is actually worse in stock Torque 1.5.
Making the code change I suggested [if (getType() & (PlayerObjectType || VehicleObjectType))] actually helps to mitigate the issue somewhat.
-Robert
#29
01/23/2007 (11:02 pm)
@Robert - is the code to replicate the "bug" very simple. So simple you could post it? Always helps to be able to show someone.
#30
"I need to backstep, apply the update, and then re-apply my moves again...and all this happens by iteratively calling processTick()/interpolateTick() as appropriate."
I'm not dealing with this particular problem Thomas has, but a related issue you mentioned - ensuring my client and server control object stay in sync. How does all the backstepping and rewinding work with processTick(), and where is it happening in the code? I found a good post by Tim Gift a while back, but I've never been able to wrap my head around it, or how to design with it in mind.
I'm extending the player's movement to have a motion that is initiated by a move packet, but then span's multiple ticks - kind of like the player hits a key, and he follows a path for x ticks, where he can't do any other movements - then he gains control of himself again. And I'm getting tons of packet out of sync warnings.
Anyway, any thoughts or pointers are much appreciated! Figured I'd ask here since it's somewhat relevant, and hopefully useful info for others following this thread.
01/26/2007 (9:09 pm)
@Stephen - I have a question about backstepping with control objects."I need to backstep, apply the update, and then re-apply my moves again...and all this happens by iteratively calling processTick()/interpolateTick() as appropriate."
I'm not dealing with this particular problem Thomas has, but a related issue you mentioned - ensuring my client and server control object stay in sync. How does all the backstepping and rewinding work with processTick(), and where is it happening in the code? I found a good post by Tim Gift a while back, but I've never been able to wrap my head around it, or how to design with it in mind.
I'm extending the player's movement to have a motion that is initiated by a move packet, but then span's multiple ticks - kind of like the player hits a key, and he follows a path for x ticks, where he can't do any other movements - then he gains control of himself again. And I'm getting tons of packet out of sync warnings.
Anyway, any thoughts or pointers are much appreciated! Figured I'd ask here since it's somewhat relevant, and hopefully useful info for others following this thread.
#31
I want to control the jumping of Aiplayer.I changed AIPlayer.cc file by
movePtr->trigger[2] = true; but problem is that AIPlayer are jumping like crazy.How will i control it , like when grenade will be blast then player will jump.help me.........
11/15/2007 (1:05 am)
Hello,I want to control the jumping of Aiplayer.I changed AIPlayer.cc file by
movePtr->trigger[2] = true; but problem is that AIPlayer are jumping like crazy.How will i control it , like when grenade will be blast then player will jump.help me.........
Torque Owner Thomas \"Man of Ice\" Lund
Thanks a bunch for at least having pointed at some of the causes.Still cant get my head around that it should suddenly work with camera distance - maybe the turrets get out of scope at that distance or something! Hard to see. And then suddenly free up packet bandwidth.
I hope Robert got something out of this too! He reported similar problems. Wonder if that was some stock object and/or home brew too