Virtual Worlds Best Practices in Education (VWBPE) 2020 Special considerations for large and complex projects in Second Life.

1. VWBPE 2020
Overcoming Limitations of LSL
for SL and OpenSim
JB Hancroft
jbhancroft@gmail.com

2. Agenda
- Introduction
- Objective
- Terminology / Background
- Limitations

3. Introduction
- Professional scripter and game designer
- Dept of Defense (DOD) Federal Virtual World
Challenge (FVWC) award winner
- SLPro! presenter (LindenLab conference)
- Clients include - universities, gov't and military,
pharma companies, R&D, others

4. Objectives
Provide you with some practical solutions to
work around LSL and SL/OpenSim limitations.
A blend of design approach and specific technical
solutions...

5. Terminology / Background (1)
- LSL is an event-driven language
- Events (e.g. a message input on a listen, a timer, a link
message, a web-server reply, etc.)
- Multiple scripts in an object run in parallel, often in an
unpredictable order
- Messages between scripts are called link messages
- Messages between objects: I call them "listen" messages

6. Terminology / Background (2)
- Messages from a web or database server: let's call them
HTTP messages (or “off-world server”)
- Mono - the larger and faster of the compiled run-time
object formats (checkbox when you Save a script)
- Viewer - what you run locally, as a "fat" client
- Sim/region - the portion of the server dedicated to
simulating your virtual land, objects, and experience

7. Memory limit of 64k per Mono script
Solution: run multiple parallel scripts
Key to success: each one 'owns' certain data
as the 'source of truth' for that data, and owns
the operations on that data
Be careful - by default, each script Saved as Mono
takes up the full 64K code/stack/heap space.
See llSetMemoryLimit( )

8. Too Many running scripts causes lag
Solution 1: turn scripts off when you don't need
them
llSetScriptState("script name",FALSE);
But, this is still taking up memory, even when not
running

9. Many running scripts can cause lag
Solution 2: have an object act as a script
warehouse that can send over a script to the
desire destination, on demand
llSetRemoteScriptAccessPin( ) - sets the PIN
llRemoteLoadScriptPin( ) - transfers the script

10. Too many running scripts causes lag
Solution 3: Use off-world computing (e.g. a web
server)
This is particularly useful for applications that
need to work with large sets of text data.
Example - store error message text off-world (web
server)
Alternative - keeping all of the text in a script (poor
use of memory) or a local Notecard (can be slow)

11. Each script can have only 1 timer
event pending
Solution:
Have a separate 'timers' script that will manage
multiple stacked and/or interleaved timers, which
are then signalled by using llMessageLinked( );

12. Too many link messages...
LSL has an event queue of 64 events, then events
get dropped (without warning)
Solution: use a link message 'logging script' to see
what actual sequence of messages are being
sent, to where, and when (this is a great
debugging technique, will help you confirm your
design is working as expected, and help eliminate
extra link message traffic)

13. Too many link messages...
Solution: have scripts ignore high-frequency link
messages by filtering them out first, before
checking all of the other things that the script must
do.
if (num != 12000) return;
<rest of your code>

14. Too many link messages...
Separate the scripts into functional groups and put
the groups of scripts into separate prims.
llMessageLinked(<prim number>,...) lets you
direct the message to a particular destination
prim, reducing the amount of messages that ALL
of the scripts need to process.
(You might consider this link message "routing")

15. Too many link messages...
For scripts that broadcast 'status' or data updates,
have them cache the previous version of what
was sent out.
If the data hasn't changed, don't send it again
(Suggestion: have a way to force the message to
be sent, in some circumstances)

16. Too many link messages...
Solution: Localize code, to reduce link message
'noise', so it's a procedure call, not a link msg
Avoid over-factoring your code into too many
scripts.
(This can be difficult, in very large projects)

17. Unreliable code execution order
In SL, you have to take extreme measures to
control the order in which scripts reset, start, or
run. Very complicated sets of parallel scripts can
exhibit widely varying or intermittent behavior.
Solution: make your design as asynchronous as
possible, ideally allowing the restart of any one
script at any time, with all required data being
provisioned by other scripts. This will decouple
your design/build/test sequence from having to do
a complete restart of everything on each and
every code change.

18. SL has region restarts / rollbacks
Think about restarts and rollbacks during the
design phase of your project, before you get
deeply invested in an approach that might be
crippled by a rollback.
You can detect a rollback by keeping some 'state'
on an off-world / external server, and watching for
a change in SL to an earlier state.

19. Conclusions
Think about the structure of your design before
you start coding!
Think about small modules, but not too small.
Think about how your scripts run in parallel.
Think about performance ahead of time.
Make your design easy to maintain and debug.

20. Thank You!
Thank you for your time and attention. If you'd like
further information on any of what I've covered
here, please feel free to contact me:
Contact info:
email: jbhancroft@gmail.com
SL: JB Hancroft