Inheritance or Datablocks?

#1 You can derive datablocks from one another, but datablocks are only used for assigning data. But you can also specify a class and a superclass for your game objects and define functions for that class all in script.

There is no concept of public / private etc.

Heres another similar thread.

http://www.garagegames.com/mg/forums/result.thread.php?qt=9109

#2 Also, in script, you're limited to two levels of inheritance - for instance: t2dStaticSprite -> Vehicle -> Plane, but not t2dStaticSprite -> Vehicle -> Plane -> F14. Datablocks can circumvent this to some extent.

#3 #James

I read more about tgb network and it seams that in TGB there is no sincronizing between client and server objects, so I'm assuming that datablocks play a very smaller part in TGB than in TGE...

PS: I can't access that thread because I don't own TGE...

#Kalle

Thanks, that's a great limitation I didn't knew of... I'll remember that :)

--

Then... can I say that in TGB datablocks are just "blocks of constant values" (that can be used as some sort of type definition when needed)? (and do nothing about networking eficiency?)

#4 Yes, in TGB datablocks are also refered to as ConfigDatablocks because they serve no networking purpose like their TGE datablock siblings. They are only for initializing objects. A config datablock will set any object fields specified in the datablock when it is assigned, size, position, bitmap, behaviors, etc..

Eg. (you might already know this) In the editor you can drag an object into your level then select it, go to the edit tab, then the scripting dropdown and you will see a popupmenu labeled config datablock, there you will find any datablocks you have defined in your game/gamescripts/datablock.cs file. You can also assign datablocks to objects in script.

For example imagine a coin pickup item. You could create one in the editor setting all its field just right, assigning all its behaviors if you are using them, then save the level, then in torsion or your script editor open your level file, cut out the definition of that object, rename it as a config datablock and save it in your datablocks.cs file. Now you have the ability to replicate that object, and any changes to the datablock definition will affect all copies (the next time you run, not real time). Any object that needs to be replicated like respawning a player, enemies, projectiles, etc. probably should have and be defined by its own config datablock.

At least this is how I use config datablocks. A newer way to do this is with the template behavior and .clone() which I believe is covered in some of the 1.5 tutorials, in which case you might not use config datablocks at all...

#5 Yay! precious information again :) thanks James, now I understand TGB datablocks much better!
I'll intend to use them just as you described (to define and replicate objects that are, in essence, just clones)

I don't want to mix behaviors with all I'm learning yet... but when I do you'll immediately notice, as new threads will appear here =)