Datablock classes

Every datablock type you can declare, with usage counts from the 334 files in base/scripts.vl2 [script] and the engine’s own validation ranges where they exist [binary].

Census

Types used only by mission files and not declared in scripts.vl2: EnergyProjectileData (blaster), SniperProjectileData, ShockLanceProjectileData, LinearProjectileData, RepairProjectileData, and ProjectileData (abstract — “cannot be used as a concrete datablock type” [script]).

Validated field ranges

The engine validates many fields in onAdd and refuses the datablock — or clamps — if they are out of range. These messages are in the binary [binary] and are the authoritative bounds. Violating them produces a console error at load time and a datablock that does not work.

ProjectileData and descendants

GrenadeProjectileData

The blaster’s grenadeElasticity = 0.998 sits deliberately just under the ceiling [script].

SeekerProjectileData

SniperProjectileData / TargetProjectileData

TracerProjectileData

ELFProjectileData

ShockLanceProjectileData

ParticleData

The times[] ordering rule catches people out. Keyframe times must ascend.

ParticleEmitterData

“invalid particles string. No datablocks found” and “particle string too long [> 255 chars]” are the two failure messages. The second bites when you list many particle types in one emitter.

ExplosionData

DebrisData

TurretData / TurretImageData

ForceFieldBareData

PrecipitationData

Declaring a datablock

datablock <Type>(<Name>)
{
   field = value;
};

datablock <Type>(<Name>) : <ParentName>
{
   field = value;      // everything else inherited
};

Rules:

• The parent must exist at declaration time.
• Referenced datablocks must exist at declaration time — see Datablocks.
• Unknown fields become dynamic fields — no error, no effect on the engine, readable from script.
• className selects the script dispatch namespace, and is how ItemData becomes a weapon, a pack, or hand inventory.

The className values

Setting className to an existing value is the cheapest way to get a complete behaviour set. See SimObjects and namespaces.

Under the community patches

No datablock types are added, removed, or changed, and every validated range above still applies — the validation lives in Tribes2.exe, which neither patch modifies.

One type is functionally inert on the QoL patch: EffectProfile (140 declared in the shipped scripts). The blocks still parse and AudioProfile.effect still accepts them, but TribesNEXT’s IFC22.dll stubs the Immersion force-feedback exports [binary], so nothing plays. Declaring them remains harmless; omitting them was always fine. RC2a keeps the vendor DLL and force feedback works.

Everything else — every field, every range, every className dispatch value — is identical.

Related

• Datablocks — semantics, inheritance, ghosting
• 03 · Content Recipes — each type in use
• Class hierarchy — the engine classes behind these
• 07 · Community Patches — what the patches do change