Fatal - Exceeded maximum number of data blocks WTF???

#1 I think you can do it by increasing DataBlockObjectIdBitSize in sim.h, which is the number of bits used for datablock ids. The default is 10, which gives you a maximum of 1024 datablocks (actually 1021 since their ids start at 3).

#2 ..that should be 'upped' in the trunk. .Seriously.

#3 That's a ton of datablocks... do you have any idea where most of these are coming from?

#4 weapons, vehicles and characters.
I've started making common datablocks, it is way to much.

#5 I can see triggers taking up a lot ...

#6 @Tom: Is there a reason for limiting datablocks to 1024 ?

#7 A limit must exist. If you look at sim.h you'll understand why. IDs are 32-bit values. Since every object needs an ID number, and the datablocks IDs should never mix with the standar object IDs, a number of IDs is reserved for datablock usage. The value can be increased/decreased as needed. Each additional bit doubles the number of datablocks you can have, but remember that it halves the number of available object IDs too.

Also, I *think* datablocks will re-use IDs when you exit a mission or something like that, so if you load only the necessary ones when loading a level, you're safe. This requires thinking a bit differently about how datablocks are loaded, since by default everyone just execs all their datablocks scripts when the server is created.

#8 Manoel, it is great that you are so technical but your answer encompasses the answer I seek, it is not an 'answer' to the specific question. :P
//
..of course everything needs limits. I just think they should be updated.
I agree that loading all datablocks (needed and unneeded) is a bad choice but that doesn't mean that someone should be limited to 1024 per mission. Seems a bit 2003'ish.

//edit: are there other old settings in the code that should be updated ? ...I assume, yes.

#9 I'm unsure off the top of my head if there are side effects to increasing the datablock limit.

I guess a little more bandwidth from sending more than 10bits of data for each datablock id.

Anything else?

#10 Just curious has anybody seen any other negative results of increasing the datablock limit?

#11 Raising the limit to push through more also means up two twice as long waiting times when they want to enter the mission if you are really going to use them as all datablocks are sent from server to client on join (I'm assuming the common non-AFX user naturally :) )

#12 Thanks Marc. I have just been working creating single player games so mission load times is not a big issue for me. I would gladly accept the longer load times in return for more game content (sounds, triggers, etc).

I am still learning a lot about datablocks but from what I can see every sound, particle emitter, trigger, and etc needs them. To me hitting the 1024 limit could happen fairly quickly especially when the game has a lot of different pickups, weapons, and vehicles. From what I have read these can be loaded and unloaded when you go from different missions but can they be unloaded during game play in the same mission?

#13 don't know, with weapon, pickups etc you won't reach it.

chances that you do through the media assets and npc variations is muuuch higher as you have at least a magnitude more of them normally :)

in torque you technically always create MP games, there is no client only mode unless you did a lot of rework.

there though was once a resource to shortcircuit the loading of datablocks.
the alternative is datablock caching like AFX offers it

#14 Thanks for the help. I never really payed a lot of attention to AFX until now. Looks pretty impressive and as you said datablock caching that it offers could be a big help. Time to investigate it a little more and find its limits...

#15 I believe the number of bits can be safely increased in the enum, and everything adjusts to the new size.

But the big question is: are you using those thousand datablocks at the same time in the same level?

If not, then you can probably fix your problem (and optimize your "loading datablocks" time) by *not* creating every single datablock in your entire game when loading any mission. Move your datablock creation into different scripts and selectively execute them depending on the mission being loaded in the server, before the client connects.

If you really need to use thousands datablocks at the same time, another approach is to make them client-side. I never tried it, but I think disabling the datablock transmission and simply executing their creation scripts client-side should do the trick. However, this only affects the loading time: datablocks are objects like everyone else and need IDs, so you'd still need to increase the number of bits reserved for them.

#16 Something along the lines of having a *.cs file the same name as your mission which executes only the files that will be used in that mission.

First cuppa tea of the day, so psuedocode.

//caution [psuedocode]
function LoadDataBlocks()
{
      exec("./" @ $Server::MissionFile @ ".cs");
}
//caution [/psuedocode]

You might also consider "pooling" common functions like sound and particles for weapons, rather than have them all seperate. After all if every bullet impact particle is the same and you've got 40 weapons, why have 40 impact particles? Same with an "empty fire sound", do you really need the same "click" noise datablocked seperately for all 40 weapons?

#17 Thanks for all of the help. I agree completely about using the same datablock for as many things as possible like impact particles. But one more question.. if you load and unload the datablocks for each mission does that mean you can have more than one datablock with the same ID number as long as only one is loaded per mission.
Example:
Mission 1 - Datablock ID# 500 = sound (located in Mission1.cs)
Mission 2 - Datablock ID#500 = particle emitter (located in Mission2.cs)

#18 I don't think that's how it works, ID's get handed out at level start. You can happily use names that way though. I name every object that that is dynamic in a level, or that will later spawn into that level. That way I can the object from the console without hunting the damn thing down in-game and finding it's ID.