[eINFO] Getting FE ready for our mods - object sanity please (modding from the /mods/ folder) (update 30/10)

By on October 24, 2012 4:34:14 PM from Elemental Forums Elemental Forums

Heavenfall

Join Date 07/2008
+436

Since players have started to explore modding now, they've come upon one crucial decision: do I put it in my installation folder or do I create a new folder in the /mods/ folder?

The mods we've seen so far have mostly been put in the installation directory. This is bad for any number of reasons. It makes it impossible to have several mods installed at once. It makes it difficult to uninstall mods. It makes it messy when you include graphics files.

So why are people doing it? Because putting stuff in the /mods/ folder is ridden with bugs. These have been here since E:wom and it is basically a quagmire that you need to navigate to make it properly.

 

I'm going to list some examples below. If you are confused by the description, I am explaining it like I am in the /mods/ folder.

 


GameItemType - I'm starting with these because they are the basis of what I'd expect. Whenever I create a mod for one of these types that already exist, all tags that were previously defined in the old type are deleted. So, if there is a sword I can easily overwrite it with my own definition. Except... if I overwrite all the items, the system that arranges random loot (using <Likelihood>) completely breaks down from monsters (not goodiehuts).

ImprovementType and AbilityBonus and AbilityBonusOption - unlike the GameItemType/UnitType, the ImprovementType does not forget any tags previously defined in the old version, when it is being overwritten. So, we are unable to remove a modifier from an ImprovementType (rather, we have to block it, and create a new one, which is a work-around).

SpellDef - SpellDefs are like a mix of the two above - we can overwrite it, and everything from the old SpellDef is lost when we do this - except those <SpellResourceCost> and <Prereq> tags that are not deleted but stay saved. Edit: It appears <SpellDefEffect> tags are also not deleted.

UnitType - All tags appear to be lost when overwritten except <SelectedAbilityBonusOption>.

TechDef - this type is straight up not overwriteable or even modifiable from /mods/. If I attempt to modify a TechDef from a mod file, the result is always that nothing happens at all.

TerrainType - I'm not sure about these, but I think they appear to be overwritable, but when overwriting TerrainTypes you must copy the entirety of the original TerrainTypes.xml file. GameModifiers are also not deleted from the old type. And there is also a major difference between modding the TerrainTypes from the mod folder, and from the installation folder. When doing it from the mod folder, no new Terraintypes can be added - instead of adding more, the game goes back to the start - if I add one single TerrainType, the game will overwrite the first defined TerrainType (Land) in the map files. When modding from the installation directory, I can add new terraintypes without being picky. (fixed in 1.12)

EnvironmentType - this type is straight up not moddable. For some reason, EnvironmentTypes are hardcoded in the exe, and adding new ones just creates environments that you can't actually use anywhere.

ElementalDefs.xml - another container that requires you to copy all the contents of the files if you wish to mod a single one. Most tags in this file should be treated like a top-level node.

UnitGroupingType - only moddable from installation directory, not a mod file. Like the TechDef, nothing is changed if I attempt to alter it from a mod file.

ElementalMap - this type is one of the strangest types, because it requires that they be put in special folders. Strategic maps must be in /Maps/ and tactical maps in /Maps/TacticalMaps/. What is the logic here? It's really dumb because it means we have to spread our /mods/ out over several folders.

 

Speaking of separate folders, why does /Mods/Gfx/ even exist? It is the only folder scanned for graphics files (.hkb .dds .dds). Whyyy? Again, it just means we have to spread our mods out over another folder.

 

The above comments are simply "what we've discovered". There could be all kinds of bugs we haven't even found yet because noone tried a certain something.


What you've accomplished with XML in this game is quite crazy, it allows for a surprisingly deep level of modding given that we can only change or alter data. But these things I've described above are just examples of the painful boobytraps that new modders have to navigate when changing the game from the /mods/ folder. Most people start by changing a unittype or a gameitemtype - either a saved unit design, or some new fancy weapon they want to test. Those "just work", because old versions (mostly) get overwritten. But after that, there are many different things you must take into consideration which appear to have no reasoning behind them.

