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
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.