Heavenfall Heavenfall

[eLIB] UnitStat Background Mod v.ZG for FE

[eLIB] UnitStat Background Mod v.ZG for FE

 

This library mod is for other modders to include in their mods. There is no point downloading this on its own as a player.

 

UnitStat Background Mod v.ZF = FE 1.34


As part of making the game have greater depth, which is the purpose of any mod, I will be releasing a UnitStat Background mod. The purpose of this library-type mod is to flag unittypes, items and traits with certain UnitStats that will allow the modders to identify them in various scenarios. It is a bit difficult to explain, so I will simply give an example: Imagine a dragon has UnitStat_BG_IsDragon = 1. Then we put this modifier on a weapon:

            <GameModifier>
                <ModType>Unit</ModType>
                <Attribute>AdjustUnitStat</Attribute>
                <StrVal>UnitStat_Accuracy</StrVal>
                <StrVal2>UnitStat_BG_IsDragon</StrVal2>
                <Value>10</Value>
                <vsHigher>1</vsHigher>
            </GameModifier>

The result is a weapon that gains +10 accuracy whenever it attacks against a dragon. Voilá, a dragon-slaying weapon. Or a trait. Such UnitStats can also be referred to in Calculate tags in spells, for example to make a damage spell deal even more damage against a dragon.

Note that this mod will only function as a library of back-ground unitstats. It will be up to the modders to use the unitstats as they see fit.

 

I want to open up the floor for what unitstat flags the modding community expect to find in such a mod.

 

This is my planned list of unitstats. Note that these unitstats will not have defaultvalue set to 0 for all units, they will simply have 0 by virtue of not having it. 

Equipment UnitStats:

UnitStat_BG_IsUsingMount - 1 for mounted units, 0 for un-mounted units

Unit UnitStats: (stats marked ^ are given through traits to help players understand what is what)

UnitStat_BG_IsChampion - 1 for champions and sovereigns
UnitStat_BG_IsSovereign - 1 for sovereigns, 0 for others (note that everyone with IsSovereign also have IsChampion)
UnitStat_BG_IsMilitia^ - 1 for city militia, 0 for all others
UnitStat_BG_IsHumanoid - 1 for any unit that resembles a human in shape, not necessarily in size
UnitStat_BG_IsNotAlive^ - 1 for any unit that does not have blood pumping in its veins, is incapable of consuming nutrition, and is incapable of reproduction
UnitStat_BG_IsEmpire - 1 for sovereigns, champions and designed units from empire factions. 0 for others
UnitStat_BG_IsKingdom - 1 for sovereigns, champions and designed units from Kingdom factions. 0 for others
UnitStat_BG_IsRace_ - These unitstats are given to mark all champions, sovereigns and designed units from certain racetypes. These are the "races" that appear in Unit Details when you create a normal unit. The wildcard (*) is replaced by the name of the race as it appears in-game. The vanilla game contains 10 races that have the following names: Altarians, Mancers, Ironeers, Amarians, Tarthans, Krax, Wraiths, Trogs, Urxen, Quendar. For example, all of the race Altarians have UnitStat_BG_IsRace_Altarians = 1
UnitStat_BG_IsMonster - for all units considered monsters. Note that this applies to recruited monsters as well. Anything that is not humanoid is considered a monster.
UnitStat_BG_IsDragon - 1 for dragon monsters, 0 for others
UnitStat_BG_IsElemental - 1 for elementals, 0 for others
UnitStat_BG_IsBeast - 1 for beasts, 0 for others
UnitStat_BG_IsTwisted - 1 for Twisted creatures, 0 for others
UnitStat_BG_IsConstruct - 1 for construct creatures, 0 for others (basically golems)
UnitStat_BG_IsDemon^ - 1 for demons, 0 for others
UnitStat_BG_IsGod^ - 1 for the 5 elemental gods found in the wildlands and other godtype units at your discretion, 0 for others
UnitStat_BG_IsSummoned^ - 1 for units that are specifically summoned through magical spells, and NOT those trained. 0 for others
UnitStat_BG_IsImmortal^ - 1 for certain units that cannot die from old age. In the core game, these include: Titans, Dragons and Butchermen, Elemental gods (NOT all elementals!). 0 for all others. Keep in mind constructs are not immortal and may die from old age (they basically turn to dust after a few thousand years), but they are also UnitStat_BG_IsNotAlive^ 1.
UnitStat_BG_IsOversized^ - It is 1 for units that are substantially larger than a single human-sized mounted man. Note that this indicates that a singular unit of this sort is oversized - a unit does not become oversized if it goes from 1 to 9 members. Dragons, Giant Slags, Giant Drakes, elemental gods, and so on. It is 0 for all others.
UnitStat_BG_IsMale - 1 for units specifically marked male. 0 for others. Note: This is only applied to champions and sovereigns and troops. Practically noone else has a gender. It is perfectly possible for a unit to have 0 in both _IsMale and _IsFemale.
UnitStat_BG_IsFemale - 1 for units specifically marked female. 0 for others. Note: This is only applied to champions and sovereigns and troops. Practically noone else has a gender. It is perfectly possible for a unit to have 0 in both _IsMale and _IsFemale.
UnitStat_BG_IsFlying^ - 0 (default) = incapable of flight. 1 = Capable of Flying (does not need to be constantly flying)

