server local datablocks
by D Player · in Torque Game Engine · 11/01/2002 (2:39 pm) · 3 replies
Does anyone know if there is a standard or proper way of creating datablocks that will not be transmitted to the client? I'd rather not have datablocks that are only relevant to the server cluttering up the network connections.
About the author
#2
99% of datablocks are sent on mission load only and then only the ones that are physically designed in the bitstream to do so.
Other datablocks in script or code are not sent if they are not required to be. Here is a small example of a datablock in script
11/02/2002 (5:55 am)
Hi David,99% of datablocks are sent on mission load only and then only the ones that are physically designed in the bitstream to do so.
Other datablocks in script or code are not sent if they are not required to be. Here is a small example of a datablock in script
new ScriptObject(blaData)
{
class = bla;
prop1a=1;
prop1b="bla";
};
#3
I'm not using datablocks as per Torque normal, and my concerns are more towards the limited networks IDs (and the fact that the ID system doesn't deal with datablock deletion, so you can only have ~1020 created over a game session) than the bandwidth.
Anyways it has become clear to me that not sending datablocks is not a good idea, since so many objects refer to datablocks. Instead I'm going for a better trick where I simply remove the entire ID system and set mId = this; and keep a proper inheritance hierarchy of datablocks to help compress the network traffic and reduce memory usage when dealing with many datablocks that are based on (variations of) a template.
For proper inheritance, I keep a pointer to the parent (one way linkage) and for requests to get dynamic fields I query the parent if the field is not found in the current datablock. For set requests, it creates the dynamic field in the child. To send a new datablock over the network, I just have to send the changed fields.
I expect this system to be slightly slower but more more usable and durable than the current system. The one big flaw is that you can't delete template datablocks. If that is needed, I could always add reference counting... but I think it's better to just be careful with the datablocks.
11/02/2002 (6:52 am)
I'm sorry for not being detailed enough in my original post.I'm not using datablocks as per Torque normal, and my concerns are more towards the limited networks IDs (and the fact that the ID system doesn't deal with datablock deletion, so you can only have ~1020 created over a game session) than the bandwidth.
Anyways it has become clear to me that not sending datablocks is not a good idea, since so many objects refer to datablocks. Instead I'm going for a better trick where I simply remove the entire ID system and set mId = this; and keep a proper inheritance hierarchy of datablocks to help compress the network traffic and reduce memory usage when dealing with many datablocks that are based on (variations of) a template.
For proper inheritance, I keep a pointer to the parent (one way linkage) and for requests to get dynamic fields I query the parent if the field is not found in the current datablock. For set requests, it creates the dynamic field in the child. To send a new datablock over the network, I just have to send the changed fields.
I expect this system to be slightly slower but more more usable and durable than the current system. The one big flaw is that you can't delete template datablocks. If that is needed, I could always add reference counting... but I think it's better to just be careful with the datablocks.
Associate Kyle Carter