datablocks on client
by Guy Allard · in Torque 3D Professional · 02/02/2010 (10:00 am) · 7 replies
I originally posted this here: http://www.torquepowered.com/community/forums/viewthread/110055 but no answers, so I'm trying here instead.
It would be really useful from within a GUI to be able to look at a datablock and pull some of the values from it to display in the Gui. Things like maxDamage, shapeFile etc.
However, the datablocks that exist on the client cannot be referenced by name like they can on the server (e.g. armor.maxDamage). I've seen this discussed a few times, and the reason that the name is not networked has something to do with security, but I can't see what the security problems might be.
The datablock on the client only contains information, there's no logic there to be messed with by a client as the logic is dealt with separately on the server. I know that a small engine change will allow datablocks to be accessed on the client in the same way as on the server, but what are the potential security holes that are created by doing this?
It would be really useful from within a GUI to be able to look at a datablock and pull some of the values from it to display in the Gui. Things like maxDamage, shapeFile etc.
However, the datablocks that exist on the client cannot be referenced by name like they can on the server (e.g. armor.maxDamage). I've seen this discussed a few times, and the reason that the name is not networked has something to do with security, but I can't see what the security problems might be.
The datablock on the client only contains information, there's no logic there to be messed with by a client as the logic is dealt with separately on the server. I know that a small engine change will allow datablocks to be accessed on the client in the same way as on the server, but what are the potential security holes that are created by doing this?
About the author
Recent Threads
#2
The only issue is that sending the names would increase datablock download time, specially if you have them in large amounts.
A simple change in SimDataBlock's packData() and unpackData() would allow the names to be networked.
02/02/2010 (12:21 pm)
I don't think there is a security issue. After all, they can still be accessed by issuing getDataBlock() in the objects that are using them.The only issue is that sending the names would increase datablock download time, specially if you have them in large amounts.
A simple change in SimDataBlock's packData() and unpackData() would allow the names to be networked.
#3
02/02/2010 (3:28 pm)
AFX built a cached system to that allows to transmit dynamic fields and changes in a datablock. You might want to try to ask in the public forums about it and see if that approach works for you 
#4
That said, what happens if you do define a datablock on the client? Do you end up with a new, unlinked datablock with the name in question? If so, you could just exec your datablocks on the client separately. Since the actual game objects use datablock ghost IDs to refer to them, it shouldn't collide.
Probably won't work, but that's my "beat it with a stick" suggestion.
02/04/2010 (2:43 pm)
I think the security issue in question is related to players being able to define "replacement" datablocks on the client that override the actual values. So datablocks are referred to by ghost IDs instead of names, so your clients can't just console in a new datablock def of that name and expect it to read from it.That said, what happens if you do define a datablock on the client? Do you end up with a new, unlinked datablock with the name in question? If so, you could just exec your datablocks on the client separately. Since the actual game objects use datablock ghost IDs to refer to them, it shouldn't collide.
Probably won't work, but that's my "beat it with a stick" suggestion.
#5
Creating datablocks client side would not help in any way as the needed are the ones coming from the server, hence the question regarding the db name transmition.
02/04/2010 (4:26 pm)
I dont think the security issue be that way. As I understand, the server is authoritative datablock wise, as the simulation happens in it, while the client displays just a visual representation.Creating datablocks client side would not help in any way as the needed are the ones coming from the server, hence the question regarding the db name transmition.
#6
Granted, since the server is authoritative about 90% of game events, it wouldn't really give you much; you could change your player speed, but it would only result in terrible prediction and interpolation. You could, however, change the models the game loads for players or, say, zoom values allowed on weapons...
Anyway, I guess it still doesn't explain why we can't reference them by the name. Just because they exist as ghost IDs doesn't mean they can't use their original names as aliases.
02/05/2010 (1:10 am)
I mean that you could re-define the datablocks after load. They only get downloaded during mission loads, and so you could alter them during gameplay and the server would never know until the next mission load event.Granted, since the server is authoritative about 90% of game events, it wouldn't really give you much; you could change your player speed, but it would only result in terrible prediction and interpolation. You could, however, change the models the game loads for players or, say, zoom values allowed on weapons...
Anyway, I guess it still doesn't explain why we can't reference them by the name. Just because they exist as ghost IDs doesn't mean they can't use their original names as aliases.
#7
I'm trying to figure the same thing out with TGE -- to display to the client, the stats on the selected unit ... like you mention; maxDamage, plus attackDelay, isMelee,mVision and other attributes.
EDIT: This my be relevant;
http://www.torquepowered.com/community/resources/view/4852
02/20/2010 (9:14 pm)
Can't you resolve the local ID to its ghost ID and then query the server for the details on the datablock ?I'm trying to figure the same thing out with TGE -- to display to the client, the stats on the selected unit ... like you mention; maxDamage, plus attackDelay, isMelee,mVision and other attributes.
EDIT: This my be relevant;
http://www.torquepowered.com/community/resources/view/4852
Torque Owner Davide Archetti
Default Studio Name
Actually, I use the datablock data client side, although I don't use their name but their id, indeed, since the user can select several kinds of avatar, I just show to the user the list of possible avatar's type, the datablocks, and then, using the datablock's id I can access all the data.
So, to show data in a gui, you shouldn't really need to know the datablock's name.