Fractal Softworks Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

Starsector 0.97a is out! (02/02/24); New blog post: Simulator Enhancements (03/13/24)

Pages: [1] 2

Author Topic: Discovery: How Starsector decides which mods override which other mods. Updated.  (Read 6191 times)

ShadowDragon8685

  • Ensign
  • *
  • Posts: 45
    • View Profile

This has thoroughly broiled my noodle; having made some discoveries, I figured they might be useful to others.



Just the observance:

My observance is that Starsector loads mods strictly in descending alphabetical order, A to Z, by the mod's displayed name in the mod list. IE, the "name":"foo", field. It locks in mods, meaning that, for example, if you have a weapon_data.csv with a name of Silverjohn and an ID of mp_silverjohn in two mods; say, one which is named Mighty Pirates and one which is named Overpowered Mighty Pirates, it will lock in the data from the first-loaded weapon_data.csv and discard the later one; in this case, it will ignore your extension-mod Overpowered Mighty Pirates because Overpowered comes later in the alphabet than Mighty.

The general fix for this would be to make the mod name begin with something that comes before M; 0verpowered Mighty Pirates (note that I have used the numeral zero instead of the letter O) would work, or you could also name it 11 Mighty Pirates: Overpowered or any such thing.



The full explanation:

I'm trying to make some very, very tiny (for personal use) mod-mods that modify the behavior of other content-extension mods to make those mods' ordnance weapons behave like the vanilla weapons modified by Missiles & Sundries.

I was getting outright inconsistent results. The method I've used, in each case, has been:

Make a mod folder, with a mod_info.json. Into that goes a data/weapons folder. Into that folder, I copy the original mod's weapon_data.csv, and open it up with LibreOffice Calc.

I then highlight and delete the whole lines of anything that is not an ordnance weapon receiving a modification, make such number changes as seem appropriate to retarget limited-use-per-deployment ordnance weapons to the Missiles & Sundries regenerating missiles numbers, and save the mod. Then activate both mods.

This method worked to modify the Ship and Weapon Pack and Sylphon R&D weapons, but it faied to modify Mayasuran Navy and Arsenal Expansion weapons.

This is an example of the mod_info.json:

Code
{
"id":"zz_sd_Reload_Missiles_Mayasura",
"name":"Reloadable Missiles: Mayasuran Navy",
    "utility": "true",
"author":"ShadowDragon8685",
"version":"1",
"description":"Revamps the missiles from Mayasuran Navy to auto-reload in-combat, in the same manner as those from Missiles & Sundries. NOT WORKING AT PRESENT; modified Mayasuran Navy mod directly",
    "gameVersion":"0.9.1a",
}

I had thought that mods were loaded in the order of "id":"foo", with later mods by id name overwriting newer ones, but this is demonstrably not the case. I then thought that it was a matter of alphabetical order in the file structure with the first mods' lines "locking-in" and later ones being ignored; I've been naming my folders "sd_foo" to keep all mine together. That comes previous to Ship and Weapon Pack and Sylphon R&D, but after Arsenal Expansion and Mayasuran Navy, so I tried renaming the folder and ID for my override for Aresenal Expansion to "AA_SD_foo" and even "11_SD_foo" didn't work.

Aaaaand just now, I have tried changing the mod name.

Code
{
"id":"1_sd_Reload_Missiles_Arsenal_Expansion",
"name":"1 Reloadable Missiles: Arsenal Expansion",
    "utility": "true",
"author":"ShadowDragon8685",
"version":"1",
"description":"Revamps the missiles from Arsenal Expansion to auto-reload in-combat, in the same manner as those from Missiles & Sundries. NOT WORKING AT PRESENT; modified Arsenal Expansion directly.",
    "gameVersion":"0.9.1a",
}

This appears earlier in the mod-list than

Code
"name": "Arsenal Expansion",

My current working hypothesis is thus that Starsector is loading mods strictly in descending alphabetical order, A->Z, with earlier entrants which feature a line "locking in" their entry and ignoring later lines with the same ID.
« Last Edit: April 03, 2020, 05:07:36 AM by ShadowDragon8685 »
Logged

xenoargh

  • Admiral
  • *****
  • Posts: 5078
  • naively breaking things!
    • View Profile

I've been working on a not-so-tiny mod that basically rebuilds a lot of Vanilla data.  It's finally in the last stages of development and polish.

What I've discovered along the way is that:

1.  Any time we use the replace operation, no other mod later in the mod load-order can alter that data file, period.  This doesn't just lock out Vanilla data; it effectively freezes the file.

