| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| en:games:star_trek_armada_1:modding:model_hierarchy [2025-04-23-15-58] – 7saturn | en:games:star_trek_armada_1:modding:model_hierarchy [2025-04-23-18-04] (current) – [Geometry Nodes] 7saturn |
|---|
| 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. Officers quartes nodes (//oq//) are for the officers upgrades of starbases. | 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. |
| [[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//. |
| | * 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. | * 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//. | * 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//. |