Other Custom UnitStats:

UnitStat_BG_HasInjuries - 0 for all, each injury suffered by a champion adds +1. Note that there are many "flaws" that are NOT injuries. This tag is specifically for champion injuries suffered due to incapacitation in combat.
UnitStat_BG_Spellbooks - between 0 and 5, depending on how many spellbooks this champion/sov/unit has. It is enough to have rank 1 in a spellbook to get +1 in this unitstat.
UnitStat_BG_GreyMagic - Between 0 and 25+, depending on how many spelltraits this champion/sov/unit has. Each spelltrait adds 1, so a champion with Death2 Fire3 would have UnitStat_BG_GreyMagic = 5.

Non-unit Stats
A_Additive_TileYieldGrain - Faction-wide bonus additive to Grains. Ex: +1 Grain in every city
A_Additive_TileYieldMaterials - Faction-wide bonus additive to Materials. Ex: -1 Material in every city
A_Additive_TileYieldEssence - Faction-wide bonus additive to Essence. Ex: -1 Essence in every city

 


 

Currently disabled

UnitStat_BG_IsInSwamp - 0 for all units, 1 for those who are occupying a Swamp tile on the strategic map
UnitStat_BG_IsInPlains - 0 for all units, 1 for those who are occupying a Plains tile on the strategic map
UnitStat_BG_IsInHills - 0 for all units, 1 for those who are occupying a Hills tile on the strategic map
UnitStat_BG_IsInDesert - 0 for all units, 1 for those who are occupying a Desert tile on the strategic map
UnitStat_BG_IsInForest - 0 for all units, 1 for those who are occupying a Forest tile on the strategic map
UnitStat_BG_IsInCity - 0 for all units, 1 for those who are occupying a City tile on the strategic map
UnitStat_BG_IsInRiver - 0 for all units, 1 for those who are occupying a River tile on the strategic map



UnitStat_BG_IsUsingSmallShield - 1 for units with a small or normal shield equipped, 0 for others. Does not mark tower shields.
UnitStat_BG_IsUsingTowerShield - 1 for units with a tower shield equipped, 0 for others. Does not mark non-tower shields
UnitStat_BG_IsUsingSpear - 1 for units with a spear, 0 for others
UnitStat_BG_IsUsingStaff - 1 for units with a staff, 0 for others
UnitStat_BG_IsUsingBow - 1 for units with a bow, 0 for others
UnitStat_BG_IsUsingMace - 1 for units with a mace, 0 for others
UnitStat_BG_IsUsingSword - 1 for units with a sword, 0 for others
UnitStat_BG_IsUsingAxe - 1 for units with a axe, 0 for others
UnitStat_BG_IsUsingDagger - 1 for units with a dagger, 0 for others

UnitStat_BG_IsUsingTwoHanded - 1 for units with a Two-handed weapon equipped, 0 for others. This counts for all weaponry that requires both hands to use, such as staffs, bows and spear.
UnitStat_BG_IsUsingOneHanded - 1 for units with a one-handed weapon equipped, 0 for others.
UnitStat_BG_IsUsingDualWield - 1 for units with two one-handed weapons equipped, 0 for others
UnitStat_BG_IsWearingLeather - This value is between 0 and 7 - each equipped leatherpiece adds 1, chest and leggings add 2 instead of 1
UnitStat_BG_IsWearingChainmail - This value is between 0 and 7 - each equipped chainmailpiece adds 1, chest and leggings add 2 instead of 1
UnitStat_BG_IsWearingPlate - This value is between 0 and 7 - each equipped platepiece adds 1, chest and leggings add 2 instead of 1
UnitStat_Bg_MagicalNature - A custom value given to items of a magical nature. Any non-magical item should have nothing (0). As a base-line, magical items will start at UnitStat_Bg_MagicalNature = 100. Particularly powerful, or reality-bending items might have 200 or even 300. There is no clear line between rarity of items and this stat, because the game has many "uncommon" magical and non-magical items. Items will display their number in the item tooltip, unless it is 0 in case it won't be mentioned. Accessories can also have this stat.
UnitStat_BG_IsRanged - 1 for any weapon that turns the main attack of a unit into a ranged attack. 0 for others
UnitStat_BG_IsMelee - 1 for any melee weapon, and any unarmed monster. 0 for others


 

 

 