This is a real problem when we're talking about the CSVs; if mod A replaces ship_data.csv, then Mod B wants to load up some .ships, nope; if we reverse the load order, then mod A deletes all of mod B's work. 

So, instead, I'm basically using replace operations on individual entries in /hulls/ ... lots and lots of data entry, but it's the only safe way to provide for mod-interoperability (and even then, it's a little limited; if Mod A replaces data\\hulls\\astral.ship for example, no other mod can touch it, period).

It seems a little extreme, when really, all I really want is for Vanilla's assets to not load.  Preferably, by directory and file-type wildcards for ease of production.

Luckily, few mods use replace; most mods that want to do something big have been TCs.

2.  In your case, you're running into a problem that's basically my fault (sorry about that). 

I asked Alex if we could make it possible for JSONs to merge (a .ship file, for example) rather than overwriting one another. 

JSON overwrites were a major pain in the rear, for projects that, for whatever reasons, needed to be broken up into segments; it meant that if Mod A needed to make a change to, say, the Tac Laser, then Mod B came along and also did so, only Mod B's changes were preserved.

However, this comes with some major problems, too.  If two JSONObject / JSONArray entries / fields get merged, the result is that both are integrated into the whole.  This can cause all sorts of interesting problems; the one I've observed the most is that if a Vanilla .ship has been altered by a mod, but hasn't been replaced via mod_info, then all sorts of wonky things can happen. 

For example, say you've decided to rework the turrets on, say, the Conquest; you take the ship into SSEd and remove the Vanilla turrets, then add the new ones, perfectly mirrored and all that. 

It all looks beautiful and you export your changes, and it all looks OK in-game... until you'll notice something weird; the ship has two turret spots, often really close together (if you used Vanilla positions as a basis). 

Why is this happening?  Well, whatever utility Alex uses to make .ship files with (which he's never released to the public, so we can only speculate) uses a slightly-different system for naming the turret ids than SSEd does. 

This means that Turret A and Turret B may be in what looks like identical positions, but, in terms of merging, they aren't the same at all; their ids don't match (well, providing that Alex's merging code is checking that- IDK whether he addressed that issue but we did talk about it). 

So there is more turret in that JSONArray than there used to be, and additional CPU overhead, processing that empty turret, one presumes, and, well, now end-users can put another gun on, if they catch on to that problem.  Great ::)

When I realized that that (and other Bad Things) were happening, I started to use replace in the mod_info to address these things.  You'll have to do the same thing here, too; you're seeing effects of merges, as well as load order.  People still presume load order is all that matters, like in some other games, but it's not... and that's my fault.

Honestly, I think we should:

1.  Have an option in mod_info that says, "don't load up any Vanilla assets, period" that isn't TC, where we're wanting to exclude every other mod, too.

2.  Have something we can add to a JSON we've altered, that, if present, causes the file in question to overwrite any previous version of the same file, but not files further down the load order. 

Then Mod A can overwrite something in Vanilla (or another mod higher on the load order), but Mod B, loading afterwards, can modify Mod A's data in some subtle way (like what you're trying to do here).

3.  A remove option in mod_info, that, if present, will remove the file or directory contents (in memory) so that we can put fresh new things in.


As it is... meh.  I have a mod_info that already looks like this:
Spoiler
   "replace":[   
   
      #SHIP REPLACEMENTS
      #DRONES
      "data\\hulls\\drone_assault.ship",
      "data\\hulls\\drone_borer.ship",
      "data\\hulls\\flash.ship",
      "data\\hulls\\drone_pd_midline.ship",
      "data\\hulls\\lux.ship",
      "data\\hulls\\mining_drone.ship",
      "data\\hulls\\drone_pd.ship",
      "data\\hulls\\drone_sensor.ship",
      "data\\hulls\\spark.ship",
      "data\\hulls\\drone_terminator.ship",
      "data\\hulls\\wasp.ship",
      
      #FIGHTERS
      "data\\hulls\\broadsword.ship",
      "data\\hulls\\claw.ship",
      "data\\hulls\\cobra.ship",
      "data\\hulls\\dagger.ship",
      "data\\hulls\\gladius.ship",
      "data\\hulls\\hoplon.ship",
      "data\\hulls\\khopesh.ship",
      "data\\hulls\\longbow.ship",
      "data\\hulls\\perdition.ship",
      "data\\hulls\\piranha.ship",
      "data\\hulls\\talon.ship",
      "data\\hulls\\thunder.ship",
      "data\\hulls\\trident.ship",
      "data\\hulls\\warthog.ship",
      "data\\hulls\\xyphos.ship",
      
      #FRIGATES
      "data\\hulls\\afflictor.ship",
      "data\\hulls\\brawler.ship",
      "data\\hulls\\centurion.ship",
      "data\\hulls\\cerberus.ship",
      "data\\hulls\\defender.ship",
      "data\\hulls\\dram.ship",
      "data\\hulls\\gargoyle.ship",
      "data\\hulls\\glimmer.ship",
      "data\\hulls\\gremlin.ship",
      "data\\hulls\\hermes.ship",
      "data\\hulls\\hound.ship",
      "data\\hulls\\hyperion.ship",
      "data\\hulls\\kite.ship",
      "data\\hulls\\lasher.ship",
      "data\\hulls\\lumen.ship",
      "data\\hulls\\mercury.ship",
      "data\\hulls\\merlon.ship",
      "data\\hulls\\monitor.ship",
      "data\\hulls\\mudskipper.ship",
      "data\\hulls\\omen.ship",
      "data\\hulls\\ox.ship",
      "data\\hulls\\picket.ship",
      "data\\hulls\\ravelin.ship",
      "data\\hulls\\scarab.ship",
      "data\\hulls\\sentry.ship",
      "data\\hulls\\shade.ship",
      "data\\hulls\\shepherd.ship",
      "data\\hulls\\tempest.ship",
      "data\\hulls\\vigilance.ship",
      "data\\hulls\\warden.ship",
      "data\\hulls\\wayfarer.ship",
      "data\\hulls\\wolf.ship",
      
      #DESTROYERS
      "data\\hulls\\bastillon.ship",
      "data\\hulls\\berserker.ship",
      "data\\hulls\\buffalo.ship",
      "data\\hulls\\buffalo2.ship",
      "data\\hulls\\condor.ship",
      "data\\hulls\\drover.ship",
      "data\\hulls\\enforcer.ship",
      "data\\hulls\\fulgent.ship",
      "data\\hulls\\gemini.ship",
      "data\\hulls\\hammerhead.ship",
      "data\\hulls\\harbinger.ship",
      "data\\hulls\\medusa.ship",
      "data\\hulls\\mule.ship",
      "data\\hulls\\nebula.ship",
      "data\\hulls\\phaeton.ship",
      "data\\hulls\\crig.ship",
      "data\\hulls\\scintilla.ship",
      "data\\hulls\\shrike.ship",
      "data\\hulls\\sunder.ship",
      "data\\hulls\\tarsus.ship",
      "data\\hulls\\valkyrie.ship",
      
      #CRUISERS
      "data\\hulls\\apogee.ship",
      "data\\hulls\\aurora.ship",
      "data\\hulls\\brilliant.ship",
      "data\\hulls\\colossus.ship",
      "data\\hulls\\colossus2.ship",
      "data\\hulls\\colossus3.ship",
      "data\\hulls\\dominator.ship",
      "data\\hulls\\doom.ship",
      "data\\hulls\\eagle.ship",
      "data\\hulls\\falcon.ship",
      "data\\hulls\\gryphon.ship",
      "data\\hulls\\heron.ship",
      "data\\hulls\\mora.ship",
      "data\\hulls\\quetzalcoatl.ship",
      "data\\hulls\\rampart.ship",
      "data\\hulls\\starliner.ship",
      "data\\hulls\\venture.ship",
      
      #CAPITAL
      "data\\hulls\\acanthus.ship",   
      "data\\hulls\\astral.ship",
      "data\\hulls\\atlas.ship",
      "data\\hulls\\atlas2.ship",
      "data\\hulls\\conquest.ship",
      "data\\hulls\\guardian.ship",
      "data\\hulls\\legion.ship",
      "data\\hulls\\odyssey.ship",
      "data\\hulls\\onslaught.ship",
      "data\\hulls\\paragon.ship",
      "data\\hulls\\prometheus.ship",
      "data\\hulls\\prometheus2.ship",
      "data\\hulls\\radiant.ship",
      
      #SKINS
      "data\\hulls\\skins\\brawler_tritachyon.skin",      
      
      #VARIANTS
      "data\\variants\\fighters\\mining_drone_Standard.variant",
      
      #FACTION / WORLD DATA
      "data\\world\\factions\\default_fleet_type_names.json",
      "data\\world\\factions\\default_ranks.json",
      "data\\world\\factions\\default_ship_roles.json",
      "data\\world\\factions\\derelict.faction",
      "data\\world\\factions\\hegemony.faction",
      "data\\world\\factions\\independent.faction",
      "data\\world\\factions\\knights_of_ludd.faction",
      "data\\world\\factions\\lions_guard.faction",
      "data\\world\\factions\\luddic_church.faction",
      "data\\world\\factions\\luddic_path.faction",
      "data\\world\\factions\\neutral.faction",
      "data\\world\\factions\\persean_league.faction",
      "data\\world\\factions\\pirates.faction",
      "data\\world\\factions\\player.faction",
      "data\\world\\factions\\poor.faction",
      "data\\world\\factions\\remnants.faction",
      "data\\world\\factions\\scavengers.faction",
      "data\\world\\factions\\sindrian_diktat.faction",
      "data\\world\\factions\\sleeper.faction",
      "data\\world\\factions\\tritachyon.faction",
      
   ],
[close]
...and it's going to get a lot longer before I'm release-ready, I'm guessing.
« Last Edit: June 20, 2019, 03:02:42 PM by xenoargh »
Logged
Please check out my SS projects :)
Xeno's Mod Pack