FE needs a much more consistent way to overwrite installation content from the /mods/ folder - call it object sanity if you will. XML needs to be treated in one way across the board. Nothing that is expressed in XML should be hardcoded or irrevocably bound to a certain system. Otherwise, people will just continue to modify the installation directory and modding will continue to suffer from the same problems I spoke of in the start - difficult to share, difficult to combine, difficult to install and un-install.

Here is a "case-in-point", the installation instructions from my mod Stormworld 1.5a

To install the Stormworld mod, extract the folders you wish to use (read more below) to Documents/My Games/FallenEnchantress/Mods

So you should end up with the structure looking like this (example):
Documents/My Games/FallenEnchantress/Mods/Stormworld_ExpandedFactions
Documents/My Games/FallenEnchantress/Mods/Gfx/
Documents/My Games/FallenEnchantress/Mods/Stormworld_Rivermod

Make sure that you turn on "Use Mods" in the in-game Options menu (under Gameplay). Note that whenever you change that option, you are required to restart the game for changes to take effect.

If you are using the Stormworld_Rivermod module, you must also do the following after extracting the folder as described above: open the /Stormworld_Rivermod/ folder, and then open the TerrainTypes.rar file. This .rar file contains two files, one named simply TerrainTypes.xml and one named TerrainTypes_Backup.xml. Extract the one named TerrainTypes.xml into C:\Program Files\Stardock Games\FallenEnchantress\data\English\ so that it overwrites the version already present there.

If you are running into problems with missing forests or swamps in-game, run the game as Administrator (right-click shortcut -> Run as Administrator).

Locked Post 21 Replies +1 Karma
Search this post
Subscription Options


Reason for Karma (Optional)
Successfully updated karma reason!
Kongdej
October 24, 2012 4:38:31 PM from Elemental Forums Elemental Forums

good post, hope we get some stuff sooner or later

Reason for Karma (Optional)
Successfully updated karma reason!
October 24, 2012 4:53:59 PM from Elemental Forums Elemental Forums

Yeah, this should be at the top of the list when they start expanding modding. New features are great, but make the system work right first.

Just to be clear, I'm not asking Stardock to fix these bugs individually. Rather, come up with a consistent way that the game reads and interprets XML then apply it across the board. Edit: If there has to be exceptions, document that.

Reason for Karma (Optional)
Successfully updated karma reason!
October 24, 2012 5:08:00 PM from Elemental Forums Elemental Forums

probably in fact its easier like that

 

there should be like a priority or something

if some element is both in mod and in main xml and you are actually playing that mod, ignore main xml and only load mod element

 

or maybe a new tag like /flush or something, so that you open your wolf stuff with that and client erase everything about the old wolf

Reason for Karma (Optional)
Successfully updated karma reason!
October 24, 2012 5:11:38 PM from Elemental Forums Elemental Forums