92,370 views 145 replies
Reply #51 Top

Quoting Capn, reply 50
HF, Your CoreSpells shows two SummonEarthElementals. They appear to be identical. Core Units has the Likihood mis-spell in it.

Rest of the Mod is awesome. Thanks for all of the hard work!

Thank you for the reports. The earth elemental spell duplicate was removed. The <Liklihood> tag is how it is in the core files, and it is how it is spelled in some cases.

Reply #52 Top

I noticed some more errors that will be fixed in the next version. All shields had the old _IsUsingShield tag, that is being removed. Also, the unitstats for IsUsingTowerShield and IsUsingSmallShield were not set up properly and won't work in version A.

I've also made some other decisions in regards to what unitstats go into the mod.

UnitStat_BG_ResistBlunt
UnitStat_BG_ResistCutting
UnitStat_BG_ResistPierce

these stats are already unoficially in the mod, but they'll be permanently added. They're great unitstats that work in the background, so I see no reason to put them elsewhere.



From the lib_allowglobalyieldmod.xml file,

A_Additive_TileYieldGrain
A_Additive_TileYieldMaterials

Those allow global additions to material and grains for abilities. It's not really unitstats at all, but I'm putting it here any way. Wanna fight about it? Anyway, they're useful if you want a faction ability or something like that, that gives +1 grain or -1 grain for your entire faction.

 

Another unitstat that will be joining the general line-up is the

UnitStat_BG_IsUsingDualwield

even though no core weaponry is using that method, I say it will be common enough in mods to bring it in here. As in, I have it in every mod I'm making and it's just plain easier to have it in this lib.

 

Also, I'm an idiot and forgot to add the unitstats for _IsRace_. They'll be in v. B.

Reply #54 Top

Thanks,

I'll give it a run. I am getting a number of odd bugs with 86 and the A version and the Relinquary mod. Missing art work for items and weapons, some spells not working Eagle Eye for one (FOW not being removed), can't build caravans, and a weird Sov build were the base init value was 12 and not 22. Added a bow and did not see I was at 6 and was getting killed right and left since I had no actions after the first shots. Not sure what to make of it all. I may just reload 86 clean and then layer in your mods and mine to see where the break is.

Great stuff BTW!

Reply #55 Top

If it happens again, do send me a save

Reply #56 Top

I'll reload clean tonight and retest. If it breaks I'll post the save file.

Reply #57 Top

In what directory are you putting the mods? Also, were you using an old custom sovereign from before 0.85?

Reply #58 Top

New Sov, C:...\Documents\My Games\FallenEnchantress\Mods

Your information is showing up. I'm getting ready to copy out my mods from core files and then flush and redo the install. More later.

Reply #59 Top

If you're still taking suggestions, I'd like to request UnitStat_BG_UnitSize (referencing the literal size of the unit, rather than the troop count) that takes the following values:

1= Small

2= Medium

3= Large

4= Very Large.


You could then link the Shrink and Growth spells to this stat and do all sorts of fun things. For example, I think it would be fun to have, say, a Boiling Blood spell that does more damage to smaller units than larger units, or modify the Gale-type spells to have a chance of blowing small units back, but not large units. Because, really, who doesn't want to shrink enemy units and microwave them a little bit. Thanks! The work is much appreciated, as always.

EDIT: After reading a little bit more carefully, I see that you already have an IsOversized stat. I think that this system would be a little bit more flexible, but it's obviously up to you to include it or not. 

Reply #60 Top

I just ran across this thread and I have a suggestion. 

First though, maybe you could explain for me how these comparisons work. Can you choose which 2 units to compare and when, or is the timing and which 2 units automatically handled by the game and you only set up rules for those events.

 

 

Reply #61 Top

Maybe an undead stat so we can have turn undead as a spell?

Reply #62 Top

Are these unitstats respected at design time? Like could you make a certain combination of items cause a penalty attribute (like plate armor and bows) or allow for adding a new attribute (like say tortise formation if you give the unit a sword and tower shield)?

Reply #63 Top

I have bolded my replies. The nesting of quotes suck donkey.

Quoting LightofAbraxas, reply 59
If you're still taking suggestions, I'd like to request UnitStat_BG_UnitSize (referencing the literal size of the unit, rather than the troop count) that takes the following values:

