Star Trek: Armada utilizes SOD files, that basically contain each units' structural definition, the mesh, as well as references to the textures to be applied to the faces defined by it.

Along with that come also the so-called node definitions. Each node has a specific role, like functioning as a point of origin from which weapons fire or from where damage-flares are emitted. Every node has a vertex position and some types also have a direction in which they point (e.g. crew damage indicator sprites).

The totality of the nodes is part of the node hierarchy of the model. Each node is tied to a parent node, except for the root node, which stands for itself. While the textures on the faces of the mesh are clearly visible, nodes serve as location points of other elements, so are by themselves not visible. The names of nodes are in part fixed, in part depend on your models mesh groups or the number of hardpoints you give them.

Depending on what tool you use, Node names may be prepended by node type prefixes. See Node Name Conventions on an example for Milkshape 3D. Some names are very specific, serving a unique purpose: borg, crew, damage, engines, geometry, hardpoints, life, lights, root, sensors, shield and target. They must not be used for anything else but their standard function. Others depend strictly on the contents of your model.

Here is an example structure of nodes derived from the Cube unit:

root
 damage
  borg
  crew
   crew1
  engines
   plasmalrg
  life
   steamlrg
  sensors
   sensor
  shield
  target
 hardpoints
  hp01
 geometry
  bbattleglow1
  Lod0
   Bbattle_2
  Lod1
   Bbattle_1
  Lod2
   Bbattle

The indentation represents the hierarchical structure. There are different types of nodes, some of which are mandatory.

Nodes of this type are simply named borg. borg nodes are serving the task of parts of the model to be displayed, once it has been built or assimilated by a Borg faction. For all other factions the referenced model is set invisible. The borg node is child node of damage and it is optional. By itself the borg node and its child elements do not have any direction. The direction of the child elements is implicitly clear by the mesh models alignment as part of the entire model. So they don't need any alignment via node direction. A borg node without any child nodes will have no visible effect. So you can simply omit it, of you do not intend to give your model any borg indicators. (E.g. when meant for the Borg faction to begin with, the unit most likely will be recognizable as Borg anyway.)

The child elements of the borg node have to have the name(s) of the mesh group(s), that are only displayed for as long as the occupying crew is of faction Borg. These child nodes may also have an additional child node each, that has the name of another mesh group making up the borg glow (green, not the team color). These also only appear, if the currently occupying crew is of faction Borg.