ShadowDragon8685

  • Ensign
  • *
  • Posts: 45
    • View Profile

... Maan, that is so high level I barely understood two-thirds of it. Is there something specific I'm doing wrong with my method here, some better, more prescribed, way of doing what I want to do?
Logged

xenoargh

  • Admiral
  • *****
  • Posts: 5078
  • naively breaking things!
    • View Profile

OK, in plain English:

1.  Make your mod A that changes stuff in Mod B.  Let's say, in your case, you're modding cool_ship_in_mod_b_I_wanna_change.ship in StarSector Editor, adding a new turret.

There are two ways to go about this:

A.  In Mod A (your mod-of-a-mod), in mod_info.json, add a section like this:

"replace":[
               "data\\hulls\\cool_ship_in_mod_b_I_wanna_change.ship",
],

This means you overwrite Mod B's copy.  Cool, it's easy, but it locks out others from also modifying that file (i.e., don't do it unless you're pretty sure nobody will care).

B.  Or (or!) for a simple changes like this, you can do this, in cool_ship_in_mod_b_I_wanna_change.ship:

Basically, take the text SSEd saves, and just cut it down to the stuff that's new.

Code
{
  "hullId": "cool_ship_in_mod_b_I_wanna_change",
  "hullName": "Cool Ship In Mod B",

  "weaponSlots": [
    {
      "angle": -180,
      "arc": 2.5,
      "id": "new_turret_i_added_to_this_cool_ship",
      "locations": [
        -51.5,
        16
      ],
      "mount": "TURRET",
      "size": "SMALL",
      "type": "DECORATIVE"
    }
  ],
}
The turret, above, will get merged into the existing file; the ship will have a new turret location now. 

If you're merely changing, say, how much damage something does, just alter the entry in weapon_data.csv; that entry will replace the existing one.

If you're tweaking a .variant... well, that's where I've run into serious problems, lol.  Variants pretty much require a replacement operation, or Bad Things happen when it merges, like overflowing the number of available Groups.  This is because Groups don't have an id, for some reason.  I.E., if it's the first entry, it's group 0 (1, to players) and so forth.  But when they merge, because there's no id, they just get piled up on one another, which causes all sorts of silly things to happen.

Lastly, load order isn't all it's cracked up to be, again, because of the different ways we can overwrite, merge, etc.; so far as I can tell, every single mod in the load order gets loaded, then they get merged in the order of loading.  But, because they're merged, not replaced, it's irrelevant which order they originally loaded in.

For little mods, where you just wanna tweak a few things, B works great.  Want to make Pilums a little faster?  No problem, tweak the engine values; since there are already engine values for the Pilum already, when your mod merges in, it overwrites them; no need to include all of the other data at all.

The bad part is when you're wanting to mess with a lot of things... or Variants, in particular, because Variants both reference other things (.ship, .skin, fighter Wings and .wpns) but are also referenced in a few places as well (for example, the enforcer_Elite.variant shows up in Mission code, some Variants show up in the .faction files, there are a few referenced in rules.csv, sim_opponents.csv and sim_opponents_dev.csv, etc., etc.). 

There, to be really honest, I'd recommend making new ones or using option A (replacement) rather than merging, which will probably be a mess.  At one point, I searched for an hour to find a crash, only to find it was a Variant of a fairly-uncommon ship I'd made minor edits to, including removing a turret that the game's original .variant file referred to. 

