OpenXcom Forum
OpenXcom => Suggestions => Topic started by: Arthanor on March 13, 2015, 05:03:21 pm
-
This is for mod compatibility, obviously.
When you define a research project that has an "unlock" or "getOneFree" property, the last mod loaded will overwrite any previous list from other mods or default. This makes it difficult to have multiple mods interact properly.
You don't want to list things from other mods in your "unlocks" list because you don't know if the user will actually have those other mods. But, if you don't and they do use the other mods, then some things won't unlock because their list was overwritten. The only option is a megamod that will combine both, but ideally mods should be modular and allow users to pick what they want to use.
Could it be possible to have the unlock and getOneFree lists for research projects behave like alien missions? In other words, what you list under unlock and getOneFree would be added to the list instead of replacing it, to replace a list you would have to first delete it.
-
yeah, but what if one mod adds to it and the second one deletes it? you can't have it both ways. any two mods that try to alter the same thing in different ways are inherently incompatible.
-
If a mod deletes a listing, it is a mod that is actively attempting to control what the list contains. It is natural for such a mod to be incompatible with other mods that add to the list. It is rarely required to do that (mostly in full conversions/mod packs, which are not really intended to work with other mods any ways).
But most mods are only trying to add things and it would be useful for both to be able to add to the same list without overwriting each others. This way you can have two mods that, say, add some new tech unlocked by engineers and would be able to coexist, which is impossible currently.
It might not be a perfect system, but it would be a better one than what we currently have.
-
Yeah, I like this idea. In most situations it would make modding way easier - for the user, not the modder. And the user is supposed to be pampered more. ;)
-
I think this is possible to do, without rewriting eventing from the scratch.
We will have two syntax that are allowed for list items.
Current one without any change:
list: [A, B, C, D]
and new one:
list: #equal [C, D, E, F, G]
add: [E, F, G]
sub: [A, B]
Yaml can easy recognize between list and map and we can exploit it. For code perspective change will be very small form current version:
_list = node["list"].as<std::vector<std::string> >(_list);
we will have
Ruleset::uniqueList(_list, node["list"]); https://if it's list, work old way, if map it's adding/removing unique values.
When everyone adds only, then this will work fine without worrying about load order to much. But with use of delete this could be problematic in theory.
Biggest problem I see is that will be very hard to debug, because you will never see final list, and load order will be very important.
And now question for Warboy and moddes, this will be worth its cost?
-
Thanks for the support!
Load order would be crucial for mods that delete the list, but those would be tricky any way. As it is, every mod behaves like it deletes the list and puts its own. By allowing mods to only add we would reduce the number of "deleters" a lot and reduce how important load order is.
Right now, I have to include unlocks or dependencies of other mods in mine if I want them to be compatible, and I still have to hope that the user loads mine last, otherwise my mod is overwritten.
For some things, instead of having:
research:
- name: STR_PROJECT_A
unlocks:
- STR_PROJECT_C
I have started using:
research:
- name: STR_PROJECT_B
cost: 0
dependencies:
- STR_PROJECT_A
unlocks:
- STR_PROJECT_C
because I know this way I am not overwriting anyone else's list. But it adds a lot of clutter in the save since you get all those invisible (to the player) projects showing up to unlock stuff. And I cant do tiers of unlocks this way.
As for not seeing the whole list for debugging research trees, someone has made a "research tree visualizer" which could help, and having a cleaner game save also helps a lot. Removing "accidental deletion" by adding new mods would also reduce the incidence of mod issues.