[Released] uMod 2.0 - Modding support made easy!

Asset Store | Website | Documentation | Scripting Reference
​

uMod 2.0 is a complete modding solution for the Unity game engine and makes it quick and painless to add mod support to your game. Modders are able to extend to and modify game-play by creating mods with assets, scripts and even entire scenes, all within the Unity editor.

Features

• Basic mod support out of the box
• Supports all assets that Unity can handle, Yes! even scenes and scripts can be included
• Load from the local file system of from remote server
• Supports command line launching of mods
• Supports multi-mod loading
• Catches exceptions and errors generated by mods
• Modders can create their content in the Unity editor and export easily using uMod Exporter
• C# scripts and assemblies can be included in mods
• Cross domain scripting allows communication between game and mod scripts
• Script execution security allows developers to restrict modded code
• Customizable build pipeline allows for custom exporter tools to be created
• Supports asset sharing allowing modders to make use of game assets
• Includes a directory utility for managing a mod directory
• Dedicated online scripting reference
• Many more features

Take a look at the Roadmap for upcoming features. You can also request a feature to be added via our website.

Upgrading

If you purchased uMod 1.0 then you are entitled to a free upgrade to uMod 2.0. You should already be able to upgrade for free via the asset store even though the displayed upgrade price is $1.

Want to know more? Take a look here for more information about uMod 2.0​

 

Version 2.0.1 has been submitted to the asset store. The version includes:

• Small bug fixes in the exporter and core plugin
• Added demo video showing how to create and export a basic mod
• Added support for older Unity versions (5.0.0 to present)

 

Version 2.0.5 has been released.

The new version includes code security validation which allows you to setup namespace or assembly restrictions for modded code. Any code that breaks these restrictions will not be loaded making it possibly to have very safe modding support.

Any namespace or assembly name can be restricted but good candidates would be 'System.IO' and 'System.Reflection'.


These restrictions can be setup in the security tab of the uMod settings window:

​

 

I hope to pick this up over the weekend if I can get the funds together. Is the price reduction temporary? If so, when do you plan to increase it?

 

Thanks for the interest. Not sure whether the price reduction will stay or not yet but it will last for at least a few weeks.

 

Thanks for the info, I bought the asset this morning.

 

No problem, let me know if you need any help or want to request a feature

 

Version 2.0.8 has been submitted to the asset store for review.

This is a fairly large update and includes a number of changes:

• New scripting API for developer side. UMod.Scripting now allows developers to have far more control over loading and interaction of mod code. See documentation for more info.
• New file format in preparation for future features. Unfortunately this means that backwards compatibility will be lost for previous versions and mods will need to be re-exported.
  
