| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| en:games:star_trek_armada_1:modding:model_hierarchy [2025-04-23-15-49] – 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. |
| 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. Its name might be set with ODF directive //repairHardpoint//. | 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//. |
| [[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//. |
