AI players leaves mounted objects behind
by Bjarne Grönnevik · in Torque Game Engine · 09/16/2004 (1:51 am) · 15 replies
Background: We are having AIPlayers that are constructed around the core model ( image 2 ) in the script. They are mounted on mount points that are attached to an animated skeleton made in Maya. The reason for this is that we want the mechas to be able to get parts blown out of them.
Problem: Most mechas are mounted OK, but some leave some of their parts behind when they move away from their spawn locations. The parts left vary from all to some to none ( mostly all ). As you can see from the pictures below: they actually have the parts mounted, as the control points are where they should be ( if you press F11 and click on a "ghost object", it is then drawn correctly in the correct place on the mecha... and the "ghost object" it left behind is gone ).
The "ghosts" of the mechas parts:
( Image 1 )
The actual mecha ( note that the control points of the parts are present, but still the parts are not drawn ):
( Image 2 )
A mecha as it should be mounted. Most mechas look like this, it is 2 out of 6 mechas that have this strange behaviour:
( Image 3 )
The actual code doing it is around 25 repetitions of this code ( with different entities and mounts, naturally ):
Does anyone have any idea why this would happen? And why it does not happen in the same way all the time?
Problem: Most mechas are mounted OK, but some leave some of their parts behind when they move away from their spawn locations. The parts left vary from all to some to none ( mostly all ). As you can see from the pictures below: they actually have the parts mounted, as the control points are where they should be ( if you press F11 and click on a "ghost object", it is then drawn correctly in the correct place on the mecha... and the "ghost object" it left behind is gone ).
The "ghosts" of the mechas parts:
( Image 1 )The actual mecha ( note that the control points of the parts are present, but still the parts are not drawn ):
( Image 2 )A mecha as it should be mounted. Most mechas look like this, it is 2 out of 6 mechas that have this strange behaviour:
( Image 3 )The actual code doing it is around 25 repetitions of this code ( with different entities and mounts, naturally ):
%flag = new StaticShape()
{
datablock = km_flagShape;
};
MissionCleanup.add( %flag );
%player.flag = %flag;
%player.mountObject(%flag, 2);Does anyone have any idea why this would happen? And why it does not happen in the same way all the time?
#2
Update: After delaying the start og the mecha construction some seconds using a schedule, they now haul their parts with them as they depart. But they still suddenly ( and unpredictably ) drop their parts after a while. Typically all parts at once. The behaviour above is still unchanged ( if you press F11 and click on a "ghost object", it is then drawn correctly in the correct place on the mecha... and the "ghost object" it left behind is gone ).
09/16/2004 (6:08 am)
Thanx, but I'm more concerned about function than looks right now ;)Update: After delaying the start og the mecha construction some seconds using a schedule, they now haul their parts with them as they depart. But they still suddenly ( and unpredictably ) drop their parts after a while. Typically all parts at once. The behaviour above is still unchanged ( if you press F11 and click on a "ghost object", it is then drawn correctly in the correct place on the mecha... and the "ghost object" it left behind is gone ).
#3
09/16/2004 (7:11 am)
Does this happen for regular network players or just AIplayers?
#4
For some reason it also seems to affect only the AIs that spawn first in the sequence...
09/16/2004 (7:25 am)
We only have a local player ( this is an single player demo ). This only happens for the AI, never for the local player.For some reason it also seems to affect only the AIs that spawn first in the sequence...
#5
It sounds like its not ghosting the movements of the parent object to the child (usually setup in processAfter I guess).
Most of the objects Ive seen mounted have been using shapebaseimage's and mountItem (which works on shapebase classes and DOES update them specifically) I'm not entirely sure what the update route is with shapes mounted on other shapes.
09/16/2004 (7:51 am)
If those are mounted, should you be using mountImage rather than mountobject?It sounds like its not ghosting the movements of the parent object to the child (usually setup in processAfter I guess).
Most of the objects Ive seen mounted have been using shapebaseimage's and mountItem (which works on shapebase classes and DOES update them specifically) I'm not entirely sure what the update route is with shapes mounted on other shapes.
#6
But naturally there is no such thing as a simple solution... the reason we use mountObject is that you can only mount 8 images... but I see no real reason we could not boost that number a bit :)
There was also some talk about using separate collision boxes on the mounted objects, but I think we skipped that: it's of no consequence any more.
Could this solve an AI lag problem whe are having as well? :
When giving an AI a setMoveDestination command, it does a half walk, half teleport type movment. The mounted objects seem to have a hard time keeping up.
09/16/2004 (8:10 am)
As soon as you said it, I got filled with hope. As the only things the mecha never looses are its gun mounts ( attached with mountImage ).But naturally there is no such thing as a simple solution... the reason we use mountObject is that you can only mount 8 images... but I see no real reason we could not boost that number a bit :)
There was also some talk about using separate collision boxes on the mounted objects, but I think we skipped that: it's of no consequence any more.
Could this solve an AI lag problem whe are having as well? :
When giving an AI a setMoveDestination command, it does a half walk, half teleport type movment. The mounted objects seem to have a hard time keeping up.
#7
09/16/2004 (8:56 am)
Are the mechs customizable by mounting different sections or are you just using this for dammage effects? If its just for damage effects, mesh hiding would work a lot better.
#8
( and yes, they are designed to be able to use different waepon mounts as well as different mech configurations and mounting custom parts )
09/16/2004 (9:01 am)
The thing is that they are designed to be blown clean off, as in hurled away, bouncing of anything it hits... and perhaps explode after a while... yessss... explosions are a must :)( and yes, they are designed to be able to use different waepon mounts as well as different mech configurations and mounting custom parts )
#9
I noticed that the AIs did a lot less of the half walk, half teleport type movment when I enterd the "spectator mode". So we suspected the network code ( as I think the player stops sending some updating data when in "spectator mode" ).
So I changed the lines:
After that the AIs were smooth as a baby-butt.
We are creating a singleplayer, so the values may be way to big for any multiplayer games. But tweak on if you have the same trouble as we did.
The mechas still loose their parts however :'(
09/17/2004 (8:47 am)
In reply to my own question before:Quote:Could this solve an AI lag problem whe are having as well? :
When giving an AI a setMoveDestination command, it does a half walk, half teleport type movment. The mounted objects seem to have a hard time keeping up.
I noticed that the AIs did a lot less of the half walk, half teleport type movment when I enterd the "spectator mode". So we suspected the network code ( as I think the player stops sending some updating data when in "spectator mode" ).
So I changed the lines:
$Pref::Net::LagThreshold = "400"; $pref::Net::PacketRateToClient = "10"; $pref::Net::PacketRateToServer = "32"; $pref::Net::PacketSize = "200";...to:
$Pref::Net::LagThreshold = "800"; $pref::Net::PacketRateToClient = "20"; $pref::Net::PacketRateToServer = "64"; $pref::Net::PacketSize = "400";( doubling it ).
After that the AIs were smooth as a baby-butt.
We are creating a singleplayer, so the values may be way to big for any multiplayer games. But tweak on if you have the same trouble as we did.
The mechas still loose their parts however :'(
#10
09/17/2004 (3:10 pm)
Is PacketRateToXXXXX a value representing how many packets to send in a fixed time frame, or a time frequency (in ms) at which to send packets? I always thought the latter, but if doubling all those values smoothed out your AI movement glitches, I'm wondering if I have it backwards.
#11
When in doubt: Check the code :)
09/18/2004 (4:49 am)
Well, either you have it backwasrds, or one of the other values affects this behavior more.When in doubt: Check the code :)
#12
First, yes PacketRateToXXXX is a frequency as I thought. They are used in the code solely to calculate another internal variable (PacketUpdateDelayToServer or toClientUpdateDelay accordingly) which is the real delay between updates. Strangely, this calc is done against a value of 1024 and not 1000 so the math does not strictly represent 'times per second' (but it's very close) unless there's some compensating mechansim elsewhere.
Additionally, There are some constraints enforced on the pref values. PacketRateToXXXX is forced to be between 8 and 32 for the server and 1 and 32 for the client. PacketSize is also constrained to 100 minimum, 450 maximum.
Incidentally LagThreshold appears to be used exclusively to pop up the 'lag icon' in the UI.
So I guess this means doubling the PacketSize value is likely to have been what fixed up the AI. :)
09/18/2004 (7:11 am)
Indeed! I was not at my machine at the time so I was unable to do so then, but I've done so now and the info is definitely good to know.First, yes PacketRateToXXXX is a frequency as I thought. They are used in the code solely to calculate another internal variable (PacketUpdateDelayToServer or toClientUpdateDelay accordingly) which is the real delay between updates. Strangely, this calc is done against a value of 1024 and not 1000 so the math does not strictly represent 'times per second' (but it's very close) unless there's some compensating mechansim elsewhere.
Additionally, There are some constraints enforced on the pref values. PacketRateToXXXX is forced to be between 8 and 32 for the server and 1 and 32 for the client. PacketSize is also constrained to 100 minimum, 450 maximum.
Incidentally LagThreshold appears to be used exclusively to pop up the 'lag icon' in the UI.
So I guess this means doubling the PacketSize value is likely to have been what fixed up the AI. :)
#13
I'm asking becuase the AI vehicles in my game have the same behavior (sometimes just teleport forward).... but offcourse I can't afford to have laggy networking, its a multiplayer game.
09/18/2004 (7:49 am)
How does doubling the packet size affect the net performance. Does this affect the bandwidth the server needs? Does it slow down the networking?I'm asking becuase the AI vehicles in my game have the same behavior (sometimes just teleport forward).... but offcourse I can't afford to have laggy networking, its a multiplayer game.
#14
Changing the value from 200 to 400 would effectively double the maximum required bandwidth per client, which I'd guess means not only doubling the downstream bandwidth requirement of each client, but also doubling the upstream bandwidth requirement of the server, which is of course already multiplied by the number of clients it is serving.
This may or may not be a problem; the above numbers are only talking about the difference between 2k and 4k roughly, if I understand the gist of things.
Comments or corrections from anyone who's looked at it in more depth would be welcome. :)
09/18/2004 (8:47 am)
Offhand it looks like packetSize dictates how big the buffer is for the stream on a per-transaction basis, so assuming there is enough data queued to be sent, this would directly effect bandwidth requirements, as would be expected.Changing the value from 200 to 400 would effectively double the maximum required bandwidth per client, which I'd guess means not only doubling the downstream bandwidth requirement of each client, but also doubling the upstream bandwidth requirement of the server, which is of course already multiplied by the number of clients it is serving.
This may or may not be a problem; the above numbers are only talking about the difference between 2k and 4k roughly, if I understand the gist of things.
Comments or corrections from anyone who's looked at it in more depth would be welcome. :)
#15
09/20/2004 (4:57 am)
If you're going single player only, you can go into the code and bump the packet size up to 5000 or so and it'll decrease your loading times a bunch. By default it limits it to 450. 
Torque Owner Gonzo T. Clown