Server/client command calling order
by Daniel Buckmaster · in Torque Game Engine · 09/19/2007 (10:47 am) · 6 replies
It seems that client commands are called quite slowly. In my game, I'm using server and client commands to find the selected object on the screen, change a GUI element, and change it back if there's no longer an object selected. To cut a long story short, the client command which sets the GUI text is processed and called after the crosshair has passed over the weapon and called the function to clear the GUI. The result is that if you just flick the crosshair over a selectable object, the GUI will say 'press E to use' permanently.
I guess a solution would be to set up an identical server/client command hierarchy for the instruction to wipe the GUI, thereby inducing the same amount of lag, but this seems pretty inefficient.
On the other hand, it's not exactly a performance issue...
I guess a solution would be to set up an identical server/client command hierarchy for the instruction to wipe the GUI, thereby inducing the same amount of lag, but this seems pretty inefficient.
On the other hand, it's not exactly a performance issue...
About the author
Studying mechatronic engineering and computer science at the University of Sydney. Game development is probably my most time-consuming hobby!
#2
Unless I'm missing something...
09/19/2007 (11:06 am)
Sounds to me like you should be able to just process on the client side for the GUI stuff. Then only jump back to the server if the press e to use the object. You don't really need the server confirmation of the objects position unless they plan to use it.Unless I'm missing something...
#3
If the server determines that the object isn't really selectable, or something else controls, it can send an event down to force the GUI to change, but this should be an exception based system, not a standard data flow.
By the way, it's not that net events are inherently slow atomically, it's that you are converting to a different update frequency--screen updates at frame rate, network events operate at a 100 millisecond period. Since your current data flow requires two network events (to server, from server), you're forcing an event series to convert from frames per second to "round trip in 200 ms"--not a particularly efficient frequency conversion.
09/19/2007 (11:09 am)
Tim and Eric have hit upon what is probably a better design--instead of converting the hover event into a NetEvent, then transmitting that to the server and then back again, I'd take the hover event directly to the GUI (both are client side), and then send a net event that handles the actual event of selecting something.If the server determines that the object isn't really selectable, or something else controls, it can send an event down to force the GUI to change, but this should be an exception based system, not a standard data flow.
By the way, it's not that net events are inherently slow atomically, it's that you are converting to a different update frequency--screen updates at frame rate, network events operate at a 100 millisecond period. Since your current data flow requires two network events (to server, from server), you're forcing an event series to convert from frames per second to "round trip in 200 ms"--not a particularly efficient frequency conversion.
#4
09/19/2007 (12:24 pm)
Thanks for the responses! And I guess it's true that my system isn't exactly at optimum efficiency. However, I don't believe it's a performance issue - the hover event is only generated once when you select an object (crosshair moves over it) and once when you deselect it (crosshair moves off object). I agree though, I should separate the GUI elements and the actual object interaction...
#5
09/19/2007 (12:28 pm)
Right, but as I mention, it's not a performance issue, it's a timing issue. Sending off net events (in both directions) de-synchronizes the event from the actual execution flow, and allows many other events to occur before that net event sequence makes it's round trip.
#6
09/20/2007 (10:10 am)
Okay, I understand now - and that's what the original issue was caused by. Thanks for the advice. 
Torque Owner Tim Heldna
If you can do it all on the client, that helps (though security becomes an issue).
If you can do it in all in source even better.
Other than that you can always crank up your network pref settings, although this really isn't a solution.
I take it you're using a looping schedule, you could always crank the cycles per second that it runs (though once again this becomes a network performance issue if too much stuff is going on).