1= Small

2= Medium

3= Large

4= Very Large.




You could then link the Shrink and Growth spells to this stat and do all sorts of fun things. For example, I think it would be fun to have, say, a Boiling Blood spell that does more damage to smaller units than larger units, or modify the Gale-type spells to have a chance of blowing small units back, but not large units. Because, really, who doesn't want to shrink enemy units and microwave them a little bit. Thanks! The work is much appreciated, as always.

EDIT: After reading a little bit more carefully, I see that you already have an IsOversized stat. I think that this system would be a little bit more flexible, but it's obviously up to you to include it or not. 

I considered a "size" unitstat earlier, but honestly... there are hundreds and hundreds of units in the game. It's just sooo much work. I think maybe if people helped me out with that one, I would definitely put it in but on my own... no.

 

Quoting UmbralAngel, reply 60
I just ran across this thread and I have a suggestion. 

First though, maybe you could explain for me how these comparisons work. Can you choose which 2 units to compare and when, or is the timing and which 2 units automatically handled by the game and you only set up rules for those events.

 

 

 

These stats are relevant on different occasions. The circumstance of the game decides when they are relevant.

The first occasion is whenever two units engage in melee fighting. That is, if one unit hits another in melee. Then we can use simple modifiers such as this

       <AbilityBonusOption InternalName="ChampionIsHatedByGods">
            <DisplayName>Hated by Gods</DisplayName>
            <Description>All Gods hate this unit and deal +40% physical damage against it.</Description>
            <GameModifier>
                <ModType>Unit</ModType>
                <Attribute>AdjustUnitStat</Attribute>
                <StrVal>UnitStat_BG_ResistBlunt</StrVal>
                <StrVal2>UnitStat_BG_IsGod</StrVal2>
                <Value>-20</Value>
                <vsHigher>1</vsHigher>
            </GameModifier>
            <GameModifier>
                <ModType>Unit</ModType>
                <Attribute>AdjustUnitStat</Attribute>
                <StrVal>UnitStat_BG_ResistCutting</StrVal>
                <StrVal2>UnitStat_BG_IsGod</StrVal2>
                <Value>-20</Value>
                <vsHigher>1</vsHigher>
            </GameModifier>
            <GameModifier>
                <ModType>Unit</ModType>
                <Attribute>AdjustUnitStat</Attribute>
                <StrVal>UnitStat_BG_ResistPierce</StrVal>
                <StrVal2>UnitStat_BG_IsGod</StrVal2>
                <Value>-20</Value>
                <vsHigher>1</vsHigher>
            </GameModifier>



The second occasion is whenever a spell is cast. Just as above, the same modifier applies whenever a unit is target by a spell, or casting a spell. The game compares caster vs target.

The third occasion when these unitstats are relevant for comparison is when you are casting a spell and you wish to use the Calculate tag. See CoreSpells.xml for example, but basically, it allows for effects based on unitstats - a spell might cause a 10% slow, but 20% slow if target is a dragon, for example.

 

Quoting seanw3, reply 61
Maybe an undead stat so we can have turn undead as a spell?

I have _IsNotAlive. Are you thinking that undead is different from that? isNotAlive is used for golems and catapults currently. Would an undead unit have both IsUndead and IsNotAlive?

 

Quoting Sarudak, reply 62
Are these unitstats respected at design time? Like could you make a certain combination of items cause a penalty attribute (like plate armor and bows) or allow for adding a new attribute (like say tortise formation if you give the unit a sword and tower shield)?

No, they are not.

Reply #64 Top

Quoting Heavenfall, reply 63

[quote who="Sarudak" reply="62" id="3094057"]Are these unitstats respected at design time? Like could you make a certain combination of items cause a penalty attribute (like plate armor and bows) or allow for adding a new attribute (like say tortise formation if you give the unit a sword and tower shield)?

No, they are not.

 

This makes me sad. I think I am going to request this. The ability to have traits require/disallow certain equipment could add much more depth and allow for more archetypes of units that are effective.

Reply #65 Top

For the next update (which will be released at the time of the next official beta update), the weapons are going to change somewhat.

Each sort of weapon will have its own unitstat, ie axe, spear, sword, staff, bow, mace, dagger. Also, these two

UnitStat_BG_IsUsingTwoHanded - 1 for units with a Two-handed weapon equipped, 0 for others. Note that Spears and Staffs do not count as two-handed
UnitStat_BG_IsUsingOneHanded - 1 for units with a one-handed weapon equipped, 0 for others.

