A video of my FOSDEM talk about Mono in Second Life and our plans for the future of scripting is now online (the slides are also available here ):
Watching back, I was surprised to hear myself say “Hooray!”, “Shit” and “Crap” quite so often…
While you’re catching up on FOSDEM talks, I recommend Miguel, Jeremie and Alan‘s talks from the Mono track. Unfortunately it doesn’t look like the very interesting talks on the XMPP track are available online, but I’m going to be catching up on lots of the talks I missed out on, including the key note talks on Saturday morning which I missed due to the very enjoyable beer event on Friday evening…
Back on our Happy Hippo campus in SL, a lively debate has sprung up about Mono’s possible lag-reducing effects! We have many students running comparable LSL scripts that have been pasted over the default “Hello, Avatar” code in their prims. Our campus store also has many product “vendors” running comparable scripts… but under different script UUIDs. So here’s our question: If we converted all of these commonly used scripts to Mono and did the following two things, could we actually reduce script-based lag in the sim and as a result, perhaps even allow more scripted product vendors to be set out?:
— Set up a “Mono Script Dispenser” from which users could drag commonly used Mono scripts (like door, texture-change, teleport, notecard-readers, and vehicle scripts) from a “centralized inventory source” into their prims.
— Have one staff member drag a single Mono “vendor script” from their inventory into each of our product vendors. (And if this would provide benefits, could they also accrue if we did the same with a regular LSL vendor script… or must Mono be used, as I believe?)
Most people we’ve asked say that such measures cannot reduce script-based sim lag because (basically) the “bytecode sharing” benefits of Mono that were advertised in the SL Wiki “only apply to text strings” and NOT to entire running scripts… or that our interpretation of the SL Wiki’s statements is incorrect. The Mono Wiki seems to imply pretty clearly, though, that these steps could reduce script-based lag (especially when extended to a large number of users running scripts with the same UUID), but our school would really appreciate some expert clarification!
Comments
Hello Jim/Babbage!
Back on our Happy Hippo campus in SL, a lively debate has sprung up about Mono’s possible lag-reducing effects! We have many students running comparable LSL scripts that have been pasted over the default “Hello, Avatar” code in their prims. Our campus store also has many product “vendors” running comparable scripts… but under different script UUIDs. So here’s our question: If we converted all of these commonly used scripts to Mono and did the following two things, could we actually reduce script-based lag in the sim and as a result, perhaps even allow more scripted product vendors to be set out?:
— Set up a “Mono Script Dispenser” from which users could drag commonly used Mono scripts (like door, texture-change, teleport, notecard-readers, and vehicle scripts) from a “centralized inventory source” into their prims. — Have one staff member drag a single Mono “vendor script” from their inventory into each of our product vendors. (And if this would provide benefits, could they also accrue if we did the same with a regular LSL vendor script… or must Mono be used, as I believe?)
Most people we’ve asked say that such measures cannot reduce script-based sim lag because (basically) the “bytecode sharing” benefits of Mono that were advertised in the SL Wiki “only apply to text strings” and NOT to entire running scripts… or that our interpretation of the SL Wiki’s statements is incorrect. The Mono Wiki seems to imply pretty clearly, though, that these steps could reduce script-based lag (especially when extended to a large number of users running scripts with the same UUID), but our school would really appreciate some expert clarification!
Many Thanks, Jim/Babbage!
Sincerely,
Dave (SL “Times Sands”)