Summary
BridgeServer /eval always prepends return to the submitted script before passing it to LuaJ. This means anything but a single Lua expression hits a parse error.
Code: plugin/src/main/java/dev/ragger/plugin/scripting/ActorManager.java:567
public String eval(final String script) {
final LuaActor temp = new LuaActor(
"__eval", "return " + script, client, chatMessageManager, itemManager,
worldMapPointManager, this, null
);
...
}
Repro
curl -s -X POST http://localhost:7919/eval \
-H "Authorization: Bearer dev" \
-H "Content-Type: application/json" \
--data-binary '{"script":"local p = player.position(); return p.x"}'
Returns:
{"error":"[string 'return local p = player.position(); return p.x...']:1: unexpected symbol ..."}
The body becomes return local p = ... which isn't valid Lua.
Fix options
- Detect whether the script contains statements (look for
local, ;, multiple lines, function calls without a top-level return) and only prepend return for single-expression scripts.
- Wrap as
return (function() ... end)() so callers can write either form.
- Try parsing as
return <script> first, fall back to compiling <script> raw and capturing the last expression.
Option 2 is the simplest and most permissive — single-expression scripts still work because they get implicit-return semantics inside the function body when written with an explicit return.
Workaround
Until fixed, callers must squeeze everything into one expression with no local bindings:
Summary
BridgeServer/evalalways prependsreturnto the submitted script before passing it to LuaJ. This means anything but a single Lua expression hits a parse error.Code:
plugin/src/main/java/dev/ragger/plugin/scripting/ActorManager.java:567Repro
Returns:
The body becomes
return local p = ...which isn't valid Lua.Fix options
local,;, multiple lines, function calls without a top-levelreturn) and only prependreturnfor single-expression scripts.return (function() ... end)()so callers can write either form.return <script>first, fall back to compiling<script>raw and capturing the last expression.Option 2 is the simplest and most permissive — single-expression scripts still work because they get implicit-return semantics inside the function body when written with an explicit
return.Workaround
Until fixed, callers must squeeze everything into one expression with no
localbindings: