Opening SLua script after compile error selects "LSO2" compile target (was: Recovering from "(0, 0) : ERROR : Syntax error")
inĀ progress
Hooten Haller
Possibly related to [https://feedback.secondlife.com/scripting-bugs/p/script-suddently-losing-connetion-with-the-server-on-save]
A few times I've gotten the above error. Fixing the syntax error does not eliminate the message āĀ it's as if the script inventory instance is permanently disabled. My workaround has been to copy the script text to a new inventory instance.
I was able to reproduce this on SLua Tombolo.
1) Create a block and add a new SLua script to it.
2) Change line 1 to:
``
xxx ll.Say(0, "Hello, Avatar!")
``3) Save. See an expected, normal error message.
4) Clone the object. Edit the script in the clone.
5) Notice the cloned script is marked not-running.
6) Use the external editor button to edit the cloned script. See the dreaded (0,0) error.
(I am using BBEdit as my external editor:
/usr/bin/open -a bbedit "%s"
)---
Second Life Project lua editor 7.1.12.13973830462 (64bit)
Release Notes
You are at 194.7, 250.2, 23.1 in SLua Tombolo located at simhost-0766603a88e3665d6.aditi
SLURL: secondlife://Aditi/secondlife/SLua%20Tombolo/195/250/23
(global coordinates 41154.7, 23802.2, 23.1)
Luau 2025-03-27.14115520293
Release Notes
CPU: Apple M2 Max (2400 MHz)
Memory: 32768 MB
OS Version: macOS 15.3.2 Darwin 24.3.0 Darwin Kernel Version 24.3.0: Thu Jan 2 20:24:23 PST 2025; root:xnu-11215.81.4~3/RELEASE_ARM64_T6020 x86_64
Graphics Card Vendor: Apple
Graphics Card: Apple M2 Max
OpenGL Version: 4.1 Metal - 89.3
Window size: 2602x2102
Font Size Adjustment: 96pt
UI Scaling: 1
Draw distance: 512m
Bandwidth: 3000kbit/s
LOD factor: 1.25
Render quality: 2
Texture memory: 21845MB
Disk cache: Max size 1638.4 MB (99.9% used)
HiDPI display mode: true
J2C Decoder Version: KDU v7.10.4
Audio Driver Version: OpenAL, version 1.1 ALSOFT 1.23.1 / OpenAL Community / OpenAL Soft: OpenAL Soft
Dullahan: 1.14.0.202408091638
CEF: 118.4.1+g3dd6078+chromium-118.0.5993.54
Chromium: 118.0.5993.54
LibVLC Version: 3.0.21
Voice Server Version: Not Connected
Packets Lost: 13/10384 (0.1%)
March 30 2025 06:20:01
Log In
H
Harold Linden
Merging the post about the script type being incorrect on scripts in inventory. The core underlying issue is that we don't currently have an accounting of what the _actual_ type of a script is on the script inventory item, and the various hacks we use to get around that don't work when a script is in an errored state or in user inventory.
Rider Linden is in the process of writing an implementation that should fix both those cases.
H
Harold Linden
Merged in a post:
Compiler Dropdown is Incorrect when opening a script from inventory
Tapple Gao
- Create a new script in inventory (not a prim):
default { state_entry() { llOwnerSay(llGetScriptName()); } }
- Select Compiler > LSL Mono
- Save
- Close and re-open the script
- Compiler now says "LSL 2025 VM" (incorrect)
- Drop the script in a prim
- Open the script in the prim
- Compiler now says "LSL Mono" (correct)
"LSL Legacy LSO2" also has this issue. "LSL 2025 VM" and "SLua" do not
SuzannaLinn Resident
Second Life Project Lua Editor 7.2.3.20386497225 (64bit)
It looks like all the LSL scripts, of any version, when opened from the inventory, show LSL 2025 VM. Even the ones compiled in the pre-Lua era.
Tapple Gao
Env:
Second Life Project Lua Editor 7.2.3.20386497225 (64bit)
You are at 109.9, 21.7, 23.0 in SLua Beta Porridge located at simhost-07e5b72529208ad6c.agni
(global coordinates 255854.0, 254486.0, 23.0)
Luau 2025-12-04.19944688578
OS Version: Linux 6.17.12-300.fc43.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Dec 13 05:06:24 UTC 2025 x86_64
H
Harold Linden
marked this post as
inĀ progress
TL;DR
: For now try setting the script type back to "SLua" in the in-world editor when this happens.This is an issue with how the sim tells the viewer what
kind
of script a script is. This has been an issue for 15 years, but previously the only side-effect was your script would be compiled as LSO2 rather than Mono. Now that there are multiple languages, it's a bigger issue because the viewer doesn't know what the language of script you're editing is unless it compiled successfully previously. We discovered this internally a week after the alpha release and are working on it.The reason this happens is because how the viewer has historically determined the desired compile target for a script is nasty. Essentially, the viewer asks the simulator what the type of the script it's about to edit is. To determine that, the server looks at the compiled bytecode of the script, and tells the viewer whether it's Mono, LSO2, or what have you. If there
is
no bytecode for the script, the simulator just tells the viewer that it doesn't know what the desired compile target is, and the viewer falls back to compiling for the legacy LSO2 target.Ultimately, using the call out to the simulator to ask about the bytecode was always a hack, and we're switching to a mechanism where we store the user's
intended
compilation target that will stick with the script even if the script compilation fails.Hooten Haller
I think, basically, if a syntax error exists in a script then a reinstantiation will come back borked. Reinstantiation can happen, for instance, when cloning or when the script is in an attachment and you re-log.