At this point, I've just used replace to replace every single one of them, because who has time for that, and it's the only way to be sure that if there's something wrong... it's in my local files, not some reference-of-a-reference that did bad things when merged, lol.
« Last Edit: June 21, 2019, 01:19:19 AM by xenoargh »
Logged
Please check out my SS projects :)
Xeno's Mod Pack

TJJ

  • Admiral
  • *****
  • Posts: 1905
    • View Profile

Sounds like we need a mod to mod the mod loading code so that mods can better mod mods.  :o
Logged

ShadowDragon8685

  • Ensign
  • *
  • Posts: 45
    • View Profile

Sounds like we need a mod to mod the mod loading code so that mods can better mod mods.  :o

Did anyone else just hear the Inception Sound?

But yeah, a mod-load-order define might not be a bad idea.
Logged

Alex

  • Administrator
  • Admiral
  • *****
  • Posts: 23988
    • View Profile

It might be, yeah. But as you correctly worked out, it's currently based on the name, so for the relatively few cases that care about this, it can be worked with.
Logged

jeffg10

  • Ensign
  • *
  • Posts: 42
  • Cheesus Crust
    • View Profile

If this is a topic for concern it may be worth someone trying to make a mod like modswitch from rimworld, basically some guy made a mod that changed how the mod loader behaved next time the mod loader was loaded with that mod installed, idk if that's something that's possible although if not i could see an alternative in someone helping Alex change how it works, although that may be a bit more in the weeds (sorry i don't have any in depth modding experience myself i'm just throwing around some interesting ideas)
Logged
"Someone else might have wept or screamed in frustration or even given up right there and perished. But I didn't have the right to do any of those things, not while my people were in danger. Like it or not, I would have to explore this harsh world on my own."

ShadowDragon8685

  • Ensign
  • *
  • Posts: 45
    • View Profile

Having experimented further with this, I can say that Starsector does *not* like it if you have only the ID and the changes you want to "lock in" in a line in a csv.

IE, if you only want to make a ship which is unboardable boardable, you need that ship's entire stat-line in your CSV, otherwise Starsector throws an error and won't launch.
Logged

stormbringer951

  • Commander
  • ***
  • Posts: 130
    • View Profile

Having experimented further with this, I can say that Starsector does *not* like it if you have only the ID and the changes you want to "lock in" in a line in a csv.

IE, if you only want to make a ship which is unboardable boardable, you need that ship's entire stat-line in your CSV, otherwise Starsector throws an error and won't launch.

That's intended behaviour; according to the javadoc, it merges by rows, not by fields.

Quote
JSONArray getMergedSpreadsheetDataForMod(java.lang.String idColumn,
                                         java.lang.String path,
                                         java.lang.String masterMod)
                                         throws java.io.IOException,
                                                JSONException
Useful for building a mod that allows other mods to override some of its data. Merges on spreadsheet level only; rows with matching ids get replaced by non-master rows. If multiple non-master rows have the same id, one will be picked in an undefined manner.

Discussion with Alex about row replacement vs field merging in this thread makes it clear that it is intended that mods should be allowed to override data files by blanking out a field in the csv (otherwise you could not).

Hmm. I mean, it does merge, it just merges spreadsheets, not row contents. Clarified that in the comments.

I think the way you're expecting it to work would restrict a mod to a specific set of column changes, where when you're merging json, you'd really want it do be on a per-item basis.

E.G. a mod couldn't 1) add an "eggs" column but also 2) change any other data for an existing animal. Unless an empty cell didn't count as that row having that column but that would mean a mod couldn't blank out a cell. It just gets very hacky.
« Last Edit: June 23, 2019, 02:56:24 AM by stormbringer951 »
Logged
Weapons Group Controls mod - deselect all weapon groups, hold-down hold-fire mode, toggle alternating/linked fire
Captain's Log - throw away your notepad: custom notes, ruins and salvageable reminders
Old Hyperion - for your dose of nostalgia
Adjustable Skill Thresholds - set fleet DP and fighter bay thresholds

ShadowDragon8685

  • Ensign
  • *
  • Posts: 45
    • View Profile

That's fine, it's just not what I had heard - I had heard that it only merged cells with data.
Logged

xenoargh

  • Admiral
  • *****
  • Posts: 5078
  • naively breaking things!
    • View Profile

FWIW, Alex, I don't think how it works is, "bad", for anything but what I'm doing.  Which nobody should be trying anyhow, lol.
Logged
Please check out my SS projects :)
Xeno's Mod Pack

