Second Life Wiki - User contributions [en]

Talk:AW Groupies/Chat Logs/JoeLindenTPVBrownbag-2010-04-13

2010-04-14T17:46:30Z

Fred Rookstown:

== "Cost/Benefit" Debate?! ==

I cannot stress enough how infuriating the following comment by Joe Linden is (quoted from the transcript):

[12:21] [Voice Transcript] Joe Linden: we've ha a lot of internal debate around cost/benefit of OS

I'm sorry, but WHAT? Developers have spent hundreds, if not ''thousands'' of man-hours developing patches for Linden Lab '''FOR FREE''', and they have the gall to question whether it's cost-effective? If there is truly such a debate going on, '''Linden Lab no longer deserves Open-Source community assistance.''' They can pay someone $100USD an hour for patches from now on for all I care. -- [[User:Fred Rookstown|Fred Rookstown]] 17:44, 14 April 2010 (UTC)

Talk:AW Groupies/Chat Logs/JoeLindenTPVBrownbag-2010-04-13

2010-04-14T17:44:49Z

Fred Rookstown: "Cost/Benefit" Debate?!

== "Cost/Benefit" Debate?! ==

I cannot stress enough how infuriating the following comment by Joe Linden is (quoted from the transcript):

[12:21] [Voice Transcript] Joe Linden: we've ha a lot of internal debate around cost/benefit of OS

I'm sorry, but WHAT? Developers have spent hundreds, if not ''thousands'' of man-hours developing patches for Linden Lab '''FOR FREE''', and they have the gall to question whether it's cost-effective? If there is truly such a debate going on, ''Linden Lab no longer deserves Open-Source community assistance.'' They can pay someone $100USD an hour for patches from now on for all I care. -- [[User:Fred Rookstown|Fred Rookstown]] 17:44, 14 April 2010 (UTC)

User:Fred Rookstown

2010-03-22T04:11:10Z

Fred Rookstown:

Blah blah blah, I do coding and stuff.

== Current things I'm working on ==

Due to 3PVP shenanigans, I've decided to no longer support the "open source" Linden Lab viewer nor any more of its protocols. The company has become quite delusional in its expectations of 3rd-party, unpaid, open-source developers.

User:Fred Rookstown

2010-03-02T23:43:42Z

Fred Rookstown: Naaaah. nvm.

Blah blah blah, I do coding and stuff.

== Current things I'm working on ==

* [[User:Fred_Rookstown/2WayLSLToViewerComms]] - An analysis and (maybe) proposal for 2-way script to viewer communications.
* [[User:Fred_Rookstown/SilverLining|Cloud and Virtual Weather Improvements]]
* [http://luna-viewer.googlecode.com/ Luna Viewer] - A viewer that provides an enormous level of extensibility via the Lua scripting language. May also implement the other stuff mentioned above.

User:Fred Rookstown

2010-03-02T23:43:12Z

Fred Rookstown:

Blah blah blah, I do coding and stuff.

== Current things I'm working on ==

* [[User:Fred_Rookstown/2WayLSLToViewerComms]] - An analysis and (maybe) proposal for 2-way script to viewer communications.
* [[User:Fred_Rookstown/SilverLining|Cloud and Virtual Weather Improvements]]
* [[User:Fred Rookstown/Plugin Architecture|Plugin Stuff]]
* [http://luna-viewer.googlecode.com/ Luna Viewer] - A viewer that provides an enormous level of extensibility via the Lua scripting language. May also implement the other stuff mentioned above.

User:Fred Rookstown

2010-02-25T02:18:57Z

Fred Rookstown:

Linden Lab Official:Live Data Feeds

2010-02-02T07:13:14Z

Fred Rookstown:

{{:API Portal/navigation
|style=style="float:right;width:15em;padding-bottom:1em;"}}

== Homepage stats feed ==

; XML feed
: http://secondlife.com/xmlhttp/secondlife.php

; LLSD feed (With timestamps)
: http://secondlife.com/xmlhttp/homepage.php

; Newline-seperated key-value pairs, with timestamps (for [[llHttpRequest]]())
:http://secondlife.com/httprequest/homepage.php

These feeds display:

* status: ONLINE when the grid is online. (What other values are presented?)
* signups (in # of accounts): number of Resident accounts that are open and in good standing; updated daily
* logged_in_last_60 (in # of accounts): number of Resident accounts that have logged in in the past 60 days; updated daily
* transactions (in US$): amount of resident-to-resident L$ transactions for past 24 hours divided by the average LindeX exchange rate for past 24 hours; updated every 30 minutes
* inworld (in # of accounts): number of Resident accounts currently logged in; updated every 3 minutes

== LindeX data feeds ==

; [[LLSD]]-formatted XML
:http://secondlife.com/xmlhttp/lindex.php

;Newline-separated key-value pairs for [[llHttpRequest]]()
:http://secondlife.com/httprequest/lindex.php

The LindeX feeds are updated every 15 minutes and include one set of timestamps.

[https://blogs.secondlife.com/community/features/blog/2006/10/03/new-data-feeds-1 Source]

Bug triage/2010-01-25

2010-01-18T04:09:06Z

Fred Rookstown: Yell at me if I'm doing it wrong. :|

{{Bug triage}}

<onlyinclude>
{{Triage Template/schedule
|Date=2010-01-18
|Time=12:00 NOON SLT
|Place=[http://slurl.com/secondlife/Hippotropolis/241/32/23 Hippotropolis Meeting area].
|}}
</onlyinclude>

Next meeting: {{#var:date}} at {{#var:time}} at {{#var:place}}. See [[Bug triage]] for details.

== Fast Track Import ==
(Move bugs here that have solid repros, or valid patches that you have reviewed)

* {{jira|VWR-6484}} - Votes: 19 - Minimap height indicators all show ""lower than me"" if over the old 768 build ceiling - {{User|Buckaroo Mu}}
** Status?
* {{jira|VWR-4137}} - Votes: 22 - Date columns in tables are sorted alphabetically - {{User|Celierra Darling}}
** Only two of the three were fixed.
* {{jira|SVC-4937}} - Votes: 29 - "The server is experiencing unexpected difficulties" error when saving a notecard inside a prim. - {{User|Bones Outlander}}
** Requesting status update be posted to pJIRA

== Hot by Vote ==
[http://jira.secondlife.com/secure/IssueNavigator.jspa?mode=hide&requestId=11885 High Voted Bugs]

* {{jira|SVC-5239}} - Votes: 97 - Details... button on PERMISSION_DEBIT dialog triggers run_time_permissions() with a deny action - {{User|ZenMondo Wormser}}

== Misc Pool ==
[http://jira.secondlife.com/secure/IssueNavigator.jspa?mode=hide&requestId=11885 Misc Pool]

* {{jira|MISC-3766}} - Votes: 0 - Logged first here in JIRA, referred over to tech support, left unresolved and told to re-enter here as a bug. - {{User|Laneybug Macbain}}
* {{jira|SVC-5237}} - Votes: 0 - LLGetLocalPos - {{User|Benjamin Bowenford}}
* {{jira|VWR-16132}} - Votes: 0 - Parts of Avatar become invisable when wearing ALPHA texture cloth(s)ing - {{User|Master Kane}} - Last Triaged: 11/16/2009 9:26 AM
* {{jira|VWR-9093}} - Votes: 4 - Female shape, torso muscularity slider bug... - {{User|Lanfer Christensen}}
* {{jira|SVC-4900}} - Votes: 3 - llUnescapeURL does not unescape + character - {{User|Dedric Mauriac}}
* {{jira|SVC-4860}} - Votes: 2 - when teleport routing is set to blocked people can not enter directly into parcel when i tp them myself - {{User|Alexandrea Fride}}
* {{jira|VWR-12870}} - Votes: 2 - Loggong out of linux viewr version 1.22.11.113941 hangs computer - {{User|Corin Clary}} - Last Triaged: 1/5/2010 10:08 AM
* {{jira|VWR-16535}} - Votes: 2 - Unicode displays as question marks in object name/descriptions - {{User|Dedric Mauriac}}
* {{jira|VWR-16294}} - Votes: 7 - When using llDetachFromAvatar() after teleport the objects still appears attached to the user but not to other residents and becomes almost impossible to detatch. - {{User|Madeline Kaligawa}}
* {{jira|VWR-5710}} - Votes: 6 - No-transfer or no-modify objects can't be copied into attachments. - {{User|Argent Stonecutter}} - Last Triaged: 11/6/2008 11:37 AM
* {{jira|VWR-8468}} - Votes: 6 - HUD group does not change when active group changed - {{User|Annie Obscure}} - Last Triaged: 8/13/2008 9:47 AM
* {{jira|WEB-673}} - Votes: 6 - http://secondlife.com/support/downloads.php requires javascript - {{User|Kephra Nurmi}}
* {{jira|VWR-11360}} - Votes: 5 - Linux beta crash on loading for Intel 945 series - {{User|Heather Kincess}}
* {{jira|VWR-14070}} - Votes: 5 - terrain blending not rendering with new viewer update - {{User|Uri Jefferson}}
* {{jira|VWR-15844}} - Votes: 5 - "llDetectedTouchPos does not return relative positition from attach poing, but position on screen when attached as a HUD" - {{User|Tron Kaffebaum}}
* {{jira|VWR-2727}} - Votes: 5 - Primatives sometimes disappear from view. Depends on direction of view. - {{User|Mupsey Greenwood}}
* {{jira|VWR-3291}} - Votes: 5 - "Arrow Keys Always Move Avatar While Chatting", when disabled, should allow up arrow to do chat history. - {{User|Gigs Taggart}}
* {{jira|VWR-6001}} - Votes: 5 - Landing on a slope the avatar turns and flies downhill - {{User|JC Sandial}}
* {{jira|WEB-645}} - Votes: 5 - Friendslist not any longer sorted by name - {{User|Bibi Book}}
* {{jira|MISC-1960}} - Votes: 4 - Make PJIRA name capitalization match Second Life capitalization - {{User|Data Linden}}
* {{jira|MISC-2860}} - Votes: 4 - SLIM incorrectly show friends as offline who are actually logged on to SL - {{User|absolute balderdash}}
* {{jira|MISC-3256}} - Votes: 4 - Route 9 parcels mislabeled - {{User|Athanasius Skytower}}
* {{jira|SVC-1003}} - Votes: 4 - llLoadURL does not open secondlife:// slurls - {{User|Emma Nowhere}}
* {{jira|SVC-1242}} - Votes: 4 - Texture Animation is not copied (llSetTextureAnim) - {{User|Haravikk Mistral}}
* {{jira|SVC-2066}} - Votes: 4 - Loss of sync in AO walk when going over even tiniest of surface irregualrity - {{User|Ravanne Sullivan}}
* {{jira|SVC-2310}} - Votes: 4 - Physics Object sinking - {{User|Jay Karlfeldt}}
* {{jira|SVC-4685}} - Votes: 1 - Not possible to drop inventory into objects which are using an full alpha texture (when highlight transparent is disabled) - {{User|EddyFragment Robonaught}}
* {{jira|SVC-471}} - Votes: 1 - llGetNextEmail no longer recieves mail from UUID@lsl.secondlife.com - {{User|Kae Fox}}
* {{jira|SVC-4895}} - Votes: 1 - tools>Recompile Scripts in Selection & Reset Scripts in Selection intermitantly fails to apply to all prims in link set. - {{User|EddyFragment Robonaught}} - Last Triaged: 10/7/2009 7:51 AM
* {{jira|SVC-4994}} - Votes: 1 - "vehicles won't start, or run for only a couple seconds" - {{User|Frank Skosh}}
* {{jira|SVC-5095}} - Votes: 1 - llGetOwnerKey on detaching object is incorrect - {{User|Sierra Janus}}
* {{jira|SVC-667}} - Votes: 1 - llModifyLand does not work while the scripted object is dragged by an avatar - {{User|Hiro Pendragon}}
* {{jira|SVC-893}} - Votes: 1 - Right shift operator (>>) fills extra bits with 1 instead of 0 when the most significant bit of the number is set. - {{User|Radian Artaud}}
* {{jira|VWR-10240}} - Votes: 1 - Viewer crash while taking snapshot (with fanciful proportion) - {{User|Gally Young}}
* {{jira|VWR-10429}} - Votes: 1 - Snapshot to disk hang on new unibody MacBook Pro with Nvidia 9600M GT - {{User|Rob danton}}
* {{jira|VWR-10486}} - Votes: 1 - Worn vehicle attachments lose their rotation when viewed approaching from out of visual range or teleporting to vehicle. - {{User|pointside sunbelter}}
* {{jira|VWR-11025}} - Votes: 1 - Coalesced items lost after refused rezing (similar to VWR-7194) - {{User|Sharon Gardenvale}}
* {{jira|VWR-11430}} - Votes: 1 - HIgh Res Snapshots saved to hard disk are solid black - {{User|AM Radio}}
* {{jira|VWR-11808}} - Votes: 1 - "No Notices, No Roles, No Inviting of People in a Group where I am the Owner!" - {{User|Cathrin Larsson}}
* {{jira|VWR-11968}} - Votes: 1 - Linux viewer locks itermittently when AV's in FOV - {{User|Pervus Maximus}}
* {{jira|VWR-12014}} - Votes: 1 - Some Mac keyboard shortcuts are essentially wrong - {{User|Nava Muni}}
* {{jira|VWR-12092}} - Votes: 1 - Unable to gracefully Undo edits made when Edit Linked Parts is selected and Root Prim is one of the prims moved - {{User|sera lok}}
* {{jira|VWR-1227}} - Votes: 1 - Saving texture makes you crash - {{User|Aradia Dielli}}
* {{jira|VWR-12307}} - Votes: 1 - Avatar gets traped in the void space - {{User|shamus carter}}
* {{jira|VWR-12612}} - Votes: 1 - "Small black spots flickering all over avatar when switching on Atmospheric Shaders in Prefs->Graphics, also skin texture errors occur" - {{User|Lamat Lisle}}
* {{jira|VWR-12745}} - Votes: 1 - render-pipeline brach (R 2079) RenderDeferred failing to enable - Patch - {{User|Shyotl Kuhr}}
* {{jira|VWR-13305}} - Votes: 1 - flickering alpha windows and trees - {{User|blaze nielsen}}
* {{jira|VWR-13453}} - Votes: 1 - SLim icon difficult to see in Vista - {{User|bobbyb30 swashbuckler}}
* {{jira|VWR-13963}} - Votes: 1 - Voice incompatible with PulseAudio - {{User|Vasko Hawker}}
* {{jira|VWR-14112}} - Votes: 1 - Water Disappears / High Packet Loss When Basic Shaders Enabled - {{User|Akamu Lurra}} - Last Triaged: 9/1/2009 1:17 PM
* {{jira|VWR-14283}} - Votes: 1 - After new update problems with graphics - {{User|Barziban Castaignede}}
* {{jira|VWR-14317}} - Votes: 1 - "SLVoice process continues to run even when SL is quit, hogs CPU and RAM" - {{User|Ochi Wolfe}}
* {{jira|VWR-14336}} - Votes: 1 - Textures don't load correctly in some random cases - {{User|Raul Crimson}}
* {{jira|VWR-14516}} - Votes: 1 - Private Adult sims showing up in seach places as PG because their group is listed as PG - {{User|Emily Darrow}}
* {{jira|VWR-14598}} - Votes: 1 - "Active Speakers list, voice 'dot' and level indicator failing" - {{User|Charlette Proto}}
* {{jira|VWR-14800}} - Votes: 1 - Viewer Crash on Mac OS when uploading any images - {{User|Kye Capelo}}
* {{jira|VWR-15044}} - Votes: 1 - I cannot detach Huds attached at bottom levels - {{User|Ren Javelin}}
* {{jira|VWR-15311}} - Votes: 1 - Copying a linked set of prims makes the prims location/rotation change in the copy - {{User|Beatrix MacKay}}
* {{jira|VWR-15813}} - Votes: 1 - Sculpt textures are not loaded. - {{User|AshleyLi Hoobinoo}}
* {{jira|VWR-15820}} - Votes: 1 - hover text does not fade out soon enough for megaprims - {{User|Doran Zemlja}} - Last Triaged: 11/23/2009 8:38 AM
* {{jira|VWR-2649}} - Votes: 1 - llTargetOmega does not work properly on attachments - {{User|eren padar}}
* {{jira|VWR-4089}} - Votes: 1 - Enabling certain beacons causes Windlight viewer to hang - {{User|Davey Callisto}}
* {{jira|VWR-4423}} - Votes: 1 - win_crash_logger compile error - {{User|yukiko omegamu}}
* {{jira|VWR-4874}} - Votes: 1 - Script-Changes in attached objects get lost when I re-attach it. - {{User|MartinRJ Fayray}}
* {{jira|VWR-5863}} - Votes: 1 - Crashed when trying to remove typing animation - {{User|Nikos Carling}}
* {{jira|VWR-6006}} - Votes: 1 - "Keyboard maping error on MAC with viewer SecondLife_1_19_1_4.dmg: Ctrl-Click (No mose present) no longer provides the same result as Right click when using a mousr with two buttons. No way to ""Touch"" an object unless two button mouse is used." - {{User|Enysy Mikita}}
* {{jira|VWR-6068}} - Votes: 1 - In Full Screen (Alt-Ctrl-F1) Whirling Particle Effects Visible Around Scripted Objects (Forcing Turning All Particles Off for Machinema Making) - {{User|sitearm madonna}}
* {{jira|VWR-6592}} - Votes: 1 - "Joystick - simultaneous walking/flying and turning, turning is unresponsive" - {{User|Jorgen Friis}}
* {{jira|VWR-7022}} - Votes: 1 - "PARCEL_MEDIA_COMMAND_AGENT, llDetectedKey(0)]); doesn't work correctly." - {{User|spider garrigus}}
* {{jira|VWR-7092}} - Votes: 1 - Dividing land issue with latest viewer version - {{User|Kevin Ludwig}}
* {{jira|VWR-8478}} - Votes: 1 - "Uploading not working, Vista SP1 (64 and 32 bit)" - {{User|Saiki Spirt}}
* {{jira|VWR-9037}} - Votes: 1 - Failure to Load Gestures bottlenecking inventory downloading - {{User|Ashlin McMahon}}
* {{jira|VWR-9271}} - Votes: 1 - SL requiring duplicate build commands and teleports - {{User|wayfinder wishbringer}}
* {{jira|VWR-9373}} - Votes: 1 - Freezing and Crashing when switching from Antialiasing and/or Anisotropic Filtering. - {{User|Jessicka Graves}}
* {{jira|SVC-3514}} - Votes: 35 - llLoadUrl (and other LLMessageBox-generating functions) should be per-agent throttled, not delayed - {{User|Darling Brody}}

== Pre-meeting activity ==
Some issues will be resolved in the course of building this agenda. Rather than deleting them from the proposed agenda, move the issue and associated discussion into the appropriate section below.

=== Imported ===

=== Resolved ===

== Transcript ==
Transcript is/will be at [[Bug triage/{{#var:date}}/Transcript]]

== Creating An Agenda ==
{{Bug List Instructions}}

User:Fred Rookstown

2010-01-06T05:46:50Z

Fred Rookstown: Adding FlexLife link.

Blah blah blah, I do coding and stuff.

== Current things I'm working on ==

* [[User:Fred_Rookstown/2WayLSLToViewerComms]] - An analysis and (maybe) proposal for 2-way script to viewer communications.
* [[User:Fred_Rookstown/SilverLining|Cloud and Virtual Weather Improvements]]
* [http://flexlife.nexisonline.net/ FlexLife Viewer] - A viewer that provides an enormous level of extensibility via the Lua scripting language. May also implement the other stuff mentioned above.

Linden Lab Official talk:Scripted Agent Status

2009-12-17T01:24:59Z

Fred Rookstown: Created page with '== Required == Does anyone know whether marking bots as bots is *required*? I have a bot I'm working on, but it's on an alt account of mine that I occasionally use for non-bot ...'

== Required ==

Does anyone know whether marking bots as bots is *required*? I have a bot I'm working on, but it's on an alt account of mine that I occasionally use for non-bot stuff; Do have to set that account as a bot? -- [[User:Fred Rookstown|Fred Rookstown]] 01:24, 17 December 2009 (UTC)

User:Fred Rookstown/SilverLining

2009-11-03T20:29:08Z

Fred Rookstown:

SilverLining is a (rather expensive; $1500 USD) weather SDK by [http://sundog-soft.com Sundog Software]. Although its emphasis is in rendering full 3D volumetric clouds in realtime and at high speed, it can also create spectacular weather effects, such as:

* Precipitation - SNow, rain, sleet, thunderstorms
* Heavenly body simulation (with precession and appropriate cloud highlighting)
* weather-related timezone management
* Scene lighting

In relation to the Second Life viewer, I am planning to replace the ugly legacy particle clouds with 3D volumetric ones from SilverLining. I may also end up replacing the unrealistic WL skydome with the SilverLining one, which appears to be greatly superior.

== Progress ==

(Cancelled for now, working on replacing the rendering engine with OpenScenegraph)

* '''Clouds''': 0%
* '''Skydome''': TBA
* '''Scene lighting''': 0%
* '''Funding:'''$0/1500 (Using evaluation SDK, 5 minutes max)

User:Fred Rookstown/2WayLSLToViewerComms

2009-10-14T01:43:10Z

Fred Rookstown:

This page shall contain analyses and protocol proposals for 2-way script/viewer communications, in an attempt to improve communications between scripts and viewers.

'''Feel free to add in your own thoughts and suggestions.''' I am also willing to host an "office hour" sort of thing at my lounge in Nolan if you wish to discuss this face-to-face with others in a realtime environment.

== Why? ==

In this age of OpenSource viewers, problems begin to crop up as viewers are modified to support additions to the client code that would not be possible via LSL, such as fast, reliable client-side radars and client-side BDSM restraints. One of the most major issues encountered by developers is the transmission of data back and fourth between LSL and the client itself. Although several methods exist, they can prove to inadequate. In addition, since no current standard of communication currently exists for reliable client<-> server communications, developers wishing to integrate their products with the client must go through a trial and error process in order to find the best solution, and even then, the solution may not be a reliable communications channel.

In addition, 2-way variable communications between LSL and client-side scripts (like Lua, being developed in the Emerald viewer) would open a gigantic new realm of possibilities in SL content creation that would not be possible with the current methods.

This wiki page aims to propose a reliable, simple-to-use method of sharing data between server-side LSL and the client itself.

== Communications methods ==

Since I am by no means an expert at messing with the SL client, feel free to correct me if you feel I am wrong with any point.

=== LLMessageSystem ===

The method LL uses to share information with their servers is via the LLMessageSystem class, which sends and receives raw TCP or UDP packets from the servers and deciphers them into a manageable format. It also performs automatic bandwidth throttling.

'''Pros:'''
* LLMessageSystem is the most direct way of talking to the sim server, which is where the scripts run.
* Relatively easy to use
* Already in place
* Automatically (de)serializes data as it's sent; Little to no typecasting required.
* Totally transparent to the user

'''Cons:'''
* Would require a message.xml change to implement a new message type, and on both ends (servers and viewer)
* Would require new LSL communications functions.
* Not necessarily the most reliable method.
* WOuld require a new capability to notify the server that the channel sharing code is available.

=== HTTP Client/Server ===

HTTP transmissions to and form the client and servers. Could be XMLRPC, REST, or just plain HTTP.

'''Pros:'''
* Somewhat fast, although it depends on application and workload.
* More reliable than LLMessageSystem
* Basic classes in place.
* Can send many datatypes.
* Can send a large volume of data.

'''Cons:'''
* More overhead than LLMessages.
* Would require operation of an HTTP server on the client to be able to share data to the client, would be difficult to access behind a NAT/Firewall (polling the server would lag the client and server to death).
* Would require significant LL-side changes to be able to handle HTTP data faster.
* Raw HTTP requires significant data processing in order to convert from the request/response to client-accessible data, many typecasting operations to handle, including unicode.

=== Chat ===

Chat communications is currently used by RestrainedLife and PAR/Emerald RadarChat, in order to convey information back and forth between the script and viewer.

'''Pros:'''
* Always in place.
* Can both send and receive data through NATs and firewalls.
* Simple to send data.

'''Cons:'''
* Requires the reservation of a channel for use with the component.
* Malicious/false data can be sent more easily than other methods.
* 1024 character limit, restricting size.
* Not reliable at all; Even minor lag can seriously affect communications.
* Easy for users to identify an open channel; Just listen on the chat channel. Bad for vendors and privacy in general.

=== Jabber/XMPP ===

From [http://www.xmpp.org/about/ XMPP.org]:

:''The Extensible Messaging and Presence Protocol (XMPP) is an open technology for real-time communication, which powers a wide range of applications including instant messaging, presence, multi-party chat, voice and video calls, collaboration, lightweight middleware, content syndication, and generalized routing of XML data. The technology pages provide more information about the various XMPP "building blocks". Several books about Jabber/XMPP technologies are available, as well.''

'''Pros:'''
* Open source
* Well-known protocol
* Has [http://xmpp.org/rfcs/ documented standards]
* Scalable (Decentralized, used in Google Talk)
* May shoehorn in long-overdue group chat fixes.

'''Cons:'''
* Requires implementation on both the servers and client.
** LL has already deemed XMPP-based messaging services too immature to implement.
* May require significant code changes to handle XMPP safely and securely.
* Additional libraries required on both servers and client
* Licensing may be an issue.

== LSL methods ==

What I am considering, for LSL, is the addition of functions to establish, maintain, and terminate a data sharing channel. A script would request a channel to a service on a particular agent (normally the owner but may be otherwise in other applications), and, if the server has been notified via CAPS (on login) that the agent has datashare channels, and that the specific service has been registered on that channel, the server will tell the script to go ahead with the operation (via an event or return value). The script then receives the client's shared variables, and the script can register its own shared variables.

<lsl>
integer datashare; // Resource pointer to the channel.

default
{
state_entry()
{
datashare = llRequestDatashare(llGetOwner(),"Radar",0); // 3rd option is a service version requirement. 0 means any version, non-zero means that the server will check if the service is at least that version before allowing it.
}

datashare(integer datashare_pointer,integer update_type)
{
if(update_type==DATASHARE_AVAILABLE && datashare==datashare_pointer)
{
llShareString(datashare,"ScriptRegion",llGetRegionName()); // 3rd argument can be left blank to receive the contents of the variable.
}
// Sent when the viewer has changed something in the channel.
if(update_type==DATASHARE_CHANGED && datashare==datashare_pointer)
{
llSay(0,"Viewer channel: "+llShareString(datashare,"ViewerChannel",""));
}
}
}
</lsl>

=== Functions/Keywords to Implement ===

I'm planning on implementing Datashares on OpenSim during the summer. The following is an LSL-side roadmap.

* Datashare Management
** [[User:Fred_Rookstown/llRequestDatashare|llRequestDatashare]]
** [[User:Fred_Rookstown/llCloseDatashare|llCloseDatashare]]
* Datashare variables
** Set
*** [[User:Fred_Rookstown/llShareString|llShareString]]
*** [[User:Fred_Rookstown/llShareInteger|llShareInteger]]
*** [[User:Fred_Rookstown/llShareFloat|llShareFloat]]
*** [[User:Fred_Rookstown/llShareKey|llShareKey]]
*** [[User:Fred_Rookstown/llShareList|llShareList]]

=== Implementations ===

The Emerald viewer uses a variant of this (called GreenLife Utility Streams).

SLDev Resident Names

2009-09-18T19:03:56Z

Fred Rookstown: + Moi

[[SLDev]] > '''SLDev Resident Names'''

Most things associated with Second Life development (in-world meetings, wiki editing, JIRA) are done using Second Life names, but posting on the mailing list is often done using another name (real name or non-Second Life alias). This page is intended as a decoder ring for people to figure out who's who on the [[SLDev]] mailing list.

Don't reveal any information you don't want to, but if you post messages to the SLDev mailing list under a different name than your Second Life Resident name, please consider dropping your name in the table. (Tip: putting three tildes, e.g. "<nowiki>~~~</nowiki>", will automatically convert to your name and a link to your username on this wiki) :

{|border="1" cellpadding="2" class=sortable
|-
!| SLDev Posting Name
!| Second Life Resident Name
|-
| Andre Roche || [[User:Ryozu Kojima|Ryozu Kojima]]
|-
| Andy Estes || [[User:Drewan Keats|Drewan Keats]]
|-
| Callum Lerwick || [[User:Seg Baphomet|Seg Baphomet]]
|-
| Dirk Moerenhout || [[User:Blakar Ogre|Blakar Ogre]]
|-
| Dzonatas || [[User:Dzonatas Sol|Dzonatas Sol]]
|-
| Ettore Pasquini || [[User:Abstra Apparatchik|Abstra Apparatchik]]
|-
| Harold "LabRat" Brown || [[User:Thraxis Epsilon|Thraxis Epsilon]]
|-
| Jason Giglio || [[User:Gigs Taggart|Gigs Taggart]]
|-
| John Hurliman || [[User:Eddy Stryker|Eddy Stryker]]
|-
| Laurent Laborde || [[User:Kerunix Flan|Kerunix Flan]]
|-
| Lawson English || [[User:Saijanai Kuhn|Saijanai Kuhn]]
|-
| Matt Kimmel || [[User:Feep Larsson|Feep Larsson]]
|-
| Mike Monkowski || [[User:Mm Alder|Mm Alder]]
|-
| Nik Radford || [[User:Nik Woodget|Nik Woodget]]
|-
| Neovo Geesink || [[User:Neovo Geesink|Neovo Geesink]]
|-
| Paul Nolan || [[User:Paul Churchill|Paul Churchill]]
|-
| Rob Lanphier || [[User:Rob Linden|Rob Linden]]
|-
| Ben B yer || [[User:Bushing Spatula|Bushing Spatula]]
|-
| Dana Fagerstrom || [[User:Whoops Babii|Whoops Babii]]
|-
| Dirk Husemann || [[User:Dr Scofield|Dr Scofield]]
|-
| Mark Burhop|| [[User:Burhop Piccard|Burhop Piccard]]
|-
| Stewart Berntson || [[User:Mydnight Miklos|Mydnight Miklos]]
|-
| Aimee Walton || [[User:Aimee Trescothick|Aimee Trescothick]]
|-
| Robin Cornelius || [[User:Robin Cornelius|Robin Cornelius]] & [[User:Michelle2 Zenovka|Michelle2 Zenovka]]
|-
| Henrik Hodne || [[User:Henrik Svendsen|Henrik Svendsen]]
|-
| Tigro Spottystripes || [[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]]
|-
| "Abhセレチャイベル"|| [[User:Freija Yoshikawa|Freija Yoshikawa]]
|-
| zai || [[User:Zai Lynch|Zai Lynch]]
|-
| Rob Nelson || [[User:Fred Rookstown|Fred Rookstown]]
|}

User:Fred Rookstown/SilverLining

2009-09-16T03:48:59Z

Fred Rookstown: Created page with 'SilverLining is a (rather expensive; $1500 USD) weather SDK by [http://sundog-soft.com Sundog Software]. Although its emphasis is in rendering full 3D volumetric clouds in realt...'

SilverLining is a (rather expensive; $1500 USD) weather SDK by [http://sundog-soft.com Sundog Software]. Although its emphasis is in rendering full 3D volumetric clouds in realtime and at high speed, it can also create spectacular weather effects, such as:

* Precipitation - SNow, rain, sleet, thunderstorms
* Heavenly body simulation (with precession and appropriate cloud highlighting)
* weather-related timezone management
* Scene lighting

In relation to the Second Life viewer, I am planning to replace the ugly legacy particle clouds with 3D volumetric ones from SilverLining. I may also end up replacing the unrealistic WL skydome with the SilverLining one, which appears to be greatly superior.

== Progress ==

* '''Clouds''': 20%
* '''Skydome''': TBA
* '''Scene lighting''': 0%
* '''Funding:'''$0/1500 (Using evaluation SDK, 5 minutes max)

User:Fred Rookstown

2009-09-16T03:41:31Z

Fred Rookstown:

User:Nyx Linden/Office Hours Agenda

2009-07-22T19:01:41Z

Fred Rookstown:

==Nyx Linden's Office Hours Agenda==

Office hours are on Wednesdays at Noon in Pacific time (SL standard time) located in Borrowdale at: http://slurl.com/secondlife/Borrowdale/74/217/32

Topics are focused on avatars, content creation efficiency, content creation tools and methods, rendering issues, and many related random topics.

Please post topics for discussion / agenda items here prior to 11:50 AM. Priority will be given to topics that are posted in advance and are relevant to the goals of the office hour. Feel free to include relevant links to JIRA or wiki pages. Contact Nyx Linden if you are unsure if your topic is relevant or appropriate.

Next meeting scheduled for: July 22, 2009.

===Agenda===
# Feedback on process for managing discussion topics
# Snapshot issues: http://jira.secondlife.com/browse/VWR-7709 (META entry, collecting most bugs)
# Hot permission issues: http://jira.secondlife.com/browse/SVC-4444 and http://jira.secondlife.com/browse/VWR-8049
# Improve avatar skirt mesh http://jira.secondlife.com/browse/VWR-2258
# Antique jira entries, but worth undusting - user created Linden Plants: http://jira.secondlife.com/browse/MISC-63 and http://jira.secondlife.com/browse/VWR-303
# Windlight water on a prim (Materials)

Talk:History/WindLight

2009-06-20T15:09:34Z

Fred Rookstown: /* Cli.gs got hacked */ new section

== Redirect ==
I have redirected the page Windlight to this one as if one forgets to capitalize the "L" in the search it took you to an empty page giving the wrong impression that a page on windlight did not exist.

[[User:ZenMondo Wormser|ZenMondo Wormser]] 19:59, 20 August 2007 (PDT)

== Regarding Hardware and Setting requirements ==

I added these because I think it's important for people to know off the bat. However I'm not sure if what I have there is 100% accurate, it's based on what I've experienced myself (On an ATI Radeon 9800) and what others in the First Look group have reported.

[[User:Oz Spade|Oz Spade]] 19:35, 29 May 2007 (PDT)

== Open Source? ==

*When and in what form will we see this coming to the open source viewer? Will it be library based or source code? --[[User:Blakar Ogre|Blakar Ogre]] 07:03, 30 May 2007 (PDT)
** The full source is already available at http://wiki.secondlife.com/wiki/Source_downloads#Betas_and_First_Look --[[User:BigPapi Linden|BigPapi Linden]] 14:15, 29 November 2007 (PST)

== Comments ==

Regarding ''We emphasize that you have a lot more control over how you look, so if you're basing your judgment without delving into the Advanced Sky Editor, we recommend you give it a go, and give it time.''

This is backwards. Windlight doesn't give you more control over how you look, it gives you more control over how you see. No matter how you tune your Windlight settings, it won't have any effect on how you look to other people using Windlight. If avatars look significantly different between Windlight and the normal client and if people end up using different fixes to the default settings, the difference between how different people see the same thing (already significant) will become far greater.

The default settings shouldn't be set for "showing off Windlight", they should be set for consistency. Dramatic sunlit avatars should be an option, not the default.
* This part needs more clarification — it's actually both. I'll update it. :) --[[User:Torley Linden|Torley Linden]] 14:53, 18 December 2007 (PST)

== Cli.gs got hacked ==

Cli.gs apparently got hacked, so the link to the presets no longer works. Could someone please provide a working link? -- [[User:Fred Rookstown|Fred Rookstown]] 15:09, 20 June 2009 (UTC)

User:Fred Rookstown/2WayLSLToViewerComms

2009-06-12T18:17:37Z

Fred Rookstown: /* Functions/Keywords to Implement */

User:Fred Rookstown/2WayLSLToViewerComms

2009-06-12T04:01:54Z

Fred Rookstown: /* Why? */ Adding note about Lua content

This page shall contain analyses and protocol proposals for 2-way script/viewer communications, in an attempt to improve communications between scripts and viewers.

'''Feel free to add in your own thoughts and suggestions.''' I am also willing to host an "office hour" sort of thing at my lounge in Nolan if you wish to discuss this face-to-face with others in a realtime environment.

== Why? ==

In this age of OpenSource viewers, problems begin to crop up as viewers are modified to support additions to the client code that would not be possible via LSL, such as fast, reliable client-side radars and client-side BDSM restraints. One of the most major issues encountered by developers is the transmission of data back and fourth between LSL and the client itself. Although several methods exist, they can prove to inadequate. In addition, since no current standard of communication currently exists for reliable client<-> server communications, developers wishing to integrate their products with the client must go through a trial and error process in order to find the best solution, and even then, the solution may not be a reliable communications channel.

In addition, 2-way variable communications between LSL and client-side scripts (like Lua, being developed in the Emerald viewer) would open a gigantic new realm of possibilities in SL content creation that would not be possible with the current methods.

This wiki page aims to propose a reliable, simple-to-use method of sharing data between server-side LSL and the client itself.

== Communications methods ==

Since I am by no means an expert at messing with the SL client, feel free to correct me if you feel I am wrong with any point.

=== LLMessageSystem ===

The method LL uses to share information with their servers is via the LLMessageSystem class, which sends and receives raw TCP or UDP packets from the servers and deciphers them into a manageable format. It also performs automatic bandwidth throttling.

'''Pros:'''
* LLMessageSystem is the most direct way of talking to the sim server, which is where the scripts run.
* Relatively easy to use
* Already in place
* Automatically (de)serializes data as it's sent; Little to no typecasting required.
* Totally transparent to the user

'''Cons:'''
* Would require a message.xml change to implement a new message type, and on both ends (servers and viewer)
* Would require new LSL communications functions.
* Not necessarily the most reliable method.
* WOuld require a new capability to notify the server that the channel sharing code is available.

=== HTTP Client/Server ===

HTTP transmissions to and form the client and servers. Could be XMLRPC, REST, or just plain HTTP.

'''Pros:'''
* Somewhat fast, although it depends on application and workload.
* More reliable than LLMessageSystem
* Basic classes in place.
* Can send many datatypes.
* Can send a large volume of data.

'''Cons:'''
* More overhead than LLMessages.
* Would require operation of an HTTP server on the client to be able to share data to the client, would be difficult to access behind a NAT/Firewall (polling the server would lag the client and server to death).
* Would require significant LL-side changes to be able to handle HTTP data faster.
* Raw HTTP requires significant data processing in order to convert from the request/response to client-accessible data, many typecasting operations to handle, including unicode.

=== Chat ===

Chat communications is currently used by RestrainedLife and PAR/Emerald RadarChat, in order to convey information back and forth between the script and viewer.

'''Pros:'''
* Always in place.
* Can both send and receive data through NATs and firewalls.
* Simple to send data.

'''Cons:'''
* Requires the reservation of a channel for use with the component.
* Malicious/false data can be sent more easily than other methods.
* 1024 character limit, restricting size.
* Not reliable at all; Even minor lag can seriously affect communications.
* Easy for users to identify an open channel; Just listen on the chat channel. Bad for vendors and privacy in general.

=== Jabber/XMPP ===

From [http://www.xmpp.org/about/ XMPP.org]:

:''The Extensible Messaging and Presence Protocol (XMPP) is an open technology for real-time communication, which powers a wide range of applications including instant messaging, presence, multi-party chat, voice and video calls, collaboration, lightweight middleware, content syndication, and generalized routing of XML data. The technology pages provide more information about the various XMPP "building blocks". Several books about Jabber/XMPP technologies are available, as well.''

'''Pros:'''
* Open source
* Well-known protocol
* Has [http://xmpp.org/rfcs/ documented standards]
* Scalable (Decentralized, used in Google Talk)
* May shoehorn in long-overdue group chat fixes.

'''Cons:'''
* Requires implementation on both the servers and client.
** LL has already deemed XMPP-based messaging services too immature to implement.
* May require significant code changes to handle XMPP safely and securely.
* Additional libraries required on both servers and client
* Licensing may be an issue.

== LSL methods ==

What I am considering, for LSL, is the addition of functions to establish, maintain, and terminate a data sharing channel. A script would request a channel to a service on a particular agent (normally the owner but may be otherwise in other applications), and, if the server has been notified via CAPS (on login) that the agent has datashare channels, and that the specific service has been registered on that channel, the server will tell the script to go ahead with the operation (via an event or return value). The script then receives the client's shared variables, and the script can register its own shared variables.

<lsl>
integer datashare; // Resource pointer to the channel.

default
{
state_entry()
{
datashare = llRequestDatashare(llGetOwner(),"Radar",0); // 3rd option is a service version requirement. 0 means any version, non-zero means that the server will check if the service is at least that version before allowing it.
}

datashare(integer datashare_pointer,integer update_type)
{
if(update_type==DATASHARE_AVAILABLE && datashare==datashare_pointer)
{
llShareString(datashare,"ScriptRegion",llGetRegionName()); // 3rd argument can be left blank to receive the contents of the variable.
}
// Sent when the viewer has changed something in the channel.
if(update_type==DATASHARE_CHANGED && datashare==datashare_pointer)
{
llSay(0,"Viewer channel: "+llShareString(datashare,"ViewerChannel",""));
}
}
}
</lsl>

=== Functions/Keywords to Implement ===

I'm planning on implementing Datashares on OpenSim during the summer. The following is an LSL-side roadmap.

* [[User:Fred_Rookstown/llRequestDatashare|llRequestDatashare]]

User:Fred Rookstown/2WayLSLToViewerComms

2009-06-12T03:57:00Z

Fred Rookstown: /* Jabber/XMPP */ Adding relevant RFCs for all us developers to gawk at.

This page shall contain analyses and protocol proposals for 2-way script/viewer communications, in an attempt to improve communications between scripts and viewers.

'''Feel free to add in your own thoughts and suggestions.''' I am also willing to host an "office hour" sort of thing at my lounge in Nolan if you wish to discuss this face-to-face with others in a realtime environment.

== Why? ==

In this age of OpenSource viewers, problems begin to crop up as viewers are modified to support additions to the client code that would not be possible via LSL, such as fast, reliable client-side radars and client-side BDSM restraints. One of the most major issues encountered by developers is the transmission of data back and fourth between LSL and the client itself. Although several methods exist, they can prove to inadequate. In addition, since no current standard of communication currently exists for reliable client<-> server communications, developers wishing to integrate their products with the client must go through a trial and error process in order to find the best solution, and even then, the solution may not be a reliable communications channel.

This wiki page aims to propose a reliable, simple-to-use method of sharing data between server-side LSL and the client itself.

== Communications methods ==

Since I am by no means an expert at messing with the SL client, feel free to correct me if you feel I am wrong with any point.

=== LLMessageSystem ===

The method LL uses to share information with their servers is via the LLMessageSystem class, which sends and receives raw TCP or UDP packets from the servers and deciphers them into a manageable format. It also performs automatic bandwidth throttling.

'''Pros:'''
* LLMessageSystem is the most direct way of talking to the sim server, which is where the scripts run.
* Relatively easy to use
* Already in place
* Automatically (de)serializes data as it's sent; Little to no typecasting required.
* Totally transparent to the user

'''Cons:'''
* Would require a message.xml change to implement a new message type, and on both ends (servers and viewer)
* Would require new LSL communications functions.
* Not necessarily the most reliable method.
* WOuld require a new capability to notify the server that the channel sharing code is available.

=== HTTP Client/Server ===

HTTP transmissions to and form the client and servers. Could be XMLRPC, REST, or just plain HTTP.

'''Pros:'''
* Somewhat fast, although it depends on application and workload.
* More reliable than LLMessageSystem
* Basic classes in place.
* Can send many datatypes.
* Can send a large volume of data.

'''Cons:'''
* More overhead than LLMessages.
* Would require operation of an HTTP server on the client to be able to share data to the client, would be difficult to access behind a NAT/Firewall (polling the server would lag the client and server to death).
* Would require significant LL-side changes to be able to handle HTTP data faster.
* Raw HTTP requires significant data processing in order to convert from the request/response to client-accessible data, many typecasting operations to handle, including unicode.

=== Chat ===

Chat communications is currently used by RestrainedLife and PAR/Emerald RadarChat, in order to convey information back and forth between the script and viewer.

'''Pros:'''
* Always in place.
* Can both send and receive data through NATs and firewalls.
* Simple to send data.

'''Cons:'''
* Requires the reservation of a channel for use with the component.
* Malicious/false data can be sent more easily than other methods.
* 1024 character limit, restricting size.
* Not reliable at all; Even minor lag can seriously affect communications.
* Easy for users to identify an open channel; Just listen on the chat channel. Bad for vendors and privacy in general.

=== Jabber/XMPP ===

From [http://www.xmpp.org/about/ XMPP.org]:

:''The Extensible Messaging and Presence Protocol (XMPP) is an open technology for real-time communication, which powers a wide range of applications including instant messaging, presence, multi-party chat, voice and video calls, collaboration, lightweight middleware, content syndication, and generalized routing of XML data. The technology pages provide more information about the various XMPP "building blocks". Several books about Jabber/XMPP technologies are available, as well.''

'''Pros:'''
* Open source
* Well-known protocol
* Has [http://xmpp.org/rfcs/ documented standards]
* Scalable (Decentralized, used in Google Talk)
* May shoehorn in long-overdue group chat fixes.

'''Cons:'''
* Requires implementation on both the servers and client.
** LL has already deemed XMPP-based messaging services too immature to implement.
* May require significant code changes to handle XMPP safely and securely.
* Additional libraries required on both servers and client
* Licensing may be an issue.

== LSL methods ==

What I am considering, for LSL, is the addition of functions to establish, maintain, and terminate a data sharing channel. A script would request a channel to a service on a particular agent (normally the owner but may be otherwise in other applications), and, if the server has been notified via CAPS (on login) that the agent has datashare channels, and that the specific service has been registered on that channel, the server will tell the script to go ahead with the operation (via an event or return value). The script then receives the client's shared variables, and the script can register its own shared variables.

<lsl>
integer datashare; // Resource pointer to the channel.

default
{
state_entry()
{
datashare = llRequestDatashare(llGetOwner(),"Radar",0); // 3rd option is a service version requirement. 0 means any version, non-zero means that the server will check if the service is at least that version before allowing it.
}

datashare(integer datashare_pointer,integer update_type)
{
if(update_type==DATASHARE_AVAILABLE && datashare==datashare_pointer)
{
llShareString(datashare,"ScriptRegion",llGetRegionName()); // 3rd argument can be left blank to receive the contents of the variable.
}
// Sent when the viewer has changed something in the channel.
if(update_type==DATASHARE_CHANGED && datashare==datashare_pointer)
{
llSay(0,"Viewer channel: "+llShareString(datashare,"ViewerChannel",""));
}
}
}
</lsl>

=== Functions/Keywords to Implement ===

I'm planning on implementing Datashares on OpenSim during the summer. The following is an LSL-side roadmap.

* [[User:Fred_Rookstown/llRequestDatashare|llRequestDatashare]]

User:Fred Rookstown/2WayLSLToViewerComms

2009-06-12T03:50:26Z

Fred Rookstown: /* Jabber */ -> Jabber/XMPP

This page shall contain analyses and protocol proposals for 2-way script/viewer communications, in an attempt to improve communications between scripts and viewers.

'''Feel free to add in your own thoughts and suggestions.''' I am also willing to host an "office hour" sort of thing at my lounge in Nolan if you wish to discuss this face-to-face with others in a realtime environment.

== Why? ==

In this age of OpenSource viewers, problems begin to crop up as viewers are modified to support additions to the client code that would not be possible via LSL, such as fast, reliable client-side radars and client-side BDSM restraints. One of the most major issues encountered by developers is the transmission of data back and fourth between LSL and the client itself. Although several methods exist, they can prove to inadequate. In addition, since no current standard of communication currently exists for reliable client<-> server communications, developers wishing to integrate their products with the client must go through a trial and error process in order to find the best solution, and even then, the solution may not be a reliable communications channel.

This wiki page aims to propose a reliable, simple-to-use method of sharing data between server-side LSL and the client itself.

== Communications methods ==

Since I am by no means an expert at messing with the SL client, feel free to correct me if you feel I am wrong with any point.

=== LLMessageSystem ===

The method LL uses to share information with their servers is via the LLMessageSystem class, which sends and receives raw TCP or UDP packets from the servers and deciphers them into a manageable format. It also performs automatic bandwidth throttling.

'''Pros:'''
* LLMessageSystem is the most direct way of talking to the sim server, which is where the scripts run.
* Relatively easy to use
* Already in place
* Automatically (de)serializes data as it's sent; Little to no typecasting required.
* Totally transparent to the user

'''Cons:'''
* Would require a message.xml change to implement a new message type, and on both ends (servers and viewer)
* Would require new LSL communications functions.
* Not necessarily the most reliable method.
* WOuld require a new capability to notify the server that the channel sharing code is available.

=== HTTP Client/Server ===

HTTP transmissions to and form the client and servers. Could be XMLRPC, REST, or just plain HTTP.

'''Pros:'''
* Somewhat fast, although it depends on application and workload.
* More reliable than LLMessageSystem
* Basic classes in place.
* Can send many datatypes.
* Can send a large volume of data.

'''Cons:'''
* More overhead than LLMessages.
* Would require operation of an HTTP server on the client to be able to share data to the client, would be difficult to access behind a NAT/Firewall (polling the server would lag the client and server to death).
* Would require significant LL-side changes to be able to handle HTTP data faster.
* Raw HTTP requires significant data processing in order to convert from the request/response to client-accessible data, many typecasting operations to handle, including unicode.

=== Chat ===

Chat communications is currently used by RestrainedLife and PAR/Emerald RadarChat, in order to convey information back and forth between the script and viewer.

'''Pros:'''
* Always in place.
* Can both send and receive data through NATs and firewalls.
* Simple to send data.

'''Cons:'''
* Requires the reservation of a channel for use with the component.
* Malicious/false data can be sent more easily than other methods.
* 1024 character limit, restricting size.
* Not reliable at all; Even minor lag can seriously affect communications.
* Easy for users to identify an open channel; Just listen on the chat channel. Bad for vendors and privacy in general.

=== Jabber/XMPP ===

From [http://www.xmpp.org/about/ XMPP.org]:

:''The Extensible Messaging and Presence Protocol (XMPP) is an open technology for real-time communication, which powers a wide range of applications including instant messaging, presence, multi-party chat, voice and video calls, collaboration, lightweight middleware, content syndication, and generalized routing of XML data. The technology pages provide more information about the various XMPP "building blocks". Several books about Jabber/XMPP technologies are available, as well.''

'''Pros:'''
* Open source
* Well-known protocol
* Has documented standards
* Scalable (Decentralized, used in Google Talk)
* May shoehorn in long-overdue group chat fixes.

'''Cons:'''
* Requires implementation on both the servers and client.
** LL has already deemed XMPP-based messaging services too immature to implement.
* May require significant code changes to handle XMPP safely and securely.
* Additional libraries required on both servers and client
* Licensing may be an issue.

== LSL methods ==

What I am considering, for LSL, is the addition of functions to establish, maintain, and terminate a data sharing channel. A script would request a channel to a service on a particular agent (normally the owner but may be otherwise in other applications), and, if the server has been notified via CAPS (on login) that the agent has datashare channels, and that the specific service has been registered on that channel, the server will tell the script to go ahead with the operation (via an event or return value). The script then receives the client's shared variables, and the script can register its own shared variables.

<lsl>
integer datashare; // Resource pointer to the channel.

default
{
state_entry()
{
datashare = llRequestDatashare(llGetOwner(),"Radar",0); // 3rd option is a service version requirement. 0 means any version, non-zero means that the server will check if the service is at least that version before allowing it.
}

datashare(integer datashare_pointer,integer update_type)
{
if(update_type==DATASHARE_AVAILABLE && datashare==datashare_pointer)
{
llShareString(datashare,"ScriptRegion",llGetRegionName()); // 3rd argument can be left blank to receive the contents of the variable.
}
// Sent when the viewer has changed something in the channel.
if(update_type==DATASHARE_CHANGED && datashare==datashare_pointer)
{
llSay(0,"Viewer channel: "+llShareString(datashare,"ViewerChannel",""));
}
}
}
</lsl>

=== Functions/Keywords to Implement ===

I'm planning on implementing Datashares on OpenSim during the summer. The following is an LSL-side roadmap.

* [[User:Fred_Rookstown/llRequestDatashare|llRequestDatashare]]

Talk:LlGetRootRotation

2009-06-11T03:36:27Z

Fred Rookstown: fff

== llSetRootRotation-like method ==

I'm working on an avatar that is supposed to be able to attach to surfaces, similar to an insect. While I have the attaching-to-surfaces thing down, the problem is that, particularly on vertical surfaces like walls, I am unable to rotate the avatar so it appears that the feet are touching the ground, instead of being glued by the hip. Is there any way to do this in LSL without using a vehicle? -- [[User:Fred Rookstown|Fred Rookstown]] 03:35, 11 June 2009 (UTC)

Talk:LlGetRootRotation

2009-06-11T03:35:56Z

Fred Rookstown: llSetRootRotation-like method

== llSetRootRotation-like method ==

I'm working on an avatar that is supposed to be able to attach to surfaces, similar to an inspect. While I have the attaching-to-surfaces thing down, the problem is that, particularly on vertical surfaces like walls, I am unable to rotate the avatar so it appears that the feet are touching the ground, instead of being glued by the hip. Is there any way to do this in LSL without using a vehicle? -- [[User:Fred Rookstown|Fred Rookstown]] 03:35, 11 June 2009 (UTC)

Talk:Flycam

2009-06-10T04:47:47Z

Fred Rookstown:

== does not go ==

well i simply can't make this work. i've got the latest 3dx driver. i've installed it and even restarted. i run 2ndL and turn on FlyCam, but the device does not do anything. the graphs don't wiggle around, and of course the cam does not move. what am i missing? [[User:Klein Mandelbrot|Klein Mandelbrot]] 21:16, 16 February 2008 (PST)

I have the same issue using the last RC SL client on my mac. From what I read on windows it works ok and its the same SpaceNavigator driver so it must be some SL issue on the mac.

LL: Can you please tell us what might be the problem? or issue a fix?

Thank you

== Ubuntu 9.04 ==

I have Ubuntu Jaunty Jackalope, and I have a logitech Dual Action pad plugged in and calibrated, but it seems that SL does not want to recognise the device. Joystick calibrator sees it in /dev/input/js0. Using a slightly patched SL 1.22.11.0 (compiled from SVN). -- [[User:Fred Rookstown|Fred Rookstown]] 04:47, 10 June 2009 (UTC)

Talk:Flycam

2009-06-10T04:47:35Z

Fred Rookstown:

User:Fred Rookstown/llRequestDatashare

2009-06-07T20:33:53Z

Fred Rookstown: + Some functions I'll be prototyping on OpenSim this summer.

{{LSL_Function
|func=llRequestDatashare
|func_id=N/A
|func_sleep
|func_energy=N/A
|func_desc=Attempts to open a [[User:Fred_Rookstown/2WayLSLToViewerComms|datashare]] channel on the specified agent for the specified service, if available.
|func_footnote
|return_type=integer
|return_text=datashare resource pointer
|p1_type=key|p1_name=agent|p1_desc=Key of target agent|p1_hover
|p2_type=string|p2_name=service_id|p2_desc=Name of service to connect to|p2_hover
|p3_type=integer|p3_name=service_revision_req|p3_desc=Ensures that the service is at least this version before allowing the datashare to open.|p3_hover
|constants
|spec
|caveats
|examples=<lsl>
integer datashare; // Datashare pointer
default
{
state_entry()
{
// Open a datashare with no service version check.
datashare=llRequestDatashare(llGetOwner(),"Some Service",0);
}
}
</lsl>
|helpers
|also_header
|also_functions
|also_tests
|also_events
|also_articles
|also_footer
|notes
|mode=request
|deprecated
|location
|cat1
|cat2
|cat3
|cat4
|cat5
|cat6
}}

User:Fred Rookstown/2WayLSLToViewerComms

2009-06-07T20:29:53Z

Fred Rookstown: /* LSL methods */

This page shall contain analyses and protocol proposals for 2-way script/viewer communications, in an attempt to improve communications between scripts and viewers.

'''Feel free to add in your own thoughts and suggestions.''' I am also willing to host an "office hour" sort of thing at my lounge in Nolan if you wish to discuss this face-to-face with others in a realtime environment.

== Why? ==

In this age of OpenSource viewers, problems begin to crop up as viewers are modified to support additions to the client code that would not be possible via LSL, such as fast, reliable client-side radars and client-side BDSM restraints. One of the most major issues encountered by developers is the transmission of data back and fourth between LSL and the client itself. Although several methods exist, they can prove to inadequate. In addition, since no current standard of communication currently exists for reliable client<-> server communications, developers wishing to integrate their products with the client must go through a trial and error process in order to find the best solution, and even then, the solution may not be a reliable communications channel.

This wiki page aims to propose a reliable, simple-to-use method of sharing data between server-side LSL and the client itself.

== Communications methods ==

Since I am by no means an expert at messing with the SL client, feel free to correct me if you feel I am wrong with any point.

=== LLMessageSystem ===

The method LL uses to share information with their servers is via the LLMessageSystem class, which sends and receives raw TCP or UDP packets from the servers and deciphers them into a manageable format. It also performs automatic bandwidth throttling.

'''Pros:'''
* LLMessageSystem is the most direct way of talking to the sim server, which is where the scripts run.
* Relatively easy to use
* Already in place
* Automatically (de)serializes data as it's sent; Little to no typecasting required.
* Totally transparent to the user

'''Cons:'''
* Would require a message.xml change to implement a new message type, and on both ends (servers and viewer)
* Would require new LSL communications functions.
* Not necessarily the most reliable method.
* WOuld require a new capability to notify the server that the channel sharing code is available.

=== HTTP Client/Server ===

HTTP transmissions to and form the client and servers. Could be XMLRPC, REST, or just plain HTTP.

'''Pros:'''
* Somewhat fast, although it depends on application and workload.
* More reliable than LLMessageSystem
* Basic classes in place.
* Can send many datatypes.
* Can send a large volume of data.

'''Cons:'''
* More overhead than LLMessages.
* Would require operation of an HTTP server on the client to be able to share data to the client, would be difficult to access behind a NAT/Firewall (polling the server would lag the client and server to death).
* Would require significant LL-side changes to be able to handle HTTP data faster.
* Raw HTTP requires significant data processing in order to convert from the request/response to client-accessible data, many typecasting operations to handle, including unicode.

=== Chat ===

Chat communications is currently used by RestrainedLife and PAR/Emerald RadarChat, in order to convey information back and forth between the script and viewer.

'''Pros:'''
* Always in place.
* Can both send and receive data through NATs and firewalls.
* Simple to send data.

'''Cons:'''
* Requires the reservation of a channel for use with the component.
* Malicious/false data can be sent more easily than other methods.
* 1024 character limit, restricting size.
* Not reliable at all; Even minor lag can seriously affect communications.
* Easy for users to identify an open channel; Just listen on the chat channel. Bad for vendors and privacy in general.

=== Jabber ===

Jabber.org is the original IM service based on XMPP, the open standard for instant messaging, and one of the biggest nodes on the open Jabber network.

'''Pros:'''
* Open source
* Well-known protocol
* Has documented standards
* Scalable (?)
* May shoehorn in long-overdue group chat fixes.

'''Cons:'''
* Requires implementation on both the servers and client.
** LL has already deemed XMPP-based messaging services too immature to implement.
* May require significant code changes to handle XMPP safely and securely.
* Additional libraries required on both servers and client
* Licensing may be an issue.

== LSL methods ==

What I am considering, for LSL, is the addition of functions to establish, maintain, and terminate a data sharing channel. A script would request a channel to a service on a particular agent (normally the owner but may be otherwise in other applications), and, if the server has been notified via CAPS (on login) that the agent has datashare channels, and that the specific service has been registered on that channel, the server will tell the script to go ahead with the operation (via an event or return value). The script then receives the client's shared variables, and the script can register its own shared variables.

<lsl>
integer datashare; // Resource pointer to the channel.

default
{
state_entry()
{
datashare = llRequestDatashare(llGetOwner(),"Radar",0); // 3rd option is a service version requirement. 0 means any version, non-zero means that the server will check if the service is at least that version before allowing it.
}

datashare(integer datashare_pointer,integer update_type)
{
if(update_type==DATASHARE_AVAILABLE && datashare==datashare_pointer)
{
llShareString(datashare,"ScriptRegion",llGetRegionName()); // 3rd argument can be left blank to receive the contents of the variable.
}
// Sent when the viewer has changed something in the channel.
if(update_type==DATASHARE_CHANGED && datashare==datashare_pointer)
{
llSay(0,"Viewer channel: "+llShareString(datashare,"ViewerChannel",""));
}
}
}
</lsl>

=== Functions/Keywords to Implement ===

I'm planning on implementing Datashares on OpenSim during the summer. The following is an LSL-side roadmap.

* [[User:Fred_Rookstown/llRequestDatashare|llRequestDatashare]]

User:Fred Rookstown/2WayLSLToViewerComms

2009-06-07T20:06:16Z

Fred Rookstown:

This page shall contain analyses and protocol proposals for 2-way script/viewer communications, in an attempt to improve communications between scripts and viewers.

'''Feel free to add in your own thoughts and suggestions.''' I am also willing to host an "office hour" sort of thing at my lounge in Nolan if you wish to discuss this face-to-face with others in a realtime environment.

== Why? ==

In this age of OpenSource viewers, problems begin to crop up as viewers are modified to support additions to the client code that would not be possible via LSL, such as fast, reliable client-side radars and client-side BDSM restraints. One of the most major issues encountered by developers is the transmission of data back and fourth between LSL and the client itself. Although several methods exist, they can prove to inadequate. In addition, since no current standard of communication currently exists for reliable client<-> server communications, developers wishing to integrate their products with the client must go through a trial and error process in order to find the best solution, and even then, the solution may not be a reliable communications channel.

This wiki page aims to propose a reliable, simple-to-use method of sharing data between server-side LSL and the client itself.

== Communications methods ==

Since I am by no means an expert at messing with the SL client, feel free to correct me if you feel I am wrong with any point.

=== LLMessageSystem ===

The method LL uses to share information with their servers is via the LLMessageSystem class, which sends and receives raw TCP or UDP packets from the servers and deciphers them into a manageable format. It also performs automatic bandwidth throttling.

'''Pros:'''
* LLMessageSystem is the most direct way of talking to the sim server, which is where the scripts run.
* Relatively easy to use
* Already in place
* Automatically (de)serializes data as it's sent; Little to no typecasting required.
* Totally transparent to the user

'''Cons:'''
* Would require a message.xml change to implement a new message type, and on both ends (servers and viewer)
* Would require new LSL communications functions.
* Not necessarily the most reliable method.
* WOuld require a new capability to notify the server that the channel sharing code is available.

=== HTTP Client/Server ===

HTTP transmissions to and form the client and servers. Could be XMLRPC, REST, or just plain HTTP.

'''Pros:'''
* Somewhat fast, although it depends on application and workload.
* More reliable than LLMessageSystem
* Basic classes in place.
* Can send many datatypes.
* Can send a large volume of data.

'''Cons:'''
* More overhead than LLMessages.
* Would require operation of an HTTP server on the client to be able to share data to the client, would be difficult to access behind a NAT/Firewall (polling the server would lag the client and server to death).
* Would require significant LL-side changes to be able to handle HTTP data faster.
* Raw HTTP requires significant data processing in order to convert from the request/response to client-accessible data, many typecasting operations to handle, including unicode.

=== Chat ===

Chat communications is currently used by RestrainedLife and PAR/Emerald RadarChat, in order to convey information back and forth between the script and viewer.

'''Pros:'''
* Always in place.
* Can both send and receive data through NATs and firewalls.
* Simple to send data.

'''Cons:'''
* Requires the reservation of a channel for use with the component.
* Malicious/false data can be sent more easily than other methods.
* 1024 character limit, restricting size.
* Not reliable at all; Even minor lag can seriously affect communications.
* Easy for users to identify an open channel; Just listen on the chat channel. Bad for vendors and privacy in general.

=== Jabber ===

Jabber.org is the original IM service based on XMPP, the open standard for instant messaging, and one of the biggest nodes on the open Jabber network.

'''Pros:'''
* Open source
* Well-known protocol
* Has documented standards
* Scalable (?)
* May shoehorn in long-overdue group chat fixes.

'''Cons:'''
* Requires implementation on both the servers and client.
** LL has already deemed XMPP-based messaging services too immature to implement.
* May require significant code changes to handle XMPP safely and securely.
* Additional libraries required on both servers and client
* Licensing may be an issue.

== LSL methods ==

What I am considering, for LSL, is the addition of functions to establish, maintain, and terminate a data sharing channel. A script would request a channel to a service on a particular agent (normally the owner but may be otherwise in other applications), and, if the server has been notified via CAPS (on login) that the agent has datashare channels, and that the specific service has been registered on that channel, the server will tell the script to go ahead with the operation (via an event or return value). The script then receives the client's shared variables, and the script can register its own shared variables.

<lsl>
integer datashare; // Resource pointer to the channel.

default
{
state_entry()
{
datashare = llRequestDatashare(llGetOwner(),"Radar",0); // 3rd option is a service version requirement. 0 means any version, non-zero means that the server will check if the service is at least that version before allowing it.
}

datashare(integer datashare_pointer,integer update_type)
{
if(update_type==DATASHARE_AVAILABLE && datashare==datashare_pointer)
{
llShareString(datashare,"ScriptRegion",llGetRegionName()); // 3rd argument can be left blank to receive the contents of the variable.
}
// Sent when the viewer has changed something in the channel.
if(update_type==DATASHARE_CHANGED && datashare==datashare_pointer)
{
llSay(0,"Viewer channel: "+llShareString(datashare,"ViewerChannel",""));
}
}
}
</lsl>

User:Fred Rookstown/2WayLSLToViewerComms

2009-05-26T05:19:19Z

Fred Rookstown:

This page shall contain analyses and protocol proposals for 2-way script/viewer communications, in an attempt to improve communications between scripts and viewers.

'''Feel free to add in your own thoughts and suggestions.''' I am also willing to host an "office hour" sort of thing at my lounge in Nolan if you wish to discuss this face-to-face with others in a realtime environment.

== Why? ==

In this age of OpenSource viewers, problems begin to crop up as viewers are modified to support additions to the client code that would not be possible via LSL, such as fast, reliable client-side radars and client-side BDSM restraints. One of the most major issues encountered by developers is the transmission of data back and fourth between LSL and the client itself. Although several methods exist, they can prove to inadequate. In addition, since no current standard of communication currently exists for reliable client<-> server communications, developers wishing to integrate their products with the client must go through a trial and error process in order to find the best solution, and even then, the solution may not be a reliable communications channel.

This wiki page aims to propose a reliable, simple-to-use method of sharing data between server-side LSL and the client itself.

== Communications methods ==

Since I am by no means an expert at messing with the SL client, feel free to correct me if you feel I am wrong with any point.

=== LLMessageSystem ===

The method LL uses to share information with their servers is via the LLMessageSystem class, which sends and receives raw TCP or UDP packets from the servers and deciphers them into a manageable format. It also performs automatic bandwidth throttling.

'''Pros:'''
* LLMessageSystem is the most direct way of talking to the sim server, which is where the scripts run.
* Relatively easy to use
* Already in place
* Automatically (de)serializes data as it's sent; Little to no typecasting required.
* Totally transparent to the user

'''Cons:'''
* Would require a message.xml change to implement a new message type, and on both ends (servers and viewer)
* Would require new LSL communications functions.
* Not necessarily the most reliable method.
* WOuld require a new capability to notify the server that the channel sharing code is available.

=== HTTP Client/Server ===

HTTP transmissions to and form the client and servers. Could be XMLRPC, REST, or just plain HTTP.

'''Pros:'''
* Somewhat fast, although it depends on application and workload.
* More reliable than LLMessageSystem
* Basic classes in place.
* Can send many datatypes.
* Can send a large volume of data.

'''Cons:'''
* More overhead than LLMessages.
* Would require operation of an HTTP server on the client to be able to share data to the client, would be difficult to access behind a NAT/Firewall (polling the server would lag the client and server to death).
* Would require significant LL-side changes to be able to handle HTTP data faster.
* Raw HTTP requires significant data processing in order to convert from the request/response to client-accessible data, many typecasting operations to handle, including unicode.

=== Chat ===

Chat communications is currently used by RestrainedLife and PAR/Emerald RadarChat, in order to convey information back and forth between the script and viewer.

'''Pros:'''
* Always in place.
* Can both send and receive data through NATs and firewalls.
* Simple to send data.

'''Cons:'''
* Requires the reservation of a channel for use with the component.
* Malicious/false data can be sent more easily than other methods.
* 1024 character limit, restricting size.
* Not reliable at all; Even minor lag can seriously affect communications.
* Easy for users to identify an open channel; Just listen on the chat channel. Bad for vendors and privacy in general.

== LSL methods ==

What I am considering, for LSL, is the addition of functions to establish, maintain, and terminate a data sharing channel. A script would request a channel to a service on a particular agent (normally the owner but may be otherwise in other applications), and, if the server has been notified via CAPS (on login) that the agent has datashare channels, and that the specific service has been registered on that channel, the server will tell the script to go ahead with the operation (via an event or return value). The script then receives the client's shared variables, and the script can register its own shared variables.

<lsl>
integer datashare; // Resource pointer to the channel.

default
{
state_entry()
{
datashare = llRequestDatashare(llGetOwner(),"Radar",0); // 3rd option is a service version requirement. 0 means any version, non-zero means that the server will check if the service is at least that version before allowing it.
}

datashare(integer datashare_pointer,integer update_type)
{
if(update_type==DATASHARE_AVAILABLE && datashare==datashare_pointer)
{
llShareString(datashare,"ScriptRegion",llGetRegionName()); // 3rd argument can be left blank to receive the contents of the variable.
}
// Sent when the viewer has changed something in the channel.
if(update_type==DATASHARE_CHANGED && datashare==datashare_pointer)
{
llSay(0,"Viewer channel: "+llShareString(datashare,"ViewerChannel",""));
}
}
}
</lsl>

User:Fred Rookstown/2WayLSLToViewerComms

2009-05-26T04:31:00Z

Fred Rookstown: /* LLMessageSystem */

This page shall contain analyses and protocol proposals for 2-way script/viewer communications, in an attempt to improve communications between scripts and viewers.

'''Feel free to add in your own thoughts and suggestions.''' I am also willing to host an "office hour" sort of thing at my lounge in Nolan if you wish to discuss this face-to-face with others in a realtime environment.

== Why? ==

In this age of OpenSource viewers, problems begin to crop up as viewers are modified to support additions to the client code that would not be possible via LSL, such as fast, reliable client-side radars and client-side BDSM restraints. One of the most major issues encountered by developers is the transmission of data back and fourth between LSL and the client itself. Although several methods exist, they can prove to inadequate. In addition, since no current standard of communication currently exists for reliable client<-> server communications, developers wishing to integrate their products with the client must go through a trial and error process in order to find the best solution, and even then, the solution may not be a reliable communications channel.

This wiki page aims to propose a reliable, simple-to-use method of sharing data between server-side LSL and the client itself.

== Communications methods ==

Since I am by no means an expert at messing with the SL client, feel free to correct me if you feel I am wrong with any point.

=== LLMessageSystem ===

The method LL uses to share information with their servers is via the LLMessageSystem class, which sends and receives raw TCP or UDP packets from the servers and deciphers them into a manageable format. It also performs automatic bandwidth throttling.

'''Pros:'''
* LLMessageSystem is the most direct way of talking to the sim server, which is where the scripts run.
* Relatively easy to use
* Already in place
* Automatically (de)serializes data as it's sent; Little to no typecasting required.
* Totally transparent to the user

'''Cons:'''
* Would require a message.xml change to implement a new message type, and on both ends (servers and viewer)
* Would require new LSL communications functions.
* Not necessarily the most reliable method.
* WOuld require a new capability to notify the server that the channel sharing code is available.

=== HTTP Client/Server ===

HTTP transmissions to and form the client and servers. Could be XMLRPC, REST, or just plain HTTP.

'''Pros:'''
* Somewhat fast, although it depends on application and workload.
* More reliable than LLMessageSystem
* Basic classes in place.
* Can send many datatypes.
* Can send a large volume of data.

'''Cons:'''
* More overhead than LLMessages.
* Would require operation of an HTTP server on the client to be able to share data to the client, would be difficult to access behind a NAT/Firewall (polling the server would lag the client and server to death).
* Would require significant LL-side changes to be able to handle HTTP data faster.
* Raw HTTP requires significant data processing in order to convert from the request/response to client-accessible data, many typecasting operations to handle, including unicode.

=== Chat ===

Chat communications is currently used by RestrainedLife and PAR/Emerald RadarChat, in order to convey information back and forth between the script and viewer.

'''Pros:'''
* Always in place.
* Can both send and receive data through NATs and firewalls.
* Simple to send data.

'''Cons:'''
* Requires the reservation of a channel for use with the component.
* Malicious/false data can be sent more easily than other methods.
* 1024 character limit, restricting size.
* Not reliable at all; Even minor lag can seriously affect communications.
* Easy for users to identify an open channel; Just listen on the chat channel. Bad for combat HUDs and privacy.

== LSL methods ==

What I am considering, for LSL, is the addition of functions to establish, maintain, and terminate a data sharing channel. A script would request a channel to a service on a particular agent (normally the owner but may be otherwise in other applications), and, if the server has been notified via CAPS (on login) that the agent has datashare channels, and that the specific service has been registered on that channel, the server will tell the script to go ahead with the operation (via an event or return value). The script then receives the client's shared variables, and the script can register its own shared variables.

<lsl>
integer datashare; // Resource pointer to the channel.

default
{
state_entry()
{
datashare = llRequestDatashare(llGetOwner(),"Radar",0); // 3rd option is a service version requirement. 0 means any version, non-zero means that the server will check if the service is at least that version before allowing it.
}

datashare(integer datashare_pointer,integer update_type)
{
if(update_type==DATASHARE_AVAILABLE && datashare==datashare_pointer)
{
llShareString(datashare,"ScriptRegion",llGetRegionName()); // 3rd argument can be left blank to receive the contents of the variable.
}
// Sent when the viewer has changed something in the channel.
if(update_type==DATASHARE_CHANGED && datashare==datashare_pointer)
{
llSay(0,"Viewer channel: "+llShareString(datashare,"ViewerChannel",""));
}
}
}
</lsl>

User:Fred Rookstown/2WayLSLToViewerComms

2009-05-26T04:28:26Z

Fred Rookstown: New page: This page shall contain analyses and protocol proposals for 2-way script/viewer communications, in an attempt to improve communications between scripts and viewers. '''Feel free to add in...

