[Now Released] uMod 2.0 - Modding support made easy

Community Showcases
1

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

2 Likes
2

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

3

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.

4

Hey scottyboy, any ETA on this ? ^^

5

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

1 Like
6

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

1 Like
7

Sounds good !

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

8

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

1 Like
9

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:

2521851--174838--ExportWindow.png 2521851--174839--ExportWindowBuild.png

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.

2521851--174836--ExportSettings.png 2521851--174837--ExportSettingsRequired.png

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)

1 Like
10

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

public static string UMod.Modding.GetModChecksum(string ModName)
{
        return checksum;
}

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

public struct Mod_t
{
        public string modName;
        public string modChecksum;
        public string modAuthor;
}

public static Mod_t[] UMod.Modding.GetInstalledMods()
{
        return installedMods;
}

public static bool CheckIfModIsInstalled(string checksum)
{
        return modInstalled;
}

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 :wink:

11

Hi Stormy102

These features have already been implemented in version 2.0 :slight_smile:

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:

bool isModInstalled(string name, string versionString = "");
bool isModInstalled(byte[] idCode, string versionString = "");
IModFIle getInstalledMod(string name);
IEnumerable<IModFIle> getInstalledMods();
IEnumerable<string> getInstalledModNames();
ModPath getModPath(string name);
void installMod(string location)

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

1 Like
12

Any updates on this @scottyboy805 ?

1 Like
13

This sounds very interesting indeed!

14

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.

1 Like
15

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

16

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.

// The entry point for the mod
void onModLoaded(IModHandler handler)
{
    // Call a game method called 'damage' in the 'PlayerController' script of the 'Player' object
    ModScripts.invoke("Player.PlayerController.damage", 20);

    // Change the health field for the player (Game object names are not required but help to find the correct target)
    ModScripts.Field["PlayerController.health"] = 100;

}

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.

1 Like
17

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 :slight_smile:

1 Like
18

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

2 Likes
19

Great! Looking forward to start using it :slight_smile:

20

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 :wink: security is not necessary for development, i agree.