Game Development Community

NetObj data ghosts to local-client, but not remote-clients. why?

by Steven Peterson · in Torque Game Engine · 07/01/2008 (3:10 pm) · 6 replies

A month or so ago, I was having some trouble with some network code. Essentially I created an fxRenderObject. Then I created an 'interface class' to manipulate one or a group of those objects in the game. As an example, typing in the console 'myObjectManger.changeColor(objA, red); might find the fxRenderObject named 'objA' and change it's color to Red.

At the time this was driving me crazy because the changes were happening in the debuger-window, but not visible "in-game". I eventually learned there's a server-object and a client-object (even in a single player game) and data has to be ghosted from one to the other. Soon everything was working right, and I presumed it would now work correctly in a LAN game also,. ( forum post: http://www.garagegames.com/mg/forums/result.thread.php?qt=75016)

So I finally tested this across the LAN for real and guess what? If I type the command into the console on the server-machine the changes happen there, but are not replicated on the client-machine's view of the game world.

It seems data is being correctly ghosted between the server and local-client, but not the server and remote-client. How can this be and where should I start looking?

Thanks,
Steven

#1
07/01/2008 (3:55 pm)
Hm, odd.

try putting a debug print at the top of the object's packUpdate() and unpackUpdate().
you should see one packUpdate() for every connected client in network scope,
and of course each client should have a corresponding unpackUpdate().
#2
07/07/2008 (4:50 pm)
Orion, Thanks that was a great idea! While running that test I proved that the data IS being ghosted, and inadvertently discovered the real problem.

Keeping with the example, when I call "myObjectManger.changeColor(objA, red, 30)" where 30 is the # of seconds to interpolate the change over, a variable "mTargetTime" is calculated server side. mTargetTime = seconds * 1000 + Sim::getCurrentTime(); This value is ghosted to the clients, who repeatedly look at mTargetTime - Sim::getCurrentTime() to evenly interpolate the change.

The problem is that when each client calls sim::getCurrentTime(), they each get their OWN internal value, not a synchronized time value from the server.

I THINK mTargetTime will have to be calculated client-side... Interesting, huh?
#3
07/07/2008 (5:22 pm)
Indeed, you'll probably need some notion of synchronized time.
i think there was just a thread about that, but i can't find it now.

another way to go about it would be to ghost down the number of seconds remaining in the transition.

while you can't be sure when a packUpdate() will occur,
once it's happened, the latency to the client is pretty low (i think),
so for each client you could send down mTargetTime - Sim::getCurrentTime(),
and on the client do something like mTargetTime = Sim::getCurrentTime() + stream->readFloat() or whatever.

note this means that different client will likely get different values in their unpackUpdates(), which is a little non-standard, but perfectly fine.
#4
07/07/2008 (5:24 pm)
That was exactly it.
Fixed! Thanks. :-)


[edit]
I ghosted the "seconds" parameter to the clients, and calculated 'mTargetTime' client side. I'm sending the same quantity of network data now, and the server does one less calculation this way.

Used a slight hack to accomplish this. In the function 'Foo' where mTargetTime is calculated I nested that portion inside of if ( isClientObject()){...}) and the rest of the function in a simiilar isServerObject() block. Made a slight change so that the seconds parameter is ghosted instead of the final 'mTargetTime'.

This function 'Foo' of course calls setMask or whatever to trigger a packUpdate. In unPackUpdate I again do a if ( isClientObject() ){ Foo()} and at that point mTargetTime is calculated locally on the client.

This is more"clever" and less "elegant" than I like to do things, but it's a bugfix that works. :-)

[/edit]
#5
07/07/2008 (5:29 pm)
Rock!
#6
07/07/2008 (5:38 pm)
BTW, thanks for your quick response. I actually tried this the first day you posted back - and then set it down for the holiday-weekend for today. Somewhere along the way everything "clicked".