"id" field problem in new mod metadata.yml.

[DoxaLogos (JG)]

(I did file bug report just in case)
So, I tried to update to the latest Final Mod Pack mod, but OpenXcom couldn't find the mod when loading a saved game. I think I figured out the problem. 

Final Mod Pack 1.5b has this for it's id field in the metadata.yml "Final Mod Pack" which is same as directory the directory name in mods directory. 
Final Mod Pack 1.5.1 has for it's id field "final-mod-pack" which matches the part for the web location on the mod site.  The "id" field is stored in the options.cfg for that mod pack.  So when I try to load a saved game after updating Final Mod Pack, it can't find the mod and disables the mod.


It was my understanding the "id" field in the metadata.yml was for the mod website, so autoupdating feature could be implemented in another script.


Either "id" should be used for local installs or web site updates, but not both.  I think you'll need a new field for website updates, maybe "url".

Reproduction:
Load Final Mod Pack 1.5b.  Verify it loads and save a game with it turned on.
Install Final Mod Pack 1.5.1, and verify the game will not load unless you disable the mods.

Look in options.cfg at Final Mod Pack 1.5b and see id: Final Mod Pack  and then look at it after Final Mod Pack 1.5.1 and it will be "final-mod-pack" like in the website.

[myk002]

Final Mod Pack 1.5b has this for it's id field in the metadata.yml "Final Mod Pack" which is same as directory the directory name in mods directory. 
Final Mod Pack 1.5.1 has for it's id field "final-mod-pack" which matches the part for the web location on the mod site.  The "id" field is stored in the options.cfg for that mod pack.  So when I try to load a saved game after updating Final Mod Pack, it can't find the mod and disables the mod.

Solarius Scorch change the value of the id field at my request -- it's used as the internal id for save games and is *recommended* that it match the id in the mod portal for update scripts.

I tried to document this in the "Upgrading to the nightly" thread:

id (same as the name)
the internal id that this mod is known by.  savegames, configuration files, and other mods' metadata files will refer to the mod by this string.  if you make the value of this attribute the same as the id you used when uploading to the mod portal (https://www.openxcom.com), then autoupdate tools may be able to use it to check for new versions.

it's true that you'll have to re-enable the FMP since the id has changed, but that is by design.  it's not disabling the mod, it's just recognizing it as a different mod.

[DoxaLogos (JG)]

Then he will need to change the directory name that the mod extracts to match "final-mod-pack" on the local filesystem for it to match what OXC is looking for in the options.cfg file else it won't find the current directory name "Final Mod Pack" when the mod is extracted.  Ergo, it thinks it's not installed when it is.

[myk002]

Then he will need to change the directory name that the mod extracts to match "final-mod-pack" on the local filesystem for it to match what OXC is looking for in the options.cfg file else it won't find the current directory name "Final Mod Pack" when the mod is extracted.  Ergo, it thinks it's not installed when it is.

As the author of the code in question, I can tell you that that is not how it works.  The directory name is irrelevant.  The mod name that is displayed and the id that is used come from the metadata.yml file.  Try it -- move the directory "mods/Final Mod Pack" to "mods/Final Mod Pack 1.5.1" or something.  Start openxcom.  it will still be marked as active in the options -> mods screen.

If no metadata.yml file is provided with the mod, then the directory name is used as the default value for the mod name and the mod id, but that is not the case here.

[DoxaLogos (JG)]

As the author of the code in question, I can tell you that that is not how it works.  The directory name is irrelevant.  The mod name that is displayed and the id that is used come from the metadata.yml file.  Try it -- move the directory "mods/Final Mod Pack" to "mods/Final Mod Pack 1.5.1" or something.  Start openxcom.  it will still be marked as active in the options -> mods screen.

If no metadata.yml file is provided with the mod, then the directory name is used as the default value for the mod name and the mod id, but that is not the case here.

Okay. So I tried disabling and re-enabling FMP, no luck loading saved game.  I tried renaming the directory to "Final Mod Pack 1.5.1"  and "Final Mod Pack v1.5.1", and it still doesn't work.  I don't know what to do, but I'm unable to upgrade the mod and restore my game.  The only thing I noticed different was the id field changed in the options.cfg file to match the id field in the metadata.yml of the mod when I looked at both mods metadata.yml files, so if it's irrelevant, it still no worky.


My only recourse to roll back to 1.5b.

[myk002]

Maybe I'm not understanding what's going wrong here.  By "it doesn't work", what exactly doesn't work?  The game should give you a warning about mods being changed, but that is expected since the mod id has changed since you saved the game.  The mod is the same though, and if you continue, the save should load just fine.   What issue are you running into?

[DoxaLogos (JG)]

When I tried to load the game one time after the warning, FMP items weren't restored in the save game.   Of course, that was after I tried on the second time I got a warning.

If the warning always happen, I'll try to load the save completely this time.  I'll report back again.

[myk002]

Ok, here's what I think happened:
1) you upgraded FMP, which had the corrected id field
2) you loaded your savegame, got the warning, and saw that FMP items had disappeared -- this was because the updated FMP had a different id, and was disabled by default in the mods screen

if you enable the new FMP version in the mods screen and load your save, you'll still get the warning (since the mod id has changed), but if you allow the game to load, all the FMP items should be there now.

[DoxaLogos (JG)]

Okay.. so, I must be going crazy, but the warning is very off putting.  I didn't attempt to load the saved game, because of the last time it blew away the FMP items on restoring the saved game.

Everything works now.  I don't know what happened that it didn't restore the save game.

Edit:  After reading your response, maybe that's what happened, but it's late and my brain is foggy after a long busy day

Thanks for the help.

[DoxaLogos (JG)]

So, in light of all this, is there a way to possibly inform users that the mod has changed and that they should renable the mod on the screen? I didn't pick that up based on the initial warning, and was quite freaked out by it, since I didn't disable the mod myself.

[myk002]

there is no way in general to know if a mod has changed it's id, but in general, that isn't likely to happen often anyway.  this was kind of a special case since everyone is just getting used to the new system.

something that might be possible, and perhaps would have helped here, is to display a popup on startup saying that new mods were detected, and to go to the options -> mods page to enable them.

[Warboy1982]

something that might be possible, and perhaps would have helped here, is to display a popup on startup saying that new mods were detected, and to go to the options -> mods page to enable them.

let's not.
this problem was on solarius, not us.