ShadowDragon8685

  • Ensign
  • *
  • Posts: 45
    • View Profile
Re: Discovery: How Starsector decides which mods override which other mods.
« Reply #12 on: April 03, 2020, 05:07:15 AM »

Back at it again, and I've made another discovery about how Starsector decides which-override-which.

The behavior for lines in .csv files and the behavior for other files seems to be exactly opposite to one another. This baked my brain all night last night, and it hit me like a bolt of the thunderingly obvious this morning.

Everything up-thread about how comma separated value files take priority remains true; the mod which loads first as determined by alphabetical entry in the mod load order "locks in" lines from its CSV, and Starsector will discard any later-loading csv lines with the same id.

However, the way it behaves for other files - for example, .ship and .variant files - is exactly the opposite, with the mod which loads later in the load order as determined by alphabetical entry in the mod load order overrides earlier ones.

So, for a non-hypothetical private example, if I wanted to override DME's ordnance weapons to have reloading in combat in the style of Missiles and Sundries, I would need to ensure that whatever mod I made to do so had a name which came before "Dassault-Mikoyan Engineering" in the mod load order, which is easily, if inelegantly, ensured by naming my mod something beginning with "$D".

But, if I then want DME's fantastic strike craft to not derp around doing nothing for two minutes waiting for their missiles to regenerate rather than landing back on the carrier, I would need to make duplicate .ship and .hull entries (DME instituted its strike-craft weapons in both places), but I would also need to ensure that those are loaded from a mod which comes alphabetically later than "Dassault-Mikoyan Engineering" in the mod load order, which would have to be a separate mod.

Just some findings worth knowing, probably. This might help someone sort out mod incompatibilities, and it very much makes me yearn for end-user-definable mod load orders.

----

All of those findings I just wrote are in fact true as far as I can tell; however, as Xenoargh pointed out much earlier, it is far simpler to use a "replace:[]," tag in mod_info.json, and I am an idiot for not figuring that out earlier.
« Last Edit: April 03, 2020, 05:19:43 AM by ShadowDragon8685 »
Logged

Mondaymonkey

  • Admiral
  • *****
  • Posts: 777
    • View Profile

There are too many words to read.

If I want to modify mod files values without direct modifying mod files, do my quasi-mod shall be first or last?
Logged
I dislike human beings... or I just do not know how to cook them well.

Morrokain

  • Admiral
  • *****
  • Posts: 2143
  • Megalith Dreadnought - Archean Order
    • View Profile
Re: Discovery: How Starsector decides which mods override which other mods.
« Reply #14 on: April 03, 2020, 04:19:45 PM »

The bad part is when you're wanting to mess with a lot of things... or Variants, in particular, because Variants both reference other things (.ship, .skin, fighter Wings and .wpns) but are also referenced in a few places as well (for example, the enforcer_Elite.variant shows up in Mission code, some Variants show up in the .faction files, there are a few referenced in rules.csv, sim_opponents.csv and sim_opponents_dev.csv, etc., etc.). 

There, to be really honest, I'd recommend making new ones or using option A (replacement) rather than merging, which will probably be a mess.  At one point, I searched for an hour to find a crash, only to find it was a Variant of a fairly-uncommon ship I'd made minor edits to, including removing a turret that the game's original .variant file referred to. 

At this point, I've just used replace to replace every single one of them, because who has time for that, and it's the only way to be sure that if there's something wrong... it's in my local files, not some reference-of-a-reference that did bad things when merged, lol.

I'm legitimately scared to even attempt to prefix variants because of all the references to account for. I may honestly leave the stock ones replaced and hope that doesn't interfere with the vast majority of mods.

What has worked for me so far, however, has been prefixing every other file with a unique mod identifier (both in name and id) then specifically using the csv files to override and remove vanilla files from showing up in the game (Add the hint to remove from the codex, remove blueprint tags, etc). The replaced variant files with the same vanilla id reference the prefixed skins, weapons, hulls, wings, etc so they are effectively "replaced" with duplicate versions without having to actually replace them in mod_info's replace array. Due to the merging/override behavior of csv files, they don't need to be replaced at all when using that approach. The ids in the duplicate files in the mod that overlap with vanilla are utilized without preventing other mods from editing them (it seems at least). So a TC experience can be preserved without directly crashing anything when mod merging and a simple deletion of the vanilla csv rows in the mod's csv files make all the vanilla files accessible again in the campaign/codex/other mods (is the theory).
Logged
Pages: [1] 2