loadScript¶
loadScript(file [, mode], [,env])
Load a Lua script file. This is similar to Lua's own loadfile() API method, but it uses OpenTx's optional pre-compilation feature to save memory and time during load.
Parameters¶
| Name | Req | Type | Description |
|---|---|---|---|
file | yes | string | Full path and file name of script. The file extension is optional and ignored (see mode param to control which extension will be used). However, if an extension is specified, it should be ".lua" (or ".luac"), otherwise it is treatedas part of the file name and the .lua/.luac will be appended to that. |
mode | no | string | (optional) Controls whether to force loading the text (.lua) or pre-compiled binary (.luac) version of the script. By default ETX will load the newest version and compile a new binary if necessary (overwriting any existing .luac version of the same script, and stripping some debug info like line numbers). You can use mode to control the loading behavior more specifically. Possible values are:
|
env | no | integer | See documentation for Lua function loadfile(). |
Returns¶
| Name | Type | Description |
|---|---|---|
- | function|nil | The loaded script, or nil if there was an error (e.g. file not found or syntax error). |
- | string|nil | Error message(s), if any. Blank if no error occurred. |
Availability¶
- Since:
2.2.0 - Radio support:
all
Notes¶
- Note that you will get an error if you specify
modeas "b" or "t" and that specific version of the file does not exist (eg. no .luac file when "b" is used). Also note thatmodeis NOT passed on to Lua's loader function, so unlike with loadfile() the actual file content is not checked (as if no mode or "bt" were passed to loadfile()).
Source¶
radio/src/lua/api_general.cpp
Extended Description¶
loadScript fills a similar role to Lua's loadfile(), but it adds EdgeTX-specific handling for .lua and .luac files. On radio targets, that usually means better load-time performance and lower runtime overhead when a compiled version is available.
Use the short summary from source annotations as the API-level definition. Keep the deeper usage guidance here, where it can evolve without expanding the firmware-source comment block.
Typical reasons to use loadScript directly:
- load reusable helper modules from the SD card
- control whether text or precompiled bytecode is preferred
- handle
nil, errmsgreturns explicitly when a script is missing or invalid