Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Wispborne]

What are the odds of having a `beforeGameLoad` hook added to `ModPlugin`?

The use case I'm thinking of is detecting save-breaking mod updates and showing an user-friendly message before the save file is deserialized and blows up.

Potential method signature:

Code: java

/* SaveDescriptor could be a representation of descriptor.xml (btw, syntax highlighter doesn't like double-slash comments, it comments out the rest of the code block */
abstract void beforeGameLoad(SaveDescriptor saveDescriptor); 
/* or, more simply */
abstract void beforeGameLoad(String lastSavedModVersion); 

The code I'm imagining using it for would look something like:

Code: java

@Override
void beforeGameLoad(String lastSavedModVersion) {
  /* Version.java is left as an exercise to the reader */
  Version oldVer = Version.parse(lastSavedModVersion); 
  Version currentVer = Version.parse(Global.getSettings().getModManager().getModSpec("myMod").getVersion());

  if(oldVer.getMajor() < currentVer.getMajor()) {
    throw new RuntimeException("Updating from version " + oldVer.toString() + " of MyMod to version " + currentVer.toString() + " requires a new game. Please downgrade MyMod to " + oldVer.toString() + "  or start a new game to continue.");
  }
}

[Morrokain]

The game already shows a "mod compatibility warning" when you try to load the game (I'm not 100% sure if this is in 0.9.1a, actually), and will also show the saved with/current versions for all the mods involved in the save game's tooltip, so I think this should be covered?

I think based upon this thread there is a desire for modder customization of version control. So what I think Wispborne means with the suggestion is that a modder can determine for themself which versions will actively break saves rather than a warning just when the mod version and save version mismatches.

Even though some version mismatches won't actually break saves, the user still gets the warning if the versions are different.

(Personally I'm on the fence about it for the reasons I've stated in the thread.)

[Wispborne]

ha, Morrokain beat me to explaining it.
-------------------

What are the odds of having a `beforeGameLoad` hook added to `ModPlugin`?

The use case I'm thinking of is detecting save-breaking mod updates and showing an user-friendly message before the save file is deserialized and blows up.

The game already shows a "mod compatibility warning" when you try to load the game (I'm not 100% sure if this is in 0.9.1a, actually), and will also show the saved with/current versions for all the mods involved in the save game's tooltip, so I think this should be covered?

It is in 0.9.1a, yeah.

The difference between what's there now and my suggestion is that the present way show any version difference, regardless of whether or not it's save-compatible.
Users often have no idea what is a save-breaking update or not, due to not reading warnings on the mod page, and install multiple save-compatible updates before ending up an incompatible one that require help to diagnose.

That's an ok state of affairs, modding being fairly at-your-own-risk, but having an express way to show a helpful message when we know for sure that the user is about to get a tricky crash, or worse, would be useful.

[Alex]

Ah - the way it works in 0.95a is the tooltip will show whether it's a minor or major mismatch, based on what part of the version changed, so e.g. 0.1.1.1 -> 0.1.2.2 = minor warning ("it might not work"), while 0.1.1.1 -> 0.2.1.1  = major warning ("it probably won't work, expect it not to load").

[Wispborne]

Ah - the way it works in 0.95a is the tooltip will show whether it's a minor or major mismatch, based on what part of the version changed, so e.g. 0.1.1.1 -> 0.1.2.2 = minor warning ("it might not work"), while 0.1.1.1 -> 0.2.1.1  = major warning ("it probably won't work, expect it not to load").

Interesting. So, are you taking an opinionated approach to versioning - or can the mod itself decide what to show in the tooltip?

I ask because a minority of us use Semantic Versioning, where only the major (first) number change reflects incompatibility. The second number is a feature update bump, and the third is for bugfixes. So, in that case, going from 1.1.1 -> 1.2.2 should always be compatible.

If you're saying, "this is the way that mods should version from now on", then that's totally cool. Honestly I'd be happy to see more consistent versioning, even if it's not what I personally favor (edit: which is arguably not a great fit for mods anyway).

[Alex]

Yeah - this is largely due to having version dependency checking for mods in the launcher, which, kind of need to choose a specific scheme (any scheme, really, point being that one has to be chosen) for that to work. And if that same scheme works for estimating save compatibility, too...

The second number is a feature update bump, and the third is for bugfixes. So, in that case, going from 1.1.1 -> 1.2.2 should always be compatible.

Right! I suppose the warning in that case is a bit on the cautious side, but that seems acceptable. It's more of a "the version changed" heads up, really.

[Wispborne]

Yeah - this is largely due to having version dependency checking for mods in the launcher, which, kind of need to choose a specific scheme (any scheme, really, point being that one has to be chosen) for that to work. And if that same scheme works for estimating save compatibility, too...

Thanks, sounds like a great change! Easy to implement*, consistent, and user-friendly.

* including ignoring it by always bumping the major version

edit: I guess I am still a little disappointed the only way to indicate to an user than a mod update is compatible will be to go from 0.0.0.1 to 0.0.0.2 (assuming they aren't reading patch notes/forum page). Ah well.

[Jaghaimo]

Ah - the way it works in 0.95a is the tooltip will show whether it's a minor or major mismatch, based on what part of the version changed, so e.g. 0.1.1.1 -> 0.1.2.2 = minor warning ("it might not work"), while 0.1.1.1 -> 0.2.1.1  = major warning ("it probably won't work, expect it not to load").

Could we have one or both of these?

• Could we have a mod_info.json field (optional) to make a major mismatch save unloadable as opposed to just warnings (false by default)?
• If you will be forcing a versioning scheme - please disregard this. In the discussion linked here, many people do not feel comfortable with SemVer (or any forced versioning scheme it seems) - could we have a mod_info.json field (optional) to specify backwards-incompatible (if not present default to normal logic, so major/minor mismatch shows warning)?

Also tooltip in 0.91a is unreadable (only fraction of it fits on a 1080p screen) as soon as you have 20ish mods enabled and some mods are added, some have version changed, etc.

[Alex]

The tooltip is now better! It's formatted in a way that can fit a lot more mods on screen, and if it can't fit them all, it'll cut some off, preferring to cut off ones where there isn't a version problem.

Here's a shot of the new tooltip, btw:
https://twitter.com/amosolov/status/1168701945281994754

   

• Could we have a mod_info.json field (optional) to make a major mismatch save unloadable as opposed to just warnings (false by default)?

Hmm, if this is optional, then you'd get different behavior from mod version conflicts that look like they should be the same type of conflict to the player. I mean, could also show this flag for a mod somewhere, too, but I think that'll complicate things beyond what's reasonable. The tooltip is already possibly there anyway!

   

• If you will be forcing a versioning scheme - please disregard this. In the discussion linked here, many people do not feel comfortable with SemVer (or any forced versioning scheme it seems) - could we have a mod_info.json field (optional) to specify backwards-incompatible (if not present default to normal logic, so major/minor mismatch shows warning)?

I won't be *forcing* a versioning scheme; the code will try to parse the version string and make some educated guesses. But if someone wants to flag a version as backwards-incompatible, they can already do so by switching to the new versioning scheme, so I'm not sure that I want to duplicate the same functionality in a different way. I mean, if there are different ways to do the same thing here... it's not the most burdensome thing, but it's still something to consider and support going forward, etc.

[Jaghaimo]

Hmm, if this is optional, then you'd get different behavior from mod version conflicts that look like they should be the same type of conflict to the player.

Not for dependency checks, but for self. So if I, as a mod author know my upgrade will break saves, I would like to be able to stop save-game loading altogether (by bumping Major and enabling this optional mod_info field). It should stay optional, as not everyone will bump Major when save-breaking changes are made. In other words, if there is a Red tick for my mod on new tooltip (which looks great btw), I want to be able to make this save unloadable.


Another issue modders often encounter is "can this mod be added midgame"? A way of preventing loading a game if the answer is no would be great as well.

[Alex]

I get what you're saying - what I mean is for the player, it's "ah, this mod is incompatible" but then whether the save will actually be allowed to try loading depends not on the mod version (which the player can see) but on some other factor that the player can't see and isn't consistent between mods. I suspect there would be bug reports if this was a feature.

... actually, this is all getting rather off-topic; let me split it off.

[Tartiflette]

This is a similar topic as the "Semantic Versioning" topic so I'll cross-post my concerns about such system: this would create non-intuitive versioning since save compatibility is completely independent from the size of an update. We can have properly massive overhauls that work fine but hotfixes that break saves. Therefore the versioning wouldn't reflect that at all with situations like,

Code

[version=17.2.1] balance patch
[version=17.3.0] Added 12 ships, 6 weapons, complete campaign rework.
[version=18.0.0] fixed miss-placed mount.

On the other hand, why would the user care about versioning consistency? If the tooltip says "This update has been flagged as save breaking by the author" there shouldn't be any issue of false reports.

IMO, the best compatibility check would be a separate internal number in mod_info.json that gets ticked up when an update break saves (it could even be an arbitrary string really). If the compatibility check from the save is different from the currently loaded mod, then it triggers the error message.

With my example we would get

Code

[version=17.2.1][compatibility=13] balance patch
[version=18.0.0][compatibility=13] Added 12 ships, 6 weapons, complete campaign rework.
[version=18.0.1][compatibility=14] fixed miss-placed mount.

Such system could override the automatic check if you want to keep it as a failsafe option.

[Alex]

Well - primarily the system is there for managing mod dependencies and it's based on what version checker was already using...

Edit: what I'm trying to say is that it's not really *required* to version it to provide the most accurate save compatibility message.  Whether it's a "might not load" or "likely to not load" message, there's still room for either outcome.

[Wispborne]

Well - primarily the system is there for managing mod dependencies and it's based on what version checker was already using...

Edit: what I'm trying to say is that it's not really *required* to version it to provide the most accurate save compatibility message.  Whether it's a "might not load" or "likely to not load" message, there's still room for either outcome.

Semantic versioning is a way to conflate versioning and compatibility, but makes major version ticks unexciting if it's just a breaking bugfix.
The 0.9.5a system conflates versioning and a vague compatibility, like "lots of stuff changed, maybe your save will work, maybe not", even if the author knows for certain that it won't break saves.

I think that's why Tartiflette is talking about a separate number for it, to give mod authors the option to be express about what is save-breaking.

If I'm a user and I see an update, I'm probably not going to update if I see "this may or may not break your save game", even if it's a very low chance.

Similar to Tartiflette's example, major new content in my mod has been save-compatible. My preference is to make breaking changes without any new features.

[Morrokain]

The important thing here is consistency and user expectation though. What I mean by that is what something like what was suggested does is give modders a way to specifically say - through loading/not loading or backwards compatibility messages - "Hey my update won't break saves! Go ahead!" Or "This will 100% break saves - wait until a new game to update!"

Am I correct in that interpretation?

If that is correct, the big problem which I brought up in the other thread is that the actuality of that information isn't guaranteed to be correct. This isn't proven logic determining whether this is true, it is the modders faith in what they know about the update - which in some cases could be wrong! In the cases where it is wrong, it creates extra confusion for the end user and probably extra saltiness to their response. It might seem silly to bring that up since that is the modders own risk, etc, but I don't think we can discount the impact to end user expectations here.

That is why the warning doesn't make guarantees - and why modders probably shouldn't either - at least technically through things like launcher messages. It seems like a good idea when you first think of it, but in reality it will probably lead to less than desirable outcomes. I get that you can already do this to some extent with messages like "Will/Won't Break Saves" above the update link, but to me at least, that is different than what seems like "logic is working to determine compatibility" that is in fact still just the modders opinion of if it will work or not like what a message over the download link clearly implies. Does it seem like splitting hairs to say one is ok and one isn't? Absolutely. But remember we are talking about the end user who doesn't read anything or try and learn how stuff works - they just want it to work so they can play. The launchers seems too "official" to state something that is, in fact, really a judgement call.

Hopefully that makes sense. Its not about what versioning style to use or how to go about official compatibility warnings, but should such warnings be possible when they aren't guaranteed to be correct?

(Tartiflette's separation of versioning and compatibility control is the best way to do this, I'd say, since it removes the additional issue about versioning clarity through always incrementing Major if unsure about save compatibility. But mark my words, it will still open up a can of worms the first time anyone is wrong should it be implemented!   )