Author Topic: Overwriting Default Game Files in an XML Mod  (Read 3508 times)

Offline Kraiz

  • Jr. Member Mark II
  • **
  • Posts: 71
Overwriting Default Game Files in an XML Mod
« on: September 05, 2020, 03:47:44 pm »
Hey folks,

Was trying to create a super-simple mod to overwrite what SpaceboxDefinitions are in the game.  I am not partial to a lot of the brighter nebula/spacebox backgrounds, and wanted to only include the ones in the game that are darker, more traditional "deep space" style ones.  I thought it would be simple.  Copy/Paste the 3 existing spacebox definition files to a new mod folder, comment out the lines of the spaceboxes I didn't want to include, and that would be that.  Except when I load the game, I receive errors such as "Unrequested attribute 'visuals' in node <spacebox...." and so on.  I verified the syntax, folder locations, etc.  Looked at a few other mods and I'm unsure what I need to be doing differently.

Copied the 3 files from:
"D:\Steam\steamapps\common\AI War 2\GameData\Configuration\SpaceboxDefinition"
to the folder:
"D:\Steam\steamapps\common\AI War 2\XMLMods\DarkSpace\SpaceboxDefinition"

Then used the XML <!-- stuff --> comments to remove lines I wanted to exclude from the game.

My hope was that my modified files would overwrite the original game files, only parsing in the XML data for the spacebox definitions I wanted.  Syntax of the file is fine.  Edited using Notepad++.

What is the proper way of going about this?  I could modify the files in place, which is what I did before.  However, I wanted the modifications I made to last through an update, so tried to do it this way instead.

Offline x4000

  • Chris McElligott Park, Arcen Founder and Lead Dev
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,651
Re: Overwriting Default Game Files in an XML Mod
« Reply #1 on: September 07, 2020, 10:57:47 am »
Great question!

So, here's the rundown on mods, and files within mods:

1. The base game is parsed first, then expansions, then mods (in general).

2. The names of files are irrelevant in all cases.  Name files so that you can find what is in them, but that's the only purpose to a filename.

3. The names of folders do matter a lot, and (as you have correctly done) determine what gets imported where.

4. As you can infer from my prior two statements, you can't overwrite a file in the base game with contents from a mod or expansions.  You can only add to them (whole new stuff, or things that are based on the original), or alter stuff.

---

With that being said, obviously sometimes the way you want to alter something is to remove it.  Do do that, you need to actually alter the original and say "you're deprecated" or something along those lines.

One reason for the lack of ability to remove things is that sometimes (not in this case, but many others), removing something will cause unintended failures somewhere else.  If someone tried to remove VWings, for instance, that would be a dramatically bad thing to try to do directly, because many other things are based on it, and it would affect mod compatibility, etc.  Instead, what you'd want to do is alter VWings in a mod so that they are no longer in any of the fleets, or something to that effect.  Making them, in effect, "still there but just not used."

In your particular case, there's not a super easy way to do that.  But there are two important pieces of xml that you can use to change any particular xml element via a mod:

name="NewEntityName" copy_from="OriginalEntityName" (to make descendants or variants)
and
name="OriginalEntityName" is_partial_record="true"

More in a second on that.

---

I said above that base game, then expansions, then mods get processed, right?  That's only... mostly true.

1. First it processes all "original" nodes (no partials, no copy-froms) from the base game, then expansions, then mods.  These depend on nothing, so can't fail.

2. Then it parses all the partials from the base game, then expansions, then mods, in a loop as much as it can, until nothing is changing anymore.  It's possible for these to fail because they are actually editing a copy-from version.

3. Then it parses all the copy-froms, looping again, and then partials again looping again.

---

In your case, the easiest thing would be for you to make partial records for the things you don't like, and assign them to be things you don't like.  So, an example:

(Original file pseudo code)
<name"BrightThingYouHate1" path="path1"/>
<name"BrightThingYouHate2" path="path2"/>
<name"BrightThingYouHate3" path="path3"/>
<name"DarkThingYouLike1" path="path4"/>
<name"DarkThingYouLike2" path="path5"/>

(Your mod file pseudo code)

<name"BrightThingYouHate1" is_partial_record="true" path="path4"/>
<name"BrightThingYouHate2" is_partial_record="true" path="path4"/>
<name"BrightThingYouHate3" is_partial_record="true" path="path5"/>

And then all of the original items remain, but it is then repointing them to versions you like.

---

A few interesting facts:

1. If you were loading savegames or quick starts that used BrightThingYouHate1 in them, and you had removed BrightThingYouHate1, then those would fail to load and you'd have to add it back.

2. If you were loading savegames that used BrightThingYouHate1 in them, and you had simply used a tool to prevent BrightThingYouHate1 from seeding, then those savegames would still have them in there because they had already been loaded.  So you'd be seeing it anyhow.

3. But when you redefine BrightThingYouHate1 to be a duplicate of something you like, you run into neither problem and get around it entirely.

That's not to say that the above approach is always the correct one, but in this particular case those are some benefits of it.

---

Further aside:

1. There's I think a "don't show bright backgrounds" setting already.  It may turn off the ones you don't like.

2. If that doesn't turn off all the ones you don't like, then you could use that setting in conjunction with a partial record to just set is_bright_background="true" on the ones you don't like (that's not the real flag, but is close enough).

3. That said, that would still have the drawbacks of things showing up in a way you don't want in savegames that were not created on your machine.

Cheers!
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline Draco18s

  • Resident Velociraptor
  • Core Member Mark V
  • *****
  • Posts: 4,251
Re: Overwriting Default Game Files in an XML Mod
« Reply #2 on: September 07, 2020, 04:54:08 pm »
Loading order and overriding things is one of the big problems with Minecraft modding, too, interestingly enough.
I ended up having to add a system to Forge so that mods fiddling around with loot tables would work correctly (think about the trivial case of two mods wanting to add their new crop seed to the drop list for tall grass: the vanilla system says "just replace the loot table" but can't combine things).

Offline Kraiz

  • Jr. Member Mark II
  • **
  • Posts: 71
Re: Overwriting Default Game Files in an XML Mod
« Reply #3 on: September 10, 2020, 06:32:07 am »
Wonderfully detailed response, thank you!

I looked through the Personal settings as well as the Galaxy settings in the game lobby, though I may have just missed it.

Either way, it wasn't a big issue.  I figured I'd just make a simple mod to handle it myself.  The fact mods are "additive" so to speak makes sense.  Changing my spacebox definitions file to partial records and just
adjusting their weight value to 0 should still leave the material files in the game with a valid reference but ensure they don't seed as you mention.  That is, of course, if I'm interpreting the "weight" attribute correctly.

Again, thanks for the great write-up.

 

SMF spam blocked by CleanTalk