[Released] uMod 2.0 - Modding support made easy!

Hello,
I have question regarding umod 2.0 Why to restrict 'System.IO' and 'System.Reflection'? How do you blacklist certain script from being modded? Will it work on multiplayer?

 

The blacklisting is just used as an added security measure. It is not a good idea to allow code from unknown origins to have full access to the file system which is why we prevent code that references System.IO by default. Also System.Reflection can be used to access your game code and load external assemblies which may also be undesirable. You are able to fully configure the restricted namespaces and references in the uMod settings window if you want to change or add to these default restrictions.

I assume you mean that you don't want some of your game scripts to be used by modders? No trouble there. Mods do not have access to your games code by default and we recommend that any game code you want to expose to the modder should be compiled into an intermediate assembly that your game will use and that you can provide to your modders to receive game events and data.

Yes there should be no issue with supporting multiplayer so long as all the clients are synced correctly and have the same mods loaded.

 

Can it be applied to already finished product easly? Is it plug & play, whitelist files and done or does it need some rewriting of existing project?

 

You can add it to an existing project but you will only get basic support out of the box such as being able to load assets and scenes and running standalone scripts. You will still need to implement the code that determines which mod assets and scenes to load which will vary from game to game.

If you plan on adding mod script support for your game then I would highly recommend that you start adding mod support into the game as early as possible because you will need to establish how game scripts communicate with mod scripts and the interface you want to export to your modders (if any) and adding that into a finished game may require a fair amount of redesigning. This not only goes for uMod. I would recommend the same if you used another approach to adding mod support.

 

Version 2.1.9 has been submitted to the asset store for review. This version includes:

• Fixed a memory leak where multiple load and unload cycles would cause memory to increase and never be released.
• Fixed a bug in ModDirectory where the HasMods property would return an inverted value.
• Fixed a bug that caused finding mod scenes by name to fail.
• Fixed a bug that caused finding mod assets by name to fail.
• Added a priority value to the UModBuildProcessorAttribute which allows you to indicate when custom export processors should be called.
• Added new events during the export process which are called before and after all asset processors have run (BuildProcessor.beforeRunProcessors and BuildProcessor.afterRunProcessors)

We have also added a redesigned ModDirectory class which is currently in beta. This new version has more features and allows for any number of mod directories. It will be included as standard in a future version but for now you can use it via the UMod.Experimental namespace.

 

Is uMod 2.0 better than ModTool or [moddable]?

 

Yes ...although I may be a bit biased.

On a serious note though: I have not had first hand use with either so it would be difficult to compare them but from the documentation it looks like [moddable] is mostly for script modding using a js variant where uMod 2.0 allows for asset modding such as textures, materials, shaders, prefabs and more as well as scenes. It also allows the modder to write C# code which is compiled and will run as fast as your game code.

ModTool on the other hand looks more like a comparative asset but I think that uMod has experience in its favor because it has existed in one form or another since the start of 2015 which has taught us a lot and helped to improve the asset. I would also suggest that uMod 2.0 allows you as the developer far more control if necessary with every aspect of the modding process being exposed via the uMod API. This allows you to build higher level game API's that your modder can use in much the same way that Cities Skylines does.

I hope this is somewhat helpful.

 

Hello, I recently bought this asset and now I have a few questions:

I read on the other forum that it's possible to write a custom exporter. Could you please point me in the right direction to get started with this, as I can't seem to find anything in the docs regarding custom exporters, only the built-in exporter. Should I be looking into the BuildEngine classes?

Also in the other forum, regarding prefab nodes and their lack of visual representation, you mentioned "a custom mod tools builder that allows developers to put together a mod tools package specific to the game" to be implemented at a later date. Correct me if I'm wrong, but I could do something like this now by providing modders a Unity project with dummy prefabs that look like the the prefab they will turn into?

Thank you very much!

 

Hi,
Yes it is possible to create a custom exporter using all your own editor gui and simply use the UMod.BuildEngine API to export your mods. There is no written documentation for this because we plan to include a tool in the future which will generate a custom mod tools package using a wizard but you can check out the scripting reference here.

You can also modify the existing exporter package as much as you want to include custom content such as editor tools for you modders to use, assets from you game that modders can use to create scenes and anything else you need. You can modify the package by importing it from the asset store and simply exporting a new package with all the required content included.

