[Now Released] uMod 2.0 - Modding support made easy

Modding Support made easy!
uMod 2.0 Website


uMod 2.0 is now released! Take a look at the new asset thread here
​

What is it?
uMod 2.0 is a complete solution for adding modding support to your game allowing for custom assets scripts and scenes to be loaded at run-time. uMod 2.0 allows the community to create modded content within the Unity editor and export the assets to a run-time loadable format.

What about UMod 1.x?
uMod 2.0 has been completely redesigned to allow for new and exciting features to be implemented in an efficiency and effective way meaning that support for previous version will be dropped as we cannot maintain backwards compatibility.

UMod 1.x can be found: Here​

We will aim to release the following versions of uMod 2.0:

• Trial version: A free version with limited functionality to allow you to try before you buy.
• Standard version: The standard version of uMod for developer use, Price to be confirmed
• Source version: We are looking at the possibility of releasing a source version if there is enough interest.
• Build engine: A free editor extension that allows modded content to be exported into a loadable format.

Prices have not yet been confirmed but we will offer a free upgrade for all existing customers.

What to expect?
uMod 2.0 is essentially a complete rebuild from the ground of UMod 1.0 with three things in mind:

• Easy to use: We want people of any skill level to be able to add modding support to their games and the best way we can do this is to offer a clean and intuitive scripting API with minimal scripting required to access basic modding functionality. To accompany this API we hope to offer a wide array of tutorials and examples to show usage in different scenarios, as well as a dedicated wiki.
• Performance: One of the main problems of loading assets at run-time is time it takes which can be quite extensive depending on the content. uMod 2.0 aims to reduce loading times as much as possible by reducing the output size. We are also working to improve the run-time performance of uMod so that scripts included with the mod will have little effect on the games performance.
• Customizable: One major direction change for uMod 2.0 is that we want to allow game developers full control of the content that can be included in mods and we aim to provide a customizable build pipeline for exporting Unity assets into mod format.This means that you will be able to provide a personalized interface for exporting mods that fits your games style and even provide additional tools that can be used by modders.

Features:

• Basic mod support out of the box
• Supports all assets that Unity can handle
• Support loading mods from the file system or remove server
• Allow C# scripts or assemblies to be included in the mod
• Allows mod-to-game scripting (Modded scripts can access game scripts)
• Modders create their custom content within the Unity editor
• Command line launching
• Catch exceptions and errors generated by modded code
• Support PC, Mac and Linux platforms
• Customizable build pipeline allows developers to add custom build steps or include custom assets
• Developers can include editor tools in customized mod tools
• Many more feature to make adding mod support simple

Want more information or want to request a feature?
Let us know below​

 

Could you describe couple of cases how I can use it?
Thanx!

 

The way we see it is that there are three main types of mod that you could create with uMod:

Script modding: The modder would create custom C# scripts for the target game to either change or add functionality. With our system, modded code is allowed to access game specific code if the developer chooses to expose it. An example could be adding wall running support to an fps game or even replacing the scripts for the character controller to provide a different feel to the game.
Asset modding: The modder would create a new prefab that is designed to either replace an existing game asset such as the player character or to add new assets to the game. A good example would be adding driving functionality to a game by providing a vehicle prefab with appropriate controller scripts.
Scene modding: The modder would create a whole new level or environment for the game including adding spawn points for game specific objects such as enemies, players or event triggers.

It really depends on the game and how much the developer want to expose to the community but there are a lot of possibilities.
Its worth noting that with our system you can include any combination of these modding types.

Hope this helps.

 

Hey scottyboy, any ETA on this ? ^^

 

Great!
I cannot even imagine how it is possible, but if you managed to do it, this is awesome!

 

If all goes well then we hope to release the standard version towards the end of March

 

Sounds good !

Do you plan on having any sort of built in support for steam workshop ?

 

It has been a long term goal to add support for steam workshop since version 1.0. We do still plan to add support but it will be a long while off as we really want to focus on polishing the main features

 

For the last few days we have been working on the uMod Exporter which is product that modders will use to compile mods into a loadable format. The exporter window is designed to allow mods to be exported in a single button press and reports the progress and status to the user during the build.

At the minute the interface is basic but functional and will be fine tuned at a later stage:

​

Unlike previous version of uMod, the developer will now have full control over the build process if they desire meaning that they could create their own personalized exporter window instead of the default one provided, as well as specify assets that should or should not be included through build scripts. Developers will also be able to generate a mod tools unity package that contains the uMod build engine and the exporter window (or customized exporter window if provided) along with any assets or editor tools.

