Setting up mod_info.yaml and archived_versions

[asquared31415]

Notepad doesn't do that according to my testing, but it WAS an IDE issue, the editor I was using did that.  I found its setting to disable that and that works, and also just using notepad worked.

[Nightinggale]

This is an awesome feature. In the past I had the issue of supporting either the stable version or the beta, but it wasn't possible to get a mod to support both. mod_info would have solved it as I could have archived the stable release version and then update the root mod for the beta. This really makes distribution a whole lot easier both for modders and for players, particularly on the steam workshop.

The only downside to it is that it seems like extra work for no reason until you get that it allows multiple mods in one distribution. Perhaps this should be made clear earlier in the text. It starts out with explaining the specs, but it would be nice to have a section just before that clearly telling us why we would want to use it as opposed to the past where everything went fine without it.

[erny0507]

On 1/12/2021 at 1:25 PM, Lbphero said:

kanim stuff still appears to be borked

EDIT: i get lots of errors like this when loading mods that have anything to do with kanim files!

[18:49:53.482] [1] [ERROR] KAnimBatchManager is not ready when loading anim:anim_starfield_bg
KAnimBatchManager is not ready when loading anim:anim_starfield_bg 

my log for loading the mod "Fashionistic" is included:

Player.log 1.17 MB · 11 downloads

did you get a solution? i get the same error 

[Primalflower]

3 hours ago, erny0507 said:

did you get a solution? i get the same error 

It got fixed ages ago...maybe its just on the testing branch?

Edited January 26, 2021 by Lbphero

[Clinch]

Hopping in here for an update - I just updated a simple mod, and while the whole experience isn't great, it's completely do-able.

I think that it's more the tools (and the enormous amount of data that they 'unlock') can get in the way of the learning process (for me, at least)

I'm happy to do some custodial work as part of learning the ONI modding ecosystem, there's a few mods that I used for QoL that I would love to have in DLC-land!

 

[Cairath]

Hey @Ipsquiggle

Today my friend mentioned to me that it'd be great if workshop could be filtered by compatibility with Spaced Out. A few modders chatted for a moment in Discord about that and we thought it'd be handy if there were extra tags to denote compatibility. Marking "requires DLC" doesn't really work for mods that work for both (the majority) and does not provide an additional filter.

Rimworld has something like this:

 

I know that tags can be categorized, maybe you could consider adding 'Compatibility' category with tags 'Vanilla' and 'Spaced Out'? Would definitely help finding SO mods.

[pether]

On 1/12/2021 at 10:56 PM, Ipsquiggle said:

The logic is this (in all cases for this example "archive" includes the mod in the root folder):

1. First we filter on supportedContent -- an archive is completely excluded if the current content doesn't match one of the entries in this list.
2. Then we look for the archive with the lowest lastWorkingBuild which is greater or equal to the game version. i.e. if you have mods at versions 6, 8, and 10, and the game is at v. 7, then it will load the mod for v. 8 which is the "lowest greater version".
3. If there is no "greater" mod than the game version, we take the highest lastWorkingBuild which is less than the game version. i.e. if you have mods at version 6, 8, and 10, and the game is at v. 15, then the mod for v. 10 will be used.

Not sure if this is too late to change, but I can see an issue with this algorithm.

Lets say current live branch is version 7. My mod info currently supports version 6 and all is good. Now you guys release public_testing branch with version 8 and Harmony2.0, my mod in version 6 will crash beta branch. But if I update my mod to support both v6 and v8, my v8 update will be applied to live branch with v7 as "lowest greater" following rule 2. If I have brand new harmony 2.0 update on my v8 mod or any other changes that supports beta, but are unsupported by main game, my update will break the game for all non-beta users.

As a result, my mods cannot support both public_testing and live branches, I must pick one of them and let the mod crash on the other. If I want to update my mods, I cannot do it in advance not to destroy most people's lives and I must wait until beta goes live.

@Ipsquiggle, is it possible to modify those rules, or is it too late now and we keep what we have?

Edited June 14, 2021 by pether

[asquared31415]

You can change the latest version to be version 7 in that case (assuming the current mod that is labeled version 6 works) and then everything will just work.

[Ipsquiggle]

@pether It's quite possible we could have a better algorithm, but the current system is based on the assumption that we don't know why there isn't an exact match for the current build (i.e. no v7 mod for a v7 game).

