Multiple different types of clients, with different Events?
by Julie B · in Torque Game Engine · 03/29/2006 (11:52 pm) · 5 replies
I'm wondering if it's possible to have different types of clients, with different Events defined in each client. We have two different types of clients, a human client that does ghosting, etc. and a robot client that simply passes events with sensor data, motor commands, etc. back and forth. Obviously we have a different set of Events for each type of client (the human client is also part of the server, so it has all the events. The robot client only has the events relevant to it).
The robot client was developed last semester, and we've been focusing on the human client this semester, and are now attempting to get the robot client working again, along with the human client. We're running into problems though, seemingly because the number/type of Events on the robot client and the server don't match up (the robot has a subset of the server's events). Our robot client was now unable to connect to the server, even though it correctly solved the puzzle, etc.
I traced our problem to this code, line 104 in eventConnection.cpp:
which prevents the connection if things don't match up. We tried commenting it out, which allows the robot client to connect to the server, but then some events work, while others the server thinks are something they're not.
Do we have to create dummy events on the robot client for every server event and RPC? Is there an easier/better solution? I'm going to try the dummy event thing, but I'm not sure that will work.
The robot client was developed last semester, and we've been focusing on the human client this semester, and are now attempting to get the robot client working again, along with the human client. We're running into problems though, seemingly because the number/type of Events on the robot client and the server don't match up (the robot has a subset of the server's events). Our robot client was now unable to connect to the server, even though it correctly solved the puzzle, etc.
I traced our problem to this code, line 104 in eventConnection.cpp:
if(!NetClassRep::isVersionBorderCount(getNetClassGroup(), NetClassTypeEvent, mEventClassCount))
return false;which prevents the connection if things don't match up. We tried commenting it out, which allows the robot client to connect to the server, but then some events work, while others the server thinks are something they're not.
Do we have to create dummy events on the robot client for every server event and RPC? Is there an easier/better solution? I'm going to try the dummy event thing, but I'm not sure that will work.
About the author
#2
03/30/2006 (11:27 am)
No, our events are defined in separate files, and no, we're using different connection types for each client. We've "solved" (hacked) this problem by creating dummy events in the robot client that just call DECLARE_CLASS and IMPLEMENT_NETEVENT, but having to do this for every new event added to the server could grow to be unwieldy. I'm not sure there's a way around it though, because TNL needs to be able to map events to each other with some sort of non-string id.
#3
03/30/2006 (2:57 pm)
Yup, it doesn't work. Just an idea, but if you really don't want to compile the functionality into the client you might surround it by #ifdef so you can still include them but only the macros are compiled to the alternate builds.
#5
There doesn't seem to be the same problem with ghosting. It only seems to care if you actually try to ghost to a client that doesn't have the definition compiled. So it might be possible, I just started using TNL myself so I'll be interested.
03/31/2006 (6:20 am)
If the real problem can't be fixed of course. Just so you don't have to make multiple copies of the files or whatever.There doesn't seem to be the same problem with ghosting. It only seems to care if you actually try to ghost to a client that doesn't have the definition compiled. So it might be possible, I just started using TNL myself so I'll be interested.
Carter Dodd