your modders can also place prefab nodes in scenes which will be replaced with the target game asset when loaded. By default prefab nodes are just displayed as a magenta cube but you can easily create custom prefab nodes that resemble the prefabs they will replace using the PrefabNode script. (One of the main problems with prefab nodes is that they don't have any visual resemblance to the actual game assets (which is fine for things like player start points but not for visual scene elements) but providing dummy assets will be much more intuitive for the modder so that would be a very good idea.

 

Version 2.2.0 has been submitted to the asset store for review. This version includes:

• Fixed a bug where mod scene objects that accessed other objects scripts would get a null reference instead of a script reference.
• Fixed a bug where script linking would sometimes fail for prefab instances.
• Fixed a bug where prefab instances would have 2 mod identity components when loaded.
• A few other bug fixes.

 

Hello, Scotty

I was taking a look at the product roadmap for the Current 2.2.x version and I want to ask if you could elaborate more on the "Build Engine: Support for building in memory" section. Also I will love to see the "Mod: Sandboxed Unity API" integrated too.

 

The build in memory support will allow you to access all uMod generated content via the build engine API instead of just invoking the build engine and letting it create all the content automatically. Essentially it means that the mod files will not be written to the file system as part of the build process and instead you will have full control over where and when the files are written so you can implement custom build processors to work on the build result.

Thanks for the interest in the sandbox API. It would be a big task to implement many of the basic features of the Unity API especially since it is always evolving but we may be able to work on implementing some of the core functionality that you would expect to see such as gameobjects and components. What sort of things would you need access to just so we can get a general idea of the scale of the API. it may be possible for us to create a tool that generates the API since it will just essentially be a wrapper of the Unity Engine with some security code added.

I should also mention that the roadmap is overdue an update and some items have been removed, changed or brought forward. I will try and update it when possible.

 

So we could load a content from a mod without loading the entire mod or am I misunderstanding that?

As for the sandbox API, probably it will be nice if it was like settings based so that we could select what we want to protect. I can see that we could have different modding based on the actual game. Is hard to know right now, probably we could have a better idea once the game is out and we have a modding community so that we could see what information we shouldn't allow for modification.

Looking forward to the roadmap update.

 

The initial plan for the build in memory support is to allow you to examine the contents of the mod after it has been built and run any custom post processing code. We will add support for loading the contents at a later date but initially it will just be for listing the included contents.

For the sandbox API we will probably look into creating a tool that generates the API based upon a UnityEngine.dll which you can specify. This should ensure that it will work with all supported versions of the engine and keep up to date with the latest releases. We will of course allow you to choose that parts of the Unity engine that you want to allow access to for your modders.

 

uMod 2.2.1 has been submitted to the asset store for review. This version includes:

Note: This version contains some breaking changes.

• Added new feature: Mod viewer window
• Added new feature: Runtime C# Compiler
• Added support for mods to save and load configuration data via 'UMod.IModPersistentData'. This exposes a similar interface as Player Prefs so modders can save and load simple values.
• Update UI for editor windows and tools.
• Added replacement 'ModDirectory'. Original has been moved inot namespace 'UMod.Legacy' and will be removed in a future update.
• A number of small bug fixes.

Mod Viewer Window
The mod viewer window allows you to quickly and easily see the contents of any loaded or installed mod. You can also load assets and mod scenes via this window for quick testing.



Runtime C# Compiler
This version adds a new optional package to uMod 2.0 that allows compilation of C# scripts at runtime using a modified version of the mcs compiler. The compiler can be installed from the uMod packages window at 'Tools -> uMod 2.0 -> Packages'. Once installed you will be able to compile and load C# scripts using a 'ScriptDomain' reference. See the Script Reference for API details. Automatic compilation of scripts inside the mod folder will be added in a future update.

 

Hi,

I am considering buying this plugin for our project, but I am a little wary because of the outdated website and documentation. Particularly it was not reassuring to see "To be added" in the section about security settings.

How up-to-date would you say the current online documentation is? Are you shipping a more updated version with the asset store distribution?

 

Hi,
Thanks for your interest in our asset. The website is indeed outdated but all of the relevant documentation such as the user guides and the scripting reference is fully up to date. This also includes an offline user guide which is packaged with the asset. You will be pleased to hear that the security settings have been added in a previous version along with a number of other features.
We will however look into updating the website as soon as possible to reflect the current features of uMod 2.0.

 

How can I communicate with gameobject component when I act as a modder?

 

Hi,
You can use the whole Unity API as you would normally if you know which game object you want to access. If you need to access specific game system objects from a mod like a player controller or pickups or something along that line then we encourage the developer to create an interface assembly as described in the documentation here. This is essentially a portion of game code that is shared between your game and your modders and you can add game specific code for accessing your games objects into this assembly. Your modders will then be able to use this interface assembly to find specific game elements or access shared game code to communicate. As I mentioned you can use the whole Unity API from a mod (unless the developer prevents access) so you can also use 'GameObject.Find' or similar however we would not recommend this approach.

Let me know if you need more information or if anything is unclear.

 

Thanks for your quick reply!

Now I understand that in order to make mod script communicate with the game code, I need to define some shared interface both for the game maker and modder.

I'm wondering how could uMod load the mod script at runtime, I think you use dynamic compilation or such thing. But we know that at the iOS platform, we can't use this method, because of iOS only support AOT. So can I use uMod at the iOS platform?

Note that I have no plan for adding mod support for an iOS game, I just wondering .

 

uMod can compile scripts at edit time which then means that you can add mod behavior scripts to game objects prior to export and they will be loaded correctly by uMod at runtime. This is all handled by the uMod exporter tool which is used to build the mods and it will compile all scripts in your export folder during the mod build process.

We do also include a runtime C# compile based on the MCS compiler which can load C# source files and compile them in game. This compiler is distributed as an additional package and can be installed along with the core uMod package.

Unfortunately we only support windows, mac and linux platforms as we assumed that these would be the platforms most used for modding games.

 

Thanks!

 

uMod 2.2.2 has been submitted to the asset store and should be available for download within a couple of days. This is a small update and includes:

• Fixed a bug where reloading a previously loaded mod would cause mod scripts to remain un-activated meaning that they never run.
• Fixed a bug where the ModDirectory would not list some mods if they were created with a previous version of the exporter.
• A few other minor bug fixes

 

uMod Exporter 2.2.2b has been submitted to the asset store for review. This is a small update but adds full support for .Net 4.6. Mods can now be compiled targeting the .Net 4.6 framework and will be loaded successfully by the uMod run-time. There are a few things to consider:

• The target framework version used by mods is set via the player settings as normal. The exporter will detect this setting while building the mod.
• Mods can only target 4.x if the target game is using the same version or higher.
• Games using uMod running under 4.x can load mods that target older frameworks.

 

@scottyboy805 I'm having an error when I try to use this with my new project on 2018.3.1.f1 I narrowed it down to this asset. Is there any solution for this? Here's the list of my imported packages:

• Addressables System
  
• Burst
• Entities
• Jobs
• Mathematics
• ProBuilder
• TextMesh Pro

 

Hi,
It looks like this error is caused by multiple versions of Mono.Cecil being present. uMod includes its own version of Mono.Cecil for compatibility on older versions of Unity but you should be able to delete it to get rid of that error. You can find it located at 'Assets/UMod/Plugin/Mono.Cecil.dll'.

Let me know if that does not fix the issue.

 

That allows it to import, but now I keep getting this error.

Then when importing the exporter (wanted to test if the default example work) it breaks all my assembly references and I get errors from a bunch of my scripts because of it where it fails to find UnityEngine namespace and such.

 

Thanks for the information. That looks like a fairly fatal error so I will have to look into it and get back to you when I have anything to report. We tested on 2018.3.0 a few weeks ago and everything was working perfectly so it may be specific to this revision of Unity or a project specific error. One thing you could try is re-downloading from the asset store in case of corruption or similar but I doubt that it will be that simple.

 

Yeah, that was my first thing to try and it didn't change anything unfortunately. I'll try to see if it's replicable on an empty project using the packages noted above. And forgot to say, it's happening on 2018.3.1f1

 

Hi again,
I managed to recreate this error in 2018.3.1f1 using the packages you mentioned. It looks like this is still related to the Mono.Cecil problem and for some reason the Mono.Cecil that unity is loading automatically does not seem to play nice with uMod and causes uMod.dll to fail to load some of its types resulting in the error you reported.
I was able to get around this by re-importing the Mono.Cecil assembly that is included in the uMod package and then changing its properties so that it is not loaded in editor:

Spoiler: Mono.Cecil import settings

After this I was able to run the example scene and load a mod successfully however this can only be a temporary fix as it will cause builds to fail. I just thought you could try this temporarily until we have a better solution.

 

Perfect, that seems to allow me to use it. I'll keep an eye on the thread for any final solution. Thanks

 

We now have a proper solution in place to fix this issue. We are waiting to hear back from another customer about a separate issue before we publish the update but in the meantime you can send us an email at info(at)trivialinteractive.co.uk and we can send you the update direct.

 

uMod 2.3.0 has been submitted to the asset store for review. It should hopefully be available within the next couple of days although the asset store team are having some issue so it may be longer. This version includes major changes to the code security system:

• Removed Mono.Cecil dependency for better compatibility with 2018.x versions of Unity.
• The code security system can now track every illegal assembly reference, namespace usage or type reference and every single occurrence within the code base. This means your modders no longer have to guess which code is failing security checks.
• You can now mark illegal namespaces using wild cards to also exclude child namespaces. For example: 'System.IO.*' will also make 'System.IO.Compression' and other nested namespaces illegal.
• It is now possible to mark specific types as illegal. UI interface and API's for this will follow in the next update
• Mod scripts located in assemblies that have failed verification will now fail to load with a helpful error message rather than a generic type not found error.
• Fixed a bug where mods would fail to build when running the exporter on the Unity linux editor.
• A few other small bug fixes.

We will also be looking to shift code security steps to the export process so that the code is verified while building the mod in order to reduce mod load times slightly. This will be implemented in a future update.

Spoiler: uMod Code Security Verification Report

 

uMod 2.3.1 has been submitted to the asset store for review. This version includes:

• Fixed an exporter bug where mods containing only scene assets will fail to export
• Removed Mono.Cecil dependency from the build engine
• Fixed a package submission issue where a development folder was included in the previous update which may cause errors on import

 

uMod 2.3.2 has been submitted to the asset store for review. This version includes:

• Major improvements to serialization system
• Object dependencies will now be relinked prior to relinking the target object. Previously you were able to access an un-linked prefab object so when calling GetComponent the scripts components added prior to export will not be available but this is not the case anymore.
• public / serializable fields that reference a script component will now be handled correctly. This includes script references that exist on a prefab object and circular component references are also supported.
• Unity events can now be serialized
• Included .mdb files in uMod main asset so users can provide better error reports when reporting bugs.

Unity event serialization has a couple of limitations:

1. Only events with one or zero generic arguments are supported (UnityEvent<T> or UnityEvent) and they must be overridden so that the declared type is non-generic as per Unity documentation.
2. Only the following types are supported as a generic argument: System.Int32, System.Single, System.Boolean, System.String.
3. Argument values specified via the UnityEvent inspector will not be passed to the listeners. Instead the default value for the type will be used. Unfortunately Unity does not provide an API to access this inspector value so we cannot support this.
4. Event listeners will appear empty at runtime if you view the event inspector but the events will still be hooked up and will be called correctly. This is standard Unity behavior since we relink the event listeners via code.

 

I'm really intrigued by this asset and thinking of buying it, but I can't really get my head around how everything will be implemented. Would it be possible for you to create an tutorial not showing how to create a mod, but the developers side? Maybe something like your basic level example, where you create those assets and libraries modders will use later to change the bullets from a sphere to a cube object, for example?

This way it would be way easier to understand what I as a developer have to put in to my classes in order to load mods, but also to extend methods in a class, how these interfaces look like that modders will be using, how I export or generate the placeholders for modders, and so on.

 

Hi,
We should be hopefully creating an example project based on one of the Unity demo games that will show how to add modding support to an existing game but before we start on this we are working on a major breaking update so we want to finish that before we start on documentation and examples otherwise we would need to rewrite them.

In terms of how to approach the coding aspect as a developer you will generally want to create some form of interface assembly which is just an assembly that both your game and modders will use where you define any classes or interfaces that you would like your modders to use. The documentation covers it in a bit more detail although much of the design and choices will depend upon your game.

 

Hello, we would use UMod for both modding and in our internal asset pipeline. For this we need to add UMod to our build pipeline. Would it be possible to expose the calls to list available mods in the project and to build them one by one from editor script?

 

Hi,
Yes this is possible although we are currently working on a major update to make this much easier. At the moment the build API is public but is only documented via xml code comments and may not be as easy to understand as we would like. You can invoke the build engine and access any build profiles created via the export settings window in code.

If you download the uMod 2.0 exporter from the asset store you will be able to access these API's so you can see if it suits your needs before buying the main uMod asset. You will want to look into the 'UMod.BuildEngine' and 'UMod.Exporter' namespaces.

I hope this helps you. let me know if you need any help using these API's.

 

Hi, looking to buy this. I have an online 2D game and I want to support custom skins/sounds online. When a player joins another player's match, I want host and client players to download each other's new sprite sheets and audio, so everyone can see each other's custom skins when playing online. So I only want modders to be able to add sprite sheets and audio clips. Any issues with this? It looks like you can include the .meta files based on your patch notes, but just wanted to make sure that modders can export texture2D's with their .meta files so that the sprite sheet data is included.

 

Hi,
Yes this is all possible. If you want all other players to see the skins then you will need to either send the mod containing the skins to all other players or send a network message to other clients to download the mod from some location. If you intend to send the mod then you will need to send the entire mod folder that the uMod exporter generates, probably zipped up into a single archive for convenience. This will be easier after the next update as we are moving towards a single mod file format.

Texture 2Ds and all other Unity texture types are supported so no issues there. Once the mod is built though the meta files are no longer used as they are editor only but you should still be able to use 'UMod.ModHost.SharedAssets.LoadWithSubAssets' to access the individual sprites for the sprite sheet.

 

Thanks!

 

Hi, great asset. I'm just implemented on my game, and all is good so far.

I got a question about ScriptAssembly.FindAllSubtypesOf the documentation says that it return all the objetcs that inherit from a type, in my case an Interface. All is good. I made a simple mod with a class that implement my Interface, and recibe some events, then load the mod on the game and technically the ScriptAssembly.FindAllSubtypesOf should return an array with one item: the script that implement the Interface, but its actually returning to items, the script that implement the Interface and the Interface itself, is this the expected result?

 

Hi,
Yes this is the expected result of that method as it is essentially using IsAssignableFrom on all types in the assembly. We could probably change the behaviour so that the type passed to the method is skipped. Would this be more intuitive do you think?

 

Yes, Don't worry about it, the thing was that I put the Plugin folder with the interface, inside the Mod folder so the build was adding the Interface to the mod package. Once I move the Plugin folder to the root of my project. All is working a it should.

My next question, Is there a way to prevent the ModAssets property of a ModScript class from turning null when an scene change? This I what I doing

Code (CSharp):

1. public class DemoModClass: ModScript, GameInterfaceEvents {
2.  
3.     private GameObject sphere = null;
4.     private float scale = 0f;
5.  
6.     public override void OnModLoaded()
7.     {
8.         //This work at it should
9.         Debug.Log("Mod Loaded");
10.         Debug.Log(ModAssets.AssetCount); // This return 3 that is exactly the numer of assets that are in the mod
11.     }
12.  
13.     public override void OnModUnload() {      
14.         //This also work
15.         Debug.Log("Mod Unloaded");
16.     }
17.  
18.     // This event is called from the game using http://umod.trivialinteractive.co.uk/Documentation/Developer/#Interface%20Communication
19.     public void OnSceneLoad()
20.     {
21.         Debug.Log("Event Called"); // This work correctly
22.         // Next line show error because now ModAssets is null
23.         sphere = ModAssets.Instantiate<GameObject>("Sphere");
24.         sphere.transform.localScale = new Vector3(scale, scale, scale);          
25.     }
26. }

Now, I'm loading the mod on the first scene, and the way uMod works once a mod is loaded is remain loaded for all the scenes, I know because calling IsModLoaded and IsModActivated on the ModHost after the scene is changed return true., but I don't know why the ModAssets properties became null when the scene change

 

Yes it is best to make sure that the interface assembly does not get included in mod builds but can still be referenced by them by existing in the projects so I can see how that would have caused a problem.

There is a known issue with the 'ModScript' class. Basically it is a monobehaviour class but is treated specially by uMod because it also implements the 'IMod' interface which provides all the mod load and update events. The problem comes when that behaviour component gets destroyed for whatever reason (a scene change in your case) but the reference to the behaviour is still maintained by uMod so if you broadcast any messages to the mod or invoke the behaviour using a ScriptProxy then it will call the method on what is essentially an invalid mono behaviour. We should hopefully be fixing this in the next update but for now you should be able to mark the script as 'DontDestroyOnLoad' and that should cause it to survive scene changes and keep the 'ModAssets' reference alive.

 

Just a quick question: How well does this play with IL2CPP? I'd imagine that this might be tricky but maybe we're lucky ;-)

 

Unfortunately IL2CPP is not supported at the moment due to build errors. We will look into this further after version 2.4 is released but I cannot say for sure if we will be able to get it working.

 

Hi, How I can prevent from the scenes on the mod to load when the mod is loaded? If I had a mod that had a scene and I only want it to load that scene when the user do certain actions, is that possible?

 

Hi,
Yes this is something that is very easy to change. Just go to 'Tools -> uMod 2.0 -> Settings' and disable the option called 'Auto Load Mod Scenes'. Now you will need to manually load mod scenes using the API's when required.