The best thing to do would be to update lastWorkingBuild for an archive each time you upload your mod package. e.g. in your scenario, when you add the v8 mod, you also know that the older version was last working on game v7, so it's mod_info.yaml should be updated to reflect that. All ambiguity is removed and the game can do the correct thing.

I realize this is a bit of extra legwork each time a testing branch hits, but it only has to be done in the case that a person is already uploading a new version of their mod anyways.

We could make ambiguous cases "bias downward" instead of "bias upward", but then we'd just run into broken mods in the opposite scenario (i.e. where v6 is obsolete and v8 accounts for the v7 changes). In all cases, the problem is resolved by the mod having accurate information at the time of upload though.

Let me know whether or not that makes sense in your experience though!

[pether]

18 hours ago, Ipsquiggle said:

Let me know whether or not that makes sense in your experience though!

I might miss something, but I can think only of one scenario when the game with v7 can choose between mods in v6 and v8: that is when there is public_testing branch with v8 of the game and somebody made changes in their mods explicitly for that branch. In that case, if somebody is making update for beta instead of live game it is because beta introduced changes that are not present in live v7 and somebody wants to mod those changes. This way, live game loading mod for beta would crash.

I cannot think of any other scenario when player loads v7 of the game, but somehow v8 is somewhere present as well. 

Do I miss something?

Having that said I guess it is not a big deal to update mod_info to increase last working build from v6 to v7 and then don't worry about game loading mod for v8. I just don't understand what scenario you want to have covered.

Thanks!

[Ipsquiggle]

Hahah, you've really got me thinking about this!

I had to draw a diagram with a bunch of scenarios on it. Here's what I've discovered:

NOTE TO THOSE COMING IN THE THREAD LATE: This is an exploration, not a reference document!

So the critical ones are the (b) and (c) scenarios.

In (A) bias to older, a user's game can crash if they join preview, but the mod hasn't been updated (scenario Ac). If they don't join the preview, they don't care if the mod has been updated or not (Ab), until preview moves to release (effectively Ad).

In (B) bias to newer, if they choose to stay on trunk (i.e. to avoid mod incompatibility), their game could suddenly start crashing if the mod updates but doesn't properly update their old version's lastWorkingBuild (scenario Bb). All other scenarios are the same.

So, it seems to me that (A) is the better choice... And our current implementation is (B) isn't it

Okay so it took a while but I'm now convinced this makes sense. My remaining concern is who would be affected if this is changed. I'll be thinking on that and making sure this doesn't have major knock-ons.

Thanks for your persistence.

[pether]

20 minutes ago, Ipsquiggle said:

Thanks for your persistence.

You're welcome, I'm currently in validation mode and I tend to break code or whine about the details - and it's hard for me to switch when I enter the forums. Let me know if I started whining too much

I hope I could help. Thanks for all improvements in the game and modding system, it's looking better and better every week 

[Cairath]

Wouldn't it be less complicated if we could specify version range? Not gonna lie, analyzing the above took me a moment

[pether]

2 minutes ago, Cairath said:

Wouldn't it be less complicated if we could specify version range? Not gonna lie, analyzing the above took me a moment

Like "applicableFromBuild" and "appicableUntilBuild"? Yeah, that might be easier to read. People who don't read forums much would know what is happening and there would be little unspoken magic like "greatest smaller unless there is smalest greater". 

[Ipsquiggle]

So I've been thinking about this, and it seems like having two build numbers won't erase any of the confusion; we'll still have to have resolution rules for when there's gaps, or for when there's overlap, etc.

I also don't think having two build numbers will solve any scenarios where a modder would have to update both the current and previous archives, as they already do now.

I do think there's a chance that the additional explicitness would provide clarity, but I feel that the messiness of real scenarios would often fall outside the boundaries, and so people would have to be thinking about the exceptional cases anyways.

Here's the proposal I'm leaning towards:

1. From the archives whose supportedContent matches the running game...
2. ...the game loads the archive with the highest version that doesn't exceed the game version.

examples:

• Game at v7, archiveA at v7 -- loads archiveA
• Game at v8, archiveA at v7 -- loads archiveA
• Game at v8, archiveA at v7, archiveB at v9 -- loads archiveA
• Game at v9, archiveA at v7, archiveB at v9 -- loads archiveB

 

This handles rolling updates and preview periods, and doesn't require updating the lastWorkingBuild on archived mods.

