Jump to content

ONI Is Upgrading to Harmony 2.0!


Recommended Posts

3 minutes ago, Ronivan said:

So, the Harmony 2.0 will also be updated for the vanilla version?

yes, but in currently-unspecified later and before that there will be some time for beta, similar as we have public_testing for the DLC

Link to comment
Share on other sites

19 minutes ago, Ronivan said:

So, the Harmony 2.0 will also be updated for the vanilla version? I mean, I know it will eventually, but I want to know if it will be updated right on next week.

It'll come to vanilla when the merge hits vanilla, which is TBD, but not next week

 

edit: i apparently snoozed too long before  hitting send :P

Link to comment
Share on other sites

  • Developer

Hey all, today's patch has a few more changes to the mod system, though there shouldn't be anything breaking!

mod.yaml has a new (optional) field, `staticID`. This is translated to a field on Mod, so you can use it to more reliably communicate between mods. It's also what gets used as the Harmony ID if provided.

Your mod can have a single mod.yaml in the root folder with any of these fields:

title: "Your Mod Title" # recommended you make this the same as your mod name in Steam
description: "Something About Your Mod" # currently unused, but may be someday
staticID: "yourSuperCoolMod" # a name for other mods to recognize you by, recommended to not change this once you set it

mod_info.yaml has a new optional field `version`, a string that gets prepended with a 'v' in the UI
mod_info.yaml has a new field `APIVersion`. If a mod loads a DLL, this must be set to `2` to indicate that the latest version of the mod system (i.e. Harmony2.0) is being used, otherwise the mod will be disabled

Each archive in your mod can have a mod_info.yaml with any of these fields:

supportedContent: EXPANSION1_ID # see the forum post on mod_info.yaml for a full list of options here
lastWorkingBuild: 468097 # recommended to update this each time you upload your mod
version: "1.3.42" # an arbitrary string that will be displayed to users on the mod screen. is prepended with a "v" in the UI
APIVersion: 2 # required if your mod includes DLLs to let the game know you've updated to Harmony2.0

The Mod class now has a field `packedModInfo`. This contains the contents from the mod_info.yaml that was chosen to be loaded.
The Mod class now has a field `staticID` which contains the value provided from mod.yaml.

The UserMod2 class now has a property `mod` that contains the Mod your assembly is being loaded by. You can use this to access all the usual things, including the new above data.

These changes are fairly unobtrusive but should still be considered experimental, so please let me know what you think!

Link to comment
Share on other sites

  • Developer

Yes, mod.yaml is to define the "standard" properties of your mod. Normally we pull the title and description from the Steam Workshop, and those fields previously were only used for local mods. Think of it as providing the same "face" that the workshop provides, but for mod distributed through channels other than Steam (github, Nexus, etc).

Based on the question, I'm wondering if we've even mentioned it before... :wilson_facepalm:

Anyways, it seemed to me that putting the staticID in this file would help keep it more canonical.

Link to comment
Share on other sites

 

14 hours ago, Ipsquiggle said:

supportedContent: EXPANSION1_ID # see the forum post on mod_info.yaml for a full list of options here lastWorkingBuild: 468097 # recommended to update this each time you upload your mod

When I tested the mod archive today, the lastWorkingBuild root is set to 0 and the archived_versions is set to 466654. Unable to load the beta mod contents correctly. The player.log file shows:

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.TypeLoadException: Could not resolve type with token 01000025 (from typeref, class/assembly Harmony.HarmonyInstance, 0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null)
  at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke(System.Reflection.MonoMethod,object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00032] in <695d1cc93cca45069c528c15c9fdd749>:0 
   --- End of inner exception stack trace ---
  at System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00048] in <695d1cc93cca45069c528c15c9fdd749>:0 
  at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] in <695d1cc93cca45069c528c15c9fdd749>:0 
  at KMod.DLLLoader.LoadUserModLoaderDLL () [0x00088] in C:\jenkins_workspace\workspace\SimGame_Windows\game\Assets\scripts\Mods\ModDLLLoader.cs:80 

"Seems to have loaded the mod content in archive 466654 and got an error, not the beta mod content I wanted" .

Is lastWorkingBuild 0 not available in Harmony2.0?

Here is my  mod_info.yaml

MyOniMod/
|- mod_info.yaml
|    > supportedContent: ALL
|    > lastWorkingBuild: 0
|    > version: "1.1.0"
|    > APIVersion: 2
|- (beta mod contents)
|- archived_versions/
    |- vanilla_pre_mergedown/
    |   |- mod_info.yaml
    |   |     > supportedContent: ALL
    |   |     > lastWorkingBuild: 466654
    |   |- (normal mod contents)
Link to comment
Share on other sites

  • Developer

