XML Format
Table of Contents
Unsupported. Fleet Operations 4.0.0 introduces a new format for techtree files to overcome some limitations of the old .tt files. Though it is still possible to use the old .tt format, it is not recommended when creating new mods.
Advantages over .tt Files
- Support for "either-or" tech requirements
- Race dependent tech requirements
- Tech requirements based on available allied or enemy players (races).
- Tech requirements based on allied or enemy player technology
- Read the documentation for more details...
**** Also, there will be a little tool ready that converts the .tt files to .xml format
Technology Tree XML
The new TechnologyTree files are written in a XML format. These files require a root element which has the name "techtree".
The most basic Technology file therefore should look like this:
<techtree>
</techtree>
Comments in XML files have to be started with a <!‑‑ and end with ‑‑>
<!-- I am a comment -->
Root can have four different elements:
object: To define the requirements of a ODF file to be build.
capacityList: A list for complex object capacity limits.
include: Allows inclusion of another file.
parentInclude: Allows inclusion of the same file from a parent mod.
object
Attributes of <object>
ODF
Defines the associated ODF file. This must be defined. The .odf file extension is not required, but it is the default.
Example:
<object ODF="fed_mediterraneanY.odf"/>
logicGroups
***description here*** logicGroups represent "or" requirements
fedSaber requires:
FederationRace and fedAkira and fedNewton
or
RomulanRace and fedAkira
Example:
<object ODF="fedSaber">
<requirement logicGroups="1" race="federation"/>
<requirement logicGroups="2" race="romulan"/>
<requirement logicGroups="1,2">
<obj>fedAkira.odf</obj>
</requirement>
<requirement logicGroups="1">
<obj>fedNewton.odf</obj>
</requirement>
</object>
Elements of <object>
requirement
Objects can have more than one requirement element. Each requirement is handled as an OR requirement for the object. An object without a "requirement" element has no technology requirements.
Attributes of <requirement>
race
Defines the faction required to build that requirement (defined by the Faction configuration Name ODF command).
Example:
<!-- The Mandril freighter can only be build by Federation or Borg players -->
<object ODF="fed_mandril.odf">
<requirement race="federation"/>
<requirement race="borg"/>
</object>
Boolean, Default: FALSE
Hide button if requirement is not met. Checks for every requirement (i.e., if set to TRUE, the button is hidden if any single requirement is not met).
Elements of <requirement>
obj
Defines an object requirement.
Set the value to the ODF that is required to build the object.
Example:
<!-- A storage dock is required to build the Mandril freighter-->
<object ODF="fed_mandril.odf">
<requirement>
<obj>fed_storage_dock.odf</obj>
</requirement>
</object>
Attributes of <obj>
mustNotHave
Boolean, Default: FALSE
Reverses the requirement.
Example:
<!-- The player must not have an Eraudi Yard to allow construction of the Mandril freighter -->
<object ODF="fed_mandril.odf">
<requirement>
<obj mustNotHave="true">fed_eraudi_yard.odf</obj>
</requirement>
</object>
cap
Defines simple capacity requirement.
Attributes of <cap>
maxCapValue
Integer, Default: 1
Defines the maximum capacity for the vessel. One built craft has a capValue of 1 by default (can be changed with capValue).
If maxCapValue is set to 10 and 9 crafts of this type were built, then only 1 more of the craft can be built. See capValue on how to increase maxCapValue during a game.
Example:
<!-- You can only build 10 Mandril freighters -->
<object ODF="fed_mandril.odf">
<requirement>
<cap maxCapValue="10"/>
</requirement>
</object>
tooltip
String, Default: "GUI_CP_CAP_TOOLTIP"
The tooltip that is displayed prior to the capacity being filled. Can either be specified in the Dynamic_Localized_Strings.h or directly within the technology tree.
tooltipReached
String, Default: "GUI_CP_CAP_TOOLTIP_REACHED"
The tooltip that is displayed when the capacity is met. Can either be specified in the Dynamic_Localized_Strings.h or directly within the technology tree.
tooltipOver
String, Default: "GUI_CP_CAP_TOOLTIP_OVER"
The tooltip that is displayed when the capacity is exceeded. Can either be specified in the Dynamic_Localized_Strings.h or directly within the technology tree.
Example:
<object ODF="fedMayson">
<requirement>
<cap tooltip="Work in Progress" tooltipReached="Already present" tooltipOver="Already present"/>
</requirement>
</object>
countConstructions
Boolean, Default: TRUE
When set to 1 (true), vessels currently being built also count against the cap.
capList
Links to a capacityList.
Set the value of capList to name attribute of a capacityList.
Example:
<object ODF="fed_mandril.odf">
<requirement>
<capList>FreighterLimit</capList>
</requirement>
</object>
Attributes of <capList>
contextODF
String
Context ODF in which the capList is queried.
<!-- To be used, the Federation Warp In weapon (fedWarpIn) requires fedWarpInThreeSlots to not have filled its cap, defined by the warpinCap capacityList -->
<object ODF="fedWarpIn">
<requirement>
<capList contextODF="fedWarpInThreeSlots.odf">warpinCap</capList>
</requirement>
</object>
enemy/ally
A faction or player requirement. The element name either can be "enemy" or "ally".
Attributes of <enemy/ally>
race
String
Defines the faction via the Faction configuration Name ODF command.
Elements of <enemy/ally>
obj
Optional. Object requirements for another faction or player.
The value defines the ODF for this requirement.
Attributes of <obj>
mustNotHave
Boolean, Default: FALSE
Works the same as for the obj requirement.
Example:
<!-- If an enemy player has a Borg Cube, you are unable to build a Mandril freighter -->
<object ODF="fed_mandril.odf">
<requirement>
<enemy>
<obj mustNotHave="true">bor_cube.odf</obj>
</enemy>
</requirement>
</object>
capacityList
Attributes of <capacityList>
name
String
Must be defined. A name for the capacityList.
Example:
<capacitylist name="veteranCap">
</capacitylist>
maxCapValue
Integer, Default: 1
Defines the maximum capacity value for objects in the capacityList. See capValue on how to increase maxCapValue during a game.
Example:
<capacitylist maxCapValue="25">
</capacitylist>
tooltip
String, Default: "GUI_CP_CAP_TOOLTIP"
The tooltip that is displayed prior to the capacity being filled. Can either be specified in the Dynamic_Localized_Strings.h or directly within the technology tree.
tooltipReached
String, Default: "GUI_CP_CAP_TOOLTIP_REACHED"
The tooltip that is displayed when the capacity is met. Can either be specified in the Dynamic_Localized_Strings.h or directly within the technology tree.
tooltipOver
String, Default: "GUI_CP_CAP_TOOLTIP_OVER"
The tooltip that is displayed when the capacity is exceeded. Can either be specified in the Dynamic_Localized_Strings.h or directly within the technology tree.
Example:
<object ODF="fedMayson">
<requirement>
<cap tooltip="Work in Progress" tooltipReached="Already present" tooltipOver="Already present"/>
</requirement>
</object>
countConstructions
Boolean, Default: TRUE
Vessels currently being built also count against the cap.
Elements of <capacityList>
obj
Attributes of <obj>
capValue
Integer, Default: 1
The value of a vessel. By default each build object in the cap has a value of 1. So if 2 vessels with a defined capValue of 5 are being built, a maxCapValue of 10 can be reached.
Example:
<capacitylist name="FreighterLimit" maxCapValue="10">
<obj>fed_mandril.odf</obj>
<obj capValue="5">bor_freighter.odf</obj>
</capacitylist>
If the capValue is negative, the maxCapValue will be shown to be increased by this capValue in-game. Consequently, if 2 vessels with a defined capValue of -5 are built, a maxCapValue of 20 can be reached.
Example:
<capacitylist name="FreighterLimit" maxCapValue="10">
<obj>fed_mandril.odf</obj>
<obj capValue="-5">bor_freighter.odf</obj>
</capacitylist>
include
Include another technology tree file of XML or TT format. ***The location of this command matters: must be placed at top, otherwise it overwrites the other techtree file.
<techtree>
<include file="normal.xml"/>
<!-- also mixing old and new tech file formats is possible-->
<include file="tech1.tt"/>
</techtree>
Note that including another technology tree file does not overwrite the same commands of the parent file. It only adds to them.
For example:
<!--The parent file has an either/or requirement-->
<object ODF="fedPlatform">
<requirement race="federation">
<obj>fedAntares.odf</obj>
</requirement>
<requirement race="federation">
<obj>fedCassiopeia.odf</obj>
</requirement>
</object>
<!--The child file, which will include the parent file, has an either/or requirement with two additional objects-->
<object ODF="fedPlatform">
<requirement race="federation">
<obj>fedAntares.odf</obj>
<obj>fedStrategicDivision.odf</obj>
</requirement>
<requirement race="federation">
<obj>fedCassiopeia.odf</obj>
<obj>fedStrategicDivision.odf</obj>
</requirement>
</object>
When the parent file is included in the child file, the Platform will thus require an Antares Yard OR a Cassiopeia Yard OR an Antares Yard and Strategic Division OR a Cassiopeia Yard and Strategic Division.
parentInclude
Include the file of the same name from the parent mod. ***The location of this command matters: must be placed at top, otherwise it overwrites the other techtree file.
Example:
<techtree>
<parentinclude/>
</techtree>
Note that including another technology tree file does not overwrite the same commands of the parent file. It only adds to them.
For example:
<!--The parent file has an either/or requirement-->
<object ODF="fedPlatform">
<requirement race="federation">
<obj>fedAntares.odf</obj>
</requirement>
<requirement race="federation">
<obj>fedCassiopeia.odf</obj>
</requirement>
</object>
<!--The child file, which will include the parent file, has an either/or requirement with two additional objects-->
<object ODF="fedPlatform">
<requirement race="federation">
<obj>fedAntares.odf</obj>
<obj>fedStrategicDivision.odf</obj>
</requirement>
<requirement race="federation">
<obj>fedCassiopeia.odf</obj>
<obj>fedStrategicDivision.odf</obj>
</requirement>
</object>
When the parent file is included in the child file, the Platform will thus require an Antares Yard OR a Cassiopeia Yard OR an Antares Yard and Strategic Division OR a Cassiopeia Yard and Strategic Division.