Reading datablocks on the client

#1 Try using the tree(); command. You'll see that all the datablocks are in the DataBlockGroup and this happens when you are the host, when you are the client, all the datablocks should be in the serverConnection group.

#2 I checked out the serverConnection group and was able to find the datablocks. My question now would be how to access them? It appears they dont have a name set to them.. would I need to edit the datablocks unpack function to give it a name? Or is there some type of search function I can use to find the datablock I'm looking for.


Thanks in advance

#3 Oh, yes, you have to change the datablock pack/unpack data to send also its name on the net, or you can scan alla the datablocks getting their type, and then access a member you know it's there, for example if you have created a new datablock that is spellData and inside it there is the field spellName, you can use something like this:

...
%group = ServerConnection;
for (%i=0; %i<%group.getCount(); %i++)
{
   %obj = %group.getObject(%i);
   %className = %obj.getClassName();

   switch$ (%className)
  {
      case "SpellData" : 
          %spellName = %obj.spellName;
          $globalSpellData = %obj;  // or if you want to be sure to get the Id = %obj.getId();
          break;
      case "ItemData":
        .....
  }
}

#4 Thanks Davide! I think that info will help alot of people

#5 For those interested in accessing the datablock on the client like it was on the server, add the following code to your pack/unpack method:

Pack

....
stream->writeString(this->getName());
....

Unpack

const char *dataBlockName;
	....
dataBlockName = stream->readSTString(); 
this->assignName(dataBlockName);

#6 The main question however is why do you want to access the datablocks client side?

datablocks (for the most part) store information related to gameplay, and the client should never (ok, just about always mostly never) have gameplay specific logic...instead, you should implement the code/logic server side, and allow the ghosting system to replicate the server state on your client(s).

The main reason datablocks are difficult to access client side is that while the client engine code needs them to do things like know what shape to render, what animations to use, etc., the rest of the data isn't intended to be exposed to a coder/level designer.

#7 Its more of a convenience really. The spell datablocks only contain information about the spell, no actual code. Rather than having to duplicate all the spells information on the client, I can access the datablock to show spell info (casting time, description, mana cost, etc).

#8 Hmm..ok, I can see that as a valid reason!

Will have to think about this one a bit, but my first guess would be to either do what was above, and then be careful not to start coding game logic client side, or possibly create a script that parses your datablock and dumps the appropriate information to a flat text file that you can distribute with your client, and reference the information from there. A touch more kludgy from the usability perspective, but maintains your security a bit more.

#9 Thanks for this discussion. I'm working with a more complicated version of Client Side TS Static that is datablock based

They are all defined with datablocks on the server then can be created on the client for various gui interactive type things that only the local client needs to see.

sending the name over/assigning it was the final block in my tower of goodness that is working code.

thanks again.