* Expands the SS13.lua module by adding loop helpers and functions to get the script runner. (#79081)
## About The Pull Request
`SS13.get_runner_client()` and `SS13.get_runner_ckey` will return the
client and the ckey respectively of the user who ran the lua script. Can
be unreliable after the first sleep or yield.
The SS13 module can now be made local as the tables that need to be
accessed globally have been moved to their own global variables.
Added `SS13.start_loop(time, amount, func)`, `SS13.end_loop(id)`,
`SS13.stop_all_loops()` that allow lua scripts to more easily make
loops. Removed the `timer` parameter from these functions, which
specified the timer subsystem to use.
Documentation on all new added functions have been added in the
lua/README.md
## Why It's Good For The Game
Getting the client who ran the script and the ckey that ran the script
is useful for self contained scripts that are looking for an entrypoint
(e.g. location to spawn some item/mob/structure). `dm.usr` is a special
variable used for other purposes and can be unreliable when used this
way even if there haven't been any sleeps or yields yet, so having a
dedicated variable and function to handle it makes things easier.
Being able to make the SS13 module local allows for more self-contained
scripts. Although this isn't super helpful because `require` will still
load the same object for all lua scripts loaded on the same state.
Basic looping helpers allow for lua scripts to more easily create loops
without needing to recursively do a `set_timeout` or to do a
`while(true) do SS13.wait(1) end` loop.
## Changelog
🆑
admin: Added SS13.get_runner_ckey() and SS13.get_runner_client() which
stores the ckey and returns the client of the user who ran the lua
script. Can be unreliable if accessed after sleeping.
admin: Added timer loop helpers to the SS13.lua module, check the docs
admin: The SS13.lua module can now be made local without causing any
errors.
/🆑
---------
Co-authored-by: Watermelon914 <3052169-Watermelon914@ users.noreply.gitlab.com>
* Expands the SS13.lua module by adding loop helpers and functions to get the script runner.
---------
Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com>
Co-authored-by: Watermelon914 <3052169-Watermelon914@ users.noreply.gitlab.com>
* More lua harddel fixes (#77556)
## About The Pull Request
Fixes some more lua harddel problems with lingering refs on the gc_guard
variable. This variable has been changed to a list instead and will get
cleared every time the SSlua subsystem fires so that lua instantiated
objects that are not tracked by the subsystem will essentially delete
themselves on the next tick, aka whenever the lua script sleeps.
Also removed the unnecessary and not completely functional
lua_reference_cleanup proc which wasn't even being called reliably
because the signal handler was the datum itself.
## Why It's Good For The Game
Fixes more harddel bugs, increases consistency.
Co-authored-by: Watermelon914 <3052169-Watermelon914@ users.noreply.gitlab.com>
* More lua harddel fixes
---------
Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com>
Co-authored-by: Watermelon914 <3052169-Watermelon914@ users.noreply.gitlab.com>
* Fixes some lua problems, specifically with qdeling callbacks and adds lua utility functions (#77468)
## About The Pull Request
See title. Callbacks were getting deleted in SS13.lua which is
non-ideal. They should be automatically collected by the garbage
collector.
Also adds some utility lua functions like SS13.is_valid,
SS13.stop_tracking, SS13.new_untracked, SS13.type and SS13.qdel
## Why It's Good For The Game
Fixes some harddel issues, as well as callbacks clogging up the garbage
subsystem.
## Changelog
🆑
admin: Added new lua functions: SS13.is_valid, SS13.stop_tracking,
SS13.new_untracked, SS13.type and SS13.qdel
/🆑
---------
Co-authored-by: Watermelon914 <3052169-Watermelon914@ users.noreply.gitlab.com>
* Fixes some lua problems, specifically with qdeling callbacks and adds lua utility functions
---------
Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com>
Co-authored-by: Watermelon914 <3052169-Watermelon914@ users.noreply.gitlab.com>
* Fixed lua-created atoms from hard deleting (#77391)
## About The Pull Request
Lua created atoms hard delete because they get added to a references
list without ever being cleared. This fixes that by registering a
qdeleting signal on them and removing them from the list on delete.
## Why It's Good For The Game
Harddel fixes
## Changelog
🆑
fix: Fixed a hard delete that would occur with lua-created atoms.
/🆑
---------
Co-authored-by: Watermelon914 <3052169-Watermelon914@ users.noreply.gitlab.com>
* Fixed lua-created atoms from hard deleting
---------
Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com>
Co-authored-by: Watermelon914 <3052169-Watermelon914@ users.noreply.gitlab.com>
* Auxtools is now a config opt-in (#74501)
See https://github.com/tgstation/tgstation/pull/74497
Causes auxtools to not be a default part of the server environment and
requires server operators to manually enable it.
---------
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Auxtools is now a config opt-in
---------
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* bumps auxlua to 1.4.0 (#72108)
## About The Pull Request
Mothblocks recently talked about wanting an auxlua function to check if
the lua state was about to overrun its execution limit, and that was
something I had been thinking about for a long time prior, but never
bothered to actually implement until it was brought up. So I did just
that. The documentation has also been updated to include a description
of how the execution limit works and how to use the new function,
`over_exec_time`
## Why It's Good For The Game
Allows for lua loops of indeterminate length to do as much work as they
reasonably can in a single tick without setting off the execution
limiter and erroring out.
## Changelog
🆑
admin: Adds a new function for admin lua scripting, "over_exec_time",
for checking if lua code is running close to the execution limit.
Details are available in the lua editor's help menu.
admin: The execution limit is described in detail in the lua editor's
help menu.
/🆑
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* bumps auxlua to 1.4.0
Co-authored-by: Y0SH1M4S73R <legoboyo@earthlink.net>
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Fixes hard-dels related to lua signal handlers (#69555)
When I changed the syntax of SS13.lua to account for the ability to properly index tables with datums, it turns out that the callbacks created for signal handlers and timeouts had circular references, resulting in hard-deletes.
My first solution was to make it so signal handler and timeout callbacks use weakrefs, which get resolved in lua_state/call_function, but it turns out that, when calling the signal cleanup function, a qdeleted-but-not-yet-garbage-collected datum's weakref resolves to null because datum.gc_collected is set to GC_CURRENTLY_BEING_QDELETED before COMSIG_PARENT_QDELETING gets sent.
To resolve this issue, Potato and Oranges both recommended that I make a snowflake variant of resolve which ignores whether the datum a weakref points to is qdeleted - only that it is null or it's weakref isn't the very weakref resolve was called on. This proc was given a lengthy autodoc comment describing when it should or shouldn't be used, to ensure it is only used in cases similar to the one I needed to create it for (needing to resolve a weakref to a datum in a COMSIG_PARENT_QDELETING handler registered on that very datum).
* Fixes hard-dels related to lua signal handlers
Co-authored-by: Y0SH1M4S73R <legoboyo@earthlink.net>
* [Lua] You can now `await` expensive non-sleeping procs. (#69570)
When trying to run getFlatIcon using lua scripting, I discovered that it was so expensive that, for certain atoms like complex humans, there is no way it will complete within the lua execution limit. While Mothblocks would suggest just raising the execution limit, the idea leaves a bad taste in my mouth due to the possibility of a script causing extreme lag by consistently overrunning the BYOND tick.
I instead elected to make /datum/auxtools_promise sleep once before invoking its assigned proc, thus immediately returning execution to lua, even if the proc being awaited wouldn't sleep. This allows for awaiting extremely expensive non-sleeping procs (like the aforementioned getFlatIcon)
* [Lua] You can now `await` expensive non-sleeping procs.
Co-authored-by: Y0SH1M4S73R <legoboyo@earthlink.net>
* Lua UI improvements (#68887)
Atomized from #68816, with a little addition. Fixes some dumb formatting issues with the lua editor, adds a "jump to bottom" button when viewing the state log, and paginates the state logs.
* Lua UI improvements
Co-authored-by: Y0SH1M4S73R <legoboyo@earthlink.net>
* Fixes a lua state null return related to the print wrapper, improves the lua editor ui formatting, and implements a stopgap lua lag fix (#68816)
This PR fixes this issue by making sure every proc called in the stack of /proc/wrap_lua_print which could sleep is called using INVOKE_ASYNC, and to prevent such problems in the future, marks all the wrappers as SHOULD_NOT_SLEEP(TRUE). I also figured out how to fix the dumb overflowing problem of the lua editor ui.
Due to lag concerns regarding lua states with a large number of global variables (including fields within global tables), I have made it so the global table and state log are hidden by default - they can be shown using a toggle button in the editor ui.
* Fixes a lua state null return related to the print wrapper, improves the lua editor ui formatting, and implements a stopgap lua lag fix
Co-authored-by: Y0SH1M4S73R <legoboyo@earthlink.net>
