Ghosting Global Variables
by rpi (#0010) · in Torque Game Engine · 04/07/2005 (4:47 pm) · 7 replies
So I've read up on the Ghosted data stuff and i'm trying to figure out how to get a few global variables working. This is all in script and i'd like to keep it that way if possible.
On the server I keep track of all players in the game using an array. This array is a global variable. I also have a piece of cheese in the game that players race to pick up. Right now, when the player picks the cheese up, it is destroyed and another cheese is created at a random location 5 seconds later.
Here's my problem. I have radar code written (in script). The radar needs to iterate down the list of players every 50 ms or so. For a shared client/server, this works just fine. Obviously, a dedicated client doesn't have the global script variables of the server.
My question is, A) is it possible to get the global variables to the dedicated server? B) once I get the global variables on the client, will they update or do I have to update them?
My fellow coder and I were debating B. I thought that ghosted objects get updated, and he thought they didn't. All I really need is the location of the players and cheese, so I guess I could just send a message from the server to the client with all the locations, but the less network traffic I generate, the better.
Thanks ahead of time.
Edit:
I forgot to mention that I probably should just hide the cheese and move it to another location rather than destroy it but that's not how it's implemented at the moment.
On the server I keep track of all players in the game using an array. This array is a global variable. I also have a piece of cheese in the game that players race to pick up. Right now, when the player picks the cheese up, it is destroyed and another cheese is created at a random location 5 seconds later.
Here's my problem. I have radar code written (in script). The radar needs to iterate down the list of players every 50 ms or so. For a shared client/server, this works just fine. Obviously, a dedicated client doesn't have the global script variables of the server.
My question is, A) is it possible to get the global variables to the dedicated server? B) once I get the global variables on the client, will they update or do I have to update them?
My fellow coder and I were debating B. I thought that ghosted objects get updated, and he thought they didn't. All I really need is the location of the players and cheese, so I guess I could just send a message from the server to the client with all the locations, but the less network traffic I generate, the better.
Thanks ahead of time.
Edit:
I forgot to mention that I probably should just hide the cheese and move it to another location rather than destroy it but that's not how it's implemented at the moment.
#2
04/07/2005 (5:18 pm)
Ghosting is only for replicating NetObjects. If you just want to have a global variable, the best approach is to just update it yourself.
#3
I don't think I made one point clear. The global array basically points to the player objects. It exists so that we can easily manipulate each player in the game if we want. So obviously I can't transfer the entire object, and if I send the object via a NetConnection, I end up with the serverID which is useless on the client. How do I retrieve the object on the client and guarantee that it will update on the client side everytime the server changes something in that object's dat?
Here's the thing I have trouble getting my head around.
Torque has to be replicating objects across the network somehow. I mean, how else would the client know where to draw the shapes, players, walls, etc in the game? Isn't there a way to expose these objects that the client has to TorqueScript so that we don't have to double the data that is transferred?
I mean, when a player moves, he/she tells the server about the move, the server executes it, and then it updates all the clients.
Why can't each client script have access to these objects to keep the network load down?
I mean, we don't want to be able to change the data on the client - obviously that would allow for cheats and hacks. Just being able to access it, perhaps marking certain methods as client-safe (get's) versus client-unsafe (set's), would save a lot of traffic IMHO
There's no reason why a radar really should have to really even interact with the server in this instance. Otherwise, now I have to schedule on the server a function that runs every 50 ms to transmit the data.
I know it's just nitpicking, and probably something you guys hear alot, but I just had to get it off my chest. (I know I know, if I want it done, I have the engine source and I should just modify it myself).
04/08/2005 (6:56 am)
Thanks for the responses.I don't think I made one point clear. The global array basically points to the player objects. It exists so that we can easily manipulate each player in the game if we want. So obviously I can't transfer the entire object, and if I send the object via a NetConnection, I end up with the serverID which is useless on the client. How do I retrieve the object on the client and guarantee that it will update on the client side everytime the server changes something in that object's dat?
Here's the thing I have trouble getting my head around.
Torque has to be replicating objects across the network somehow. I mean, how else would the client know where to draw the shapes, players, walls, etc in the game? Isn't there a way to expose these objects that the client has to TorqueScript so that we don't have to double the data that is transferred?
I mean, when a player moves, he/she tells the server about the move, the server executes it, and then it updates all the clients.
Why can't each client script have access to these objects to keep the network load down?
I mean, we don't want to be able to change the data on the client - obviously that would allow for cheats and hacks. Just being able to access it, perhaps marking certain methods as client-safe (get's) versus client-unsafe (set's), would save a lot of traffic IMHO
There's no reason why a radar really should have to really even interact with the server in this instance. Otherwise, now I have to schedule on the server a function that runs every 50 ms to transmit the data.
I know it's just nitpicking, and probably something you guys hear alot, but I just had to get it off my chest. (I know I know, if I want it done, I have the engine source and I should just modify it myself).
#4
I am guessing here that your radar display routine loops through each object on the server (players, cheese), determines if that object is "visible" or not, and then displays it. It's possible, based on your implied issue, that you don't even do a visibility check--you just display each thing and move on.
Now, how ghosted objects really work across a true networked connection:
Each tick, the simulation is polled to determine which objects need to be ghosted to which clients. There are a couple of different ghosting options, and I'll focus on scopeAlways and Ghostable: the first means that this object is -always- sent to -all- clients, and therefore is on the client's object space.
The second means that this object may be ghosted to a particular client, if the object is in the client's "observation space". This is defined by the onCameraScopeQuery() for the object itself. If the onCameraScopeQuery() returns an indication that the object should be scoped to this particular client, that is done, and the appropriate information is transmitted to the client. If not, then the object is marked as not appropriate for that client, forcing the client to (later) purge the object's information from it's local information store.
Long story short: the information you are looking for already -is- on the client's information space, assuming your objects are set to scopeAlways. If they are simply "ghostable", then it may or may not be there. For the simple scenario you describe, you could turn the player and cheese objects into scopeAlways objects, and then have your radar routine poll the appropriate SimGroup client side (script even should still work) to render the information.
04/08/2005 (7:09 am)
I think that your breakdown here is that you are trying to adapt a single player co-located client/server solution (your scripted radar) into a networked functionality without refactoring your implementation.I am guessing here that your radar display routine loops through each object on the server (players, cheese), determines if that object is "visible" or not, and then displays it. It's possible, based on your implied issue, that you don't even do a visibility check--you just display each thing and move on.
Now, how ghosted objects really work across a true networked connection:
Each tick, the simulation is polled to determine which objects need to be ghosted to which clients. There are a couple of different ghosting options, and I'll focus on scopeAlways and Ghostable: the first means that this object is -always- sent to -all- clients, and therefore is on the client's object space.
The second means that this object may be ghosted to a particular client, if the object is in the client's "observation space". This is defined by the onCameraScopeQuery() for the object itself. If the onCameraScopeQuery() returns an indication that the object should be scoped to this particular client, that is done, and the appropriate information is transmitted to the client. If not, then the object is marked as not appropriate for that client, forcing the client to (later) purge the object's information from it's local information store.
Long story short: the information you are looking for already -is- on the client's information space, assuming your objects are set to scopeAlways. If they are simply "ghostable", then it may or may not be there. For the simple scenario you describe, you could turn the player and cheese objects into scopeAlways objects, and then have your radar routine poll the appropriate SimGroup client side (script even should still work) to render the information.
#5
One word "Cheating".
04/08/2005 (8:58 am)
Quote:Why can't each client script have access to these objects to keep the network load down?
One word "Cheating".
#6
Thanks for the info - it looks like I'd have to do some engine hacking to do that. While I don't mind it, I don't exactly have time to do it right now. We have a deadline in about a week and there's a lot of other stuff I need to do so while the hack is a longer and less elegant solution, it was faster to just have the engine broadcast the information every 50 ms or so.
I'll definitely look into this later on though if I get the time to make it better. Thanks for all the help guys!
04/10/2005 (9:04 pm)
@Stephen - Thanks for the info - it looks like I'd have to do some engine hacking to do that. While I don't mind it, I don't exactly have time to do it right now. We have a deadline in about a week and there's a lot of other stuff I need to do so while the hack is a longer and less elegant solution, it was faster to just have the engine broadcast the information every 50 ms or so.
I'll definitely look into this later on though if I get the time to make it better. Thanks for all the help guys!
#7
Obviously it's a matter of term selection, but especially when using text based forums, the terms you use are important!
04/11/2005 (5:03 am)
No problem at all--however, please don't look at what I discussed as "hacking"--it's how the engine is intended to be used. Interestingly, what you are doing currently is probably more accurately described as a "hack solution"--doing things that work, but aren't necessarily how things were designed to be used.Obviously it's a matter of term selection, but especially when using text based forums, the terms you use are important!
Associate Ron Yacketta