Cool VL Viewer forum http://sldev.free.fr/forum/ |
|
Lua scripting and viewer automation feature http://sldev.free.fr/forum/viewtopic.php?f=6&t=1736 |
Page 1 of 1 |
Author: | Henri Beauchamp [ 2017-01-14 11:14:35 ] |
Post subject: | Lua scripting and viewer automation feature |
Starting with v1.26.20.4, the Cool VL Viewer implements Lua (Lua v5.4 since v1.28.0.1) scripting/automation support. EDIT: it became way too tedious for me to maintain a full (70+ pages worth) Lua documentation on this forum, and for you to read it as an immense wall of text... Please, refer to the PDF manual instead. There is a specific thread for Lua scripting related feature requests. Please use it to post any such request. |
Author: | Henri Beauchamp [ 2017-01-28 14:53:34 ] | |||||||||
Post subject: | Sample Lua automation script | |||||||||
Sample/demonstration automation script (user_settings/automation.lua):
|
Author: | Henri Beauchamp [ 2017-02-13 09:37:11 ] |
Post subject: | Sample Lua automation script |
Here is what the Lua status bar icon looks like: ![]() And here is an example of a side-bar corresponding to the sample script given in the previous post: ![]() |
Author: | Henri Beauchamp [ 2017-03-28 09:18:38 ] | |||||||||
Post subject: | Firestorm's parcel Windlight emulation with Lua | |||||||||
Here is a simple way to emulate Firestorm's parcel Windlight support in the Cool VL Viewer, via Lua (just add/merge to your automation.lua script):
Notes:
|
Author: | Henri Beauchamp [ 2019-01-05 11:49:39 ] | |||||||||||||||||||||||||||
Post subject: | Custom Lua floaters | |||||||||||||||||||||||||||
Custom Lua floaters are supported via specific functions. Here is an example of how to use them. First, add a "floater_lua_test.xml" file to your custom skins directory ("~/.secondlife/skins/default/xui/en-us/" under Linux and "%appdata%\SecondLife\skins\default\xui\en-us\" under Windows) containing the following XUI floater definition:
Then, add this code to your automation.lua script:
Finally, log in with the viewer and type in the chat:
Have fun ! ![]() |
Author: | Henri Beauchamp [ 2019-02-23 14:40:41 ] |
Post subject: | Lua script files preprocessing |
The Cool VL Viewer v1.26.22.36 released today implements Lua script files preprocessing support via a built-in prepocessor. When loading a Lua script file (be it the automation script or any script you would load via the "Advanced" -> "Lua scripting" menu), the viewer first attempts to load the file as a genuine Lua script file and, on failure (which happens if it encounters preprocessor #directives elsewhere than on the first line of the script (*)), it hands over the file to the built-in preprocessor, which returns a (long) string containing the preprocessed sources, the Lua interpreter then being fed again with it in a second (and last) attempt to execute the script. (*) As per Lua specifications, the first line of any script that would start with a '#' is ignored. This is to cope with shebang lines. |
Author: | Henri Beauchamp [ 2020-08-22 09:22:48 ] | ||||||||||||||||||
Post subject: | Lua threads support | ||||||||||||||||||
The Cool VL Viewer v1.28.0.6 released today implements Lua automation threads. So far, the Cool VL Viewer could only execute (relatively) short sequences of Lua code based on automation script callbacks (or command lines), and that Lua code was executed within the main thread/loop of the viewer, meaning the more complex the code and the more the frame rate would 'hiccup' (given the burst-like load of such Lua callbacks). Also, to avoid freezes or infinite loops, the Lua code executed by the automation script is subject to a watchdog (short) timeout, meaning you cannot perform very complex and long processing this way. With automation threads, you may now run a full Lua program (and in fact up to 8 Lua programs) in the background (your OS will affect those threads to unused or lightly loaded CPU cores, meaning they won't even slow down the viewer itself !). A Lua thread is started (from the automation script only) by loading a separate Lua file and executing it as a separate "Lua state". However, that thread still gets the opportunity to call the viewer-specific Lua commands (even non-thread-safe ones, thanks to a special and transparent mechanism), just like if they would be executed by the automation script itself. It may also exchange data with the automation script (and other threads) via "signals". A Lua thread source is a Lua program file containing at least a ThreadRun() function as an entry point for the thread looping code. ThreadRun() is called at each thread loop and must return a boolean; when the latter is true, the thread keeps running and ThreadRun() is called again after a 1ms "sleep" (which is used both to yield to the OS and allow threads rescheduling by the latter, and to avoid "eating up" a full CPU core when ThreadRun() executes very short sequences of Lua code). Whenever ThreadRun() returns false, the thread is stopped and destroyed. When it is launched by the automation script (via the StartThread() function), the thread may receive parameters in a global "argv" table. Note that to avoid infinite loops and to allow timely detection of thread stopping requests from the viewer, the ThreadRun() function execution time is still bound by a 0.5s watchdog. However, a special Sleep() Lua function is available to threads, which resets the watchdog when invoked (because signals and thread stopping requests are checked/processed during the Sleep() call, even when sleeping for 0ms); so, even if each ThreadRun() involves complex/long processing, you can ensure it will not be interrupted by the watchdog under normal operation, by calling Sleep() appropriately. The Lua thread program file may also contain an OnSignal() callback (and the automation script may also have such a callback to receive data from threads). This callback is entered whenever another thread (or the automation script) invokes SendSignal(), directing it to our thread. As for the viewer-specific Lua functions which are not thread-safe (e.g. SendChat()), the mechanism I implemented ensures they can be called from threads nonetheless (they cause the thread to pause and set a variable indicating to the viewer main thread that it needs the corresponding code to be ran on its behalf, which is performed during the (badly named) "idle loop" of the viewer). The print() and warn() Lua functions receive a special treatment: they use an internal print buffer when invoked from a Lua thread and the text gets printed in the viewer chat on the next return of ThreadRun(), on the next invocation of Sleep() or of a non-thread-safe viewer-specific Lua function invocation (whichever happens first). Here is a (dummy) example of how to use threads: 1.- Add this code to your automation.lua script:
2.- Create a "thread.lua" file and place it in user_settings/include/ (or in user_settings):
3.- Start the viewer, and from the chat, enter: /lua print(AutomationRequest("thread")) /lua print(AutomationRequest("thread")) /lua print(AutomationRequest("thread! 2")) /lua print(AutomationRequest("thread")) /lua print(AutomationRequest("thread? 1")) /lua print(AutomationRequest("-thread 1")) /lua print(AutomationRequest("thread? 1")) etc... |
Author: | Henri Beauchamp [ 2021-12-18 09:16:56 ] | |||||||||
Post subject: | Example of LSL to Lua scripting | |||||||||
This is just an example of what can be done when using LSL and Lua in conjunction (here to automatically invite residents to a group based on a list of names stored in a note card). Do not forget to enable "Advanced" -> "Lua scripting" -> "Accept Lua from LSL scripts". To work, this scripts needs to be executed while logged in with the Cool VL Viewer is v1.28.2.52 or newer (it needs the new AgentGroupInvite() Lua function).
|
Author: | Henri Beauchamp [ 2024-01-15 15:05:37 ] | |||||||||
Post subject: | FPS limiting and draw distance auto-adjustment | |||||||||
I just updated the PDF manual with functions for side bar buttons which can toggle fps limiting and optionally the auto-maximization of the draw distance based on the frame render time (i.e. when there is enough time left after rendering a frame when compared to the chosen fps limit, the DD is increased, and on the contrary, it is decreased when the fps actual rate falls below that chosen limit). The latter feature is very handy when sailing or flying, since it maximizes your view distance without ruining your frame rate. I will not update the script above (it is updated in the PDF manual however), but here is what you need to change in that example automation.lua script or your own script:
|
Page 1 of 1 | All times are UTC |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |