Xml Tag Functions

EAW has about 4000 xml tags (according to the modder Eniken Sklavenwalker), and not all of them have avious naming.

So I will open this thread here to mirror our Internal variant of it. Now here is what (we think that) xml tags do:

bool GUI_Hide_Health_Bar = Will hide Health + Shieldbar if set to "No", then the player can only see energy of own ships while selected in the dashboard.

int Gui_Bracket_Size = Sets the Size of the Healthbar, 0 = Small, 1 = Medium, 2 = Large
float GUI_Bounds_Scale = (0.1 - 2.0) Sets the Height of the Healthbar, smaller ships need smaller value, capitalships need it higher

<Attack_Animation_Is_Overlay> = Caution: If set to "Yes" this tag can disable the Attack Animation entirely.


What do we know about Containers?
I messed a few nights ago with them and had some tests.

They are aviously connected to the unit through the GroundCompany unit using the <Create_Team_Type> tag.

What I know now is that Containers overwrite most tags of "GroundCompany" Teams and "Squadrons", even if these tags are empty in the Container or not added at all. That's the reason why they need Encyclopedia Text values, Icon, Select Box Scale and Abilities repeated from the GroundCompany or the Unit itself.

We can make code sleeker when we leave Encyclopedia Text values, Icon, Select Box Scale and especially Abilities away from Squadrons/Teams that use Containers, because they are obsolete there.

I wonder which tags are exactly overwritten, I mean a full list? This is what I found by now:


I guess the main purpose of Containers is allowing the player to select multiple Units in the Team as "one single unit", and moving them as one object with a single energy bar and select box.

And <Select_Box_Scale> shall only be written in the Container Unit, and not in the Infantry, because a big Selectbox shall be around the whole squad instead of many little boxes, one per team member inside of the Infantry/Vehicle unit.

How do Locomotors work?
Like most of the tags you should know which part of your unit needs what kind of locomotor.

For example you can paste a certain behavoir in both the Infantry unit and the GroundCompany Instance, but you actually better write it only into the instance that really needs it instead of writing unnecessary code that
might cause a minimal delay at runtime for running double code (my assumption).

Also there is the tag <Uses_Multiple_Locomotors>, if set to "Yes" it needs the two locomotors listed in:
<Primary_Locomotor_Name> and <Secondary_Locomotor_Name> additionally to the <Behavoir> Locomotors

The Behavoir tags are always supposed to contain only one type of locomotor, because if you type 2 into Behavoir or Landbehavoir they just block eachother. Even if you have <Uses_Multiple_Locomotors> to yes the engine only expects the primary locomotor in Behavoir.

Caution: There are some tags like <Has_Pre_Turn_Anim>, if set to "Yes" they block the Locomotor or block the usage of the "Jet_Pack" ability of Boba Fett, which is the ability that activates second locomotor and plays the fly animations from the Boba_Fett.alo

Also <MovementClass> is supposed to be the same class as the used Locomotor in behavoir. For example use Infantry in <MovementClass> together with WALK_LOCOMOTOR in <Land_Behavoir>
Then JETPACK_LOCOMOTOR in <Secondary_Locomotor_Name>

---

So most locomotors are for the Infantry/Vehicle/Ship SINGLE units, these are:

WALK_LOCOMOTOR: Single unit (team uses something else utilizing Containers.)
BIKE_LOCOMOTOR: (Vehicles) Used for the speeder bike
FLYING_LOCOMOTOR: (Vehicles) Used for flying units, though sometimes it is better to use Walk Locomotor + Hover to let them hover a steady path like Helicopters

LAND_TEAM_INFANTRY_LOCOMOTOR: (Infantry) Always used for units that are in a squad Probably will only work in combination with an container unit connected to the GroundCompany instance using the <Create_Team_Type> tag. And in combination with the LAND_TEAM_CONTAINER_LOCOMOTOR in <Land_Behavoir>, which also needs these requirements of its own:

LAND_TEAM_CONTAINER_LOCOMOTOR is meant to only be used in Container units and without these two tags the teams won't move at all:
<MovementClass>Infantry</MovementClass>
<OccupationStyle>1x1</OccupationStyle>


And you need the exactly same values in <Max_Speed> and <Max_Rate_Of_Turn> in both, the unit itself and in the Container too (but not in Groundcompany or Squadron)
Otherwise the unit will be really slow because it waits for the Container, which is pretty slow without having these tags.
BUG: Also a value of 3.0 or higher is safe for <Max_Rate_Of_Turn>, but if it is lower it will result in the Infantry units of the squad rotating too slow when they turn and then just move right away without rotating into the new target direction (the delay time passed and they just start away): They all move into different directions out of the squad instead of moving to the point where the player sends them!

<ContainerArrangement>Dartboard</ContainerArrangement> = Without this the team moves slower, I guess they collide and slow eachother down. Also they all move into the same point without distributing in the space.
<FormationSpacing>0.8</FormationSpacing> = Locomotor works without it, but then it uses default distance beteween team members which can be wrong


Also the Infantry units of this Container need all to have LAND_TEAM_INFANTRY_LOCOMOTOR because with WALK_LOCOMOTOR they would just move unorganized outside of the Team Selectbox.

---

Space Locomotors

---

[/color]

All singe space units use SIMPLE_SPACE_LOCOMOTOR
Otherwise if they are part of a squadron of more then 1 unit FIGHTER_LOCOMOTOR is the right one.

Fighter_Locomotor assignes a coordinate from the <Squadron_Offsets> tags (each ship in the team needs a own Squadron_Offsets entry with unique coordinates):
<Squadron_Offsets>x, y, z</Squadron_Offsets>

Hmm,
I just made an fortuitous and interesting discovery , I intended to do something else and placed the entry
DUMMY_STAR_BASE into the <Behavior> tag of a Spaceship. Then cheat-spawned it to a galactic map via lua script.

Now I was pretty surprised to see it always destroys the StarBase on the planet I spawn that unit, like WTF

So the game seems to just auto replace the existing StarBase by the next object with DUMMY_STAR_BASE in its <Behavior> tag that enters the orbit.

This will come in handy to spawn LV 6 star bases or stuff for custom factions by build able dummy spawners.

Another interesting thing, these two tags make Starbase Hardpoints repairable and can be applied to capital ships, in theory.
But they are only going to work in Skirmish Mode, and they also work only in combination with DUMMY_STAR_BASE in the <SpaceBehavior> tag. (remember to keep it away from <Behavior> because of the bad GC layer interaction featured in my last post).

<Repair_Cost_Per_Frame>1.3</Repair_Cost_Per_Frame><Repair_Amount_Per_Frame>.50</Repair_Amount_Per_Frame>

And there is one additional side effect; If you loose your real Starbase in Skirmish you don't loose the game while any ship remains on the map with DUMMY_STAR_BASE in its <SpaceBehavior> tag.
The player looses when all of these ships died.

Now would it be any good idea to give Hardpoint repairing abilities to well chosen Super capital ships?
Maybe, but these units would need an additional self destruct lua script that kills them if the real Starbase dies. Another possibility would be to keep them as second major target and their build thus would be limited to 1x per game.