Skip to content

A small webserver app that, based on a config file relays events from OBS to MIU actions

Notifications You must be signed in to change notification settings

St0l3nID/OBS-to-MIU

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

18 Commits
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Installation

Python

Clone repository and install requirements from requirements.txt.

On Windows

The Release section has the latest binaries supplied as an executable file. Download, unzip, run.

How to use

The heart and center of this application is the configuration file, which will map OBS-Events to MIU-Actions. The file will be loaded into memory on startup, so if you actively work on it make sure to restart the application.

  1. Activate OBS Websocket in Tools/WebSocket Server Settings.
  2. Inside Mix it Up, enable Developer API in the Services section.
  3. In config.json add proper password, ports etc. for both applications.
  4. Configure the mapping in config.json to define what events from OBS are sent to MIU.

Config.json Examples

Getting event information

By default the shipped config.json, has debug_mode set to true. This will print every single OBS event into the console window, including all the data it contains. I recommend simply running with empty mapping in the beginning and just click around in OBS, change settings, switch scenes, hide elements etc, see what you can get from your streaming software and think what you might use it for in Mix it Up.

You could use the opacity changing in OBS to start a sound in MIUs overlay. You can listen to which scenes are shown in your current Stream to turn on and off channel point rewards. A slideshow could be hooked up to sound effects. The options are not limlitless but kind of.. they are.

Once you have your config file written with proper mapping i would recommend setting debug_mode to False so it only prints events that were sent to MIU, keeps it clean and it will be easier to see if there is any issue.

Variable names are valueable here as you can send them to MIU easily by using the $ you know from MIU. Also you will use them as conditions later.

Understanding the config mapping

We are going through specific examples and introduce features step by step.

Simple Example

The syntax is Json. We always start with the event name as key, and inside the Dictionary ( { } ) we have the conditions, fe which action to trigger, and what data to send.

Fe. if you want to route all CurrentProgramSceneChanged events (which happens after a completed scene transition) to MIU, this would be inside the OBS_MIU_MAPPINGS dictionary:

    "CurrentProgramSceneChanged" : {
        "miu_action_group" : "SceneChanged"
    }

Every time this event fires, it will now trigger the miu action named "SceneChanged". If you look at that event in debug mode, you can see it also has the Scene that we changed to as a variable called sceneName. If we want to pass that along to Mix it Up as arguments for the action, our mapping would look like this:

    "CurrentProgramSceneChanged" : {
        "argument": "$sceneName",
        "miu_action_group" : "SceneChanged"
    }

Note that i adopted the $ symbol from MIU, to identify which parts of the argument to replace with a value from the events data. You are not limited to variables here, you can also simply write normal text in there.

        "argument": "Scene we changed to: $sceneName"

Note that variable names are case sensitive.

Conditions

Some events are very spammy, or you might only want the event under specific conditions, in that case you want to define the conditions under which the event is relayed to MIU.

    "CurrentProgramSceneChanged" : {
        "conditions": {
          "sceneName": ["AFK", "IRL"]
        },
        "name": "PlayMusic",
        "arguments": ["$sceneName", "activated"]
    }

This example would only trigger the MIU-Action 'PlayMusic' if we change our scene to any scene named either "AFK" or "IRL". Note that name and miu_action_group are identical, and arguments and argument are as well, hence they can be used interchangebly (mostly so typos are less of a thing). I would recommend using arguments and miu_action_group in all cases to make the mapping clearer. Likewise, writing this:

        "arguments": ["$sceneName", "activated"]

Is giving the same result as this:

        "arguments": "$sceneName activated"

Multiple mappings for one event type

To define multiple target actions under varying conditions the syntax changes a bit.

We need to define a miu_action_groups array ( [] ) of different mappings within the event dictionary. Each of them with their own conditions, arguments etc.

  "InputSettingsChanged" : {
      "miu_action_groups": [
        {
          "conditions": {
            "inputName": "AFK",
            "inputSettings": {
              "text": "Only trigger if text is this"
            }
          },
          "arguments": "newText: $inputSettings/text",
          "miu_action_group": "TestBridge2"
        },
        {
          "conditions" : {
              "inputName" : "Game Capture"
          },
          "arguments": "WindowTitle $inputSettings/window",
          "arguments_process": "arguments.split(':', 1)[0]",
          "miu_action_group" : "TestBridge2"
        }
      ]
    }

As you can see we added square brackets within the event dictionary, and inside we now have mapping for each set of conditions.

In this example we respond to InputSettingsChanged and send it along to the MIU-Action TestBridge2 if the inputName is "AFK" (which for this event is the name of the source) and if the text field is set to "Only trigger if text is his". Other source names or text-contents would not trigger the MIU action.

Note that the argument i pass along is the text from nested data within the event, therefore i have to specify the nesting "pathlike" as $inputSettings/text.

The second routing is sending the event along if the source named "Game Capture" is changed in any way. Im also grabbing the window title and pass it along. If the variable window is not provided the string would be empty.

There is also custom python code in here to filter the argument string.

Custom code for arguments

In the previous example we can see this line:

          "arguments_process": "arguments.split(':', 1)[0]",

This code will be run on the arguments-string after the identifers have been replaced with the events values. I'm not responsible for your python skills ;)

This specific example will split the arguments-string on all ":" and take the first element only to pass along (which would be the window title). You can use either "arguments" or "argument" here, which will just be the resulting string, whatever is returned from your code will be passed along.

Make sure to test this well.

About

A small webserver app that, based on a config file relays events from OBS to MIU actions

Topics

Resources

Stars

Watchers

Forks

Packages

No packages published

Languages