Individual Player Dynamic Fields
by Christian · in Torque Game Engine · 03/13/2007 (10:21 pm) · 5 replies
Just wanted to know how other people handle your player/characters dynamic fields. If you have it so your players fields are set up, and he dies, you have a new player and those fields are all gone. Is there a way to attach fields to clients instead of the actual player somehow?
#2
About the sending some info TO client - that depends on the needs.
You can hack into the C++ code and add the fields to be hardcoded in engine and be sure it's added to packUpdate/unpackUpdate functions (for transmission).
Another way - using commandToClient(%client, 'tag', %args....);
May be there are another ways of handling that - but I stick with these two. Anyway, it depends of what you exactly need.
hope this helps
03/15/2007 (5:48 am)
For keeping the info on server I use %client instead of %player, so it doesn't get lost when player respawn.About the sending some info TO client - that depends on the needs.
You can hack into the C++ code and add the fields to be hardcoded in engine and be sure it's added to packUpdate/unpackUpdate functions (for transmission).
Another way - using commandToClient(%client, 'tag', %args....);
May be there are another ways of handling that - but I stick with these two. Anyway, it depends of what you exactly need.
hope this helps
#3
03/15/2007 (10:25 am)
I'm at work so I can't try it now. Which would you use to store simple numbers such as experience, level, etc for each human player? 
#4
the first question to ask yourself when you want to add a field to a player is: "Do [all the] other players in the game need to know the value of this field for all other players ?"
for example, "experience" might be something you want all players to know about other players, but "account balance" maybe not so much.
if it *is* something you want to have high-visiblity,
you'll want to add the field to the C++ object of the client or player and include it in the ghosting mechanism via packUpdate() and unpackUpdate(). there are many, many forum posts on that topic.
if it isn't something you want shared, then a server-side script variable is sufficient.
in that case i'd go w/ banks advice and put it in the %client object.
03/15/2007 (12:20 pm)
Assuming you're working on a multi-player game,the first question to ask yourself when you want to add a field to a player is: "Do [all the] other players in the game need to know the value of this field for all other players ?"
for example, "experience" might be something you want all players to know about other players, but "account balance" maybe not so much.
if it *is* something you want to have high-visiblity,
you'll want to add the field to the C++ object of the client or player and include it in the ghosting mechanism via packUpdate() and unpackUpdate(). there are many, many forum posts on that topic.
if it isn't something you want shared, then a server-side script variable is sufficient.
in that case i'd go w/ banks advice and put it in the %client object.
#5
If we are talking about something that should be avail. to all players around (in view-range) - then I use the packUpdate/unpackUpdate to transmit all required data.
E.g.: the maxHealth for my project is NOT defined by datablock used by player (the def. Torque behavior gives maxHealth set by datablock). I think it will be very useful to have a look at Breaking MaxHealth and Energy from the Databock resource made by Vince Gee (hey Vince!!).
The stuff like personal preferences are kept only server-client communication made by using commandToClient() / commandToServer().
And one more thing to mention - to make your project more "secure" - do all the logic server-side only. Even if you need some kind of interaction, e.g. rayCast - do the rayCast on client side, BUT - check again on server - is it "correct" information what client gives to server.
And, Orion is right - this is most depends on "what" information do you need to update between the server and client(s).
Take into example "The Lounge" - even by just "playing" it can give you some experience. You, as developer, "feel" everything not like usual player. As for me - huge thanks for Orion & Team for their project -as it gave me lots of stuff to think about :)
03/15/2007 (3:54 pm)
As for my project, the "server-client" only stuff is handled by commandToClient();, and all information is kept (and counted) on server-side only, by assigning temp. variables on %client.If we are talking about something that should be avail. to all players around (in view-range) - then I use the packUpdate/unpackUpdate to transmit all required data.
E.g.: the maxHealth for my project is NOT defined by datablock used by player (the def. Torque behavior gives maxHealth set by datablock). I think it will be very useful to have a look at Breaking MaxHealth and Energy from the Databock resource made by Vince Gee (hey Vince!!).
The stuff like personal preferences are kept only server-client communication made by using commandToClient() / commandToServer().
And one more thing to mention - to make your project more "secure" - do all the logic server-side only. Even if you need some kind of interaction, e.g. rayCast - do the rayCast on client side, BUT - check again on server - is it "correct" information what client gives to server.
And, Orion is right - this is most depends on "what" information do you need to update between the server and client(s).
Take into example "The Lounge" - even by just "playing" it can give you some experience. You, as developer, "feel" everything not like usual player. As for me - huge thanks for Orion & Team for their project -as it gave me lots of stuff to think about :)
Torque Owner Christian