Mod Mapping Rabbit Hole

As I crawled further down the rabbit hole that is data refactoring for mods, I reached another "am I insane?" point today.

As previously mentioned, this mod refactor goes to the heart of the data management code in NEO Scavenger, and changing simple ID refs into combo Mod:ID refs involves a lot of changes (maybe dozens of code rewrites in each of dozens of classes). Even though I was able to get data loaded into memory in a segregated way, changing all the game code to use the new data ID format was getting more complex the more I worked on it, and gave me pause.

So after some rethinking, I examined some alternatives. I think there might be a way to remap this data on the fly as it's loaded in. This way, I don't have to rewrite all of the NEO Scavenger data refs (of which there are probably hundreds). Instead, all of the data just gets new IDs to avoid conflicts as things are loaded, and the old code still works as-is.

E.g. if mod1 has a pencil set as ID 13.0, that conflicts with the base data's 13.0 (medium branch). The idea is that this remapper will recognize that conflict, and assign it something safe, like 113.0. Then, it stores this info in a remapping table, so any other items in mod1 that need to refer to 13.0 get switched to 113.0, too.

Furthermore, if mod1 needs to refer to base game data, it can still use "0:13.0" style IDs, and the game will know that they mean the base data. Basically, "13.0" means the item refers to data within this mod, and "X:13.0" means the item refers to modX's 13.0 (where X can be "0" for base data, or anything else).

If my hunch here is correct, this will save me a lot of time. I'm thinking this might be working in a day or two, as compared to a week of work on the other way. It's unfortunate that it took this long for me to figure that approach out, but it's also possible I needed to screw up once to realize it wasn't going to work.

Anyway, I've started this new remapper approach, and so far, it "feels" better. I don't have that nagging feeling of working towards failure anymore (not yet, anyway). I think just the fact that it touches way less code makes me feel better.

I'll continue work on this tomorrow. And part of this work will be offline, due to a scheduled power outage. In theory, the outage only lasts 4 hours, so I'm getting my laptop loaded up with the requisite files so I can plug away at remapper code during that time (probably off-site, in a cafe with working power outlets). Hopefully, I should have access both in the early morning and afternoon, so I should be able to catch up on any online stuff then.

Have a good night, all!


EmperorZA's picture

gotta break a few eggs to make an omelette hehe wish I could do complicated stuff like that


ra1's picture

If possible, try to also allow a mod to (explicitly) reference another mod's objects. Often with mods in games...some bubble to the top and become a defacto-standard which the other mods depend or build on. Alternatively, a mod may want to merge itself with another mod. It would be nice if this wasn't considerably difficult.

Finally, even if you don't require adherence, it would be nice if there was an official mod guidelines document which would, among other things, allow mod devs to generally prevent accidentally stepping on each other's toes when the above cases occur.

dcfedor's picture

@ra1, I agree, and I'm hoping to allow cross-referencing. In the design I'm planning, a mod references its own data by not specifying any mod at all.

E.g. itemID=13.0 will reference this mod's copy of 13.0

If a mod wants to reference the base game data, it must specify mod "0".

E.g. itemID=0:13.0 will reference base data's copy of 13.0

And if a modder wants to reference another mod, just replace "0" with that mod's name.

E.g. itemID=DeFactoMod:13.0 will reference DeFactoMod's copy of 13.0

So far, this seems feasible. I'm doing some behind-the-scenes work on remapping IDs, so hopefully these types of references will work!

Dan Fedor - Founder, Blue Bottle Games