ModConfig.xml with packageIds system worse than old one

Started by ruPal, February 26, 2020, 09:43:01 AM

Previous topic - Next topic

ruPal

1. You cannot have more than 1 local copy of the same mod. New limitation.
2. You change ModConfig.xml content everytime when you make local copy by adding "_steam" postfix to Steam mod. Local mod and Steam mod may be written in ModConfig.xml with the same packageId (that depend on if player has one or both steam/local mods). That may lead to conflicts when you load Steam collections and want to share your ModConfig.xml. Example:
1. Player 1 makes collection and upload his ModConfig.xml to share with other. Player 1 does not have local mods and uses only steam mods. His ModConfig.xml file contains no mods with "_steam" postfix.
2. Player 2 has local mods and some of the mods have the same packageId that are in ModConfig.xml of Player 1. Player 2 subscribes on mods and loads ModConfig.xml of Player 1. With current realisation Player 1 and Player 2 will have different ModConfig.xml because in Player's 2 some of the mods will be loaded from local mods while all mods of Player 1 are Steam mods.

May I ask to make constant _steam postfix for any steam mod and no postfix for local copies. That will not fix the issue #1, but will fix issue #2. IMO, new system confuses with contant adding and deleting "_steam" postfix. I do not know what was the purpose of changing old system (when you used folder names to save/load mods), IMO we can still use it for ModConfig.xml and leave packageIds for sorting only, that solves both issues.

Tynan

Let me get Nowhere to respond; he's the one who's been working on the mod manager system.
Tynan Sylvester - @TynanSylvester - Tynan's Blog

Nowhere

I see, the idea of having universal, clean ID in all systems was compelling to us and we might've overextended it. I think we still have time to change ModsConfig back to folder names if people genuinely rely on old behavior a lot. And it might be necessary now that we have "multiple revisions of the same mod" on roadmap. The packageId solution will always be limiting in this light.

To address the rest of the post:

In most scenarios it should still find mod by a packageId whether it has _steam postfix or not in XML. And if you have both steam and non-steam active, it will keep only one.

On your scenario: It will still load it, but it might be confused about which one to load in this case. And if for some reason(unclear to me so far) you have different(functionally, so it matters) versions of the same mod and still want to apply someone else's mod list that also contains this mod... Yeah. In that case you might need to re-adjust it afterwards. Is that a common scenario? Not arguing, genuinely asking.


Tynan

Tynan Sylvester - @TynanSylvester - Tynan's Blog

ruPal

Quote from: Tynan on February 28, 2020, 12:37:26 AM
We know :) So this is considered important.
Personally, I do not consider myself as a good modder, but I am so pleased.  ::)  Thank you.

Quote from: Nowhere on February 27, 2020, 01:19:37 PM
I see, the idea of having universal, clean ID in all systems was compelling to us and we might've overextended it. I think we still have time to change ModsConfig back to folder names if people genuinely rely on old behavior a lot. And it might be necessary now that we have "multiple revisions of the same mod" on roadmap. The packageId solution will always be limiting in this light.

To address the rest of the post:

In most scenarios it should still find mod by a packageId whether it has _steam postfix or not in XML. And if you have both steam and non-steam active, it will keep only one.

On your scenario: It will still load it, but it might be confused about which one to load in this case. And if for some reason(unclear to me so far) you have different(functionally, so it matters) versions of the same mod and still want to apply someone else's mod list that also contains this mod... Yeah. In that case you might need to re-adjust it afterwards. Is that a common scenario? Not arguing, genuinely asking.

UPD: You may ignore everything below. Since I didn't encounter that issues and no one reported it to me. That is all a theoretical reflections. I will modify my software to overwrite local copies with new when installing mod packs. Probably, I was too fast in my decisions.

That was my first opinion on the situation. Probably, I exaggregated the problem. Sorry for that. There is one main problematic situation that I see (split it on two, because of HSK):

1. HSK mod pack. They use outdated mods and if they consider to update pack to 1.1, they will have to change packageIds of included mods or ask players to install pack on the game with empty Mods folder. Otherwise they may encounter duplicate packageId errors.
2. Any other Local packs. If we create custom local pack (similar to HSK) and want to distribute it offline, we may encounter the same issue if other players have local mods with the same package IDs.

We can solve that manually modifing package ID (in local packs) with custom prefix or postfix, that looks as a solution. But then we lose newly added vanilla autosort function, because other mods still rely on "clean" package IDs.  I do not have information about your plans on packageId system, but if you gonna use package IDs in mod patching then we should not modify package IDs in any way.

There was an issue with old system too, when you have steam and local mods in folders with the same name. New system solves that.

I do not have information about local mod packs popularity, so can give only personal opinion on that. Afaik with new system we are limited to use only one pack per game instance.

harpo99999

personally, I do not use low pressure water, only local mods (and even inside the installation location with a savedata path)

Nowhere

I added a write up on supporting multiple revisions of the same mod in this document:
https://docs.google.com/document/d/1WuoJRYUTxb0hbFncG0DFRaablGUoALZu5Wr6p3t22k0/edit#

It does touch ModsConfig.xml - basically, if we're gonna implement a system like this, I think it would be better with folder names in ModsConfig.xml. Otherwise, It seems fine either way. Both have theoretical issues.
Please, feel free to add your thoughts to it.