Function Scripting

[Durisian]

Just to put it out there -

I think the loading of lua scripts could be a bit more friendly.

At the moment - lua scripts are loaded from the shows folder at software startup. But if you have a show your loading from another source, such as a usb key that the client has handed you - you need to restart the software so it loads the scripts needed for the show off the usb key. And it doesn't load any venue specific scripts from the usual show folder. Of course I could copy the show file and scripts to the D:\shows folder - would still need to restart though.

So I had a few ideas (Uh oh)
- Would be handy if the console had a writable place to store venue or production company based scripts. Scripts that are used by the owners of the equipment - D:\scripts seems logical. as opposed to the horizon directory which can not be modified.

- A global function scripting window in the software, that saves the scripts within the show file, so there's no need to remember to copy the .lua files when transporting a show.

- Finally, a bit that is probably much more complicated - Some sort of conflict resolution. So if a show is loaded with functions that have conflicting names from those already loaded from D:\scripts, a prompt would ask you which one you want to use.


Mick

[RobertBell]

We thought of some of these ideas when we were asked to do a d:\AutoRun folder for OpenPalette applications that needed to be started when a show starts. We were a bit nervous to do this.

I wonder how we could do that conflict resolution - there may be very small changes in code. We'd need a 'Diff" application.

[Durisian]

Still been thinking about this
I've had a lot problems in the 'HELP!' department due to complications with current .lua file setup.
Mostly with people booting with a show outside their normal show folder - or taking a show to different console, without the .lua file.
The big issue is trying to teach people with limited computer skill about utilising more advanced scripts. It's all well and good to write a script for someone else - but as it currently stands, they have to go beyond thinking about normal lighting operator stuff.
I tend to avoid posting function scripts on the forum becuase of that, when I do - I usually dumb it down so it can be added as a simple macro.
I'd really like to see function scripts become much more a part of the familiar software than the current 'added on' vibe.

Here's a theory:
A new view/display: Scripts
Presented similar to other displays -
4 Columns - Name | Parameters | Description | Code

For explanation - we have some code

Code: Select all

function hello (text)
  HC.MessageBox(text)
end


Name - the execute name: in this case 'hello'. hello() would execute that script
Parameters - List of parameters for the function: text
Description - Much like userfunctiondescription
Code - As above without function or end (can be added automagically)

These can be put in the script and command windows:
Script windows uses the function and parameters to generate the functions in the list. Taking description when added.

Command window has the name under available and populates argument with the various parameters.
- In case of parameter arrays: whenever the argumnet is given a value, a new argument should be added waiting for a value.
Description should be prominantly shown.


As with other things - these scripts can be stored in pages.
If the script 'hello' is stored in the 'general' page: The final trigger code could be general.hello("A Message")

Scripts can then stroed in the show file and can be easily shared using import - as with anything else in the show file
Confict resolution becomes easy - A simple check when writting the name or import can throw an error.

Common scripts can simply be added to a template show file.

[jltsale]

I like the idea of a lua library of sorts. I would also like to catagorize them and make them interactive. By this I mean the script would also have information attached to it that told me what cue/variable/... it was used in.
I would also like to be able to store variables although I know that this is difficult with lua. We are talking about making it a structured language.