will be changed so they are determined by weapon. Two-handed weapons are Staffs, Spears, Bows and all other Two-handed weapons. Only those weapons that can be equipped with a shield will be given the OneHanded unitstat. This is to make it easier to understand for the players, but also to allow for weapon proficiencies and so forth. Keep in mind the AI will have a difficult time understanding such traits intelligently, when outfitting champions.

To give an example, a two-handed battleaxe would have

_IsMelee = 1
_IsUsingTwoHanded = 1
_IsUsingAxe = 1

Reply #66 Top

I was wondering about some kind of _IsMasterwork UnitStat but I cannot actually think of an scenario where to use it. After all, you can have a masterwork weapon but many pieces of masterwork armour.

I do like the change for the weapons (ie _IsAxe). Does it make sense to have here stats based on the type of damage? In my case I know that my Blade Dancer needs to work with blades no matter the length of those blades (as long as they belong to one-handed weapons).

Reply #67 Top

Thanks a lot, Heavenfall! I'll try to make the best use of these weapon-specific UnitStats.

Reply #68 Top

Quoting Wintersong, reply 66
I was wondering about some kind of _IsMasterwork UnitStat but I cannot actually think of an scenario where to use it. After all, you can have a masterwork weapon but many pieces of masterwork armour.

I do like the change for the weapons (ie _IsAxe). Does it make sense to have here stats based on the type of damage? In my case I know that my Blade Dancer needs to work with blades no matter the length of those blades (as long as they belong to one-handed weapons).

I'm not sure what you mean with type of damage... each weapon already has a unitstat with its type of damage.

We could use the masterwork thing but limit it to weapons only. But... it's a lot of work going through the magical items, so unless there's something great to use it for I'm going to disregard it on account of being lazy.

Reply #69 Top

I'm curious, why did you remove the art assets from the items XMLs? By that I mean that the contents of the <GameItemTypeArtDef> tags have been removed. Is this intended?

Reply #70 Top

They are already defined in the installation directory, there was no need to do it again.

Reply #71 Top

How could I use a background stat to have a spell only work once per unit. Could I just have the spell add one point of UnitStat_BG_IsBeenCharmed to them on cast? Then prevent the spell from working if they have a point of it?

Reply #72 Top

Yes, but you must also call the value when setting itself. How to explain...

       <GameModifier>
            <ModType>Unit</ModType>
            <Attribute>AdjustUnitStat</Attribute>
            <StrVal>UnitStat_HasBeenCharmed</StrVal>
            <Calculate InternalName="Calc" ValueOwner="CastingUnit">
                <Expression><![CDATA[[UnitStat_HasBeenCharmed] * -1]]></Expression>
            </Calculate>
            <Calculate InternalName="Value" ValueOwner="CastingUnit">
                <Expression><![CDATA[[Calc] + 1]]></Expression>
            </Calculate>
        </GameModifier>

This is the thing that makes UnitStat_HasBeenCharmed stick at 1. If the target has 0, it will give him 1. If he has 1, it will not change it (1 * - 1) + 1 = 0

Note the lack of <Duration> which means the stat change will last beyond this combat.

 

 

Reply #73 Top

Sweet. I have been trying to make the spells from Code Geass: Lelouche of the Rebellion. Now I can.

Reply #74 Top

It appears the only way to add these

UnitStat_BG_IsInSwamp - 0 for all units, 1 for those who are occupying a Swamp tile on the strategic map
UnitStat_BG_IsInPlains - 0 for all units, 1 for those who are occupying a Plains tile on the strategic map
UnitStat_BG_IsInHills - 0 for all units, 1 for those who are occupying a Hills tile on the strategic map
UnitStat_BG_IsInDesert - 0 for all units, 1 for those who are occupying a Desert tile on the strategic map
UnitStat_BG_IsInForest - 0 for all units, 1 for those who are occupying a Forest tile on the strategic map
UnitStat_BG_IsInCity - 0 for all units, 1 for those who are occupying a City tile on the strategic map
UnitStat_BG_IsInRiver - 0 for all units, 1 for those who are occupying a River tile on the strategic map

is to make it a coremod, which I'm obviously not inclined to do. The issue is that the same terrains are used in strategic and tactical mode, and I can't separate the modifiers accordingly.

The coremod solution is to copy the strategic terrains into new tactical terrains, then change all the battle maps to use those terrains instead.

I'll keep watch in case the game changes anything in this area, but otherwise it looks like it won't happen.

Reply #75 Top

I've been doing some science over in the reliquary thread: https://forums.elementalgame.com/418506/get;3105148

As a result, when the next version of this library is released, all core items will have their likelihood reduced by 75%. This will allow modders to add new random items to the game.