This page shall contain analyses and protocol proposals for 2-way script/viewer communications, in an attempt to improve communications between scripts and viewers.

'''Feel free to add in your own thoughts and suggestions.''' I am also willing to host an "office hour" sort of thing at my lounge in Nolan if you wish to discuss this face-to-face with others in a realtime environment.

== Why? ==

In this age of OpenSource viewers, problems begin to crop up as viewers are modified to support additions to the client code that would not be possible via LSL, such as fast, reliable client-side radars and client-side BDSM restraints. One of the most major issues encountered by developers is the transmission of data back and fourth between LSL and the client itself. Although several methods exist, they can prove to inadequate. In addition, since no current standard of communication currently exists for reliable client<-> server communications, developers wishing to integrate their products with the client must go through a trial and error process in order to find the best solution, and even then, the solution may not be a reliable communications channel.

This wiki page aims to propose a reliable, simple-to-use method of sharing data between server-side LSL and the client itself.

== Communications methods ==

Since I am by no means an expert at messing with the SL client, feel free to correct me if you feel I am wrong with any point.

=== LLMessageSystem ===

The method LL uses to share information with their servers is via the LLMessageSystem class, which sends and receives raw TCP or UDP packets from the servers and deciphers them into a manageable format. It also performs automatic bandwidth throttling.

