T3D bug, 300 AI's jumping/jerking instead of walk *BUG FIX*

#1 You have to be very careful when tinkering with GameBase::getUpdatePriority() because it's essentially a zero-sum game. Artificially boosting the priority of certain objects will in effect reduce the priority of others. As an example, increasing the 'weight' of Players/AIPlayers may 'fix' the warping issue but cause things like projectiles to update later than they normally would (which will manifest as delayed creation/destruction and warping on the clientside).

The reason you see warping with hundreds (or really even a handful) of AIPlayers is because there's simply too much state data for the server to push out into a single packet (of which the size is determined by $pref::Net::packetSize - in bytes). As of 1.1 each AIPlayer required ~14 bytes to update their state so if you have a default packetSize of 200 bytes you may only 'fit' 10-11 AIPlayers into a single packet.

When this happens getUpdatePriority() kicks in and determines the order in which objects have their state data sent out. Objects that are deemed higher 'priority' have their states updated first and things of lesser importance get sent later. getUpdatePriority() insures every object will eventually be updated but depending on the number of objects it could take several packets to do so (which might translate into several seconds depending on the $pref::Net::packetRateToClient setting).

There are a couple alternatives to tinkering with getUpdatePriority():

1). Reduce the bandwidth requirements of AIPlayer. The old RTSKit used this approach in order to get hundreds of networked units on the screen. I don't know the specifics but I do seem to recall some old .plans by Josh Williams discussing the changes.

2). Change Player::sMinWarpTicks, Player::sMaxWarpTicks and Player::sMaxPredictionTicks. I posted some questions/findings about these a while ago here but never got any response. What I found is increasing sMaxWarpTicks allowed me to have hundreds of AIPlayers (well, AIUnits in my case) on the screen/ghosted while still having a very low packetSize.

I believe these variables are for tweaking the clientside interpolation of Player objects. These variables are also still set to something suitable for Tribes 2, FYI.

#2 Ahh, but you see I didn't artificially boost AI, I artificially decreased them.

Instead of sending the whole zone, I only send what is in the cull range, (Which is added by the resource) I then decrease their ranking by the cull range instead of the view distance. I then take the square root of the percentage, to make the AI closer to the player send more updates than the ones farther back.

If you read the code, you will see that I am just culling the AIs which are far enough out that they aren't important to the player.

So, it's not a matter of Artificially boosting anything, it's just better culling.....

#3 This is hot! I cant wait to see the second resource:)

#4 Just to clarify, I wasn't referring to the vis distance change (which makes sense given the resource) but rather the fov change. You're artificially increasing the player's field-of-view which will essentially boost the update priority of objects that would otherwise be considered 'off screen'. The nature of getUpdatePriority() is that changes like that will solve one problem (namely, warping of Players/AIPlayers that are just out of view) but may create another one as some other object will now be packet-starved.

There's nothing wrong with tweaking the weightings in getUpdatePriority(). The current settings are another holdover from Tribes 2 so they probably -should- be tweaked for each project. I just want folks to be aware of the consequences. :]

#5 Interesting recource!