The question in my mind is, which of these two proposals (the one here, or having a version range) makes it easiest for a new modder to get their head around the system?

[Cairath]

I think I like the idea.

More of a visual person though, so attempted to draw it:

Does that match what you have in mind?

With this approach "lastWorkingBuild" would need to be renamed to something like "minimumGameVersion"

 

[CynicalBusiness]

49 minutes ago, Ipsquiggle said:

The question in my mind is, which of these two proposals (the one here, or having a version range) makes it easiest for a new modder to get their head around the system?

I'm liking these changes a lot so far. Answering your question, your proposal, at a glance, is the most intuitive to me and I think the one I prefer.

As I was thinking about it, a few edge cases came to mind:

• Game v6, archiveA v8 -- Does the game make an attempt to load this archive? Error? Marked as incompatible?
• Game v8, archiveA v8 ALL, archiveB v8 VANILLA -- Which archive actually gets loaded?

All in all, keep up the good work!

[Cairath]

It's been brought up on discord that being able to specify maxV in addition to minV would allow for mod deprecating if needed (in your approach a blank mod could be uploaded instead). I can get behind both proposals at the moment. I feel like a range is more explicit and intuitive, but other folks should chime in. I'll try to get some more opinions from newer modders on discord.

Personally, I think I prefer the approach you suggested now.

Edited June 18, 2021 by Cairath

[Ipsquiggle]

@Cairath The diagram you posted is accurate. (I also have a notebook full of sketches, though not so neatly arranged haha...)

edit: And yes, I am also considering the damage of renaming that field... Transition pain vs. future pain is always a rough call!

@CynicalBusiness Although I'd like to discourage people from marking their mod as compatible with game builds that don't exist yet... My gut says to err on the side of trying to load something, so in that case it would load the "oldest" mod. But I don't think I'd publish that as a rule someone should know about. I'll probably have it throw an error if it's a dev mod in any case!

To your second point, again I'd like to try and load something. Probably first encountered, so root > first folder > second folder, etc. Our current system already suffers from this, I should also probably throw an error if it's a dev mod.

[Cairath]

17 minutes ago, Ipsquiggle said:

My gut says to err on the side of trying to load something, so in that case it would load the "oldest" mod. 

I'd rather not load at all - if the live version is, say, 10, and testing is at 11, and testing has new stuff that does not exist/would make no sense in the live version, live version should not load that. Some modders are very eager to release new mods when testing hits and there's some exciting stuff. And people don't really read descriptions in the workshop :P

20 minutes ago, Ipsquiggle said:

And yes, I am also considering the damage of renaming that field... Transition pain vs. future pain is always a rough call!

Everything is broken anyway

Edited June 18, 2021 by Cairath

[pether]

10 hours ago, Ipsquiggle said:

Transition pain vs. future pain is always a rough call!

Harmony 2.0, UserMod2 and other changes will cause us to change everything anyway. Transition pain is already there, I would say that if you are considering even more changes to make future life easier - this is the best moment to do it.

And let me just say that I welcome this pain as I know it will be much better after that. I never thought I will be so excited for modding changes, there are plenty good additions to the system! 

So no, the changes are not that painfull. The only thing I really dread are outdated mods that will be stolen and/or duplicated causing steam workshop to be one big mess

[Ipsquiggle]

The change has been pushed to public preview, the mod_info.yaml format is currently backwards compatible. This particular change is also going to non-SO version of the game on Thursday for forward-compatability.
 

Quote

 

Mods: lastWorkingBuild has been replaced by minimumSupportedBuild in mod_info.yaml. The behaviour is now: "From the mod archives with supported content, pick the one with the highest supported build that doesn't exceed the game build."

The old field will still function in existing mods, but modders are encouraged to update their mod_info.yaml next time they publish their mods.

 

I will update the top post once this is live to everyone on Thursday.

[pether]

On 6/23/2021 at 12:22 AM, Ipsquiggle said:

The old field will still function in existing mods, but modders are encouraged to update their mod_info.yaml next time they publish their mods.

it seems that old field crashes the game, even if the mod is disabled

Edited June 24, 2021 by pether
Possibly only for mods in dev directory

[Ipsquiggle]

Yes... I guess I should have said, "Modders are strongly encouraged to updated this field, with an error for mods in the dev folder".

Basically, having the wrong field name will an error for dev mods, but silently work as a fallback for Steam or Local mods.

[pether]

OK, so this is known feature, not a bug? Good