[sldev] Script to client channel.

Ambrosia chaosstar at gmail.com
Mon Feb 16 00:26:22 PST 2009


The main issue with enhanced lsl-to-client communication, like in
RestrainedLife that was mentioned as an example, is..

The change of behavior runs deep. RestrainedLife is not about the UI,
but direct client behavior for all sorts of things.
All effects and behavior that one'd want to be executed in the client
via messages coming from in-world would need to be implemented, and/or
at least selecteable. You'd have to have a either predefined messages
and commands with hardcoded effects, or some kind of template system
with which to program the viewer.

Added to that, the viewer'd need to allow for all kinds of implemented
functionality to be executed, given that the change'd not be for a
specifc system, but for people to build their own systems on (Again,
RestrainedLife was an example). The viewer architecture isn't that
easy. Implementing such a templating would be a huge undertaking, and
I see a huge potential for abuse as well if there is some kind of
default.

IMO the best solution for such quite deep changes of behavior is to
simply make a modified client for a specifc system, like
RestrainedLife is today. It's by far the more secure approach, if you
want such enhanced client functionality triggered by in-world objects.


When it comes to UI changes only, I also think the other way around
would be much nicer...create an UI that is scriptable via a language
like LUA.
World Of Warcraft is an -excellent- example what people can do with a
programmable LUA UI.

On Mon, Feb 16, 2009 at 09:13, Lawson English <lenglish5 at cox.net> wrote:
> Henri Beauchamp wrote:
>>
>> On Sun, 15 Feb 2009 19:58:55 +0000, ordinal.malaprop at fastmail.fm wrote:
>>
>>
>>>
>>> I am generally in favour of allowing more interaction between LSL and
>>>  the client, but I have to say that for something as basic and general  as a
>>> HUD, the method would give me pause.
>>>
>>> .../...
>>>
>>> What we _really_ need is a thorough overhaul of scriptable UI methods  so
>>> that scripts can expect consistent results between clients, whether  that
>>> means some sort of toolkit along the lines of Tk, or perhaps web  forms -
>>> but chat commands and blue button windows are not sufficient.  At the very
>>> least we need a way to enter text in a dialog box.
>>>
>>
>> Something like this is apparently already planned:
>> https://wiki.secondlife.com/wiki/LlTextBox
>>
>>
>
>
> Both llTextBox and llFloaterHUD
> (http://wiki.secondlife.com/wiki/LSL_Browser_HUD) have one flaw, IMHO:
>
> they use the existing chat channels (which are all public) to pass
> information back and forth. Given that a HUD can only be used by one avatar
> at a time, it seems worthwhile to implement a set of private HUD channels
> that offer a direct HUD <=> client connection without rebroadcast to the
> rest of the sim. A given HUD could reserve one or more channels that can't
> be intercepted by other prims/avatars, thereby providing a greater level of
> privacy and virtually no chance of spoofing the server or client unless you
> have physical access to the network connections.
>
> Lawson
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting
> privileges
>


More information about the SLDev mailing list