[Released] uMod 2.0 - Modding support made easy!

uMod 2.8.2 and uMod 2.0 - Moddable Tanks Demo 1.1.0 have been submitted to the asset store for review. This version of uMod includes:

• Fixed a compatibility issue with newer Unity versions where building a mod tools package would fail to package any shared game assets.
• Fixed a compatibility issue with newer Unity versions where generating the shared assets database in the game project could fail when building a mod tools package.
• Fixed a compatibility issue with newer Unity versions where the build engine could fail to produce a mod containing scripts because the Compilation API used was no longer supported.
• Fixed a bug in the code security engine where attempting to security check code with debug
• Fixed a bug in the mod tools builder where shared asset previews would not be generated for some shared assets.
• Optimized load time of the content and asset sharing tabs of the mod tools builder window. The pages will now load bout 10x faster than before.
• Fixed a bug in the asset sharing window where loading time would slow exponentailly as project size increases.
• A progress dialog is now displayed on the asset sharing tab for large projects as sharable assets are scanned.
• Improved the GUI rendering of the content and asset sharing tabs of the mod tools builder window.
• GUI tree views now use culling and better logic to display an extremely large number of assets without performance issues.
• Optimized the expanding of GUI tree view nodes for better a experience with large projects.

This version of moddable tanks demo includes:

• Updated in line with Unity Tanks demo update.
• Updated minimum supported Unity version to 2020.1
• The demo now packages uMod configuration assets so that setup is as simple as can be.
• The demo now packages uMod generated database of game assets, used for the asset sharing feature. This means that users no longer have to build a mod tools package for the demo to work out of the box.
• The demo now requires uMod 2.8.2 or newer.

 

uMod version 2.8.3 has been released on the asset store. This version includes:

• Fixed a bug in the mod tools builder where the shared assets configuration assets would not be updated when building if no new shared assets were added to the build.
• Fixed a bug in the mod tools builder where the shared assets configuration assets would not be updated if all shared assets were removed, causing features like the game assets window to show missing assets and cause many issues.
• Added new event to the mod tools builder 'OnBuildToolsPostProcess' that is called after a successful mod tools package build.
• Fixed a bug in the tree view GUI of the mod tools builder wizard where the mixed check state of a folder could display incorrectly in some cases.
• Redesigned the saving and loading system for the asset sharing and content section of the mod tools builder wizard to be much more robust, and will no longer lose the saved state for moved, renamed or otherwise modified assets.
• Removed some obsolete debug features.

Spoiler: Build Tools Post Process Event Example

Code (CSharp):

1. using UMod.BuildTools;
2. using UMod.BuildTools.Build;
3. using UnityEngine;
4.  
5. [UModBuildToolsPostProcessor]
6. public class BuildToolsProcessorExample : BuildToolsPostProcessor
7. {
8.     // Methods
9.     public override void OnBuildToolsPostProcess(string outputPath)
10.     {
11.         Debug.Log("This method will be called when the build has finished");
12.     }
13. }

 

uMod version 2.8.4 has been released on the asset store. This version includes:

• Fixed a bug in the mod tools builder wizard where the project settings tab would not save selections correctly.
• Fixed a bug in the mod tools builder where the project settings would always reset to include all when building a mod tools package, partially related to the above issue.
• Add pre build event to mod tools builder to match the recently added post build event. Useful for setting some tools values before a build, such as incrementing version numbers without requiring you to use the build API manually.
• Added 'Sync' option for 'Developer Name' in the mod tools builder wizard that will sync with the 'Company Name' entered in the Unity player settings (no need for manual updates).
• Added 'Sync' option for 'Game Name' in the mod tools builder wizard that will sync with the 'Product Name' entered in the Unity player settings (no need for manual updates).
• Added 'Sync' option for 'Game Version' in the mod tools builder wizard that will sync with the 'Version' entered in the Unity player settings (no need for manual updates).

Spoiler: Build Tools Pre Process Event Example

Code (CSharp):

1. using UnityEngine;
2. using UMod.BuildTools;
3. using UMod.BuildTools.Build;
4.  
5. [UModBuildToolsPreProcessor]
6. public class BuildToolsPreProcessorExample : BuildToolsPreProcessor
7. {
8.     public override void OnBuildToolsPreProcess(BuildContext context)
9.     {
10.         Debug.Log("Build start: " + context.ToolSettings.GameName);
11.     }
12. }

 

