Cool VL Viewer forum

Before I go too far off the 'deep end' and modularize my automation script, would you also be removing loadfile()? At this point, I can use it to manage loading chunks for things like constants or classes containing utility functions. I know all other 'module loading' behavior has been omitted in favor of security.

Note that if your automation script gets very long and you wish to speed it up, you may still use Lua's 'luac' byte-compiler to create an "automation.luac" byte-code file, and change the "LuaAutomationScript" debug setting to load the latter instead of "automation.lua"... As long as the automation script was compiled by you, you are safe from crafted byte-code injections.

Well spotted !

Both loadfile() and load() will be disabled in next release. They are dangerous, and could be used by LSL scripts (when the Lua llOwnerSay() hook is enabled) to inject crafted Lua byte-code, or to load modules from the main automation script, that could block the viewer execution if badly written...

I thought those might have been missed. I have been rapidly learning about Lua, not because I have any great plans for a script but because it is 'new to me'. I was trying to do what a good programmer would do and compartmentalize, make things reusuable and generally section up my code so it wasn't in a monolithic file.

Nice tip about 'luac'. I hadn't gotten that far yet and doubt I would ever need it. My automation.lua is just used to manipulate debug settings thus far, either via the OnSendChat() or sidebar buttons/dialogs. I am not doing, nor do I think I would, any serious processing of anything that would need that sort of speed improvement.

The buttons (as you mention in the forum post) run in another Lua context/state therefore I cannot use any of my own functions in them even if they are global. That is the main reason I started investigating the load/loadfile functions so that I could avoid needing to use an AutomationMessage() to deal with sidebar/dialog button communication.

Cheers.

AutomationMessage() is precisely designed to allow Lua command lines coming from buttons/scripts to communicate with the automation script. The latter should contain all the complex tasks, dispatched via its OnAutomationMessage() callback. I.e. the buttons should merely send a keyword to the OnAutomationMessage() callback, and the latter should do all the hard work.

Yes, this is what I'm doing. I was just attempting to find other ways to have execution of Lua in a button. That's how I found that load/loadfile() were 'exposed'. I am NOT using them since you will be disabling them.

BTW, I also decided to set up an Eclipse project with the LDT plug and a 'custom builder' to compile my automation.lua. It seemed like a good idea to save the viewer from doing that work and having some syntax checking is nice.

I was wondering if logging, configuration reading and possibly data persistence might be useful additions.

I tomorrow's release, there are four more functions available to the automation script (or more exactly two pairs) for reading and writing two specific debug setting strings (one in the global settings, the other in the per-account settings), which are designed for such a purpose as storing data/configuration between sessions. What you put in those strings and how you format the data in them will of course be your business to determine (no defined format, it's just a plain string as far as the viewer is concerned).

That's excellent. Useful for persisting things across sessions. BTW, AgentStand() doesn't seem to be available. Am I missing something on how to call it?

It's "AgentStandUp()" in the code and "AgentStand()" in the documentation... I just changed it to "AgentStand()" in the code for today's release, to mirror better the "AgentSit()" function name.

Thanks for getting the naming worked out on that.

I have a question not directly related to your additions to the viewer for executing Lua, but rather using Lua itself. I currently have a single .lua file and am using luac to compile it to bytecode for the viewer to pick up. All that works great, but my automation.lua is getting large especially since I have added serial/deserialize methods to make use of the new user data settings.

From what I have read, I should be able to create multiple .lua files and using luac combine them into a single bytecode file. A single file is created but I cannot seem to call any functions defined locally in the other files. I realize I can't create my own modules because of the 'require' restriction but I'm trying to achieve some form of compartmentalization of my own code since I will always compile. Maybe I just don't understand the usage of 'local' as it pertains to a separate file once it is compiled into bytecode. It seems to act more like it's private. I had been trying to avoid using globals in my automation.lua, maybe they are OK in the auxiliary files? Total noob at Lua.

Cheers