'''Pros:'''
* LLMessageSystem is the most direct way of talking to the sim server, which is where the scripts run.
* Relatively easy to use
* Already in place
* Automatically (de)serializes data as it's sent; Little to no typecasting required.
* Totally transparent to the user

'''Cons:'''
* Would require a message.xml change to implement a new message type, and on both ends (servers and LL)
* Would require new LSL communications functions.
* Not necessarily the most reliable method.
* WOuld require a new capability to notify the server that the channel sharing code is available.

=== HTTP Client/Server ===

HTTP transmissions to and form the client and servers. Could be XMLRPC, REST, or just plain HTTP.

'''Pros:'''
* Somewhat fast, although it depends on application and workload.
* More reliable than LLMessageSystem
* Basic classes in place.
* Can send many datatypes.
* Can send a large volume of data.

'''Cons:'''
* More overhead than LLMessages.
* Would require operation of an HTTP server on the client to be able to share data to the client, would be difficult to access behind a NAT/Firewall (polling the server would lag the client and server to death).
* Would require significant LL-side changes to be able to handle HTTP data faster.
* Raw HTTP requires significant data processing in order to convert from the request/response to client-accessible data, many typecasting operations to handle, including unicode.

=== Chat ===

Chat communications is currently used by RestrainedLife and PAR/Emerald RadarChat, in order to convey information back and forth between the script and viewer.

