InitialControlSet is not the end of Level Load?
by John Cooney · in Torque Game Engine · 05/15/2006 (11:31 am) · 11 replies
I have a level which features (among other things) a precipitation object. There is a countdown at the beginning of the level ("3 . . . 2 . . . 1 . . . Go") which hangs at the number 3 for about two seconds, and I've discovered that I can eliminate that delay by removing the precipitation.
Now, the odd thing about that is, the countdown is shown only after initialControlSet is called. In theory, initialControlSet should signal the end of loading, and a readiness to enter the game. However, by putting an echo on the Precipitation OnAdd, I can see that the client-side version of the Precipitation is loaded AFTER entering the game.
Now, I can delay the PlayGui switch until the "true" end of the load, but I don't know where that is. I guess my questions are:
1) Should InitialControlSet be seen as a valid place to assume loading is finished?
2) If not, is there a better place to make that assumption?
I'm sorry to bother you guys with this. It may be a really simple thing that I'm just overlooking, but I can't find it yet.
Now, the odd thing about that is, the countdown is shown only after initialControlSet is called. In theory, initialControlSet should signal the end of loading, and a readiness to enter the game. However, by putting an echo on the Precipitation OnAdd, I can see that the client-side version of the Precipitation is loaded AFTER entering the game.
Now, I can delay the PlayGui switch until the "true" end of the load, but I don't know where that is. I guess my questions are:
1) Should InitialControlSet be seen as a valid place to assume loading is finished?
2) If not, is there a better place to make that assumption?
I'm sorry to bother you guys with this. It may be a really simple thing that I'm just overlooking, but I can't find it yet.
About the author
#2
I mean, the "InitialControlSet" is called, which tells the server that it has a "ClientInGame", but then almost two seconds later, the "OnAdd" for my precipitation object is called.
I could cheat, and just schedule the PlayGUI initialization for about two seconds later, but given that different systems can have different load times, I was looking for something more accurate.
05/15/2006 (3:11 pm)
On the client side, "InitialControlSet" is the function that makes the "CommandToServer" call for "ClientInGame". The big issue for me is that, on the client side, "InitialControlSet" is called before all the client objects are added.I mean, the "InitialControlSet" is called, which tells the server that it has a "ClientInGame", but then almost two seconds later, the "OnAdd" for my precipitation object is called.
I could cheat, and just schedule the PlayGUI initialization for about two seconds later, but given that different systems can have different load times, I was looking for something more accurate.
#3
05/22/2006 (2:09 pm)
Okay, well, I'll just go with the 'cheat' then. Thanks guys.
#4
In other words, it sounds as if, for that particular mission file, and that particular scoping scenario, you were in fact already cheating the system by having your countdown happen after what just happened to be the last ghostable object was delivered to the client. This is a non-deterministic solution (most likely), since the ghosting order is not dependent on criteria available to you at that specific level.
If you are simply looking for a countdown period to start after ghosting has happened, but before the player gets control (or something similar), you can most probably use scripted net events (commandToClient/commandToServer) to have the client indicate readiness to start the countdown, and have the server send the numbers one by one. This won't guarantee exact timing on the countdown, but at least may lead you to a more correct and appropriate solution.
05/22/2006 (8:52 pm)
Not sure why this didn't occur to me right off the bat, but only ScopeAlways objects are downloaded prior to entering the game. Once the control object is in game, the scoping system can then determine which "nearby" (in scope) normal ghost objects should be transmitted, and then they are sent down the pipe.In other words, it sounds as if, for that particular mission file, and that particular scoping scenario, you were in fact already cheating the system by having your countdown happen after what just happened to be the last ghostable object was delivered to the client. This is a non-deterministic solution (most likely), since the ghosting order is not dependent on criteria available to you at that specific level.
If you are simply looking for a countdown period to start after ghosting has happened, but before the player gets control (or something similar), you can most probably use scripted net events (commandToClient/commandToServer) to have the client indicate readiness to start the countdown, and have the server send the numbers one by one. This won't guarantee exact timing on the countdown, but at least may lead you to a more correct and appropriate solution.
#5
05/23/2006 (12:21 pm)
Awesome! Cool! Thanks! Um . . . how can I tell when the ghosting is finished? Sorry if I'm being obtuse, but I don't know quite where that would be. 
#6
You could simply add a commandToServer in the onAdd script callback of whatever object it is that you are waiting for to be ghosted and then have it the server send a commandToClient back to let the PlayGui know to start the count down.
05/23/2006 (12:44 pm)
Stephen's point is that ghosting is never really done.You could simply add a commandToServer in the onAdd script callback of whatever object it is that you are waiting for to be ghosted and then have it the server send a commandToClient back to let the PlayGui know to start the count down.
#7
05/23/2006 (12:56 pm)
Okay, Cool. Thanks guys!
#8
05/23/2006 (12:56 pm)
Is onAdd actually called on the client-side though?
#9
05/23/2006 (1:27 pm)
No, I don't think so, but even coming from the server side, it does give me a good position for testing when all the clients are ready to enter the game.
#10
to::onAdd() in the C++ source code (which is called on server and client.
05/23/2006 (3:28 pm)
Easy enough to add:if (isClientObject()) Con::executef(mDataBlock,2,"onClientAdd",scriptThis());
to
#11
05/23/2006 (3:59 pm)
Of course, another solution would be to make those things that slow the countdown into "ScopeAlways" objects. That seems to have solved my problems. 
Torque 3D Owner Stephen Zepp
You could easily send a commandToClient() from this function to have a "last second synchronization" if you like.