Connection sequence questions
by Stephen Zepp · in RTS Starter Kit · 11/13/2004 (10:36 am) · 10 replies
I'm in the process of integrating the kit against our dev line, and after tracing through the startup sequence, one of the things I noticed is that it seems you have changed the connection sequence (through the "Ready/Not Ready" lobby) to be server initiated instead of client initiated--basically, all clients tell the server ok, go!, and then once all have announced, the server tells the clients to all connect at once.
I admit, my brain is fried, but I haven't found a "connect" function anywhere in the RTS scripts. I'm assuming that the new startup sequence doesn't need this anymore, but in our project, we still want to have the players connect on their own timing--we're still a persistent world after all.
Any pointers on reversing the actual connection flow so that it matches how stock TGE does it, specifically mirroring connect() but using the RTSConnection instead?
Also, what in the script changed server side to catch an RTSConnection instead of a GameConnection?
Heh..maybe I just need to take a break, but any pointers would be greatly appreciated.
I admit, my brain is fried, but I haven't found a "connect" function anywhere in the RTS scripts. I'm assuming that the new startup sequence doesn't need this anymore, but in our project, we still want to have the players connect on their own timing--we're still a persistent world after all.
Any pointers on reversing the actual connection flow so that it matches how stock TGE does it, specifically mirroring connect() but using the RTSConnection instead?
Also, what in the script changed server side to catch an RTSConnection instead of a GameConnection?
Heh..maybe I just need to take a break, but any pointers would be greatly appreciated.
#2
11/13/2004 (6:29 pm)
Since RTSConnection inherets from GameConnection, this will, in fact, work. It does seem kind of cracked out, but it is still valid.
#3
GameConnection::onConnectionAccepted() ?
the only onConnectionAccepted in the supplied scripts is
RTSConnection::onConnectionAccepted
I could understand if the inheritence was reversed, but this is boggling me--it appears to be calling a child's method, not the parent?
Thanks for the response by the way--as of right now I think I've gotten past this stage, now trying to get datablocks to match/not crash (ugh, I'm trying like crazy to figure out how to make this more robust--these are difficult to debug!)
11/13/2004 (6:37 pm)
I can understand how it can work as you said, but how does it happen? If this is really a GameConnection, doesn't the Con::executef becomeGameConnection::onConnectionAccepted() ?
the only onConnectionAccepted in the supplied scripts is
RTSConnection::onConnectionAccepted
I could understand if the inheritence was reversed, but this is boggling me--it appears to be calling a child's method, not the parent?
Thanks for the response by the way--as of right now I think I've gotten past this stage, now trying to get datablocks to match/not crash (ugh, I'm trying like crazy to figure out how to make this more robust--these are difficult to debug!)
#4
11/13/2004 (7:29 pm)
It calls into the script code. The script checks and finds the calling object's script namespace is for class RTSConnection, and calls RTSConnection::onConn, then GameConnection::onConn, then others up the hierarchy. Just because the code is in GameConnection doesn't mean that the script associated with it can't be elsewhere. :)
#5
11/13/2004 (7:32 pm)
@Ben: hehe..I guess. That one -really- threw me, and could actually be a problem for us in the long run. We will be (hopefully) having players swap back and forth between having a full player as their control object, with the option to hit a gui button and move back to their "home base" in RTS mode. I'm still working out the specifics, but to me that means being careful with which is the connection object, and/or possibly having two connection objects and keeping one "on ice"...I really need to dig deep on that one first however. 
#6
That would be a great one to post as a resource when you get it sorted out if you're willing. I can see a lot of people wanting to do something similar (including me).
[Edit: I hate typos.]
11/14/2004 (5:28 am)
@StephenThat would be a great one to post as a resource when you get it sorted out if you're willing. I can see a lot of people wanting to do something similar (including me).
[Edit: I hate typos.]
#7
11/14/2004 (9:30 am)
Well, keep in mind the connection object is distinct from the control object. Basically, just do some calls to setControlObject, maybe swap some GUI stuff, and you're basically set.
#8
The reason it turns out that it was so confusing is that I visually compared the %conn creation lines instead of diffing them, and late at night failed to note that there was a difference: in the rts pack we create %conn = new RTSConnection, while stock does %conn = new GameConnection.
In hindight it was a newbie mistake, and once I fixed that we vaulted past that part of the startup sequence.
My initial thought is to create a script wrapper for the connections, and swap back and forth between two diff connection types based on a player variable. Combined with mode checking on the server side as a robust/hack check, it should meet our needs (I hope!).
11/14/2004 (10:16 am)
Yeah, as I've dug deeper into getting our integrated project running (we're -this- close, that dreaded ChatHud stuff is doing things lower level than it should be, so getting Asserts instead of Console messages), it's not looking quite as hard.The reason it turns out that it was so confusing is that I visually compared the %conn creation lines instead of diffing them, and late at night failed to note that there was a difference: in the rts pack we create %conn = new RTSConnection, while stock does %conn = new GameConnection.
In hindight it was a newbie mistake, and once I fixed that we vaulted past that part of the startup sequence.
My initial thought is to create a script wrapper for the connections, and swap back and forth between two diff connection types based on a player variable. Combined with mode checking on the server side as a robust/hack check, it should meet our needs (I hope!).
#9
11/14/2004 (10:09 pm)
Well, RTSConnection is a subclass of GameConnection. So all the functionality is still in RTSConnection.... or is mostly there, and easy to add back in. Switching connection types won't really work well.
#10
Will take a poke at it :)
11/15/2004 (2:28 am)
Hmm, ok, thanks for keeping me from going down a wrong path. I had assumed from your descriptions about removing functionality and/or optimizing the net traffic for the pack that one connection wouldn't do the trick.Will take a poke at it :)
Torque 3D Owner Stephen Zepp
Tracing through the connect handshaking, I see that:
--Client starts game, picks mission, launches mission
--server side onConnectRequest is called
...
--Connection is established, "Connection established 1430" log message written
--gameConnection.cc issues a Con::executef(this, 1, "onConnectionAccepted");
Now is where I get confused. Up to this time, we're working with a GameConnection, but when the client executes that onConnectionAccepted, it's running the script for RTSConnection:onConnectionAccepted ?
unless something is being tricked, or I'm missing something, this within the context of void GameConnection::onConnectionEstablished(bool isInitiator)
is a GameConnection--so how does the client catch the Con::executef with an RTSConnection?