@crazy_xyr The easiest convention is for root to be the newest version, but it's just the same as a version in the archive folder as far as the game is concerned.

So when it tried loading the game at version 468097, it found the archive at 466654 to be a closer match than the root at 0.

The main thing to think about is: When you upload a new version of your mod, set the lastWorkingBuild to the version of the game you were testing it against. If you expect the mod in your root folder to work with the beta, then set lastWorkingBuild in the root to the beta version at the time of upload.

Link to comment
Share on other sites

18 hours ago, Ipsquiggle said:

@crazy_xyr The easiest convention is for root to be the newest version, but it's just the same as a version in the archive folder as far as the game is concerned.

So when it tried loading the game at version 468097, it found the archive at 466654 to be a closer match than the root at 0.

The main thing to think about is: When you upload a new version of your mod, set the lastWorkingBuild to the version of the game you were testing it against. If you expect the mod in your root folder to work with the beta, then set lastWorkingBuild in the root to the beta version at the time of upload.

https://forums.kleientertainment.com/forums/topic/130947-an-msbuild-task-for-automatically-generating-mod_infoyaml/

I find it troublesome to manage the directory structure manually

So I use parameters to control in the code

    <PropertyGroup>
        <UseArchivedVersions>true</UseArchivedVersions>
        <SupportedContent>all</SupportedContent>
        <LastWorkingBuild>468097</LastWorkingBuild>
        <APIVersion>2</APIVersion>
    </PropertyGroup>

 

Link to comment
Share on other sites

On 6/15/2021 at 12:29 AM, Ipsquiggle said:

There is a new class, KMod.UserMod2 which becomes the entry point to the mod. Make a new class that inherits from UserMod2 to access the entry point hooks and data.

I must just say - having easy access to mod_info data inside the mod code is really handy and I really like this feature. Previously I used to copy-paste data and hardcode them, this update makes coding much nicer, thanks! I'm growing excited to see if you manage to squeeze additional goodies before the modding changes go live!

Thanks a lot guys!

Link to comment
Share on other sites

6 minutes ago, Ronivan said:

I followed the new guidelines for the yaml file and folders, but I ended with a "No Compatible Mod Found" next to my mod name in the game mods menu. I did update my mod too.

did you set APIVersion = 2?

Link to comment
Share on other sites

It was the first thing I did when updating it.

Main folder:

supportedContent: VANILLA_ID, EXPANSION1_ID
lastWorkingBuild: 441000

archived_versions folder / expansion1_old folder:


supportedContent: EXPANSION1_ID
lastWorkingBuild: 441000
APIVersion: 2

archived_versions folder / vanilla_441000

supportedContent: VANILLA_ID
lastWorkingBuild: 441000

  

 

 

 

 

Link to comment
Share on other sites

3 minutes ago, Cairath said:

Change lastWorkingBuild to minimumSupportedVersion and version it properly with today's build number for SO

Did so like this:

supportedContent: EXPANSION1_ID
minimumSupportedBuild: 469112
APIVersion: 2

Still didn't worked. No compatible mod found.

Link to comment
Share on other sites

22 minutes ago, Ronivan said:

Did so like this:


supportedContent: EXPANSION1_ID
minimumSupportedBuild: 469112
APIVersion: 2

Still didn't worked. No compatible mod found.

i hope you not try this in base game because EXPANSION1_ID means dlc only

Link to comment
Share on other sites

  • Developer

@Ronivan There are really only two versions of your mod you need to care about: the current, active version for SO owners, and the old archive version for vanilla.

My recommendation is this:

First, put your old vanilla version into a folder archived_versions/pre_mergedown_vanilla, with a mod_info.yaml like this:

supportedContent: VANILLA_ID
minimumSupportedBuild: 441000

It's archived, never touch it again, and profit :D

Then, put the active, SO-compatible version of your mod in the root, with a mod_info.yaml like this:

supportedContent: ALL
minimumSupportedBuild: 469112
APIVersion: 2

Then continue working on that version as always, and you don't have to worry about archived versions anymore.

----

When it comes time for the next preview, if your mod breaks, do the same process: Shove what's currently in root into an archived_versions folder (and it's mod_info.yaml is already correct, no need to change it!) and continue putting your latest changes in root, updating that mod_info.yaml to the latest game build.

Link to comment
Share on other sites

1 hour ago, Ipsquiggle said:

There are archive loading problems due to the vanilla game having a higher build number than SO!. We'll be pushing an SO! hotfix today, which should resolve that.

Will we need to adjust anything, or if we made updates for 469112 build yesterday there is nothing we need to do today?

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Please be aware that the content of this thread may be outdated and no longer applicable.

×
  • Create New...