uMod version 2.8.5 has been released on the asset store. This version includes:

• Improve the appearance of uMod editor windows when dark skin is used.
• Fixed a bug in the script serialization system where references to components attached to nested prefab instances could become null upon loading a prefab from a mod.
• Fixed a dependency loading issue where asset dependencies could be loaded in an uninitialized state due to incorrect dependency sorting.
• Fixed a rare bug where including only a scene and a lighting data asset in a mod could cause a mod build to fail due to incorrect build configuration.
• Fixed a bug where the enabling the 'Allow Older Unity Versions' option in the uMod settings window would not be carried over the the mod tools package. Attempting to use the mod tools package to build a mod in an older Unity version would result in an immediate failed build stating that you need to switch Unity versions. This is no longer the case.

 

uMod version 2.8.6 has been released on the asset store. This version includes includes a hot fix to address a deserialization bug introduced in the last update, and also:

• Added support for the FormerlySerializeAs attribute to better replicate the standard Unity serialization system.
• Fixed a bug in the script serialization where some changes added in the previous update could cause the deserializer to get stuck in an infinite loop on some very rare occasions.
• The mod tools version entered when creating a mod tools package will now be built into all mods created with 2.8.6 or newer (Backwards compatibility is still maintained).
• Added 'ModToolsVersion' to the IModInfo interface to access the mod tools version that a mod was built with. For mods created with uMod 2.8.5 or older, this property will return an empty string.
• Fixed a bug where enabling the 'Allow Older Unity Versions' option in the uMod settings would not reflect in the built mod tools package. As a result, the user would see an error when they try to build a mod asking them to switch Unity versions. This will now work as correctly.

 

Hi @scottyboy805
Is it possible to get a list of mod contents (ie:- a manifest / catalogue) without having to load the ModHost first?

I see there is..
ModAssets.HasAsset(assetName)
&
ModAssets.LoadAsset(assetName)

Do these load in the whole mod to get a single asset or do they extract without loading everything?

btw really liking UMod so far, bought it a few years ago but only just got around to using it.. wish I had sooner

 

Hi,
At the moment it is not possible to get a list of contents included in a mod without loading it. You can get the content flags via the 'IModInfo' interface without loading and that will tell you whether the mod includes assets, scenes and scripts. I guess you need more information though.
The LoadAsset call will only only load the specified asset and not all mods assets. It needs the mod host to be loaded though via 'Mod.Load' or similar which can be a slow process depending upon the size of the mod. The main reason for this is that most mods will need to be decompressed before any asset information ca be read, hence the load call is required. The metadata is packaged as part of the mod file header which is why it is so quick and easy to access. You might consider Mod.LoadAsync if you are not already aware of it. That way the loading can be done in the background without blocking the main thread.

Perhaps we could add support for accessing the asset index without needing the load the mod in the future, but I think it would require a few major changes to the way uMod works. One for the long term roadmap I would say.

Glad to hear you are enjoying using uMod
Let me know if there is anything else.

 

Thanks for the clarification, I guess it's not a game stopper as I could make a separate catalogue alongside the mod and zip up together for distribution..

Regarding the loading of the host and it's contents...
When I load the ModHost does that not load the entire contents at the same time?
Or does that simply parse the mod file to find contents. then I can extract (load) an asset from that..
as in the example from the docs .. GameObject go = host.Assets.Load("MyAsset") as GameObject;
Is that actually "Loading" an asset or is it simply converting it from already loaded byte information.

I think i'm a little confused as to whats happening under the hood.

 

I will try to clarify a bit better what happens at each loading stage. One thing to note is that uMod uses asset bundles for many types of Unity content.

When you call 'Mod.Load':