uMod 2.0 no longer requires modders to provide a script containing the name and version of the mod. Instead the this information can now be entered into a settings window prior to export. This means that you are now able to create mods with no form of scripting required.

​

As with previous versions, uMod 2.0 will offer build and run support meaning that modders can compile a mod and test it within the target game all in the click of a button.This is achieved through command line launching and requires the developer to allow launching mods at startup (Which is enabled by default in uMod)

 

Hey @scottyboy805
Can you include a function to check if a mod is installed using a string checksum? e.g.

Code (CSharp):

1. public static string UMod.Modding.GetModChecksum(string ModName)
2. {
3.         return checksum;
4. }

And a way to show the list of the installed mods? Maybe

Code (CSharp):

1. public struct Mod_t
2. {
3.         public string modName;
4.         public string modChecksum;
5.         public string modAuthor;
6. }
7.  
8. public static Mod_t[] UMod.Modding.GetInstalledMods()
9. {
10.         return installedMods;
11. }
12.  
13. public static bool CheckIfModIsInstalled(string checksum)
14. {
15.         return modInstalled;
16. }

Judging from UMod 1.x this has many features that could be improved upon. I often had issues using the UModExporter, where the error was 0x17 so hopefully this will be rectified soon with a cleaner UI and less bugs

 

Hi Stormy102

These features have already been implemented in version 2.0

You will be able to get the following information prior to actually loading the mod:

• Mod Name
• Mod Version
• Core uMod version (Used for backwards compatibility)
• Mod Description
• Mod Author
• 8 byte identification code

We have also implemented a helper class which is used to manage a local directory as a modding directory. You will simply need to assign the path to the directory at startup and then you will have access to the following methods:

Code (CSharp):

1. bool isModInstalled(string name, string versionString = "");
2. bool isModInstalled(byte[] idCode, string versionString = "");
3. IModFIle getInstalledMod(string name);
4. IEnumerable<IModFIle> getInstalledMods();
5. IEnumerable<string> getInstalledModNames();
6. ModPath getModPath(string name);
7. void installMod(string location)
8.  

Let me know if there are any other features you would like added.

 

Any updates on this @scottyboy805 ?

 

This sounds very interesting indeed!

 

It's been quite a while since I last updated this. We are still actively developing uMod 2.0 however he have had a few issues getting our system to work with more recent versions of unity (Due to app domains and security) however we have now found a solution which we think will be perfect for our needs.

We have also been developing a separate asset that uMod will rely on which has shifted focus slightly away from uMod, however this asset is approaching completion so we will be able to push to get uMod 2.0 finished.

I will update this thread soon with more detail. Thanks for looking.

 

Hi there!
Any news / updates about status of development?

 

Hi,

Progress on uMod 2.0 is good and steady, although we are still trying to find solutions to a few smaller problems.

The main issue we are having is that we cannot restrict the access that modded code will have to a users computer. This is mainly due to the fact that mono (Or the mono that Unity uses) does not implement the relevant security assemblies. This means that any code run within Unity runs with full access, even if it is loaded into a separate app domain, whereas in .Net you are able to impose a security policy which will cause a security exception to be thrown without the correct privileges.

As a result of this, our security system is only able to prevent mods from running if they contain any code that accesses any restricted namespaces or assemblies, such as System.IO. If anyone is able to come up with an alternative solution we would be very interested as it is undesirable to prevent a mod running simply because it breaches a namespace restriction..

On a brighter note we have been working on the scripting system for the last few weeks including the interaction between game code and modded code and its safe to say that there are far more possibilities than there were in the previous version. Modded scripts will now be able to:

• Create custom mono behaviours scripts that run in game.
• Receive game events in a similar way to mono behaviour messages (OnDestroy, OnTriggerEnter, etc). Events are defined by the developer.
• Inherit from in game scripts to extend functionality.
• Attach game scripts to modded objects.
• Much much more.

Its worth noting that the developer ultimately has full control of which classes and members are exposed for modding.

Communication between game and mod code will still be achieved via magic strings as used in the previous version but they are far more robust and capable in uMod 2.0. The following code shown is an example of how modded code can access game code.

Code (CSharp):

1. // The entry point for the mod
2. void onModLoaded(IModHandler handler)
3. {
4.     // Call a game method called 'damage' in the 'PlayerController' script of the 'Player' object
5.     ModScripts.invoke("Player.PlayerController.damage", 20);
6.  
7.     // Change the health field for the player (Game object names are not required but help to find the correct target)
8.     ModScripts.Field["PlayerController.health"] = 100;
9.  
10. }

