| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| en:games:star_trek_armada_1:modding:model_hierarchy [2025-04-23-13-33] – [Node Structure Misconceptions] 7saturn | en:games:star_trek_armada_1:modding:model_hierarchy [2025-04-23-18-04] (current) – [Geometry Nodes] 7saturn |
|---|
| |
| 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 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. |
| | ==== Officers Quarters Nodes ==== |
| | For Starbases there is the possibility of an officer upgrade (increasing the supply of a player). The optical representation of such an upgrade are special meshs, that are only displayed once a certain level of upgrades has been reached. The //oq// node is child element of //geometry// and parent element of //oq**x**// nodes. //**x**// here is a serial number, starting with 1 and increasing with the number of elements available (usually up to 6). For each upgrade level another element is displayed. These child nodes are not hierarchical (as the crew damage nodes would be). They are a flat hierarchy below //oq//. |
| ==== Crew Nodes ==== | ==== Crew Nodes ==== |
| 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 [[en:games:star_trek_armada_1:modding:node_names#damage_sprite_node_names|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. | 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 [[en:games:star_trek_armada_1:modding:node_names#damage_sprite_node_names|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. |
| 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 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. |
| ==== Geometry Nodes ==== | ==== Geometry Nodes ==== |
| 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. [[#LOD Nodes|LODs]] on the other hand are meant for representations of different details. See [[#Level of Display]] on the concept. | 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. //oreglow// is a special grouping node. It contains the glowing elements hat are shown when a mining station is currently active (unloading a freighter). [[#LOD Nodes|LODs]] on the other hand are meant for representations of different details. See [[#Level of Display]] on the concept. Officers quartes nodes (//oq//) are for the officers upgrades of starbases. |
| |
| 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. | 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. |
| Actual hardpoints are the locations from which weapons fire. They are children of the //hardpoints// element. Each hardpoint is named ''hp//xx//'', 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. | Actual hardpoints are the locations from which weapons fire. They are children of the //hardpoints// element. Each hardpoint is named ''hp//xx//'', 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. |
| === Bot === | === Bot === |
| The //bot**x**// nodes are child elements of the //hardpoints// node. They define the location where the worker bees of [[en:games:star_trek_armada_1:constructor|constructors]] come from. | The //bot**x**// nodes are child elements of the //hardpoints// node. They define the location where the worker bees of [[en:games:star_trek_armada_1:constructor|constructors]] come from. Their names can be defined by the ODF directive //workerBeeHardpoints//, which takes multiple arguments, one for each unique worker bee. Usually this is //bot1// to //bot6//. |
| === Repair === | === Repair === |
| Child element of the //hardpoints// node can also be the //repair// node. It is the spot units will move to for repairing. It is found in yards. It is a node with location and direction. The y-direction together with its location is the line in 3-dimensional space units will line up at for repair queuing. | Child element of the //hardpoints// node can also be the //repair// node. It is the spot units will move to for repairing. It is found in yards. It is a node with location and direction. The y-direction together with its location is the line in 3-dimensional space units will line up at for repair queuing. Its name might be set with ODF directive //repairHardpoint//. |
| === Build === | === Build === |
| The //build// node almost the same as the //repair// node, except it is used for construction of units, not repairs. It is as such part of yards and [[en:games:star_trek_armada_1:starbase|starbases]]. | The //build// node almost the same as the //repair// node, except it is used for construction of units, not repairs. It is as such part of yards and [[en:games:star_trek_armada_1:starbase|starbases]]. The actual name of this hardpoint can be defined by the ODF directive //buildHardpoint//. |
| | === Docking === |
| | The //dock// is similar to the //repair// node, but it is used for defining the docking location of freighters. It is as such part of [[en:games:star_trek_armada_1:Mining Stations]]. The actual name of this hardpoint can be defined by the ODF directive //dockingHardpoint//. |
| === Reseach/Pod === | === Reseach/Pod === |
| Research items are represented by their own objects at research stations. Each item has a so-called pod, which is it's own SOD model. The nodes representing the location and direction at a research station of such a pod are named //pod**xy**//, with //**xy**// being a number. | Research items are represented by their own objects at research stations. Each item has a so-called pod, which is it's own SOD model. The nodes representing the location and direction at a research station of such a pod are named //pod**xy**//, with //**xy**// being a number. |
| [[Westworlds Big Book of Modding]] is a widely regarded source on how to set up the node hierarchy. A lot of the above information basically comes from it. But some of it is actually not of a technical requirement but more like a best practice. So even the example in section [[#a_basic_hierarchy|A Basic Hierarchy]] is essentially only one way of going about a node hierarchy for a ship. Here are some of the things that the BBOM does not contain or set unjustified as a requirement: | [[Westworlds Big Book of Modding]] is a widely regarded source on how to set up the node hierarchy. A lot of the above information basically comes from it. But some of it is actually not of a technical requirement but more like a best practice. So even the example in section [[#a_basic_hierarchy|A Basic Hierarchy]] is essentially only one way of going about a node hierarchy for a ship. Here are some of the things that the BBOM does not contain or set unjustified as a requirement: |
| * [[#node_name_conventions|Node Name Conventions]]: There are actually no requirements to use specific prefixes, such as //h_//. These stem from the importer/exporter used. The nodes come by default without any of these prefixes as can be seen in the stock game SODs as well. | * [[#node_name_conventions|Node Name Conventions]]: There are actually no requirements to use specific prefixes, such as //h_//. These stem from the importer/exporter used. The nodes come by default without any of these prefixes as can be seen in the stock game SODs as well. |
| * The //root// node is not necessarily named //root//. It can also bear other names, such as //root_1// or //root1//. Example: stock game file //Bbase.SOD// has no //root// node, although it of course has a node that constitutes as the root of the hierarchy tree. | * The //root// node is not necessarily named //root//. It can also bear other names, such as //root_1// or //root1//. Example: stock game file //Bbase.SOD// has no //root// node, although it of course has a node that constitutes as the root of the hierarchy tree. Also, the name itself, even if it is used, does not necessarily name the //root// node, example would be //Kyard.SOD//, where there is a node //root// as the actual root node, as well as another child node with the name //root1//. This suggests, that the naming of the root is basically arbitrary. |
| * The //geometry// node can also be named differently, e.g. //geometry_1//. Again, example would be the //Bbase.SOD//. | * The //geometry// node can also be named differently, e.g. //geometry_1//. Again, example would be the //Bbase.SOD//. |
| * Hardpoints do not need to belong to a node specifically named //hardpoints//. Example again is //Bbase.SOD//. Here the hardpoints are named by the usual //hp**xy**// scheme, but belong to the node //Bhardpts//. | * Same way //lights// can be named //lights_1//, example would be //Rbase.SOD//. |
| | * //lights// does not seem to be necessary at all, as is indicated by //Rsuperbl.SOD//. It does not have a //lights// node at all but the strobe nodes, that usually are placed below //lights//. This suggests, that //lights// as a grouping node is merely a convention but no technical necessity. Light nodes can basically be placed anywhere in the hierarchy. |
| | * Hardpoints do not need to belong to a node specifically named //hardpoints//. Example again is //Bbase.SOD//. Here the hardpoints are named by the usual //hp**xy**// scheme, but belong to the node //Bhardpts//. This includes the //pod// nodes (see //Kresear.SOD//). |
| * Nodes //build// and //repair// behave the same as other hardpoints, see //Bbase.SOD//. | * Nodes //build// and //repair// behave the same as other hardpoints, see //Bbase.SOD//. |
| * //hp**xy**// hardpoints do not need to be numbered consecutively. They may very well start with some other number than //00// or //01// and they may also have gaps in the numbering. Just make sure you do not use hardpoints in [[en:games:star_trek_armada_1:modding:odf_files|ODFs]], that do not exist. Example: //Bturret2.SOD//. | * //hp**xy**// hardpoints do not need to be numbered consecutively. They may very well start with some other number than //00// or //01// and they may also have gaps in the numbering. Just make sure you do not use hardpoints in [[en:games:star_trek_armada_1:modding:odf_files|ODFs]], that do not exist. Example: //Bturret2.SOD//. |
| * Hardpoints for weapons do not require to be attached to parent node //hardpoints//. You can just as well attach a hardpoint directly to the //root// node. Example: //Bbee.SOD//. | * Hardpoints for weapons do not require to be attached to parent node //hardpoints//. You can just as well attach a hardpoint directly to the //root// node. Example: //Bbee.SOD//. |
| * //hp**xy**// is not a hard defined definition for (weapon) hardpoints at all. In the //Fscout.sod// file there is no //hardpoints// node, but instead the nodes are child elements of a node named //hp20//. So neither the name of the parent node is a hard requirement, nor are hp nodes strictly weapon hardpoints. | * Weapon hardpoints do not necessarily follow the name pattern //hp**xy**//. Example would be //Romega.SOD//, where the tractor beam hardpoint is simply named //tractor//. |
| | * The naming pattern //hp**xy**// is not a hard definition for (weapon) hardpoints specifically at all. In the //Fscout.sod// file there is no //hardpoints// node, but instead the hardpoint nodes are all child elements of a node named //hp20//. So neither the name of the parent node is a hard requirement, nor are //hp// nodes strictly weapon hardpoints. |
| | * Although for many units only the pattern //hp**xy**// is used, with //**xy**// being a two digit number, more digits are indeed allowed, e.g. //hp200//, as seen in //FbaseHQ.SOD//. |
| * The mesh nodes do not need to be part of a //geometry// node. They can just as well be attached to the root node. Example: //Bbee.SOD//. | * The mesh nodes do not need to be part of a //geometry// node. They can just as well be attached to the root node. Example: //Bbee.SOD//. |
| * Certain nodes with special roles can be nested, e.g. node //damage// is found as a child of //geometry// in the //Bsuperbl.SOD// file, or //geometry// houses //hardpoints// in the //Byard2.SOD// file. | * Certain nodes with special roles can be nested, e.g. node //damage// is found as a child of //geometry// in the //Bsuperbl.SOD// file, or //geometry// houses //hardpoints// in the //Byard2.SOD// file. |