1. uMod opens the mod file or downloads/streams using a webclient for hosted mods.
2. uMod checks that the file is actual a valid mod file.
3. The mod metadata is loaded (Information available via IModInfo) and sanity checks occur like version checks and game locking.
4. Any referenced mods are loaded at this stage.
5. If the mod file is larger than the memory budget set in the mod settings, uMod will extract certain aspects of the mod file to a temp location to avoid running out of memory by loading the whole mod.
6. All asset bundles that exist in the mod are loaded either from memory or from extracted files. This is the bit that takes the most time.
7. Asset index is initialized (This is where asset meta information like name, path extension etc. is stored.
8. Assemblies are loaded and mod scripts are initialized
9. The load is completed.

When you call 'Mod.Assets.Load(...)'. The same goes for 'Mod.Scenes.Load(...)' with some slight differences:

1. uMod tries to find the asset bundle with the target asset using the asset index.
2. A load call is issued for the target asset bundle.
3. If the asset is a prefab, uMod may run its reserialized to ensure that scripts are re-linked as you would expect.
4. The loaded asset is returned through the uMod API.

I hope that helps you. You can see that quite a bit of work needs to be done to load a mod host, with most of the time being spent loading asset bundles. I believe asset bundles will only load required data and will not load assets until requested, although I don't know whether that means that the actual asset byte data will be fetched at load time or on demand. I haven't looked into them for a little while.

 

Thanks again.. I believe you are correct regarding asset bundle, but i'll look into it.
Just as clarification on what I'm trying to achieve in case you have some advice..
I have a world with each terrain being a cell, a user could create a mod that alters several cells in many ways, I don't want a mod to load in content for a cell that isn't yet loaded by the game..

I think I'll delve a little deeper into the rabbit hole.
Many thanks for the help!

 

Thanks for explaining what you are trying to do. It is an interesting use case and one that we have not considered. I guess you will want to load and unload the mods on demand according to loaded game cells, but that would really require information upfront about the cells that the mod might apply to.
I can't think of a simple way to get around that for the moment. You could create an additional accompanying file with this information I suppose, although it is not the cleanest solution. There are many build events and callback that you could use to create that file automatically when building a mod if that would be helpful. I can give examples for this if needed since the build API is mostly undocumented at the moment.

We are currently working on the next generation of uMod, and have just recently implemented a feature which might have been ideal in this case. The feature allows you to include custom metadata in a mod that is stored as part of the quick access portion of the mod file, and can be accessed without fully loading the mod. You simply create a scriptable object with data fields that you need, create a build script that fills out this data based on the mod contents, and then you can access this data at runtime without loading the mod. Unfortunately though, I don't think we will be able to back port this feature since it required major changes to the file format and structure of mods to make it work. That was only made possible since we will be dropping backwards compatibility for the current mod format as part of the major version update.

Let me know if you want to run some ideas by me to see how they could work, but I can't think of any more elegant solutions for the moment.

 

That sounds ideal actually.
The backwards compatibility probably won't be a problem as a release even for a public beta is quite a way off.
I've been implementing a custom manifest this afternoon, the plan for the time being is to have a mod for each prefab (or at least common prefabs) and cell file and keep them to a minimum until the next gen UMod looking forward to it.

If I have one request for the next UMod is that you look into being able to extract/load a single asset in a mod file with out having to load the whole thing.

Edit:-
One thing I forgot to mention is the main game assets and non infrastructure scripts will be mods themselves, don't know if that makes any difference to what your doing, thought I'd mention it.

 

For the next generation of uMod, we have already implemented lazy loading for assets and scenes with the option to preload if required. That means that asset bundles will not be loaded until the first asset load call is made, and the bundle load will be incorporated into that call. That means that you will be able to very quickly load a mod file for full access to things like the asset index and mod assemblies without the overhead of loading asset bundles at startup. It is not quite able to load a single asset only, since multiple assets may be grouped into bundles when the mod is built, but it should go a long way to improving initial load times of mods.
Another thing we have added is a full runtime reflection API for the mod file format which allows you to access every aspect of the mod like assets, scenes, assemblies, metadata and much more without actually loading the mod into a host. It is mainly intended to allow developers to inspect the contents of a mod for easier debugging, and validation that build scripts are working as intended etc.

Just to let you know that the next generation of uMod is a while off yet as it is still very early in development, and we have not even publicly announced it. Just wanted to make sure you are aware that some of these things I mentioned will not be available for quite a while.

Using mods to create the actual game content is quite a common approach we see many users taking, so we will be doing our best to make that as easy and as powerful as possible too.

 

Hi，I am looking for a mod system which has these feature:

• Create mod without UnityEditor. Users can just open a template scene via AssetBundle, import extern assets (eg: model/texture) into scene, change hierarchy as need, then save the entire scenes. The benefits of this is user don't have to learn about how to use UnityEditor, instead of dealing with tons of potential bugs, they can focus on mod creating and test them ASAP.
• Scripting at runtime (It seems the Roslyn C# reach the goal, but I am not quite sure about it)

uMod looks great, but will this plugin support these feature? Thanks!

 

Hi,
uMod 2.0 requires the Unity editor to create mods and it will stay that way for the foreseeable future. Yes, the editor has a learning curve for modders, but so will any other modding tool that you create. I get that custom modding tools can be much more focused and not have all the extra unneeded features to complicate matters, but I think the Unity editor is too powerful of a tool not to make use of it. Here are some of the main reasons we chose this approach:

• The Unity editor acts as an all purpose asset importer with support for pretty much every file format we could hope for.
• The Unity editor acts as a central asset management solution for game elements like prefabs and scenes.
• The Unity editor provides a versatile and powerful scene/asset editor with hierarchy, inspector and much more.
• Asset bundles can only be built using the Unity editor.

The method you propose would need a lot of work to implement. For starters you would need runtime asset importers for all assets you wish to support (Models, Textures, Audio, etc.) each might have many formats that you want to support too(.fbx, .gltf, .obj, .blend, etc.). After that, it sounds like you want to support scene editing for users. That is a very complex task in itself and will likely require a runtime level editor to make it possible. There are assets on the store that already do that though. Finally you will need to save and load the user created scenes/assets somehow meaning you need to create importers and exporters for supported asset types (scenes, characters, etc.). Again, there is a lot of work there when asset bundles can already do all of that for us (Apart from scripts).
With all that said, it would just be way too much work to take on to try and build that as a complete system. uMod is already a massive project and most of the work was done for us by the Unity editor and asset bundles. It still took over 6 years of continuous development to get it to where it is today.

If you do take that approach, Roslyn C# can certainly handle the runtime scripting aspect for you. I know that we have a few users who have created their own modding framework built on top of Roslyn C#, albeit with simpler json based asset files.

I hope that helps to explain why we choose the Unity editor approach. I and many others see the Unity editor as a big advantage for modding, as it is not limiting in any way like other mod tools may be. The modder can do exactly what the developers can do and they are not limited by the tools in any way.
Let me know if you have any questions or if there is anything else.

 

Really appreciate for your long reply! I actually try to make the Unity workflow run at runtime, but it seems to be a hard but thankless job. I will learn to use the uMod, thanks for support again!

 

Hi, I have try the Moddable Tanks Demo, but it show these kind of warning when I start the testing:

1.The Naming Scheme not update at the first time, but after I opened the scene 'CompleteGame', the list seems to autoupdate. Will this kind of problem happens when I release Mod Tool to user?

2.Can't detect Unity version, don't know how to fix it, please help:


3.It seems the share asset reference is missing too when I load the scene 'Canyon':

I try to follow the UserGuide.pdf#11 to regenerate its shared asset database:

but I can't find the assets mentioned above in Asset Sharing Window(The Tank.fbx seems to be moved to Assets/Models Directory, Also the "Assets/uMod 2.0 - Moddable Tanks" directory is not in the hierarchy at all):


PS:

• the Unity Editor version is 2020.3.6f1c1
• the uMod version is 2.8.6
• the uMod Example version is 1.1.0

 

Hi,
Sorry to hear you are having some issues.

1. That is normal for first use. All moddable components will register when the scene is opened for the first time. After that, you will not need to do anything else as the information will be saved.
2. Could you let me know which Unity version you are using. It looks like the Unity version could not be parsed for some reason so maybe the format has changed in newer Unity versions. It sounds like a bug and it will be fixed in the next update, but you can safely ignore it for the moment as it will not actually prevent the mod from loading.
3. It is required to regenerate the shared assets database as mentioned in the user guide. The documentation might be slightly out of date for that topic. I think you should just be able to select the prefabs folder and then generate the database. After that, the mods should relink correctly I believe. Let me know if not and I will check it.

 

1. That's good to know, Thanks!
2. The Unity Version is 2020.3.6f1c1.
3. I can's even find the 'Assets/uMod 2.0 - Moddable Tanks' folder in 'Asset Sharing' Tab, that's odd. As you can see in the following picture, there are only three root directories in the hierarchy:

 

Hi again,

1. No problem.
2. Thanks for providing the version. It looks like the extra 'c1' added onto the end of the version string was causing the version parsing to fail. This has now been fixed and will be included in the next update.
3. I looked into this and it seems you are quite right. The 'uMod 2.0 - Moddable Tanks' folder does not show under the asset sharing section when using a newer uMod version. The problem seems to be that the 'UMod' folder should not be displayed in that section, but there is a logic error that causes other folders that include the 'uMod' name to also be excluded. It is a bug on our end that will need to be fixed, but I did find a quick and easy workaround for this problem so that you don't have to wait. You can simply rename the 'uMod 2.0 - Moddable Tanks' folder slightly. I inserted an '_' at the start of the name so that I ended up with '_uMod 2.0 - Moddable Tanks' and the folder will now be displayed in that section. I hope that helps you. This problem will also be fixed in the next update and thanks for reporting it. Hopefully you will be able to continue with the demo to get the mods working now, but let me know if you are still having issues.

Let me know if there is anything else.

 

Sorry to bother, but when I build the mod with script, it will throw an error about UnityVersion format error, maybe it's the same problems with the extra 'c1', hope it helps.

 

Hi again,
It does indeed look like the same problem. I didn't realize it was causing errors at build time resulting in a failed build, so it seems the update needs to be ready asap to address this. I will hopefully submit the update tomorrow if all goes well and then it should be live on the store within a day or two. Feel free to send an email to info(at)trivialinteractive.co.uk with your invoice number and I can send you the update direct as soon as it is ready to save any waiting.

 

uMod 2.8.7 has been released on the asset store. This version includes:

• Fix a warning in newer Unity versions when loading a mod caused by different version formatting being used for some Unity versions.
• Fix an error when building a mod in some Unity versions with different version formatting. Only mods containing scripts were affected by this issue and only a very small number of Unity versions cause the issue.
• Fix a bug where some demo folders would not be displayed in the asset sharing section when they should be. Caused by some folders names using the 'uMod' name at the start of the path.

 

uMod 2.8.8 has been released on the asset store. This version includes many bug fixes and a new experimental feature:

• Fix a bug in the mod tools builder where selecting the root 'Assets' folder in the content section of the build tools wizards could cause an exception to be thrown while building a mod tools package.
• Fix a bug where shared asset configuration data from a previous build could remain in config assets causing bloat and unexpected behavior in some cases.
• Fix a submission error where the uMod package was previously uploaded with configuration data relating to test cases (Related to above issue).
• Fix a bug where shared assets data could remain from a previous build causing issues with the game assets window in some cases.
• Fix an issue where uMod is unable to create assets in the mod project when the mod tools package is setup as a UPM package. Attempting to create assets inside folder '<project>/Packages' is not possible.
• Fix a bug in the mod export settings window where creating a new export profile and then triggering a script reload or editor restart would cause that new profile to not be saved.
• Fix a bug in the mod export settings window where settings like 'ModName' and 'ModVersion' could be lost if changes are made and then a script reload or editor restart is triggered (Related to above issue).
• Fix a UI scaling issue in the uMod security window when the Windows display scaling settings are changed from the default '100%'. Scrollbars will now appear when needed to allow the full content of the window to be viewed where previously some items would be cutoff.
• Add experimental feature: Support for exporting mod tools as a UPM/Raw folder structure for use as github package for example. This feature is currently in development and will require extra steps by the user to create a valid UPM structure like adding manifest.

 

uMod 2.8.9 has been released on the asset store. This version includes:

• Fixed a bug in the mod tools builder wizard where exporting a mod tools package can cause a GUI layout exception in some cases.
• Fixed a bug on Mac OS where attempting to export a mod could cause the build to fail with an IO exception related to rooted paths.
• Updated documentation examples.

 

uMod 2.8.9b has been released on the asset store. This version includes some hot fixes for the following issues:

• Fix a bug where paths could be incorrectly formatted on Linux and Mac OS when attempting to build a mod causing IO exceptions and a failed build.
• Fix an issue where one or more errors could be reported when importing the uMod package into a project due to one or more missing uMod assets since they have not yet been registered with the asset database.

 

Hi! I find a funny thing about Unity event serialization. I have two UnityEvent (BoolEvent and Vector3Event). As you mention before, only BoolEvent will be serialized. But when I built the mod, I found out that both UnityEvent work well, and I can see Vector3Event on Inspector, does that means UMod can serialize any UnityEvent apart from (int, float, bool, string) now? If so, that will be a great news because I can offer full customization for user!

Here's the Inspector view when I am building the Mod:




And here's what I see when the Mod is loaded:

 

Hi,
I believe the update you reference added support for serializing Unity event types with zero or one arguments, as long as the type is primitive or serializable by Unity (Vector3, Color, for example). So yes, your UnityEvent for vector3 type should work just fine, but also the bool event should function correctly too. Does the event get called at all even though there are no persistent listeners displayed in the inspector (From out experience, the inspector window will not display listeners that were added at runtime which is what uMod does when deserializing)? If not, then it looks like a bug or maybe something else going on as it should work as expected for both of your event types.

 

Both the BoolEvent and Vector3Event works fine, but the Vector3Event's persistent listeners still displayed in the inspector, which was strange (I took screen shots on my #277, please checkout)

 

Yes, it is a little strange but in some limited cases uMod can make use of the default Unity serialization which could be the case here and would cause the persistent event listeners to be displayed correctly in the inspector. That is the only reason I can think of at the moment anyway but I guess the main thing is that the events are working as expected.

 

uMod 2.9.0 has been released on the asset store. This version includes:

• Upgrade to Unity 2019.4 as minimum supported version.
• Redesign script serializer for prefab assets.
• Fix a bug where event listeners on prefab instances still target the prefab object instead of the clone.
• Fix a bug where Unity events on prefab script components could not be linked correctly at build time causing problems at runtime.
• Fix a potential stack overflow during deserializtion of prefab component fields if cyclic dependencies 3 layers deep or more are serialized.
• Fix a bug where plain serialized classes (Non-Unity objects) would not have their serialized values copied from the source prefab correctly when instantiating a prefab instance (Values reset to script initialize values).
• Fix deserialization order issue for prefab instances where some script events such as 'Start' could execute before deserialization had run.
• Maintain backwards compatibility with mods created by older versions despite new prefab serializer.
• Fix a build issue where the prefab serializer could crash on some occasions due to using incorrect serialized types.
• Fix an issues where serialized data for a specific script component could be deleted after first deserialize call meaning that instantiating the object would cause script values to be set to defaults.

 

uMod 2.9.1 has been released on the asset store. This version includes the following fixes:

• Fix a bug where attempting to load the same mod from different source locations could cause an asset bundle load error. Now the already loaded mod will be returned if the mod internal name is identical.
• Fix a bug where the 'OnModUpdate' event could be called on prefab assets leading to confusing behavior.

 

There is an option in the mod Tools builder，allow scenes in mods ，When I turn it off ， Scenes in mod will still be loaded . Is that right？And if In the game, I installed a script on a GameObject. The script has a move method. I created a new script in mod to rewrite this method. Can umod automatically identify and replace it? If not, how can I make mod modify some logic without changing the main body?

 

Hi, Thanks for getting in touch.
The 'Allow Scenes In Mods' option applies to the mod tool package only and any mods built with that package. If you disable that option then you will need to rebuild your mod tools package and then rebuild any mods in order to have that option take effect, since it is a build option that is used when exporting the mod. That way, any scene assets located inside the mod export folder will be ignored and won't be built into the mod.
Alternatively you can disable the 'Auto Load Mod Scene' option in the uMod settings and ignore any scene content that is included in the mods. In that case, uMod will load the mod but will not load the default mod scene automatically so you can just use the assets and scripts in the mod only.

For the scripting question, there is no built in way to replace a mod script automatically at the moment. You could do that manually if needed when the mod is loaded, although I think you would not be able to retain the serialized fields that could be set via the inspector from the mod. I can give you an example of that if required.
Instead though, I would recommend a slightly different approach to provide new behaviours which is much more robust and the intended way to change game behaviour:

1. Create an interface assembly that will contain any common code shared by the game and the mod projects as described in the user guide.
2. Create your type in the interface assembly as a virtual or abstract class, for example with a virtual 'Rotate' method with no implementation.
3. Your modders will then be able to create derived classes in their mods which will implement this Rotate method and rotate the transform of a game object for example, or any other behaviour that they might like.
4. Once the modder has created their derived class, they can attach it to a prefab asset for example.
5. In the game project you will be able to access the mod behaviour via it's base type (Using GetComponent<MyBaseRotator>() for example) and then you can directly call the Rotate method from your game if needed.
6. That is all. This approach will allow mods to extend or implement game behaviours and will fully support serialized fields like you would expect.

I hope that helps you. I know the scripting part can get a little complex in some cases, and often the implementation will vary based on the game you are making and how you would like the modding process to work. Let me know if anything is unclear or if there is anything else and I will be happy to help you.

 

thank you.Script related issues resolved. When I turn the allow scenes in mods off ，and auto load default scene is on. It will also load the scenes in mod. Looks like allow scenes in mods doesn't work.And I have also rewritten and packaged the mod tool

 

Hi again,
Glad to hear that the scripting issues are now resolved.
I have looked into the asset options issue that you mention and I was also able to observe that the 'Allow Scenes In Mods' issue was having no effect when building the mod. After some investigation it looks like it is indeed a bug that was introduced a few versions ago. The problem has now been fixed and will be available in update 2.9.2 which should be coming within a few days if all goes well. If you are in desperate need of the fix then feel free to submit a support request on our website including your invoice number, or contact me through discord again with your invoice number and I can send you the update direct.
Thanks for reporting the issue and let me know if there is anything else.

 

Another question is how do I get this variable called ‘Modding Content Folder’ It is located in mod tool builder->content

 

Do you mean to get the variable through an editor script? If so, you can use the following code to access the modding content folder that is specified in the content section (It is important that the script is an editor script):

Code (CSharp):

1. // using UMod.ModTools.Wizard;
2. // using UMod.Shared;
3.  
4. // Load the settings asset
5. WizardIncludeContent includeContent = WizardIncludeContent.Active.Load();
6.  
7. if(includeContent != null)
8. {
9.     // This variable contains the modding content path specified in the mod tools builder wizard
10.     Debug.Log("Mod Content Folder = " + includeContent.modContentRoot;
11. }
12. else
13. {
14.     // User has not used the mod tools builder yet
15. }
16.  

Hope I have understood correctly.

 

Thanks. This method can get this variable in the game, but I can't get it in mod. I want to read the CSV file generated by the game in mod, so that mod makers can more easily wait until they need to replace or add something

 

Ok, I think I understand better now, thanks for clarifying.
In that case, I think you will only be able to do that manually since the mod tools builder will not be able to access the moddable content csv file. You should be able to follow these steps to achieve your goal of having the csv file as part of your mod tools package:

1. Export your mod tools package as you normally would to create a .unitypackage file
2. Create a new Unity project using the same version as your game project.
3. Import the mod tools package into your newly created Unity project.
4. Switch back to your game project and generate and export the csv file
5. Switch back to your new Unity project and import the csv file into the Assets folder or any subfolder of your choice.
6. In the project window, select all files and folders under the Assets folder including the csv file and the right click and select 'Export Package'.
7. Choose a location to save the new .unitypackage and the result will be your new mod tools package including the csv file.

It might be possible to automate this process if required by saving the csv file inside your game Unity project and adding it to the mod tools package via the 'Content' section of the mod tools builder. Let me know if you would like to try that option and I can perhaps give some more pointers to help achieve that.

 

There may be a misunderstanding in your understanding. What you said is right. My problem is that I can't guarantee that the path of my mod toolkit is the same in every project, but I want to read a file in the toolkit in mod. So I want to know how the mod toolkit creates the path of the file. I just need to access this folder path in the mod toolkit. I have expanded some functions, Because I feel that the current mod production is friendly to developers, but not friendly to players. I generate a mod file but it is empty. For players, they do not know which resources developers allowmodify or add in the game. Back to the topic, how can I access the file path of mod toolkit in the code? In the game project, I can use wizardincludecontent Active. Load(). Modcontentroot, but how to get it in the mod toolkit?

 

Hi again,
Sorry for the confusion, I believe I understand what you need now.
Unfortunately there is no easy way to get that modContentRoot path in a mod project because uMod does not store that path anywhere outside of the game project since it does not need access to that folder any more. I think you could possible solve this with a workaround by creating a dummy scriptable object asset that you include as part of the mod tools package via the content section. Then from an editor script inside the mod project you could use the asset database to find this asset, then get the asset path, and then get the parent folder to work out where the modding content is located. It is not an ideal solution and requires a little bit of work, but I think it is possibly the only option for the moment.
So for example you would create a dummy scriptable object script in your game project like below, then create an asset from it, and then add it to your mod tools package via the 'Content -> Include Content' section of the mod tools builder:

Code (CSharp):

1. [Serializable]
2. [CreateAssetMenu]
3. public class DummyScript : ScriptableObject{}

Then from a mod tools editor script, you could use the following code to find that particular asset and then work out the path from that:

Code (CSharp):

1.  
2. // Find the asset in mod project
3. string[] guids = AssetDatabase.Find("t:DummyScript");
4.  
5. // Get path of asset
6. string assetPath = AssetDatabase.GUIDToAssetPath(guids[0]);
7.  
8. // Work out the directory path which will be the same as modContentRoot
9. string modContentRoot = new FileInfo(assetPath).Directory.FullName;
10.  
11. // Convert to directory path that Unity asset database can work with (Relative to project)
12. string modContentRelative = FileUtil.GetProjectRelativePath(modContentRoot.Replace("\\", "/"));

If it is something that could work for you then I can give a more detailed example if needed, but for the moment I think this will be the easiest way to get that path even if the modder has moved that folder.

 

似乎没有更方便的方法。我将尝试

 

Hi, after the modder exported a mod, I want to read the mod's [IModInfo], but it seems tha only the following dll are exported to SDK:


Without umod.dll, how can I read [IModInfo] without using ModDirectory.GetMod method? Thanks!

 

Hi, At the moment it is not possible to do that from the mod project for any given mod, but it is possible to get the IModInfo during a post build event if that will be useful to you. For example, when the user builds a mod, you can create an editor script that will be invoked upon a successful build and can provide the IModInfo metadata for the mod. This will only be available immediately after a build though. If that could be useful to you, then here is a quick example script to show you how to access that:

Code (CSharp):

1. using UMod;
2. using UMod.BuildEngine;
3. using UMod.BuildEngine.Build;
4.  
5. // Script placed inside 'Editor' folder
6. [UModBuildEnginePostProcessor]
7. class AfterBuild : BuildEnginePostProcessor
8. {
9.     // Called after build has run
10.     public override void OnBuildEnginePostProcess(ModBuildResult result)
11.     {
12.         IModInfo meta = result.BuiltMod;
13.  
14.         Debug.Log("Mod: " + meta.NameInfo);
15.     }
16. }

Hope that helps you. Let me know if there is anything else.

 

uMod 2.9.2 has been release on the asset store and includes the following changes an bug fixes:

• Update minimum supported version to 2019.4 LTS.
• Fix a bug where asset includion options specified in the mod tools builder would not be taken intou account when building a mod.
• Fix an issue where some ModScriptBehaviour callbacks did not run in some cases.
• Greatly improve loading time of the 'Content' section of the mod tools builder wizard in large projects.
• Greatly improve rendering and UI response performance of 'Content' section tree views.
• Fix a buf where 'Content' selection trees could list the same asset multiple times in some cases causing toggle selection to not work as expected.
• Minor bug fixes.

 

uMod 2.9.3 has been released on the asset store and includes the following bug fixes:

• Fix a bug where UnityEvents would not be serialized correctly in some cases if they target a method accepting parameters that do not match the event arguments.
• Minor bug fixes.

 

uMod 2.9.4 has been released on the asset store. This version includes the following bug fixes:

• Fix an issue where mod scripts could become missing for DontDestroyOnLoad objects when a mod is unloaded.
• Fix a bug where DontDestroyOnLoad objects could remain active when a mod is unloaded and `CleanupModObjects` is enabled.
• Minor bug fixes.

 

What is the difference between UMod and Rosyln Compilers and dynamic c#? Are they all the same ? Is one version the latest ? Do they do different things? Looking to add mods, not sure what to get. I guessing UMod 2 has everything? Cheers!