'''Pros:'''
* Always in place.
* Can both send and receive data through NATs and firewalls.
* Simple to send data.

'''Cons:'''
* Requires the reservation of a channel for use with the component.
* Malicious/false data can be sent more easily than other methods.
* 1024 character limit, restricting size.
* Not reliable at all; Even minor lag can seriously affect communications.
* Easy for users to identify an open channel; Just listen on the chat channel. Bad for combat HUDs and privacy.

== LSL methods ==

What I am considering, for LSL, is the addition of functions to establish, maintain, and terminate a data sharing channel. A script would request a channel to a service on a particular agent (normally the owner but may be otherwise in other applications), and, if the server has been notified via CAPS (on login) that the agent has datashare channels, and that the specific service has been registered on that channel, the server will tell the script to go ahead with the operation (via an event or return value). The script then receives the client's shared variables, and the script can register its own shared variables.

<lsl>
integer datashare; // Resource pointer to the channel.

default
{
state_entry()
{
datashare = llRequestDatashare(llGetOwner(),"Radar",0); // 3rd option is a service version requirement. 0 means any version, non-zero means that the server will check if the service is at least that version before allowing it.
}

datashare(integer datashare_pointer,integer update_type)
{
if(update_type==DATASHARE_AVAILABLE && datashare==datashare_pointer)
{
llShareString(datashare,"ScriptRegion",llGetRegionName()); // 3rd argument can be left blank to receive the contents of the variable.
}
// Sent when the viewer has changed something in the channel.
if(update_type==DATASHARE_CHANGED && datashare==datashare_pointer)
{
llSay(0,"Viewer channel: "+llShareString(datashare,"ViewerChannel",""));
}
}
}
</lsl>

User:Fred Rookstown

2009-05-26T03:29:25Z

Fred Rookstown: New page: Blah blah blah, I do coding and stuff. == Current things I'm working on == * User:Fred_Rookstown/2WayLSLToViewerComms - An analysis and (maybe) proposal for 2-way script to viewer co...