The crew node is child element of damage and the parent of further nodes that are displayed when the unit suffers crew losses. It is optional (e.g. crew-less units won't need it). Usually it contains at least one child node in form of sprite nodes taken from the damage.spr file. See also Damage Sprite Node Names. By itself it does not have any direction. But its child nodes will need to be directed properly, so that sprite textures align with the surface the node is close to.

Note that when adding multiple damage nodes for crew, the order in which they will start to appear is given by the tailing number in the sprite name, after crew. The higher the number, the later the sprite is being displayed (indicating more and more amount of crew damage taken). Higher order damage nodes are added as child node of lower level nodes (making the default sprite crew16 always be the last and crew1 always be the first in stock game models).

The node damage is mandatory and has strictly a grouping function. It is parent element for the nodes borg, crew, engines, life, sensors, shields and target. The damage node is a child element of root. It does not have any direction and its location has no specific effect by itself.

The node named engines is a child of the damage element. Child elements of engines are used as damage indicators, when the engines are down. They are optional (e.g. for stationary models it makes little sense to have them). The location or direction of the engines node has no relevance by itself, but the location and direction of its child nodes does matter.

The node with the name geometry is mandatory. It represents the actual unit's optical manifestation. Without it the model will not be visible. It is child element of the root node and the parent of sub-parts of the geometry definition. Some are special in their function, such as the glow element. It makes the unit get the team color. LODs on the other hand are meant for representations of different details. See Level of Display on the concept.

The geometry node should always house nodes with the names of all mesh parts to be visible either constantly or during animations. This specifically excludes borg node elements, that are only visible if the unit is occupied by a Borg faction.

In case of mesh elements being visible only for certain levels of details (lod), the mesh elements must be child nodes of the corresponding lod node (lod1 to lodn). In case of animation elements, they must be direct child elements to geometry.

LOD nodes reference parts of the model by naming convention. Lodx with x being a number, defines the level of detail. Each LOD node has a child node, that references the part of the model by name of the mesh group to be shown for that level of detail. In the above example the sub model Bbattle_2 if referenced by the most basic LOD, with the number 0. LODs are optional. They don't have any location or orientation.

The hardpoints node is a grouping node with no direction and no effect of its location by itself. It houses two different types of nodes, actual hardpoints and bot nodes.

Actual hardpoints are the locations from which weapons fire. They are children of the hardpoints element. Each hardpoint is named hpxx, where xx is a unique, serialized number of two digits, beginning with 01. Their location is directly relevant as point of origin (when pulses, torpedoes, phasers or other originating weapons come from, when they are fired, including special weapons), but also their direction may make a difference in case of directed pulse weapons.

The botx nodes are child elements of the hardpoints node. They define the location where the worker bees of constructors come from.

The life node is a child element of the damage hierarchy. It's child nodes are usually emitters, a special kind of sprite. The are named in the same way as animated SOD models, usually representing flares. See also Steam and Fog Emitters on some commonly used ones for the life node. They are indicating the life support system being down. For ships without life support system (e.g. automated stations) it is not needed. While the location and direction of the life node has no direct relevance, the location and direction of its child nodes are relevant. They mark the origin of the emitter animation, and the direction the emitter animation will take.

The root hierarchy may also contain the lights node. If used, it holds elements that are used for lighting, such as positioning lights. Child nodes of lights are named by sprite names that can be found in the file lights.spr in the Sprites directory of your Armada main directory or in the Weapons Sprite Names article. The lights node itself has no direction and the location does not have an effect by itself. But the child elements locations and directions are both relevant.

The node named root is mandatory. It is parent of the nodes damage, hardpoints, geometry and lights. It serves strictly a grouping purpose. As such it has no orientation and its location is not relevant by itself.

The sensor node is child node of the damage node. It has no orientation and its location is not relevant by itself. It serves as a grouping node for sprite nodes. These are in stock models animated sprites, that look like welding sparks. These sprites of course have an orientation and location.

The node shield is child of root. It represents shield system damage. Child elements of it are referencing sprites shown when the shield generator is failing (red) but not when it is simply deactivated, like in a Cerulean Nebula (yellow). As always, sprite nodes have not only their location but also their direction as relevant information.

The node hierarchy target is child of damage and sprite nodes. By itself it has no orientation and its location has no effect by itself. Its child nodes are the names of the sprites shown when the weapons are down.

The names of nodes used in the stock game can be found in article Node Names.

The further away the view point of the player is from the unit, the less details a unit needs, in order to still look good. To facilitate this concept of dynamically shown models or model parts, Levels of Display (LOD). Parts of the mesh are named specifically, to be referenced by the hierarchy on form of LOD nodes.

Milkshape is not particularly well suited when it comes to creating the node hierarchy. It does not know of the concept, somewhat. Instead of it, the joint concept usually used for animations, takes its place. This has the implication, that every joint does still have a direction (just like nodes) but the location of one joint is always depending on the location of its parent element. The parent element concept is basically the same as meant for nodes. But positioning a node is not as free as it is usually required. So creating the nodes in Milkshape is not advised. 3DS Max and Storm3D Tool do a far better job.

Apparently Milkshape in conjunction with an SOD exporter requires the normally none-prefixed node names to be prefixed with indicators such as h_. These prefixes indicate what type the node has. The different types are as follows:

So for example the damage node will not be named just damage but has to be named h_damage in order to work properly. SODs imported into Milkshape will already fit this naming convention. When you have a look at the interior of SOD files exported from Milkshape, the names will be set to normal (for our example, still be named damage), too. But when creating nodes yourself, you have to prepend the names of nodes with the correct prefixes. Otherwise your model may not work (e.g. not show the meshes used or not exhibit certain behaviors, such as damage indicators).

Here are some examples of what that may look like:

[ Back to Modding ]