Unity makes use of generic functions in the GetComponent family of functions. This poses problems when attempting to use these functions from the Lua environment. The untyped equivalent of these functions return UnityEngine.Component variables that must be cast into the correct type, which is also not possible in Lua.

The framework works around this issue by introducing a set of helper functions in API_GameObject. These functions use reflection to create a typed version of generic functions at runtime, before bundling the resulting component in a DynValue to pass back to Lua.

As a result, the following functions must be used:

public DynValue BL_GetComponent(GameObject obj, string CompType)

public DynValue BL_GetComponentInChildren(GameObject obj, string CompType)

public List<DynValue> BL_GetComponents(GameObject obj, string CompType)

public List<DynValue> BL_GetComponentsInChildren(GameObject obj, string CompType, bool includeInactive = false)

public DynValue BL_AddComponent(GameObject obj, string CompType)

In some circumstances (deletion/scene loading), a reference to a UnityEngine.Object (i.e, GameObject or Component) can be checked against nil in the Lua Enviroment but when accessed generate a Null Reference Exception - this is due to an overload of the equality operator == in C# which checks UnityEngine.Objects for an invalid state. This overload does not exist in Lua. To work around this a function API_Utils.CheckValid(UnityEngine.Object), also shortened to CheckValid() has been provided.

Types to be used within Lua must be registered via UserData.RegisterType<>(); for security reasons, this has not been automated. Due to this, it is possible that some important classes have been inadvertently missed, which will result in that functionality not being available in Lua. If you run into this, please raise a bug report. Some classes have been deliberately excluded, primarily those that allow access to the file system, graphics hardware or anything that gives access to details of the users system. Please see the Security for a list.

C# functions that return collections will return them in the form of a reference to a C#-side object. MoonSharp provides a wrapper around collections that allows them to be iterated, but lacks several important functions, most significantly the ability to get the element count. The easiest way to deal with this, assuming the collection does not need to be maintained is create a Lua table via a Lua-side function:

function ToLuaTable(wrapper)
    local t = {}
    local index = 1

    -- MoonSharp EnumerableWrapper supports ipairs-style iteration
    for value in wrapper do
        t[index] = value
        index = index + 1
    end

    return t
end

Several functions are provided to manipulate C#-side arrays. These are not an elegant solution, so will be replaced in future. For security, these functions are restricted to types registered with Moonsharp

API_Utils:

public static DynValue BL_GetArrayElement(object target, string fieldName, int index)
public static void BL_AppendToArray(object target, string fieldName, object value)
public static void BL_SetArrayElement(object target, string fieldName, int index, object value)

Several unity functions involving the allocation of arrays have bugs that will result in memory access violations and a Crash to Desktop. these functions have been blocked from being used by the Lua environment

those identified so far are:

LineRenderer.GetPositions()
ParticleSystem.GetParticles()