As part of the scripting tests we have been testing multi-mod loading to check for any clashing behaviour that could cause problems. At the moment there are no issues and multiple mods seem very happy to run along side each other simultaneously, although these are only simple purely scripted test mods. We will need to test with much more substantial content to be certain.

We are also trying to figure out the best way of ensuring that each exported mod is assigned its own unique mod identifier. We have thought about exposing a event in the build engine that request the developer to generate this key and this is probably the method we will go for. This method provides the most flexibility since each developer can implement their own generation algorithm, probably using a key server of some form to ensure the code is unique. At the moment for testing purposes, the build engine simply generates a random 8-byte id which is not great.

We would be interested if anyone has any ideas on this.

Its still a little early to post a release date since there are a few smaller issues we need to nail down but we will post a date a soon as we can be sure to meet it.

Let us know what you think, Feedback is much appreciated.

Thanks for looking
Trivial Interactive.

 

Hi, thank you for such a wide announcement. Everything looks really promising.
If you have option of alpha testing, I would like to participate. It will be nice to start to prepare my project infrastructure to UMod2 =)

I am not much worry about security problems right now (maybe in one year or so, when you probably solve that). But my development is waiting for right architecture, where UMod will have key role and I need it as soon as possible to start development

 

Hi,

Alpha testing is definitely something we would be interested in. As soon as have all of the systems in place we will put together an alpha version and information of how to access it..

As for the security, if we cannot find a suitable solution soon enough then we will probably opt to release the first version without the security system in place and then add those features in a future update.

Thanks for looking

 

Great! Looking forward to start using it

 

I would sign that too. Having a complete new project in mind with modding support from the scratch and probabaly having it not finished within the next year i would like to start early with umod 2.0 rather than waiting for the nonplusultra final version will all feature ;-) security is not necessary for development, i agree.

 

Thanks for your input. I think we are going to hold off on the security system for the first release and add it as an update in a later version.

 

I'm happy to participate in testing if you want?

 

Yes no problem, I will post information about testing when we are ready.

 

Hey scottyboy, just wondering if mods will be able to use the Resources.* functions. Can a mod call Resources.Load and load a cached prefab from its own internal Resources?

 

Hi Stormy,

Mods are able to access the resources folder but instead of loading assets from the mod it will actually load assets from the game (If they exist). Instead we provide a few interfaces to both the developer and the modder that allows assets to be loaded from the mod by name (Similar to resources). You would simply use the following code to load an asset:

Code (CSharp):

1. void onModLoaded(IModHandler handler)
2. {
3.     // Load a prefab called 'Explosion' from the mod
4.     Object result = ModAssets.load("Explosion");
5.  
6.     // Create an instance of the prefab
7.     Instantiate(result);
8. }

We are also planning to add a similar system for loading raw un-compiled assets such as .obj files in a later update.

 

Ok so i'm also assuming that if i created a mod, slapped a prefab, say "CampfireGhost", the mod would be able to access it using resource.load but the game wouldn't?

 

Not quite,

Resources.Load would not be able to load the prefab. Its used only for game assets and should probably only be used by the game.
The mod would be able to load the prefab using the code I posted above. Its also worth mentioning that mods are also able to request scene changes.
The game is always able to load any content that a mod contains using a similar approach to above. uMod allows the developer to have full access to the mod as well as control over what mods can and can't do.

Hope this helps.

 

Ah ok that clarifies it. Thanks

 

uMod 2.0 is getting close to its initial release now and I thought I should find out whether there would be any interest in a source version. The prices are not set yet but the source version would probably be about 30 - 40% more expensive than the standard version.

Is this something that people would like to see?
Any feedback appreciated.

 

