Game Development Community

[bug] Ghosts are created in the reverse order - LOGGED

by Manoel Neto · in Torque 3D Professional · 09/10/2010 (8:47 pm) · 6 replies

Some calls to tree are enough to confirm this this: the ghost list is a reversed mirror of the server-side objects. This is not the kind of bug that would affect most Torque projects, but it bit me since the heavily-modified project I'm working on relies on synchronization between client and server. In my case, it causes triggers to fire in reverse order in client and server when the Player happens to touch both at the same time.

(I remember a very similar problem back in TGE days with the shape replicator).

#1
09/12/2010 (9:05 pm)
Yea... TGE has always worked like this. I don't know if it was done for a specific technical reason or not.

I know for the next major release of Torque we'll fix it, but i don't know what sort of side effects reversing that order would have on existing projects.
#2
09/13/2010 (1:49 pm)
In NetConnection::activateGhosting(), I tried reverting this loop (which is backwards):

for (j = mGhostZeroUpdateIndex - 1; j >= 0; j--)
However it wreaks havok when loading the game. I suspect ghostPushToZero() is the one to blame, since it seems to depend on the ghosts being processed in reverse somehow.
#3
09/13/2010 (9:11 pm)
Okay, here's how to "fix" this: in NetConnection::activateGhosting(), replace:

for(i = ghostAlwaysSet->begin(); i != ghostAlwaysSet->end(); i++)

By:
for(i = ghostAlwaysSet->end()-1; i >= ghostAlwaysSet->begin(); i--)
This is enough to send the objects in the same order as they exist in the server.
#4
09/15/2010 (5:20 pm)
Logged as TQA-1071 for QA to verify
#5
10/04/2011 (10:27 am)
** bump just in case this has been forgotten, I notice it doesn't have a THREED code.
It's still an issue.
#6
10/05/2011 (4:23 pm)
Last I checked, scope ghosts are created in reverse order to maintain the network masking system -- so that each of the various clients have the appropriate data sent. I can't really remember the specifics of it all (it's been a long time since I wrote the code used for speeding up the loading times on local clients), but I do remember there were issues for late-connecting clients and stuff if you did it the other way around.

You'd probably want to check your proposed fix for whether or not it causes problems with dedicated servers and for clients joining the game late. Given that some of the other changes that have been made to "improve" the engine have actually broken things (eg. the whole $timescale thing), I tend to lean more towards leaving it as is unless you understand exactly what you're doing when changing it.