• Expanded the assets API for developers and modders. You are now able to get detailed information about assets including full path, relative path, file extension, unique id and more.
• Modified interface: 'IModBoundary' has been removed. (Use 'ModScript instead)
• Modified interface: 'IMod' no longer accepts an argument for the method 'OnModLoaded'
• Removed old dll dependency that would sometimes cause errors on import.
• Fixed an exporter bug where the export would fail if 'compileScripts' was enabled in the setting but there were no scripts in the mod folder. Script compilation will no be skipped in this case.
• Exposed the exporter settings to developers so that all export data can be modified via editor scripts.

Hopefully the update should be live within the next few days.

 

Version 2.0.8 is now available in the asset store!

 

uMod 2.0 is now on sale with 25% off. Grab it while you can!

 

hi! when you plan to update the asset (it gives a warning that use some deprecated functions)

 

Those warnings are harmless and the unity api updated should automatically update the code on import, however we will distribute an additional package in the next update for later versions of unity that will remove those errors.

 

thanks

 

Hi there, using your package and whenever I export I get an error in my console:

[UMod.BuildEngine.Build.Assemblies.ScriptLinker]: Failed to locate assembly for type: UnityEngine.Vector3
UnityEngine.Debug:LogError(Object)
UMod.Shared.Log:Error(Object, Object[])
UMod.BuildEngine.Build.Assemblies.ScriptLinker:OnAssemblyLinkRequest(Type)
UMod.Shared.ModEvent:Invoke(Func`2, Type)
UMod.Interface.Link.TypeReference:.ctor(Type)
UMod.Interface.Link.LinkInstanceField:Serialize(FieldInfo, Object)
UMod.Interface.Link.LinkBehaviour:Serialize(Object)
UMod.BuildEngine.Build.Assemblies.ScriptLinker:SerializeScript(MonoBehaviour, Boolean)
UMod.BuildEngine.Build.Assemblies.ScriptLinker:LinkScript(MonoBehaviour, Boolean, Boolean)
UMod.BuildEngine.Build.Assemblies.PrefabLinker:LinkPrefab()
UMod.BuildEngine.Build.Sequence.<RunStep>d__2:MoveNext()
UMod.Shared.Editor.EditorCoroutineTask:MoveNext()
UMod.Shared.Editor.EditorCoroutine:OnUpdate()
UnityEditor.EditorApplication:Internal_CallUpdateFunctions()​

The build seems to succeed and scripts seem to work ok in my host game, but wondering what this is and if there's anything I can do to fix it. Thanks!

 

This is a known bug and is harmless. Basically it is saying that it can't find the type 'vector3' in your mod scripts which is entirely expected as it is declared in 'unityengine.dll'. The error should be fixed in the next update which will be released shortly.

 

@ghiboz What version of Unity are you using. We a currently trying to fix the depreciated API warnings you are seeing but we cannot reproduce these warnings in any major 5.x version.

 

Version 2.0.9 has been submitted to the asset store for review. The update includes:

• Partially exposed part of the build API in preparation for customizable mod exporting.
• Introduced asset processors which run on every mod asset during export (Customizable pipeline)
• Slightly modified the internal file format to include meta data. (Mods build with older versions will need to be re-exported).
• Removed an unused assembly reference which would cause errors while exporting mods and building to standalone player.
• A number of minor bug fixes.

 

@scottyboy805 I'm on 5.6.0 and now 5.6.1... I wait the 2.0.9 and retry!

 

We have tried with both of those versions and cannot get the API warnings to appear no matter what we try. Give 2.0.9 a try and let us know if the problem is still occurring for you.

 

Thanks a lot for this update! I can confirm it completely eliminates the error.

Any chance we'll see incremental build options? For example, I'm reworking my current game to support mods by moving the base game out to a mod. All of my art is finalized so I don't need to back it up and re-export it very time I change a mod script. Is there any possibility we can only re-export items that have changed, or even manually choose what we want to re-export without affecting content that has already been exported? If this isn't possible, is there any kind of workaround? I have hundreds of models and textures that I really don't want to wait for.

 

Glad to hear that the warnings no longer show up.

It will be difficult for us to support incremental building but it is something that we will need to look into to determine whether or not it is possible. We will certainly look into it as it could greatly reduce export times.

As an alternative, we are planning to add support for mod dependencies in the near future meaning that you can segregate your mods and then create references between them. You will be able to create a mod that contains a collection of assets that don't change very often and then add a reference from another mod so that you have access to those assets. We have already started implementing this system however we cannot give any deadline for its completion as there is still a lot of work involved.

 

Very cool, thank you for the update and for responding so quickly! It's going to be a while before we have everything separated out, so for now I guess I'll just put the art assets in a separate mod and load both - by the time we're ready to ship fingers crossed your solution will be ready

 

We have managed to reproduce this warning now in version 5.6.0 and will fix it in the next update.

 

Version 2.1.0 has been submitted to the asset store for review. The update includes:

• Serialization support for generic lists. You can now define List<T> fields and uMod will serialize them correctly just as you would expect whereas before all data would be lost when the mod was loaded.
• Changed the runtime script re-linking process for prefabs. Before prefabs would need to be instantiated in order for their scripts to be re-linked but now this is done when a prefab is loaded from the mod.
• Modified the build engine to gain slightly improved export times.

@ghiboz We have tried to fix the warnings you were seeing about obsolete API. We have fixed all of our calls to obsolete unity methods but are still seeing those warnings for some reason so we will need to look into it further.

 

Quick question, is there some documentation on using LoadAsync() correctly? I've got the flow working, but it still seems to block the main thread when loading in my model of ~6000 tris. I thought it was supposed to load content in the background, correct?

 

Hi,

Are you referring to 'ModHost.Assets.LoadAsync()'? This is the scripting reference page although it is slightly out dated. There is also an example script included with the package that covers async asset loading. You should find the file at 'Assets/UMod/Examples/ExampleScripts/Ex14_LoadModAssetsAsync.cs'. If your code is correct then it could be a bug because it is indeed supposed to load the asset in a background thread.

 

Version 2.1.1 is now available on the asset store. This update includes:

• Fixed a serialization bug where interfaces cause an error on export
• Fixed a bug in array serialization that caused an export to fail sometimes
• Fixed an IOException that would sometimes occur after export leaving the project in a modified state
• A few other small bug fixes

 

Hi, noob here
I'm thinking about buying your modding solution but my main question is what happens with third party assets? like some IA tools, some game frameworks like uMOBA or playmaker? will I have to dig through their code (if/when available) to adapt it to Umod? I still don't have the needed knowledge to use Umod, but I'm learning every day... thanks!!

 

It will depend upon how you use the 3rd party asset and whether your want modders to be able to access its features. The main concern when using 3rd party assets is licensing because you will not be able to redistribute these assets with your mod tools for modders to use. If you wanted to use a 3rd party pathfinding asset for example but you want modders to be able to create AI control scripts then the best option is to create an intermediate API specifically for modders that abstracts the asset implementation. You can then provide this API to your modders via you mod tools package as a separate DLL and then modders can use that API to access the pathfinding system.
With regards to playmaker, did you want to use this on the game side to load mods or did you want modders to use it? If it is the latter, then bear in mind that each user of your mod tools will need to purchase a license for playmaker in order to use it. You cannot simply redistribute the package. If you just want to use it on the game side then you can create custom playmaker actions which call into the uMod API. I am not too familiar with playmaker but from what I have read it is not too difficult to create custom actions.

I hope this answers your questions. I tried to explain it in simple terms but let me know if there is anything you don't understand.

 

Hi scottyboy805, yes your answer helps me to understand my issue, thank you very much

 

Version 2.1.2 has been submitted to the asset store for review. This update includes:

• Fixed an array serialization error
• Fixed a security check error about System.Reflection caused by code injected by the mono compiler. This would case assemblies to fail security checks even though they do not directly reference System.Reflection
• Fixed a serialization error which would cause data to be lost if there is no default constructor for a type. Now uMod will create an object will all values initialized to their default as Unity would do.
• Fixed access to read only files during export. The exporter will now handle read only files correctly without error
• Changed the cleanup build process so that only modified assets are restored after a mod is exported. This makes the exporter far less prone to failed cleanup.
• Fixed an error complaining about spawning objects from OnDestroy when closing a scene
• A few other small changes

 

hi all!
a question: the uMod Exporter is able to export (and after to be reimported with uMod) the materials with custom shaders?
thanks in advance

 

Hi,
This is partially supported. I say partially because the shaders must exist in both the game project and the mod project. Shaders that do not exist in the game project but have been exported will result in the magenta material being assigned. In order to include the shaders in both projects you will probably need to modify the exporter package to include your custom shaders/materials so your modders can assign the shaders in editor.

I hope this helps you.

 

ok, thanks.. I hoped that also for custom shaders will work..

 

Version 2.1.3 has been submitted to the asset store for review. This is quite a large update and includes:

• Changes to the exporter UI
• The build engine now uses a dialog to display the build progress
• Support for multiple export profiles which allow you to have a number of different mods in your project which you can choose to export via a drop down menu
• Updated API to support for export profiles
• Added support for partial script compilation in conjunction with export profiles. This allows only the scripts inside the mod folder to be compiled whereas before the whole C# project was compiled
• Export settings are now stored inside the project folder
• Added serialization support for animation curves
• Minor changes to the API
• Fixed a bug where linking would sometimes fail if a type does not have a default constructor
• Fixed a bug that allowed the 'Assets' folder to be selected for export
• Fixed a bug that caused the build to fail if the export path provided was empty
• Fixed a bug where prefab objects would not be cleaned up if they did not have any monobehaviour scripts attached even though they had been modified.
• A number of other small bug fixes

 

Hi,

I'm on a Mac but it's trying to export for Windows and I can't find a setting for that. Thoughts?



Thanks,
Eric

 

Hi Eric,
We managed to reproduce this error and it is indeed a bug in uMod. We have now fixed the problem and have emailed you an updated version which includes the fix so you should now be able to export properly on OSX.

Out of interest, are you having any issues compiling scripts included in your mod? Another customer has reported problems with script compilation on OSX which we are looking into but if you got to the error shown above you are either not including scripts in your mods or are not having any issues compiling?

 

@EricMuyser PS, we assumed you were using a Unity version newer than 5.3.5 but if that is not the case then let us know and we will need to send you a different version of the exporter package.

 

@scottyboy805 That's exactly right, using Unity 5.6 and the package you send over works! Thank you!!
I'm just getting started so I can't confirm everything is working as expected yet. I'll be in touch as the modding system is integral to the success of the product I'm building. Cheers!

 

Question about your asset, we're looking to support modding but we'd like to keep our mods on a webserver, and gives players the ability to download mods from the webserver automatically when they attempt to play a modded multiplayer game.

How are the mods saved? Would it be possible for us to export these through HTTP to a webserver and then download them the same way?

 

Our asset supports downloading from a server by passing the url as the path. Mods files are saved under a folder with the name of the mod and then files are loaded from the folder as needed. You simply supply uMod with the url of the mod folder and it will automatically download the files it needs from the folder to load the mod You will need to upload mods manually though as the exporter has no support for uploading to a server.

 

Version 2.1.4 has been submitted to the asset store for review. This update and includes:

• Major API changes (All example scripts have been updated to show the usage of the new API)
• The API has been modified to allow for mod references which will be available in a later update.
• Easier usage of async methods. All async methods now return an yield-able object similar to the way Unity does it.
• Much better support for mod scenes. Scenes are now treated as special kinds of assets and both the modder and the developer will have far more control over them
• If a mod fails to load because of a version error, a message will be logged displaying the required unity and uMod versions to load the mod.
• The exporter will now attempt to use the compiler included with Unity if possible otherwise it will fallback to the mono compiler if it is installed. This fixes an issue on OSX where the mono compiler could not be located.

We have also dropped support for older Versions of Unity. Only versions 5.3.5 and onward will be supported from now on.

 

Version 2.1.5 has been submitted to the asset store for review. This update includes:

• Fixed a bug in the exporter where multiple assembly references were added during compilation which caused the compile to fail.

We have also added support for mod referencing which allows a mod to reference another mod allowing access to its scenes and assets. References are setup in the export settings and are specified per export profile:



All referenced mods are automatically loaded at runtime (As long as they can be found) as part of the mod loading process so no extra steps are needed. You can simply access the content of reference mods using 'ModHost.SharedAssets' and 'ModHost.SharedScenes'. Deep reference chains are supported but you cannot create circular dependencies. uMod will detect this when adding a reference and prevent it:





At the minute we do not have support for accessing scripts in referenced mods but we are currently working on it.

 

Version 2.1.6 has been submitted to the asset store for review. This update includes:

• Fixed a bug where an exception would sometimes be thrown while parsing the command line arguments.
• Added support for paths with spaces in command line arguments by surrounding the path with quotes
• Removed an editor reference from a runtime assembly which would cause building the project to fail.

We have also added support for script referencing as part of the mod referencing system. When you add a reference to another mod you will now be able to access all public scripts that are included in that mod.

 

Version 2.1.7 has been submitted to the asset store for review. This update includes:

• Added support for game locking which allows mods to be created for specific games only.
• The 'Create New Mod' window now allows you to specify a folder where the mod will be created.
• Added an event that is triggered when an new mod is created by the exporter allowing editor code to run (UMod.Exporter.ModCreate.OnModCreated).
• A few small bug fixes.
• Updated documentation.

 

Hello, I'm facing a blocking issue when attempting to export my mod. It's a mod with scripts. My art-only mod exports with no issues. Using exporter 2.0.0 and Unity 2017.3.0f3. I've combed over all of my scripts looking for errors or deprecations and I can't seem to pinpoint where the issue lies. Here are the two errors I encounter:

Code (CSharp):

1. BUILD FAILED!
2. UnityEngine.Debug:LogError(Object)
3. UMod.BuildEngine.BuildEngineService:FailBuild(BuildEndStatus, String)
4. UMod.BuildEngine.Build.BuildSequence:Run()
5. UMod.BuildEngine.BuildEngineService:BuildMod(String, BuildOutputInfo, Action`2)
6. UMod.Exporter.Window.ExporterWindow:LaunchBuild(Boolean)
7. UMod.Exporter.Window.ExporterWindow:OnUpdate()
8. UnityEditor.EditorApplication:Internal_CallUpdateFunctions()
9.  

Code (CSharp):

1. [UMod.BuildEngine.Build.BuildSequence]: Exception thrown during pre-pass build process:  UMod.BuildEngine.Exceptions.ModBuildException: There were script compilation errors during export. Mod building cannot continue!
2.   at UMod.BuildEngine.Build.BuildStep.Fail (System.String reason) [0x00000] in <filename unknown>:0
3.   at UMod.BuildEngine.Build.Sequence.PreBuildStep.CompileRuntimeScripts () [0x00000] in <filename unknown>:0
4.   at UMod.BuildEngine.Build.BuildSequence.RunBuildStep (UMod.BuildEngine.Build.BuildStep step) [0x00000] in <filename unknown>:0
5. UnityEngine.Debug:LogError(Object)
6. UMod.Shared.Log:Error(Object, Object[])
7. UMod.BuildEngine.Build.BuildSequence:DisplayPreBuildError(Exception)
8. UMod.BuildEngine.Build.BuildSequence:Run()
9. UMod.BuildEngine.BuildEngineService:BuildMod(String, BuildOutputInfo, Action`2)
10. UMod.Exporter.Window.ExporterWindow:LaunchBuild(Boolean)
11. UMod.Exporter.Window.ExporterWindow:OnUpdate()
12. UnityEditor.EditorApplication:Internal_CallUpdateFunctions()
13.  

Thank you in advance!

 

Could you send us the exporter log file located at 'C:\Users\<username>\AppData\LocalLow\<companyname>\<projectname>\uMod Exporter 2.0\Build.log' to info(at)trivialinteractive.co.uk. Also could you try re-syncing the .csproj file for the project by going to 'Assets/Open C# Project' in the Unity editor and see if that fixes the issue. Sometimes the project file and scripts can get out of sync which can cause this error to appear.

 

Thanks for the tip! The reason this was happening was because the mod referenced scrips that weren't in the actual mod folder. I created a folder that could be used as a mod toolkit with some classes that could be used for inheritance of certain methods that could talk to the base game. This used to not be a problem, so I'm not sure if this is expected or not - I believe this could be a byproduct of the new option to compile only mod scripts. I tried with the option both on and off and had the same issue, so I'm also not sure if that is working as expected. Eventually moving the toolkit folder into the mod folder itself fixed the issue, although it did increase complexity in my specific situation, which I will explain later.

I couldn't have solved this myself without your help, so thank you so much - the clues were in the build.log file you asked for. I decided to check the log to see if it had any more info for me to trace and it told me exactly where to look. The original error in the console was not very informative however. I'm not sure if that's a uMod error or Unity error, but it may be worth looking into. It doesn't tell the user what the offending scripts are, in fact it says "<filename unknown>".

Anyway, unless something has changed, the exporter doesn't appear to check for existing unchanged files and just exports everything all at once. Because I have so much art already finished for the game, exporting everything as one package takes a long, long time, so I separated the mod into two - one for scripts and prefabs and the other for pure art. This causes extra complexity for the toolkit folder I created as I now need separate classes for Art stuff (import cleanup, bone adjustments, etc) and logic stuff and I can't share any statics between them - they each need their own libraries. Not something I can't work around, but it's something I wanted to bring to your attention.

Thanks again!

 

Glad to hear you sorted the problem.

We updated uMod to only compile scripts directly inside the mod folder so that we could add support for multiple mod profiles with scripts sharing the same Unity script project. Previously uMod would just take the included scripts from the generated .csproj file for the Unity project but now it will only compile scripts inside the mod folder.

We will look into adding more useful errors when this sort of error occurs because as you say it was easily fixable one you knew what was happening. Unfortunately we wont be able to print the name of the offending file though because the mono compiler does not have access to that information at compile time.

Yes uMod needs to re-export everything when rebuilding a mod which is not ideal and can take quite a bit of time for large mods. We are currently looking into incremental building methods but we have no timeframe on that as it is complex to integrate into our current system.

 

Version 2.1.8 has been submitted to the asset store for review. This is a small update and includes:

• Added serialization support for the built in Unity type 'Gradient'
• Shaders can now be included as part of mods and will work as expected when referenced from a material
• Removed obsolete API's that were depreciated in version 2.1.5