Checking what player datablocks you have in the game
by Jules · in Torque 3D Professional · 07/22/2010 (6:10 am) · 10 replies
Hi, I'd like to check client side with server side what datablocks are currently in the game. So if I have 4 player datablocks player1, player2, player 3 and player4.. if player 1 is being used in the game already, they need to choose another. I'm trying to make it so that you don't have the same player in the game at the same time for multiplayer.
Here's how I'd like to do it...
GUI side.. on clicking a button, check to see if player is already in the game, if so send back a message, otherwise continue to next screen.
On selecting the player it should reserve this slot straight away, as by the time they get through the other GUI options the player may have been already taken.
I'd also need to stop the reservation if the player changes his/her mind.
Would the best and easiest solution be to create reservation variable flags for each player type and do checks to see if a certain criteria is set, or just go a bit further and do a check for the datablock in the game?
Here's how I'd like to do it...
GUI side.. on clicking a button, check to see if player is already in the game, if so send back a message, otherwise continue to next screen.
On selecting the player it should reserve this slot straight away, as by the time they get through the other GUI options the player may have been already taken.
I'd also need to stop the reservation if the player changes his/her mind.
Would the best and easiest solution be to create reservation variable flags for each player type and do checks to see if a certain criteria is set, or just go a bit further and do a check for the datablock in the game?
#2
Build a list of datablock and flag them each time one is used.
During connection send available datablock
Player select his datablock
Do a final check before validation on server side if another player took the same datablock before him.
in all case, even if you succeed to get the information on client side, only server information can be trusted so you will have to double check.
07/22/2010 (7:11 am)
I will suggest the same as Tobias.Build a list of datablock and flag them each time one is used.
During connection send available datablock
Player select his datablock
Do a final check before validation on server side if another player took the same datablock before him.
in all case, even if you succeed to get the information on client side, only server information can be trusted so you will have to double check.
#3
07/22/2010 (7:20 am)
Thanks to you both. I thought it would be along the lines via listobjects. Although I wasn't sure if I needed to send this information via a Master Server or not first.
#4
07/22/2010 (7:21 am)
The major problem is, that the client can´t refer to names, because they are not set. So it would be better to do the aggregation task on the server, the selection displayed on the client and the selected item send back to the server again. 
#5
Without fallbacks, it's a little prone to hacks to let the client have that much control. If safety is a concern, at the very least the server should time out allocations and release them back to the pool. Also make sure to only allow the same single client to only ever allocate a single datablock at a time. Use a second commandToServer() to allow the client to release its allocation.
//Edit:
Ah forgot, for letting the client select, simply modify this to make it send a request for a specific datablock (use the ID; they are global). If the request goes through, the server sends an OK.
07/22/2010 (7:21 am)
Since as such the server is responsible to allocating the datablocks to clients, the logic for that should be entirely on the server side. Use a roundtrip request for that. Use commandToServer() to request the allocation and then on the server side, use commandToClient() to send the allocated datablock ID to the client.Without fallbacks, it's a little prone to hacks to let the client have that much control. If safety is a concern, at the very least the server should time out allocations and release them back to the pool. Also make sure to only allow the same single client to only ever allocate a single datablock at a time. Use a second commandToServer() to allow the client to release its allocation.
//Edit:
Ah forgot, for letting the client select, simply modify this to make it send a request for a specific datablock (use the ID; they are global). If the request goes through, the server sends an OK.
#6
07/22/2010 (7:33 am)
That's great Rene. The good ole commandToServer, saves the day again. I have a set number of characters that can be allocated in the game, and generic characters after that. I may do a check to fade out the characters in use in the game and prevent them from being selected to avoid frustration on finding out that all 8 unique characters are in use, but also do a second check on the character selected before proceding to the next GUI. Should save on the number of server calls.
#7
Yep, you could have the server first send a list of IDs that are currently available. A la "no allocation, no guarantees, it's just a tentative list what might work as a pick." And then, when the player has selected a specific block, have the client try to allocate it from the server.
07/22/2010 (7:37 am)
Yep, you could have the server first send a list of IDs that are currently available. A la "no allocation, no guarantees, it's just a tentative list what might work as a pick." And then, when the player has selected a specific block, have the client try to allocate it from the server.
#8
07/22/2010 (8:03 am)
Cool... just need to work it out... player and weapon selection is already done, which works off server side, so hopefully it shouldn't be too difficult to implement. 
#9
07/22/2010 (7:38 pm)
Somewhat unrelated, but related to the solution - I'm finding a lot of issues that seem to be solved w/ combinations of commandToServer/commandToClient - what's the performance like on these? Is using them a few times per game-frame going to cause performance issues? Or for local games is it fairly lightweight?
#10
For local games, this is almost free and you could even do this with relative high-frequency.
For networked games, definitely. In most cases, networking will have a lag significantly greater than a single frame. If you're not trying to force something synchronous out of this asynchronous framework, then you'll manage but still, high-frequency is bad (per-frame definitely).
07/22/2010 (8:24 pm)
Quote:Or for local games is it fairly lightweight?
For local games, this is almost free and you could even do this with relative high-frequency.
Quote:Is using them a few times per game-frame going to cause performance issues?
For networked games, definitely. In most cases, networking will have a lag significantly greater than a single frame. If you're not trying to force something synchronous out of this asynchronous framework, then you'll manage but still, high-frequency is bad (per-frame definitely).
Torque Owner Tobias B.
mercatronics
For a little deeper look: On the client you can look into ServerConnection via listobjects(). there you get all datablocks and player objects. Maybe you can check which datablocks where used, but this will not help you, because you have to resolve the datablock on the server.
I would add a set of used datablocks on the server and collect the unused list on startup of a client. So the server would send the list to the client then.
Hope this helps.