Well, personally I already payed for uMod v1 and didn`t get it worked for my project =)
now I am waiting for 2.0 and I am not sure if I need sources or not.
if everything will work ok, I`ll be happy to not dig under the hood - ideally I want compleet solution without bags
In worse case I can just disassemble DLL`s
of course you can use obfuscation, but I think it not worth to spent time on that, my advise - sell services, not sources

 

Thanks for the feedback. I think your right about services not sources but I know that some people will not purchase an asset without source code.

 

I like source code - if something doesn't completely work the way I want it to, then I can just tweak it slightly. We may pay more for a source version, but as we don't have a massive budget, we'd probably just get the standard version

 

On another hand - if you want someone to contribute into your development (e.g. I can help with bugfixing) it will be good to include sources to make your life easier . For me it will be strange to pay extra money to be able to fix something But this also means that you need to spent some time to make your code pretty, provide ton of comments and hopefully clean it from resharper warnings.

 

Thanks for the feedback guys. We will concentrate on the standard version and we can release a source version at a later date. The code is already fully commented and well structured so it would take no time at all to get a source version ready.

I thought I would post the new uMod 2.0 logo:

​

Much improved if I say so myself.

 

Great! Looking forward to get it

 

I like it

 

Also @scottyboy805 is there a way to assign models and textures if the modder doesn't have access to them e.g. a tree model that the modder wishes to place on a terrain or in a scene but won't be able to as the models are closed source?

 

You can use 'prefab nodes' to mark the location in a scene where an unavailable object will be placed. It is simply replaced with the target object when the scene is loaded. The same thing apply's for textures using a 'texture node' script.

We realise that this isn't ideal as the modder will have no visual representation of the object at design time. To solve this issue we plan to implement a custom mod tools builder that allows developers to put together a mod tools package specific to the game. In this package you will be able to include custom editor tools as well as scene assets to help modders create modded levels.

This won't be until a later update though.

 

Hi scottyboy805! Any news?
I am so much waiting for your release

 

We are in the middle of finalizing the exporter tools which should be completed in a few days time. Once we have finished the testing we will then upload the exporter tools to the uMod 2.0 website and they will be available as part of the beta testing. The uMod 2.0 developer package will become available for beta testing at a later date as there is still a fair bit of testing to complete.

I will post details about beta testing and how to access the tools when they are released.

 

Great, thanks!

 

It`s starting to be a good tradition - each month I am asking you about current status.
Yes, I know that now we have summer and everyone wants to have a vacation...
I am so annoying with my status-requests because now I have finished all prepositional part of work in my project (I am doing something like game-maker studio for numerous game developers who also waiting for me) and my current plan is to wrap such assets as UFPS, Voxeland and Unistorm into independent dll-modules-mods. So I am completely dependent on release date of uMod2

 

Nice of you to keep checking up and I agree that this should have been released by now but we seem to have had countless problems with different Unity versions and missing implementations in the mono framework. I do however have some good news to report. uMod exporter is completed and we have set a deadline of the 28th of this month to get the main version fully tested and released in beta so hopefully you wont have to wait much longer.

P.s sounds like a very interesting project your working on

 

>deadline of the 28th of this month
what a great news! I am so happy to hear that!

>sounds like a very interesting project your working on
yeah thanks, if it will become successful enough you are welcome to use it as reference

 

Well its that time already and as promised uMod 2.0 is now available in beta.

There will probably be a few updates per week with new features or bug fixes but I will post here every time a new version is added, so you can watch this thread for notifications.

The documentation will be expanded over the next week or so and uploaded, but as of now there are only a few example scripts and the scripting reference to get you started. Demos and tutorials will also follow shortly.

If you find a bug, then please report it using the included bug report tool (Tools->uMod 2.0->Bug Report or Tools->uMod Exporter 2.0->Bug Report) or via our website (bug report) and we will work to fix it as soon as possible.

To get started take a look at the beta page. Make sure you select the correct version to suit your Unity version otherwise you may receive a selection of errors.

As of now, we are uncertain of how long the beta will run but we will update when we know more.
Thanks for looking.

 

Today is a remarkable day!! Finaly we got UMOD2 =))

And of course first steps are problematic =)
I`ve tried to crate mod with simple test scene (with rotating cube).
First it has problems with opening this scene during bulding.
After that I`ve got bloking error about bytes file.
Plust I don`t like that building process renaming my assets (prefab and scene files)
Here is video report:

 

Cool! When my bug list is free I'll take a look.

Btw, I noticed on your roadmap you want to implement Steam Workshop support. I have a few scripts that work well with Steamworks.NET (link to github.io) that I could DM you?

 

Hi,
Which Unity version are you using? That error occurs when you use the (5.0.0) version of the exporter with a version of Unity that is newer than 5.3.0. Its happens because of changes to the way scene loading works in Unity.

Also, Renaming of the assets is essential if multiple mods are to be supported. If the build succeeds then the assets will be restored to their state before the build but it looks like this is not happening for you. I will update to make sure all assets are restored regardless of the build status.

There errors that appear after the first one are a direct cause and will disappear when the first error is fixed

 

Yes that would be great. I looked at Steamworks.Net when steam workshop was first requested and it seems like the best way to do it.

 

It is. Its a really powerful SDK and it's better than others because it is the same as the Valve Documentation.