Way to not break compatibility with Mods?

Modding
#1

Hi There!
Symbol Here

So, it sounds like mods have some sot of ID that the game reads to determine if it is compatible, and it sounds like even mods that aren’t broken by an update sometimes are considered as incompatible,

Mind that i haven’t checked the recent changes and stuff nor do i know how such systems work, so i may be wrong, so if i am, let me know

So
What if we had ID’s for each system or folder?
Some bug fixes don’t ususally break mods, ususally changes in the structure of the files are the reason they break

For an example
Have ID for the ‘Data’ and 'Entities’
If the ‘structure’ of the files in ‘Data’ have changed, the ID for ‘Data’ will change, and Mods that don’t have the same ID as it will be obsolete, so mods that contain anything to do with the ‘Data’ will be obsolete, if id doesn’t contain anything to do with ‘Data’ it won’t have an ID and will pass, but while the ‘Data’ has changed, ‘Entities’ has not, so the Mods than only contain changes in ‘Entities’ wil pass ene when not updated

I’m no programmer, nor am i a coder, so this’s more of a “would this work?” Kind of post

Again, point me out if i’m wrong

Symbol Out!

#2

I doubt it is that simple. even if it is same folder/same file etc. A lot of things are dependent on the JSON structures (assuming data) being merged/replaced. The behavior is also engine-dependent. E.g. it doesn’t work if the mods modify the same things, which is the case a lot of times. Currently modding system is still under development, so is expected to be fragile., though.

The only superficial thing that can be solved is prevent URI clashes between mods that defines new entity types I guess. One simply way though, is to put the creator’s own ID into the entity URI. As long as creator uses different ID, it will not clash. It will also allow mods by same creator to use same references.

Another method typical in modding community is to define a common “dictionary” of entities (dummy/simple objects without full definitions but has defined ids), and allow individual modders to override attributes and reference to them. It still have some careful management that the merged properties do not clash (probably should not “replace”) (or make sure it is applied in the right order, with the “patching” one applied last, though currently, there is no way to specify mod application order).

Basically, everybody who uses one of the dependent mods must first apply the “community mod”, which acts as a layer for ID arbitration as well as “interaction point” (on same entity) by different mods:

e.g. say somebody create a mod that creates Jewelry out of Jewels, which is defined by community mod, another person creates another mod that makes magical weapons out of Jewels. The two mods may probably work together, using same Jewel entity, even if the authors never communicated.

1 Like
#3

Such a system is impossible to implement and would make things just way more complicated for modders.

  1. It’s impossible to define a granularity that is both enough to be used reasonable without too many false positives and at the same time reasonable to do. Basically, you would have to give each statement an ID - not just each file, not just each function, but pretty much every statement in lua (which I guess would be about lines of lua * 0.7 statements).
  2. It’s impossible to define what should change such an ID. What is a breaking change the way mod A uses this bit of code isn’t bothering mod B at all. By changing the IDs, however, you’re breaking both - even those that aren’t really affected.
  3. It’s making modding much more difficult without adding any real benefit. Every mod author would have to define which IDs he’s using/expecting, and at the same time, needs to maintain IDs for his own mod. The points above apply again but for every mod author. In the end, we would likely end up with a system not used by the community at all, or wrong (“each release has new id(s) for everything, update your dependencies”).

The current system allows mods to continue functioning unless there have been severe changes, which will require an version update (worst case, increasing a number in a JSON file), so it’s an “optimistic” approach to the problem. It’s expecting that breaking API changes are rare, which might not be entirely true, but for most mods, should be the case.

2 Likes
#4

Thanks for letting me know

I hope there was a way for the game to check if the mod’s compatible and pass it on itself, but i guess it’s never gonna be so simple

Maybe letting all mods pass but letting the player chose to run or deactivate a mod in-game before you load a save could help(like Don’t Starve does) letting the player know that a mod is possibly obsolete and letting them chose to take a risk on having bugs

#5

I think general mod compatibility cannot be in general automatic. Unless supported by at engine level.

Usually, (not sure about don’t starve), for modding systems that seems to have “automation”, it is the community that prepares the meta-data of which mods are compatible which etc, and hosts them somewhere, which allows a mod utility to read and checks them against the mods currently installed. Others (like those for bethesda Fallout/TES series) can even help you order them correctly.

Well, at least that was so when I was more actively modding. Have been OOA for a long time :wink:

1 Like
#6

Acutally reading and thinking, i think i misled the discussion, i ment Mods not working when the game updates not compatibility between mods, so i ment that if the game reads a section of the game differently the game would update the section’s ID and signals that mods that have assets in that section are obsolete

#7

The game already tries to make them work, with the save compatibility code.

But sometimes the changes are so big (like in this case, performance improvements that changed drastically some structures), that devs change the mod API version to prevent old mods to be loaded by the game (eventually we’ll have a mod manager, but when a mod is broken and you load a save that uses it, you might get tons of errors).

1 Like
#8

It does not matter whether we are talking of compatibility between mods or with the game itself, as the game itself is just mostly a mod. The points I’ve stated still stand, it’s not possible to find proper sections, files or what not to ID things with.

This also has little to do with save games, as this does not touch APIs that changed. Of course, if a mod is doing proper serialisation, the newer (fixed) version can be used to circumvent this. In the end, modding would become way more tiresome and the entry difficulty would be vastly greater, resulting in less people able or motivated to mod. Just imagine that every time Radiant puts out a new release, you would have to wait for all mods to be updated (if ever) because something changed.

Plus, if A is using B, and B changes, should the ID of A change too? Technically, yes… So it’s turtles all the way down.

And worst of all, you would just have lots of work for all involved without any real gain.

3 Likes
#9

One of the great things about modding this game is the flexibility of organization. For most modders, they are not going to be working on an all encompassing update to all aspects of the game. The mod I am working on is mostly just adding new decorative items. I don’t need a folder tree 8 layers deep to keep it organized. For example, there are no “Entities” or “Data” folders in my mod. Specifying different versions for different branches of TR’s tree would require some sort of mechanism for me to remap my mod.

#10

How is there no entities folder in your mod if you’re adding items?

#11

I think the point is: you don’t need to put them in a specific folder at all.
The manifest is supposed to override/merge the proper files/entities via references. Your mod’s stuff can be organized just about any way you want. (afaik)

#12

That’s true, I suppose. I just always arrange mine in the hierarchy that the game is in. Never thought of not doing it.

#13

You can pull up any of my older mods and see the differences - some of them date back to the first Alpha, where the structure was at times radically different (or non-existent).

So I suppose the general answer to the question would be that you can’t avoid breaking compatibility with mods, short of not updating the game ever again.

1 Like
#14

As others have mentioned, you don’t need to have the same exact directories as the stonehearth mod. It all depends on how complicated your mod is. I also tend to organize things in a way that feels more logical to me. For example, my “some_item_recipe.json” file is in the same folder as “some_item_ghost.json”, “some_item.json”, “some_item.qb”, etc.

1 Like