Eeeek, and I who was planning on poking around altering stuff
(even though I don't even know how or where to start )

Great stuff Cpt Heaven!

Sincerely
~ Kongdej

Reason for Karma (Optional)
Successfully updated karma reason!
October 24, 2012 5:19:27 PM from Elemental Forums Elemental Forums

You can use this as a roadmap of bugs, heh.

Obviously it is not my intent to dissuade anyone from modding. But if I don't point out these problems they aren't going to get fixed.

Also remember there are always ways to work around these problems and sometimes you can even turn it into something beneficial instead. For example this XML is all I need in the /mods/ folder to block a faction with NoDominion_Elf trait from building Tower of Dominion:

 <ImprovementType InternalName="TowerOfDominion">
    <Prereq>
      <Type>RestrictedAbilityBonusOption</Type>
      <Attribute>NoDominion_Elf</Attribute>
      <Target>Player</Target>
    </Prereq>
  </ImprovementType>

Pretty neat, to be honest. But it is one of those things that come at a cost and when the final accounting is done I say it indicates change is needed.

Reason for Karma (Optional)
Successfully updated karma reason!
October 24, 2012 5:21:46 PM from Elemental Forums Elemental Forums

It is doubtful, and sad, that I'll not be using any mods if they are contained or overwrite core game files.  And that also means I'll most likely not be doing any exploring or experimenting with modding myself.

Reason for Karma (Optional)
Successfully updated karma reason!
October 24, 2012 5:26:13 PM from Elemental Forums Elemental Forums

Quoting Wizaerd,
It is doubtful, and sad, that I'll be using any mods if they are contained or overwrite core game files.  And that also means I'll most likely not be doing any exploring or experimenting with modding myself.

 

That's a shame. It takes less than 15 seconds to copy and paste the contents of your data/english folder somewhere else as a backup. If you are interested in exploring and experimenting, that shouldn't be an insurmountable hurdle, you're going to run into more difficult tasks along the way.

 

That being said, if this issue receives any attention, I imagine it will be in the form of being able to place any mod in the /mods directory.

Reason for Karma (Optional)
Successfully updated karma reason!
October 24, 2012 5:40:05 PM from Elemental Forums Elemental Forums

Quoting jshores,

Quoting Wizaerd, reply 7It is doubtful, and sad, that I'll be using any mods if they are contained or overwrite core game files.  And that also means I'll most likely not be doing any exploring or experimenting with modding myself.

 

That's a shame. It takes less than 15 seconds to copy and paste the contents of your data/english folder somewhere else as a backup. If you are interested in exploring and experimenting, that shouldn't be an insurmountable hurdle, you're going to run into more difficult tasks along the way.

 

That being said, if this issue receives any attention, I imagine it will be in the form of being able to place any mod in the /mods directory.

It's not insurmountable, just messy.  Especially if using multiple mods which overwrite each other's files and interferes with the core vanilla game as well.  I prefer clean straight self-contained and non conflicting directory structures.  From a disk maintenance perspective, as well as from a developer perspective.

Reason for Karma (Optional)
Successfully updated karma reason!
October 24, 2012 6:13:18 PM from Elemental Forums Elemental Forums

Well said, Heaven! 

I would think the first question Kael is likely to ask is, "how should it work"?  I think a discussion on that is in order.

I'm not sure how I feel about having each object completely overwritten when it is modded.  In many ways, that's probably the simplest from the DEVs perspective and the easiest to understand from a modder's perspective.  But it makes it bloody hard to mix mods together. 

But if we request only overwriting tags that are specified in our XML, then how do you delete tags you want to remove with a mod?  Perhaps with an empty tag? (i.e. <Prereq/>)  This approach makes it easier to mix mods but more difficult on the modder.

Thoughts???

Reason for Karma (Optional)
Successfully updated karma reason!
October 24, 2012 7:16:22 PM from Elemental Forums Elemental Forums

Probably requiring a bit of work, but I've really appriciated the DLC system Dragon Age uses: check off the ones you want active and then start playing.

Granted, some mods will conflict with others...but the player should be aware of that.

 

Another option would be the Scenarios section. Not sure if you can open up a 'sandbox mod' as if it were a scenario....but it's a thought...


 

Reason for Karma (Optional)
Successfully updated karma reason!
October 24, 2012 10:31:55 PM from Elemental Forums Elemental Forums

I would prefer a way to turn on and off which mods we can use as well as using the mods folder to put mods into.  Messing with the core game files is bad.  For a lot of reasons.  

Reason for Karma (Optional)
Successfully updated karma reason!
October 30, 2012 4:01:34 PM from Elemental Forums Elemental Forums

Perhaps a <remove> tag, so that you could define something, and if it exists in the core data that part is ignored.

 

Core:

Code: xml
  1. <GameItemType InternalName="ProcipineesCrown">
  2. <DisplayName>Procipinee's Crown</DisplayName>
  3. <Description>Fashioned of silver and amethyst the crown radiates magic, enough to maintain any enchantments on the wearer.</Description>
  4. <Type>Accessory</Type>
  5. <CanBeEquipped>1</CanBeEquipped>
  6. <AffectsGlobalResources>1</AffectsGlobalResources>
  7. <CustomizationPointCost>1</CustomizationPointCost>
  8. <ShopValue>25</ShopValue>
  9. <GameModifier>
  10. <ModType>Unit</ModType>
  11. <Attribute>AdjustUnitStat</Attribute>
  12. <StrVal>UnitStat_EnchantmentMaintenanceMultiplier</StrVal>
  13. <Multiplier>0</Multiplier>
  14. <Provides>Enchantments on this unit have no maintenance</Provides>
  15. </GameModifier>
  16. <IsAvailableForSovereignCustomization>1</IsAvailableForSovereignCustomization>
  17. <RarityDisplay>UltraRare</RarityDisplay>
  18. <HeroOnly>1</HeroOnly>
  19. <IsAvailableForUnitDesign>0</IsAvailableForUnitDesign>
  20. <IsUsable>0</IsUsable>
  21. <ArtDef>Art_ProcipineesCrown</ArtDef>
  22. </GameItemType>

 

Mod:

Code: xml
  1. <GameItemType InternalName="ProcipineesCrown">
  2. <Description>Fashioned of silver and amethyst the crown radiates magic, enough to maintain any enchantments on the wearer.</Description>
  3. <Type>Accessory</Type>
  4. <CanBeEquipped>1</CanBeEquipped>
  5. <remove>
  6. <HeroOnly>1</HeroOnly>
  7. </remove>
  8. </GameItemType>

This would change the description and remove the requirement for it to be hero only. (I realize you could set hero only to 0 for the same effect, merely trying to be demonstrative.)

Reason for Karma (Optional)
Successfully updated karma reason!
October 30, 2012 4:14:27 PM from Elemental Forums Elemental Forums

I certainly won't be modding or using mods with the current system. 

Way too messy.

Reason for Karma (Optional)
Successfully updated karma reason!
October 30, 2012 4:16:52 PM from Elemental Forums Elemental Forums

Updated the OP to include AbilityBonus, AbilityBonusOption and a newly found bug with SpellDef.

GarLunarfang, that sort of solution would actually be technically difficult due to the structure of XML.

One suggestion that has been posted before is to simply allow us to indicate in the top level structure of the XML whether the file is Overwriting or Modifying its contents.

Ex:

<GameItemTypes>
<PurposeTag>Modify</PurposeTag>
    <GameItemType InternalName="AmuletOfFlames">
        <DisplayName>Amulet of Fiery Inferno</DisplayName>
    </GameItemType>

the above XML would Modify the existing XML, ie no tags are forgotten. All it does is change the item's name.

On the other hand, we could have this

<GameItemTypes>
<PurposeTag>Overwrite</PurposeTag>
    <GameItemType InternalName="AmuletOfFlames">
        <DisplayName>Amulet of Flames</DisplayName>
        <Description>When it is worn even the wearer's caress burns those he or she touches.  Although some see this as a weapon, the Quendar are known to use it for pleasure.</Description>
        <Type>Accessory</Type>
        <CanBeEquipped>1</CanBeEquipped>
        <AdditionalTrainingTurns>8</AdditionalTrainingTurns>
        <ShopValue>180</ShopValue>
        <ProductionRequirement>
            <Type>Resource</Type>
            <Attribute>RefinedCrystal</Attribute>
            <Value>4</Value>
        </ProductionRequirement>
        <GameModifier>
            <ModType>Unit</ModType>
            <Attribute>AdjustUnitStat</Attribute>
            <StrVal>UnitStat_Attack_Fire</StrVal>
            <Value>3</Value>
        </GameModifier>
        <IsAvailableForSovereignCustomization>0</IsAvailableForSovereignCustomization>
        <Likelihood>200</Likelihood>
        <RarityDisplay>Uncommon</RarityDisplay>
        <IsUsable>0</IsUsable>
        <Prereq>
            <Type>Tech</Type>
            <Attribute>Glyph_Stones</Attribute>
        </Prereq>
        <ArtDef>AmuletOfFlames_ArtDef</ArtDef>
    </GameItemType>

where the entire GameItemType would be wiped due to being Overwritten, and then the new one inserted.

This would let us keep the "best of two worlds". However, it is far more important to structure the reading of XML properly before we begin talking about solutions like this.

 

Edit: the above example is a bit daft because GameItemTypes are always overwritten completely, but the point stands.

Reason for Karma (Optional)
Successfully updated karma reason!
November 17, 2012 3:16:04 PM from Elemental Forums Elemental Forums

I should have read this when I tried modding some things. Would have saved me from these similar discoveries

Reason for Karma (Optional)
Successfully updated karma reason!
December 6, 2012 10:29:47 AM from Elemental Forums Elemental Forums

This is a great post, probably explains why some of my ImprovementType mod attempts aren't doing what I was expecting.

 

Would be great to get some consistency on this stuff, so just adding a "me too" to this.

 

Thanks Heavenfall for all your work and willingness to share knowledge.

Reason for Karma (Optional)
Successfully updated karma reason!
January 29, 2013 6:13:44 PM from Elemental Forums Elemental Forums

And while we've got a modding "bitch session" going, I'd like to say that modding quests is PAINFUL!!  It is astonishing how long it takes to build a quest of only moderate difficulty. 

 
//
Reason for Karma (Optional)
Successfully updated karma reason!
March 29, 2013 2:56:38 PM from Elemental Forums Elemental Forums

Just like to add my support to this threads subject.

 

Reason for Karma (Optional)
Successfully updated karma reason!
April 14, 2013 1:33:45 AM from Elemental Forums Elemental Forums

I'd add my support for this. Consistency is BADLY needed for modding of FA and LH. It's probably the biggest obstacle for many modders who just don't have time to learn quirks of all different files that behave differently. Making things easier for modders would increase number of mods and their quality/content by large margin and that would in return attract more players and increase game's appeal (more sales if you will). Anyway, this really should have higher priority as it needs to be done and helps moders to make more and better mods, helps players enjoy game more and finally Stardock to improve their game and sales.

 

I'd also like to add a suggestion to file structure. Its about Race and Unit folders, Race is used to hold all race files while units are used to hold all unit and sovereign files. Now here is a deal, the game is designed that as you play it, make new factions and new units, the game stores them and when creating new game you can assign that faction to AI and it will use those units for that faction thus increasing game's content as you play the game. It's great concept, but file structure makes maintaining or editing factions and units a nightmare as they are all dumped in the same 2 folders like someone dumped a big bunch of files on a desk and let you sort through them. You would waste much more time finding what you need in that mess then you would spend on actual editing of said files. As you play game more, the bigger the mess and the number of files increase. In the end, if you want do delete something, edit something it's easier to delete all race and unit folder content and make a new one then sort through all of that. Basically, folder structure works against game's concept to increase game's content (and enjoyment) as player plays the game.

What I would suggest is to use one main folder for races (factions), leave in it faction files as they are BUT create subfolder for each faction created with the name of that faction and place it's designed units in that folder. So if you create a faction with name ABC the 'Faction_ABC.xml' would be created in 'Race' folder and subfolder named 'ABC' would also be created in 'Race' folder (structure would be 'MyGames\LegendaryHeroes(FallenEnchantress)\Race\ABC'. All the unit files that are createad by player while playing that faction would go in that 'Race\ABC folder'. If a player ever want's to change or delete units for that faction all he needs to do is look in that Race\ABC folder and change or remove what he want's.

 

Also, another GUI request that is related to the above; since AI uses units that player creates for player's faction BUT those unit's get deleted in game if you chose to 'Resign' them, custom made unit's also need 'Hide' button so player can hide unit's that he won't use anymore but leave them for AI to use it when it plays the game with that faction.

Reason for Karma (Optional)
Successfully updated karma reason!
April 14, 2013 7:07:38 AM from Elemental Forums Elemental Forums

Quoting Daynarr,

I'd add my support for this. Consistency is BADLY needed for modding of FA and LH. It's probably the biggest obstacle for many modders who just don't have time to learn quirks of all different files that behave differently. Making things easier for modders would increase number of mods and their quality/content by large margin and that would in return attract more players and increase game's appeal (more sales if you will). Anyway, this really should have higher priority as it needs to be done and helps moders to make more and better mods, helps players enjoy game more and finally Stardock to improve their game and sales.

+1

Reason for Karma (Optional)
Successfully updated karma reason!
July 3, 2013 10:31:42 PM from Elemental Forums Elemental Forums

Heavenfall,

It might not be a bad idea to repost this in a new thread, with any updates you may have, in the LH Modding forum.  Some of this info is quite good for modders to know about, and I'd love to see the 'duplicate thread' stickied in the LH Modding forum, assuming the powers that be would be up for a sticky!

 

Oh, and of course...

Reason for Karma (Optional)
Successfully updated karma reason!
Stardock Forums v1.0.0.0    #108433  walnut3   Server Load Time: 00:00:00.0000547   Page Render Time: