Plugins

Advanced development

The suggested way to use the Teslasuit Unity Plugin is to add one of the pre-existing DeviceBehavior scripts to a GameObject and script custom MonoBehaviours on top to interact with the various subsystems (see Component model). This page is for those who want more fine-grained control over the underlying pieces: how the plugin boots, how the native session is owned, how you reach and pair devices, and how to handle connection changes yourself.

Bootstrap with TsInitializer#

Before any Teslasuit component can work, the plugin has to load the native libraries and create a native session. Plugin initialization runs in stages: locating the native libraries, loading them, and initializing the native API. The TsInitializer step handles library loading and runs automatically before the first scene loads. You do not call it directly.

The native libraries are not stored inside the Unity project. They come from a separate Teslasuit SDK installation, so the plugin has to locate and load them manually at startup. If it cannot find them, it throws a DllNotFoundException, which means the SDK is not installed correctly. See Getting started for the fix.

The TsManager root#

TsManager is the single root object that Teslasuit components use. It creates and owns the native session (TsRoot) and disposes of it when the application shuts down.

Two properties define how it behaves:

It is optional in the scene. You can place a TsManager in a scene, but you do not have to. When a component needs the root and no manager exists, the plugin creates one on demand.
It persists across scenes. TsManager sets DontDestroyOnLoad, so the session stays alive as you move between scenes rather than being torn down and rebuilt.

Only one instance exists at a time. If a second TsManager appears, it removes itself so the session is never duplicated.

Reaching the native session#

When you need the native managers directly, access them through the root. The root exposes the suit and glove managers and the asset manager that back the higher-level components.

using TsSDK;

var root = TsManager.Root;
var suitManager = root.SuitManager;
var suit = suitManager.Suits[0];

Most projects never need this: the device and subsystem components use the root internally. Reach for it only when you want to enumerate or pair devices, or manage assets yourself. The types you get back, such as the suit and glove managers, are documented in the C# SDK reference.

Custom connection handling#

A device can connect or disconnect at any time, and it may already be connected before your script runs. The subsystem components already handle this for you, so you need this pattern only when you want to react to connect and disconnect in your own code. The reliable pattern, used by every plugin subsystem, is to subscribe to the event and also check the current state in Start:

private void Start()
{
    m_deviceBehaviour = GetComponent<TsDeviceBehaviour>();
    m_deviceBehaviour.ConnectionStateChanged += OnConnectionStateChanged;

    if (m_deviceBehaviour.IsConnected)
    {
        OnConnectionStateChanged(m_deviceBehaviour, true);
    }
}

private void OnConnectionStateChanged(TsDeviceBehaviour behaviour, bool connected)
{
    if (connected)
    {
        // behaviour.Device is now valid, cache the subsystem you need.
    }
    else
    {
        // Device is gone, release your cached reference.
    }
}

When the device disconnects, cached subsystem references become invalid, so drop them in the handler and re-acquire them on the next connection.

Threading caveat#

ConnectionStateChanged is raised on a thread other than Unity's render (main) thread.