Call a Plugin and Specify more than one Argument

Instead of calling a plugin, you can also call directly any global function inside the plugin

Lua "MyFunction('helloworld',42,'Yippee')"

If you have several functions in your plugin you want to call from macro's or from the command line, you can call them individually.

You can also 'bundle' all the functions of a plugin in a table for a better identification

MyPlugin={
    MyFun1=function(param1,param2)
        --function code
    end,

    MyFun2=function(paramx,paramy)
        --function code
    end,
}

Now you can call them from a macro with

Lua "MyPlugin.Myfun1('p1','p2')"
Lua "MyPlugin.Myfun2('px','py')"

Danger Zone !

I try to avoid (or minimise) my use of globals, they are dangerous.

For example (and I think it's an MA bug),
when you load another show, your global objects remain !! This is bad !!

At least if you do use globals, then a single table variable is a good idea,

and you should give it a very unique name.
Be sure to include:
- plugin author

- plugin name
- plugin version (be careful with that)

- maybe even the ShowFile name, to workaround the MA bug mentioned before)

I use this property name for global variable ids:
[plugin_author]__[plugin_id]__v[plugin_version]

Development Drawback

When using Globals objects, usually a Singleton (A single object), then you check if your global exists and if not then you create it.
This means that during development, when you run ReloadPlugins, it also does NOT reset your globals,

and you in some case need to restart MA3, or use another plugin to delete you globals intentionally.

I totally agree with the caution regarding globals, however I don't think it's a bug that globals persist during and after a showload

The primary purpose of the Lua engine is to run the UI, not user plugins

The showfile does not load the Lua engine, rather the opposite:

e.g.

Lua "Cmd[[Loadshow 'Simple_Show' /Type 'Demo' /nc]] coroutine.yield(2) Cmd[[Fixture 1 t 4 At 10 t 40]]"

To reload the whole Lua engine ( = reset globals), you can use the commandline syntax ReloadUI

So,

1) I didn't know aboutReloadUI, thanks.
2)I guess If I add a hook to the ShowData object, I could get notified when a show is loaded. I didn't try it. I wish there was an explicit API for a load-show event. (And I wish there was a StartMacro, or some event when the system starts (or a show is loaded)
3) Do you work for MA Lighting? How do you know all this stuff?

Quote from hepi

How do you know all this stuff?

• educated guess -> trial and error -> verification / proof -> knowledge
• 25 years of nurturing grandma1/2/3

Completely agree with the danger of using global variables. (I even reacted with a warning about this in another thread some weeks ago) Sorry for not mentioning this at the first time and thanks for correcting me.

Now, The way I use globals:

- Exclusively for tables that hold functions or universal constants for all my plugins

- Each table has a unique name that start with [author]_[plugin]
- Only for functions that need to be called from other plugins or from macro´s

During development I use a special plugin that reloads the current project with the loadfile Lua command. Since all global variables I use are given their value on declaration the are reset in the process so I never encountered any problem of persistent globals between version updates. All show dependent information I store in objects that are saved with the show, so persistent globals between shows do not cause any problem either.

Nevertheless global variables do have their function in plugins and should not be ignored. The mere fact that something is dangerous does not mean that one should never use it, only that one should be careful. The label or number of a plugin can be easily changed by the user and a plugin might have many functions that are intended to be called from macro´s or the command line. Therefore I prefer to implement direct calls to functions in global tables assuming the obvious risks of this construction.

Storing State/Config in global variables

Well, in some cases it is needed.
I thought of a solution for the Show load issue.
And my current solution is this:

- When I install the plugin, I generate a uuid (unique identifier).
- When I create my global variable (a table), I set the uuid on that table as a property.
- I store this uuid in the AddonVars (which are within the ShowData)
- Whenever I access the global table, I compare the uuid from AddonVars to the one in the global table. If they differ, it means that a new show was loaded. So I destroy the current global table, and create a new one.

Does that sound reasonable?

I didn't want to start risk trying to Hook the Show Load event. Especially since we don't have a proper StartUp macro yet.

(Oh, BTW, I found a nice hack for having a StartUp macro, but it's not so easy to Install it for other people, it's good locally for your own system)