Second Life Wiki - User contributions [en]

LlGetParcelPrimCount

2010-11-26T07:43:59Z

Lastro Greenwood:

{{LSL_Constants/Parcel Prim Count}}{{#vardefine:FALSE|{{LSL Const|FALSE|integer|0|c=Treated as false by conditionals.}}}}
{{LSL_Function
|func_id=325|func_sleep=0.0|func_energy=10.0
|func=llGetParcelPrimCount|return_type=integer
|p1_type=vector|p1_name=pos|p1_desc=[[Viewer coordinate frames#Region|region coordinate]] (z component is ignored)
|p2_type=integer|p2_name=category|p2_desc=a PARCEL_COUNT_* flag
|p3_type=integer|p3_name=sim_wide|p3_desc=boolean
|func_footnote
|func_desc
|return_text=that is the number of prims on the parcel at '''pos''' of the given '''category'''
|spec=If '''sim_wide''' is...
*TRUE then the return is the combined number of prims on all parcels in the sim owned by the specified parcel's owner of the category requested.
*{{#var:FALSE}} then the return is the number of prims of the category requested on the parcel specified.
|caveats
|constants
|examples=
<lsl>//gives prim usage information when touched.
default
{
touch_start(integer total_number)
{
vector pos = llGetPos();
llSay(0, "There are " + (string)llGetParcelPrimCount(pos, PARCEL_COUNT_TOTAL, FALSE) +
" total prims on this parcel");
llSay(0, (string)llGetParcelPrimCount(pos, PARCEL_COUNT_OWNER, FALSE) +
" prims are owned by the parcel owner");
llSay(0, (string)llGetParcelPrimCount(pos, PARCEL_COUNT_GROUP, FALSE) +
" prims set to or owned by the parcel's group.");
llSay(0, (string)llGetParcelPrimCount(pos, PARCEL_COUNT_OTHER, FALSE) +
" prims that are not set to the parcel group or owned by the parcel owner");
llSay(0, (string)llGetParcelPrimCount(pos, PARCEL_COUNT_SELECTED, FALSE) +
" prims are selected");
llSay(0, (string)llGetParcelPrimCount(pos, PARCEL_COUNT_TEMP, FALSE) +
" prims are temp-on-rez");
}
}</lsl>
|helpers
|also_functions=
{{LSL DefineRow||[[llGetParcelMaxPrims]]}}
|also_events
|also_tests
|also_articles
|notes
|permission
|negative_index
|sort=GetParcelPrimCount
|cat1=Parcel
|cat2=Parcel/Prim Count
|cat3
|cat4
}}

LlGetParcelPrimCount

2010-11-26T07:41:32Z

Lastro Greenwood: Fixed some engrish

{{LSL_Constants/Parcel Prim Count}}{{#vardefine:FALSE|{{LSL Const|FALSE|integer|0|c=Treated as false by conditionals.}}}}
{{LSL_Function
|func_id=325|func_sleep=0.0|func_energy=10.0
|func=llGetParcelPrimCount|return_type=integer
|p1_type=vector|p1_name=pos|p1_desc=[[Viewer coordinate frames#Region|region coordinate]] (z component is ignored)
|p2_type=integer|p2_name=category|p2_desc=a PARCEL_COUNT_* flag
|p3_type=integer|p3_name=sim_wide|p3_desc=boolean
|func_footnote
|func_desc
|return_text=that is the number of prims on the parcel at '''pos''' of the given '''category'''
|spec=If '''sim_wide''' is...
*{{#var:TRUE}} then the return is the combined number of prims on all parcels in the sim owned by the specified parcel's owner of the category requested.
*{{#var:FALSE}} then the return is the number of prims of the category requested on the parcel specified.
|caveats
|constants
|examples=
<lsl>//gives prim usage information when touched.
default
{
touch_start(integer total_number)
{
vector pos = llGetPos();
llSay(0, "There are " + (string)llGetParcelPrimCount(pos, PARCEL_COUNT_TOTAL, FALSE) +
" total prims on this parcel");
llSay(0, (string)llGetParcelPrimCount(pos, PARCEL_COUNT_OWNER, FALSE) +
" prims are owned by the parcel owner");
llSay(0, (string)llGetParcelPrimCount(pos, PARCEL_COUNT_GROUP, FALSE) +
" prims set to or owned by the parcel's group.");
llSay(0, (string)llGetParcelPrimCount(pos, PARCEL_COUNT_OTHER, FALSE) +
" prims that are not set to the parcel group or owned by the parcel owner");
llSay(0, (string)llGetParcelPrimCount(pos, PARCEL_COUNT_SELECTED, FALSE) +
" prims are selected");
llSay(0, (string)llGetParcelPrimCount(pos, PARCEL_COUNT_TEMP, FALSE) +
" prims are temp-on-rez");
}
}</lsl>
|helpers
|also_functions=
{{LSL DefineRow||[[llGetParcelMaxPrims]]}}
|also_events
|also_tests
|also_articles
|notes
|permission
|negative_index
|sort=GetParcelPrimCount
|cat1=Parcel
|cat2=Parcel/Prim Count
|cat3
|cat4
}}

User:Nyx Linden/Office Hours Agenda

2010-11-24T19:32:53Z

Lastro Greenwood: /* November 24, 2010 */

==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 add topics for discussion / agenda items to the end of the list below 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.

Archived agendas can be found at the [[User:Nyx_Linden/Office_Hours_Agenda_Archive|agenda archive]].

Next meeting scheduled for: November 24, 2010.

===Agenda===

== November 24, 2010 ==
# Normal mapping ({{jira|VWR-3250}})
# Nyx, can you comment on why the + is not in Inventory/Recent? ({{jira|VWR-23903}})
# What should we do if we see an inconsistency between the wiki and the (un)real world? Example is Note 2 of the Physics cost wiki page: truth: Meshes without physics shape CAN be set to type prim.
# Are physics costs recalculated at start/during/after movement?
# What is now the effect of scripted changes (eg scale) that cause prim limit to be exceeded?
# Nyx, did Esbee ever get to talk to you about the AgentHeight bug?
# Uhm kind of a thing i've forgotten about... The mesh representation for round objects doesn't seem to have a good number of segments. Good would be, say, 12, and multiples thereof, because that is divisible by both 3 and 4, making many kinds of builds join up neatly. At anything but insanely high LOD a discontinuity between, as an example, a quarter of a cylinder and a cube is apparent, perhaps because number of cylinder segments isn't multiple of 4.
# When a large number of primitives are removed, the resulting lag; What is the best way to mitigate the effect and what causes it? (When I say large I mean between 1024 and 2048 prims)
# '''Your topic here'''

Talk:LlGetDisplayName

2010-11-22T23:26:58Z

Lastro Greenwood:

Would it be worth making a specific reference to https://jira.secondlife.com/browse/VWR-23627 "Display Name and Username showing as ???" ?

[[User:Innula Zenovka|Innula Zenovka]] 18:40, 8 November 2010 (UTC)

:Yes it is worth referencing it. I'll add it right now. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 05:38, 9 November 2010 (UTC)

Added a warning about escaping strings, this is because even though it is one change per week. People can cause alot of damage.
Examples:

Unescaped shell script running on a residents server (linux) (they are stupid if they do this but still), ';rm -rf /

MySQL Example (its bad practise not to sanitize your strings but its a regular occurrence): ' or '' = ''

If it needs better formatting, please correct and let me know in world so I can remember for next time.

[[User:Lastro Greenwood|Lastro Greenwood]] 23:26, 22 November 2010 (UTC)

LlGetDisplayName

2010-11-22T23:23:31Z

Lastro Greenwood: Added warning about escaping strings to prevent a wave of injection attacks on people's backends when these functions go live.

{{LSL_Function
|inject-1=
{{LSL Function/avatar|id|sim=*}}
{{LSL Generic/pre-release|server-release=[[Display Names|DisplayNames]]}}
{{LSL_Function/warning|Security|It is a '''terrible''' idea to tie any security measures to display names. Don't do it.}}
{{LSL_Function/warning|Security|They can contain quotes and some punctuation, remember to '''escape''' strings being passed to command line scripts, sql queries, etc.}}
{{Issues/DN-202}}
|func_id=NNN|func_sleep=0.0|func_energy=10.0
|sort=GetDisplayName|func=llGetDisplayName
|return_type=string|p1_type=key|p1_name=id
|func_footnote='''id''' must specify a valid avatar key, present in or otherwise known to the sim in which the script is running, otherwise an empty string is returned. This function will still return a valid display name if the avatar is a child agent of the sim (i.e., in an adjacent sim, but presently able to see into the one the script is in), or for a short period after the avatar leaves the sim (specifically, when the client completely disconnects from the sim, either as a main or child agent).
|func_desc
|return_text=that is the non-unique [[Display names|display name]] of the avatar specified by '''id'''.
|spec
|caveats=* To get around the "avatar must be present" limitation, you can use the [[llRequestDisplayName]] function and the [[dataserver]] event to obtain the avatar's display name from a key.
* There is no opposite function ([[llDisplayName2Key]]) available since display names are non-unique
* Either of "???" or "" is returned if the region is unable to return display names. This can happen even if display names are enabled on the region, especially the first time a given key is checked. At least one retry may be advisable. Do not rely on this function to verify avatar presence.
|constants
|examples=<lsl>// Best viewed in Chat History (ctrl-h)
default
{
collision_start(integer a)//Announce who collided
{
llSay(0, "llGetDisplayName: " + llGetDisplayName(llDetectedKey(0)) +
"\nllDetectedName: " + llDetectedName(0));
}
touch_start(integer a)
{
llSay(0,"llGetDisplayName: " + llGetDisplayName(llDetectedKey(0)) +
"\nllDetectedName: " + llDetectedName(0));
}
}</lsl>
|helpers
|also_functions=
{{LSL DefineRow||[[llGetUsername]]}}
{{LSL DefineRow||[[llRequestDisplayName]]|Uses the [[dataserver]] to request avatar information}}
|also_events
|also_articles=
|also_tests
|notes=
|cat1=Avatar
|cat2=Display Name
|cat3=Key
|cat4=Avatar/Name
}}

LlRequestDisplayName

2010-11-22T23:21:36Z

Lastro Greenwood: Added warning about escaping strings to prevent a wave of injection attacks on people's backends when these functions go live.

{{#vardefine:p_data_desc|DATA_* flag}}{{LSL_Function
|inject-1={{LSL Function/avatar|id}}{{LSL Generic/pre-release|server-release=[[Display Names|DisplayNames]]}}
{{LSL_Function/warning|Security|It is a '''terrible''' idea to tie any security measures to display names. Don't do it.}}
{{LSL_Function/warning|Security|They can contain quotes and some punctuation, remember to '''escape''' strings being passed to command line scripts, sql queries, etc.}}
|func_id=NNN|func_sleep=0.0|func_energy=10.0
|func=llRequestDisplayName
|return_type=key
|p1_type=key|p1_name=id
|func_footnote
|func_desc=Requests the '''[[Display_Names|Display Name]]''' of the agent identified by '''id'''. When the Display Name is available the [[dataserver]] event will be raised. The agent identified by '''id''' does not need to be in the same region or online at the time of the request.
|Return_text=that is used to identify the [[dataserver]] event when it is raised.
|spec
|caveats=*If the request fails for any reason, there will be no error notice or dataserver event. You may use a timer to check for stale requests.
*If you merely wish to show avatar name information in the viewer window, it may be more straightforward to avoid a dataserver event and simply output: <lsl>llSay(0, "secondlife:///app/agent/" + (string)id + "/about");</lsl>
|constants
|examples=<lsl>key owner_key;
key owner_name_query;
string owner_display_name;

default
{
state_entry()
{
owner_key = llGetOwner();
owner_name_query = llRequestDisplayName(owner_key);
}
dataserver(key queryid, string data)
{
if ( owner_name_query == queryid )
{
owner_display_name = data;
llSay(0, "The display name of the owner of this script : " + owner_display_name );
}
}
}</lsl>
|helpers
|also_functions=
{{LSL DefineRow||[[llGetDisplayName]]|}}
{{LSL DefineRow||[[llRequestUsername]]|}}
|also_tests
|also_events={{LSL DefineRow||[[dataserver]]|}}
|also_articles
|notes
|deprecated
|cat1=Dataserver
|cat2=Avatar
|cat3=Avatar/Name
|cat4=Display Name
}}

User:Lastro Greenwood

2010-08-07T08:18:53Z

Lastro Greenwood:

== Lastro Greenwood's Page ==
Hey everyone, I'm Lastro Greenwood.

I specialise in software development but can kinda build.

== Scratch Pad ==
=== llCastRay ===
Determines if something is blocking line of sight to avatar.

Uses:
* Radiation?
* Checking to see if avatar is hiding behind cover
* Checking to see if avatar has line of sight to a heat source
* Other stuff that requires LOS

Observations:
* When running the trace it seems to go straight through all objects that get in its way
* It will return false if you dont filter out the object, a quick fix would be to change "if(numobj == 0)" to "if(numobj == 1)"

<lsl>integer getnumobj(list traceres)
{
return (integer)llList2String(traceres,llGetListLength(traceres)-1);
}

integer isVisible(vector start, vector finish, integer filter)
{
list res = llCastRay(start,finish,filter,0);
integer numobj = getnumobj(res);

if(numobj == 0)
return TRUE;

return FALSE;
}

default
{
state_entry()
{

}

touch_start(integer total_number)
{
vector pos = llGetPos();
vector finalpos = llDetectedPos(0);
if(isVisible(pos,finalpos,AGENT) == TRUE)
llOwnerSay("I can see clearly now!");
else
llOwnerSay("Something is in my way!");
}
}</lsl>

== RLV ==

=== RLV ASN Stargate Script ===
Allows for auto-teleporting via RLV, supports most relays

<lsl>vector regCorner;
integer relayChannel = -1812221819;
default
{
link_message(integer sender, integer num, string msg, key id)
{
if(num != 205902)
return;

list data = llParseString2List(id,["|"],[]);
string cmd = llList2String(data,0);

if(cmd == "dial succeeded")
{
string region = llList2String(data,1);
regCorner = (vector)llList2String(data,2);
llRequestSimulatorData(region,DATA_SIM_POS);
}
if(cmd == "wormhole collision")
{
string target = llList2String(data,2);
string msg = "stargate," + (string)target + ",@tpto:" +
(string)regCorner.x + "/" +
(string)regCorner.y + "/" +
(string)regCorner.z + "=force";

llWhisper(relayChannel,msg);
}

/*string msgOut = "LINK MSG\n";
msgOut += "sender: " + (string)sender + "\n";
msgOut += "num: " + (string)num + "\n";
msgOut += "msg: " + msg + "\n";
msgOut += "key: " + (string)id + "\n";
llOwnerSay(msgOut);*/
}

dataserver(key req, string data)
{
regCorner += (vector)data;
}
}</lsl>

Talk:LlCastRay

2010-08-07T00:54:45Z

Lastro Greenwood: /* Possibility of a "Fast" trace */

== Why isn't this using the sensor API? ==

# The sensor API already exists and has well understood behavior.
# The sensor API resolves many of the problems people have brought up, such as list length and range.
# The sensor API is asynchronous.
# Creating new APIs when there are already viable existing ones leads to Mainframe-itis.
# This would be an opportunity to add a result filter variant to the llSensor() family...

llCastRay(string name, key id, integer type, float range, vector path, integer request_mask);

Eg:

llCastRay("", "", AGENT|ACTIVE|PASSIVE, 32, <1, 0, 0>, SENSOR_POSITION);

/...

sensor(integer n)
{
integer i;
for(i = 0; i < n; i++)
llSay(0, "Ping at "+(string)llDetectedPos(i));
}

-- [[User:Argent Stonecutter|Argent Stonecutter]] 11:53, 7 July 2010 (UTC)

:I think somewhere Falcon said not doing it like sensors was intentional in order to get the data the moment the command is run instead of having to wait for an event, i don't remember seeing an explanation why this was a better approach though.
:Btw, how would the normal of the hit(s) be reported? A new llDetected* function? Perhaps this would be an opportunity to introduce list llDetected(integer index, list what), this way future llDetected* functions can be easily prototyped without needing to actually implement a whole new command in the server (you know, like with the primitive params stuff)
:ps: talking about normals and llDetected* i would like to plug [http://jira.secondlife.com/browse/SVC-3369 SVC-3369] "llDetectedCollisions* (similar to llDetectedTouch*)" , mind taking a look Falcon?
--[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 12:46, 7 July 2010 (UTC)

:This was not done like the sensor API because it's not really all that similar to sensors. Unfortunately I don't have time to get into a discussion of why the API you're suggesting would be problematic, but if you read the history of this feature (SVC-5389), I hope you'll begin to see where I'm coming from.
:Tigro, Sorry, I'm backlogged for a month at this point, so I don't think I'll be able to look at that soon. :) In general, I'm looking at this feature right now only because it affects a huge audience and is way, way overdue. Oh, and because I'm a physics guy and it's a physics feature more than anything else. :P

[[User:Falcon Linden|Falcon Linden]] 03:34, 8 July 2010 (UTC)

::SVC-5389 is about download problems. Do you mean SVC-5381? There's a couple of notes about sensors being "heavy", but not really any explanation of why they're "heavy". The only heavy feature of sensors is that it calculates and returns more information than you're asking for, and the request_mask would take care of that... and would open up the possibility of adding the same kind of masking to existing sensor calls. In terms of scripting, sensors are in many ways lighter because you're not having to pass around (and copy) lists.

:: There's some comments about speed of response, but also about having to throttle it to once per frame. I think the sensor API would make that less of an issue. -- [[User:Argent Stonecutter|Argent Stonecutter]] 20:09, 11 July 2010 (UTC)

== llSonar please? ==

I would appreciate if you took in consideration my suggestions at http://jira.secondlife.com/browse/SVC-2486 please; any feedback is more than welcome.

ps:llCastRay is already awesome, you rock! Please try the hardest you can to figure out how to get this to come to the maingrid with the least crippling as possible.

--[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 03:01, 3 July 2010 (UTC)

Hi Tigro,

If I understand your feature request, it sounds much like the shape cast described in SVC-5381 (http://jira.secondlife.com/browse/SVC-5381) for a sphere or a cylinder cast along its primary axis. Is that correct?

Thanks,
[[User:Falcon Linden|Falcon Linden]]

: I have just skimmed thru the comments there, do shape casting allow for somthing liek for example have a nonphys object recognize the geometry so it could rest against a jumbled pile of prims as if it was laying against them physicly? (in the ASCII art in SVC-2486 it would be having the object represented by the O's resting in the diagonal line as if it was solid) --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 05:44, 3 July 2010 (UTC)

:A practical example, imagine a giant mecha, with big flat feet, now imagine a landscape littered with prims of all sorts of shapes and sizes, to make it look realistic, on each step the foot should be rotated to rest against the highest points under it ; just raycasting you have the risk of shooting between prims, and with shapecast you don't get the rotation for the foot. --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 03:04, 4 July 2010 (UTC)

== What am I looking at? ==

A function I just threw in to replace phantom bullets for quickly acquiring a point of interest -- whatever your camera's focused on (in this sim, within 20m) is returned, allowing quicker, more intuitive targeting of other objects. PERMISSION_TRACK_CAMERA must be previously set.

<lsl>key camPing() {
// End points at the camera and 20m in front of it
vector camPos = llGetCameraPos();

// Clamp the end position to within the sim
// From an SLUniverse post by Chalice Yao
// http://www.sluniverse.com/php/vb/scripting/46344-llcastray-available-testing-maybe-only.html#post969497
float xSteps;
float ySteps;
vector camRot = llRot2Fwd(llGetCameraRot());
fXSteps = llAbs( ( 256.0 * !!camRot.x ) - camPos.x ) / camRot.x;
fYSteps = llAbs( ( 256.0 * !!camRot.y ) - camPos.y ) / camRot.y;
if(xSteps > ySteps)
xSteps = ySteps;
if ( xSteps > 20.0 )
xSteps = 20.0

// Cast the ray; ignore hits on land, otherwise get the root key
list contacts = llCastRay( camPos, camPos + ( camRot * xSteps ),
RC_REJECT_LAND,
RC_GET_ROOT_KEY );

// Return values
if ( llList2Integer( contacts, -1 ) > 0 ) { // Got a return
return llList2Key( contacts, 0 );
}
return NULL_KEY;
}
</lsl>

[[User:Jack Abraham|Jack Abraham]] 06:10, 7 July 2010 (UTC)

== RC_GET_LINK_NUM? Not RC_GET_LINK_KEY? ==

I can't think of a circumstance where knowing the link number of the return would be useful. UUID of the prim hit would be far more useful; is that within the realm of possibility? [[User:Jack Abraham|Jack Abraham]] 04:47, 3 July 2010 (UTC)

Hi Jack,

The default behavior is to return the UUID of the prim hit. If you want the root key instead, you have to use RC_GET_ROOT_KEY. The intended purpose of RC_GET_LINK_NUM was for scripts like your camera targeting system where it is expected that the camera will be pointed at a child of the linkset performing the cast. For example, suppose you make a minesweeper game where each tile is a prim in the linkset. And suppose you script it so that the use can select a tile by focusing on it and clicking. The script could cast a ray from the camera and determine the link number of the tile in the player's line of sight. Then it could use that link number in an llMessageLinked or some other LSL function to modify the appropriate child prim. Does that make sense? If it turns out no one has any use for RC_GET_LINK_NUM, I'll eliminate it for the sake of simplicity. But the behavior you're looking for is already there by default! Yay.

Cheers,
[[User:Falcon Linden|Falcon Linden]]

Makes perfect sense; I need to read better. Thanks. [[User:Jack Abraham|Jack Abraham]] 05:44, 3 July 2010 (UTC)

== Memory concerns ==

Dumping all possible avaible information into a list regardless of whether any of them will be used seems severely wasteful. If you really need to dump all the info as soon as the command is called straight into script memory, at least do somthing like adding a parameter to the command that is a list where each item identifies which pieces of information the scripter wants (like with llGetPrimtiveParams ) --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 05:51, 3 July 2010 (UTC)

I think we basically have that, Tigro; we only get UUID and hit position unless we set additional flags. Falcon indicated that we will not get all hits in the final version; that'll further reduce the size of the list. [[User:Jack Abraham|Jack Abraham]] 07:50, 3 July 2010 (UTC)

== Clamping ==

It would be a waste of server resources if every script has to add clamping code to make sure
their begin and end are inside the region! Instead, do not return an error code but just stop
and return only the hits inside the region. That might mean you have to add the clamping code in the
server, but that would be a hell of a lot more efficient than doing that in the LSL scripts.

Note that clamping is relatively easy, in C++ it shouldn't cost more than a few microseconds.
The algorithm would be something like:

1) A bounding box can be given with two vectors: ''bbmin'' and ''bbmax'', where ''bbmin'' is the bottom,
south/west corner of the sim (0,0,0), and ''bbmax'' the upper, north/east corner of the sim
(256,256,4096).

2) Let the ray begin at vector ''begin'' and end at vector ''end'' (using the same coordinate system as the bounding box).

3) Calculate bbmine = bbmin - end, and bbmaxe = bbmax - end. Check if end is outside the sim,
so clamping is needed at all, by checking that at least one coordinate in bbmine is positive
or one coordinate in bbmaxe is negative (set 'clamping_needed').

4) Shift coordinates so that ''begin'' becomes the origin and ''end'' becomes the direction
(bbmin -= begin; bbmax -= begin; dir = end - begin). Lets call ''end'' ''dir'' from now on.

5) Check that bbmin has three negative coordinates and ''bbmax'' has three positive coordinates.
If not then ''begin'' is outside the bounding box (if the signs are correct, except there are one or more zeroes, it's on the border
and you can just return ''begin''). Not sure if you should return an error code or return just no results.
Finally, if begin is outside the bounding box, but end was inside, you might want to clamp begin
instead of end. Lets assume that begin is inside the bounding box for now. If end was also inside
it, then no clamping is needed and we stop here.

6) Clamping is needed. Calculate dir.x / bbmin.x, dir.x / bbmax.x, dir.y / bbmin.y, dir.y / bbmax.y, dir.z / bbmin.z and dir.z / bbmax.z.

7) Find the largest value 'max' of those six and return ''begin'' + dir / max as the collision point of the ray in the direction dir.

As you can see, this is a very fast routine. Still, I think it should be added to the server side.
I didn't add code in order to avoid any license problems ;)

[[User:Aleric Inglewood|Aleric Inglewood]] 12:00, 3 July 2010 (UTC)

Actually, using SSE2, clamping would take just a few cpu instructions. It's not a question of efficiency for me, it's a question of future compatibility. Since we don't have script versioning for LSL, if we later add the ability to cast rays between sims or change the size of a region, existing scripts will break. I've been thinking of adding a version parameter to this function in order to deal with that possibility, in which case I could clamp in native code.

Cheers
[[User:Falcon Linden|Falcon Linden]] 17:20, 3 July 2010 (UTC)

:Definitely, clamping in native code rather than LSL is very desirable. I'm thinking a version parameter would be best done as a way of accessing old behaviors, similarly to how we have legacy prim types in llSetPrimitiveParams, and optional for the latest version. What do y'allz think?
::--[[User:Michelle Resistance|Michelle Resistance]] 15:37, 8 July 2010 (UTC)

== return also types casted ==

since filters RC_REJECT_AGENTS, RC_REJECT_PHYSICAL, RC_REJECT_NONPHYSICAL, and RC_REJECT_LAND are used, and therefore detected, it would be handy if in the results returned, the status AGENT, NON_PHYSICAL, PHYSICAL and LAND would also be returned. Is it douable ?
--

I've been thinking about that. Either I'll somehow include the type in the list of returned data (perhaps only if you add the flag RC_GET_TYPE or something) or else modify llGetObjectDetails to return the data. You'll definitely have access one way or the other. Regarding land, though, you can definitively identify that because it will return null UUID.

[[User:Falcon Linden|Falcon Linden]] 17:20, 3 July 2010 (UTC)

== Meep ==

Heya Falcon, really would absolutely love to have an llCastRay function in production.

I saw you had a concern of versioning issues. To overcome that, I heavily recommend using a list as an input, as that would be far more flexible on the kind of parameters and options you can push through rather than fooling yourself into using a hardcoded structure of llCastRay(vector start, vector end, other stuff) etc. A bit like how llSetPrimitiveParams works basically. For example in the past, LL upgraded the prim type interface from legacy to a more advanced and flexible set of input (torii, tubes and rings, yey), they could do this easily because a list was used as a parameter in the function, instead of having to expend resources on adding more functions, bloating LSL and causing legacy issues.

I also have a question, when you cast a ray and it hits an avatar, that hits the avatars' actual sphere-ish phys mesh, correct?

I have actually experimented personally with LSL and my custom client with a prototype LSL Script API, I could offload raycast processing into nearby clients easily and even built a half-working hexapod spider that can walk on a prim landscape, as well as all the fun raycasting combat gun stuff :). So, I have some serious experience to share in this field and having the raycasts locally processed would be really useful in a more timely manner (rather than suffering the delays of network lag).

What are your thoughts on the kind of filtering? Whitelist versus Blacklist? Whitelists are apparently more effective based on desire. (Would be good for consistency (which is hard enough to come by..): llSensors, llListen, ...)

On a last note, you might be wondering about my achievement with my custom client, I couldn't get raycasting weapons taking off because there is a missing critical element to gameplay: Tracers. The user of a gun MUST be able to see WHERE their bullets went (guns use fire cone spread algorithms for added realism). This is one of the significant problems that keep raycasting usage in weaponry really taking off. Otherwise I could have seriously introduced raycasting and changed the face of SL combat with my custom client. If only particle systems could be spontaneously created midair (without requiring the particle system to be 'attached' to the prim (it's possible code-wise in the client btw)) via scripts to simulate tracer effects, then raycasting would seriously be able to take off socially.

--[[User:Nexii Malthus|<span style="color: #bbb; text-shadow:-1px -1px #ddd, 1px 1px #888;">Nexii Malthus</span>]] 02:10, 4 July 2010 (UTC)

Hi Nexii,

Let me take these one at a time. First, in regard to versioning, LSL lists are very inefficient on the C++ side. They're implemented as linked lists (yuck). I do see the advantage to using a list for parameters, but it would make parsing it slower and I'd rather pull a Windows API (heh, also yuck) style move and (a) add a reserved version number parameter and (b) if necessary later, create an llCastRayEx function. Not the world's most extensible implementation, but c'est la vie.

Second, an avatar's shape isn't sphere shaped at all...and it's not a mesh, it's a convex hull. Its basic shape is kind of like a capsule. I'll leave the process of determining its exact shape via llCastRay calls with RC_GET_NORMAL as an exercise to the reader. :) (And if you do it, be sure to post pictures! That would rock.)

Third, I'm pushing hard for LL to provide client side prediction/client side physics. Although that wouldn't immediately lead to client side scripting, it eventually might. And in the meantime, although open source viewers would need to replace the physics module with an open source version (of which there are plenty), you would have a framework for doing physics-based raycasts locally.

Fourth, regarding filtering, it just made the most sense to use blacklists as it's most common to want to know "What's the first thing I'm hitting?" It's less common to want to know "what's the first avatar/prim/land triangle that I'm hitting?"

Finally, after seeing your comment about tracers I looked up the details of llParticleSystem and was astonished to see that, as far as I could tell, you're totally right. Here's one idea as a temporary workaround: rez a transparent, phantom, nonphysical sphere (perfect, solid spheres are the simplest physics shape available) at the location you need your particle effect, create it there, and then call llDie(). It sucks, I know, but I'm not a graphics programmer and can't add an appropriate particle system function. Another idea, though much much less efficient, would be to rez a set of long, colored, phantom cylinders the length of the raycast. It's still much more efficient than prim bullets since it would be nonphysical and phantom, though.

Hope that helps,
[[User:Falcon Linden|Falcon Linden]] 05:44, 4 July 2010 (UTC)

[[File:Avmeshforms.png|256px]]
Rendering of what the standing and ground sitting av shapes are!
--[[User:Moy Loon|Moy Loon]]
: Hahahahah, awesome! :D
: btw, can you repeat this but with a crouching av as well to confirm there is no change when an av crouches please? --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 18:35, 24 July 2010 (UTC)

I already know that crouching avs have no change, The sitting on a prim is different than the ground sit though!
--Moy

== Function to not fail, what do you think? ==

I made this:

<lsl>list JustRayIt(vector start, vector end, integer filter, integer flags)
{
list temp;

while((llList2Integer(temp, -1) < 0) || (llGetListLength(temp) == 0))
{
temp = llCastRay(start, end, filter, flags);

}

return temp;
}
</lsl>

The idea being to halt the rest of the script until it can get a valid trace; does it work the way i intended it to? Is there any downside to using this? Is there a better way to get the same result? --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 04:14, 4 July 2010 (UTC)

Hi Tigro,

The script you're suggesting would, sadly, be hugely inefficient. It would hog system resources until the script's time slice ran out. And, to make matters worse, once you fail you're guaranteed not succeed until at least the next frame anyway. I'm not a huge lsl scripter, so I'm not 100% sure, but I believe if you added an llSleep(0) call in the while loop, your script would be put to sleep until the next frame. Failing that, try llSleep(0.1) or some other small number.

Good luck,
[[User:Falcon Linden|Falcon Linden]] 05:29, 4 July 2010 (UTC)

:The way it is on the Oatmeals, do tracing ever fail in the frame? --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 05:40, 4 July 2010 (UTC)
:Also, doesn't llSleep hog systems resources just the same? --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 05:44, 4 July 2010 (UTC)

On Oatmeal, casts will fail if the overall physics FPS drops too low. It will never fail due to too many raycasts in the same frame, however. In production it will, but I wanted to see how people used it before determining appropriate limits.

llSleep stops execution of your script and allows the simulator to move on to processing another script. It is not implemented as a busy-wait. (At least, I sure hope not. I haven't actually checked the code.)

[[User:Falcon Linden|Falcon Linden]] 05:50, 4 July 2010 (UTC)

: How about this version?
<lsl>
list JustRayIt(vector start, vector end, integer filter, integer flags)
{
list temp;

while((llList2Integer(temp, -1) < 0) || (llGetListLength(temp) == 0))
{
llSleep(0);
temp = llCastRay(start, end, filter, flags);

}
if(llGetListLength(temp) == 1)
temp = [NULL_KEY,end, llVecNorm(end-start), 0];

return temp;
}
</lsl>
: It got the sleep as you suggested, and if it doesn't hit anything in range it still returns a key, a hit position, a normal (so it kinda works like a telescopic feeler, when not reaching anythign it eventually stops at maximum extension with no deflection), while still keeping llList2Integer(theraylist, -1) == 0
--[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 19:43, 7 July 2010 (UTC)
:Ok, i finally managed to get it to wrok right, i think, but hsould i keep posting here clogging the talk page?

== Partially offtopic: about SVC-4606 "Surface conveyour belt" ==

Falcon, if it's not you, could you please bring [http://jira.secondlife.com/browse/SVC-4606 SVC-4606] to the attention of whatever Linden that would be able to evaluate it and get it in the plans if it's possible please? (If it's you, then please take a look and see what you can do) --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 04:43, 4 July 2010 (UTC)

I have thought about adding a much, much simpler version of this (where you simply get to specify a velocity vector and a face of the prim), but it would be at least a little tricky to implement and there are a number of things of more general use that I'd like to get to first. Some day, though, it would be a great feature.
[[User:Falcon Linden|Falcon Linden]] 05:51, 4 July 2010 (UTC)

:If the server already knows about which face collided and things like the normal of the collision point (and of course the texture parameters of the prim), wouldn't it be just a matter of basic vector math to get the resulting force and stuff? I imagine this could be a game changer close to the scale of flexies, people moving around a mall on flat conveyors like those on some airports, working escalators, more realistic wheeled and tracked vehicle behavior, people will find all sorts of uses for it. Is there somewhere i can see the stuff you got planned? --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 06:01, 4 July 2010 (UTC)

I'm about to head out (it IS a Saturday night here, haha), so this is probably my last post, at least for a few hours, probably until tomorrow. The problem is related to stability and details about determining which objects to apply the force to and how. In the physics engine, this would be done by modifying the contact points between the conveyor belt and the other bodies. Also, the server doesn't really know which face collided, which makes it trickier still, as that info would have to be derived dynamically any time a body came in contact with the conveyor belt object. Finally, it would almost certainly break avatar animations which rely on the avatar's velocity (not the requested motion of the user) to determine when to play a particular animation. Unfortunately, I don't have a publicly visible list of projects I'd like to complete. But they do include llCastRay (yay progress!), llCastShape (see SVC-5389...I think...the raycast SVC, exposing the Havok vehicle kit, providing for alternative physics representation (so that the shape you see isn't tied to the shape the physics engine sees, allowing simpler collision geometry), providing control of friction, density, restitution, and gravity, ... the list goes on. Please bear in mind, however, that there is absolutely no guarantee any of these will be shipped as they are mostly unscheduled it isn't clear what LL's priorities will be in the coming months. Oh, and of course, given the opportunity, I'd put all of these ideas aside to work on client side prediction which would have HUGE impact on lag, although it wouldn't provide much in the way of new resident-facing features.

Have a good night,
[[User:Falcon Linden|Falcon Linden]] 06:24, 4 July 2010 (UTC)

That partial list of projects is, like, my wishlist as an LSL scripter. You're my new favorite Linden. ^_^;
--[[User:Michelle Resistance|Michelle Resistance]] 15:44, 8 July 2010 (UTC)

::Some of those are among the feature suggestions i've filled on pjira :)
::Falcon rocks indeed!! --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 16:10, 8 July 2010 (UTC)

== selfignoring? ==

Is there a way to have the raytrace ignore prims in the same linkset? --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 05:42, 4 July 2010 (UTC)

No, unfortunately this is not possible and would be hacky to implement (though it could be done if there were enough demand for it). It will, however, always ignore a shape that the ray begins inside of. So if you use llGetPos() from a convex prim, that prim will not be returned by the cast. You can always use the UUID of the prim to ignore the result as well.

[[User:Falcon Linden|Falcon Linden]] 05:46, 4 July 2010 (UTC)

== On the topic of limiting it to not work past a distance ==

It was done with llSensor, and what happened? People wasted server resources to overcome the limitation; you still think it's a good idea? --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 08:04, 4 July 2010 (UTC)

Nope. I don't. But llCastRay isn't artificially limited to a distance. It's simply limited to work within the region. But that isn't an artificial limit, it's a fundamental one: llCastRay uses the physics engine for raycasts. On a given simulator, nothing exists in the physics world outside the region boundaries.

[[User:Falcon Linden|Falcon Linden]] 09:47, 4 July 2010 (UTC)

:Hm, sorry, i'm not finding it now, but i could swear i had read you saying somthing along the lines of "you wouldn't want people raycasting from the other side of the sim", dunno... --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 09:56, 4 July 2010 (UTC)

Yes, I did say that. I then proceeded to change my mind. :)
[[User:Falcon Linden|Falcon Linden]] 18:59, 4 July 2010 (UTC)

== Is it a logical bug on my script or does it not update fast enough? ==

Does the data llCastRay reads from gets update as often as the position and rotation of phys objects or does it get updated less often? I'm mostly confident that the start position is inside the prim but somtimes the trace will hit the prim somehow, it happens more often when the prim is bouncing around fast. --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 11:23, 4 July 2010 (UTC)

That depends on how you're updating the objects. If you're calling llSetPos() or similar in your script, those updates will not be processed until later, whereas the llCastRay call will be processed immediately. I suspect llGetPos() will return the value you set with llSetPos() even though the physics object isn't there yet.
[[User:Falcon Linden|Falcon Linden]] 19:01, 4 July 2010 (UTC)

== "I'm personally praying that llCastRay will make simulated projectile weapons essentially obsolete in SL. " ==

I've spent a little time exploring the functionality of llCastRay today. From the perspective of a veteran LL damage combat scripter;

In terms of raw utility, llCastRay effectively provides the ability to determine a bullet's target without the intervening physics. This is an advantage because it means that traditional region crawl caused by irresponsible people spamming physical objects is significantly reduced. It also means that the number of bullets required to send an individual home is reduced; in the case of the firer being able to aim, of course.

The function seems more fitted to abstracted combat with meters and script awareness (determining distance to surfaces, etc) however, because it provides a very large volume of data back to the script calling it but does not impact what it is detecting in any way.
While it is possible to build a weapon that uses it for projectiles with traditional LL damage, the benefits do not necessarily outweigh the negatives; it effectively moves the majority of work from the source system to the projectiles instead. Using communications such as listens to transfer a target vector from a gun to a bullet on each rez is obviously absurdly inefficient considering the rates at which most people like to fire them and therefore the cast is better placed in the bullets themselves; this means that the bullets cannot be temporary prior to casting and therefore realistically on rez, although they can simply be set temporary subsequent to casting. Regardless of the method of acquiring the target position, the bullet must still travel to the location to inflict damage; a stacked primparams position is the obvious solution, as it also allows for temponrez and physics to be set in the same call.

Would it be possible to implement a sister (if somewhat crippled) function to llCastRay that has the capability to inflict LL damage on agents? While I see a great deal of value in llCastRay it is not necessarily preferable to physics as a combat tool. Something along the lines of an llCastDamage which is restricted to cast from the root position of the object calling it along a fixed axis. In a similar manner to a sensor, except with a damage variable similar to the llDamage() prim param setter that affects only the first thing it intersects. Additional fluff could be a contact sound triggered at the point of intersection, contact particles and so forth.

tested projectile, just for reference:
<lsl>
vector xyz(vector in)
{
if (in.x > 255.9) in.x = 255.9;
else if (in.x < 0.1) in.x = 0.1;
if (in.y > 255.9) in.y = 255.9;
else if (in.y < 0.1) in.y = 0.1;
if (in.z > 4095.9) in.z = 4095.9;
else if (in.z < 0.1) in.z = 0.1;
return in;
}

default
{
state_entry()
{
llCollisionSound("",0.0);
llCollisionSprite("");
llSetDamage(100.0);
}
on_rez(integer s)
{
if (!s) return;
vector p = llGetPos();
vector d = <20.0,0.0,0.0>*llGetRot();
list ray = llCastRay(p,xyz(p+d),0,0);
list tgt = [PRIM_POSITION,llList2Vector(ray,1)];
tgt += tgt += tgt += tgt += tgt += tgt;//1,2,4,8etc
llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_TEMP_ON_REZ,TRUE]+tgt+[PRIM_PHYSICS,TRUE]);
llDie();
}
}
</lsl>
[[User:Jeremy Duport|Jeremy Duport]] 19:51, 4 July 2010 (UTC)

== This is *not* a viable replacement for projectiles ==

llCastRay is a great idea, and I'll make heavy use of it in a wide range of applications, but there's no way it's going to replace scripted bullets in any meaningful way.

There's just no other way to get a decent visual effect for bullets. Particles are an enormous performance drain on the client [and don't anyone tell me to just get a better machine, I'm a poor student, damnit], and of course look the same from every direction. Scripted bullets are also the only timely way to get a particle effect at unscripted impact locations.

There's also the problem of communicating effectively between a gun and a scripted target. With combat going on, something like a listen on targets and regionsay from guns is going to trigger zillions of unnecessary events. Sure, *I* know how to properly hash UUIDs to integers, and there's reasonable code for that on this wiki, but have you actually seen the kind of shit most scripters in SL try to pull? Note that people are *still* using resizer scripts in every prim of a linkset and controlling them with linked messages.

Also, despite being sidetracked by https://jira.secondlife.com/browse/SVC-5953, I'm a week or so of work away from releasing several weapons that trigger bullet rezzes via changed events, rather than by inked messages. Tyro Dreamscape has already successfully demonstrated this method as a near-zero-sim-impact way of squeezing high firing rates of scripted bullets out of as few rezzing scripts as possible. Sure, you could bring up sim garbage collector woes, or my argument from above about the absurdly low coding standards among scripters, but the former has not been an issue in practice, at least with intentionally minimalist bullet scripts, and the latter is something I'm expecting market forces to help with. We *can* do scripted bullets the right way.

I'd really like someone to prove me wrong. Thoughts?

--[[User:Michelle Resistance|Michelle Resistance]] 15:55, 5 July 2010 (UTC)

Ummm, you do realize that you're still just calling a function in one script, that triggers an event in another, right? Except that where a linked message merely communicates between scripts, the changed() event requires triggering a function that changes some parameter of the other object, so you're asking the simulator to do a small bit of extra unnecessary work in between calling the function and triggering the event.

You are right that scripted bullets can be done the right way. But the right way doesn't mean reinventing the wheel or creating a Rube Goldberg machine, it requres understanding what the wrong way is, why certain things use extra processing resources, and finding the most effective ways to mitigate those problems. Keep in mind that people have tried to use llResetOtherScript() and actually believed that it was more efficient. It was the same sort of reasoning involved, where someone thought "method A is laggy, therefore method B will be better."

It is quite possible to make efficient physical projectile weapons. But just because many people are unable to do so does not mean that you need to find some supersekret new method for doing so. It is simply a matter of using good coding practices like KISS. Granted, it's oh so much easier to market something that's new and different, but that doesn't make it so.

[[User:Jahar Aabye|Jahar Aabye]] 19:24, 5 July 2010 (UTC)

Passing data through a changed event, at least the way Tyro and I have been doing it, has far less impact on the sim than the string operations that most people do when communicating between scripts via link messages. Try it, it's rather impressive. And, to dispel concerns that it's just a gimmick, I'll explain exactly what I'm doing and (probably) why it works better.

I've got a main script and several rezzer "thread" scripts, all in the same prim (they don't need to be, but that's how I'm doing it), a hollow sphere. When a user pulls the trigger (or an automated weapon decides to open fire), llSetColor(<AUTO, timer, aim>) is called [llSetLinkColor also works, though llSetLinkPrimitiveParams and the fast variant don't, as they don't trigger a changed event], where AUTO is a predefined floating-point number identifying that it's a firing order, timer is the argument we want the thread to past to llSetTimerEvent to control the firing rate, and aim is either 1.0 or 0.0, signifying if I'm using the prim's other face to provide additional data about where to aim the bullets (which we can do without triggering a second changed event, if the llSetColor call for the other face is done immediately before or after the firing-order call). This has been significantly more responsive (in LSO, anyhow) than a linked message in all my tests, and can easily support rather egregious firing rates [~25 bullets per second with five threads - well under the goo fence limit, though probably more than you'd want] from many simultaneous users without affecting sim FPS. My team's theory, that led us to try this in the firs place, was that the link_message dispatch code on the sim side is slowed by argument passing and filtering in a way that the changed event is not. That we're only performing floating-point operations when using face color as an argument buffer seems to make the difference. Certainly, one could use the link_message integer parameter to do filtering, and I write all my APIs that way, but it appears the extra overhead of passing string and key arguments, even when not used, is enough to upset the sim when performed at high speed. As a side benefit, using the changed event keeps the rezzer threads from needing link_message handlers, reducing the number of scripts that need to filter out other communication happening in the linkset.

Hope that allays your concerns. If not, I'll be here all week. ~_^

--[[User:Michelle Resistance|Michelle Resistance]] 23:06, 5 July 2010 (UTC)

::Well yes, you're simply shifting a portion of the load from the VM (which would handle the linked messages) to the Database and Simulator (which are handling the altering of the primitive's parameters and which then triggers the VM's changed() event). This does not make it particularly more efficient, as I mentioned before you still have a function call and an event triggered, you're merely routing it through another method, in this case the simulator, which has to then alert every client within draw/LOD distance as to the nature of the change. I am fully aware of what you are doing and how you are doing it, you are at least the third person in as many years who has mentioned it.

::Rather than a lecture on how to script guns, I'll simply say that if it works for you, then that's all that matters. There are efficient ways to use linked messages, and there are incredibly inefficient ways to use linked messages. Similarly, I am certain that people will find right ways and wrong ways to handle llRayCast() if it is ever implemented. Incorrect methods will undoubtedly spread through the grapevine with assurances that "this supersekrit way is teh best evar!!!11!!" Market forces have as of yet had minimal effect on poor scripting with regards to guns in SL, I wouldn't expect that to change at any time in the future. As you correctly note, many fashion designers still put resize scripts into every prim of hair.

::In some respects, I doubt that many amateur gun scriptors will be much different after raycasting than before. It may be less likely to be used by many amateur gun scripters simply because the default LL Damage system is built around physical collisions, and presumably that would remain the same. Also, combat systems that use raycasting would likely require at least a decent understanding LSL or else might use prewritten no-mod scripts to do the raycasting. To that extent, I do worry that raycasting may appear to be more efficient when it debuts on the grid, if only because of self-selection in terms of who is using it and how it is used. This is probably something that should be considered if llCastRay() is ever implemented, as it does have an effect on how to interpret any sort of metrics gathered when trying to determine its relative efficiency compared to bullet-based guns.

::In the end, it will be one more tool. I would hope that the devs at LL do not really think that this will completely replace physical projectiles, but it is nice to have the option. Similarly, I do hope that people understand that the relative efficiency of various guns on the grid varies wildly, and that the scriptor has a far greater impact on the relative efficiency of a gun than whether it uses physical bullets or llCastRay() when it is implemented.

[[User:Jahar Aabye|Jahar Aabye]] 00:18, 6 July 2010 (UTC)
::: Latelly i've been using llTarget and not_at_target to have stuff run as fast as the server allows without actually using somthing like while(true) --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 00:31, 6 July 2010 (UTC)
:::: In my tests, I've found that LSO loops seem to end up *slower* than repeating events like timers and not_at_target. 'Sweird. --[[User:Michelle Resistance|Michelle Resistance]] 00:47, 6 July 2010 (UTC)
:You could use llRayCast to verify if the aiming hits anyone,and then rez a "bullet", posJump it to the target and make it phys to collide if you wanna use collisions to relay hits. --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 23:57, 5 July 2010 (UTC)

:::Actually, that would probably be the worst of all worlds. You're still rezzing a bullet, still moving it to the target, still making it physical, still colliding it. All of the things that llCastRay() is attempting to prevent. Also, most combat systems that involve collisions limit (or should limit) the minimum velocity of a collision. To get around this, one would probably have to add a call to llApplyImpulse() or something similar. At the end of the day, you wind up with a situation not much better off than just firing a bullet.

:::llCastRay() is probably best implemented in a combat system in a manner similar to current sensor-based combat systems, which have been around for years. I'm not sure that sensor-based (or raycasting-based) combat is any better or worse than physical bullet-based combat. Each has different tradeoffs, and at the end of the day it's going to come down to how these functions are worked into the system that gets set up. Whether using sensors, raycasting, or bullets, it's all about understanding the strengths and weaknesses of each system, and working with that in mind. Raycasting does have some significant strengths, but only if you take advantage of them. Raycasting, if done correctly, will probably take some load off the physics engine at the possible cost of runtime efficiency and memory. Physical bullet systems are simpler and may have an advantage in terms of runtime efficiency and memory use if done correctly, at the expense of offloading more of the work on the physics engine that has to deal with all of the active objects and the collisions generated.

[[User:Jahar Aabye|Jahar Aabye]] 00:18, 6 July 2010 (UTC)

Ahoy folks!

I don't know enough about the issues in LSL to comment on most of the topics brought up in this thread. But with regard to the issues around the appearance of raycasts vs rezzed bullets, once you use llCastRay, you'll at <i>least</i> be able to set your bullets phantom. This prevents the physics engine from needing to check for collisions with anything but the land. Unfortunately, due to an old bug, collision checks against the ground are still very expensive. We expect to fix this by 1.44 at the latest. Once that's done, phantom bullets will be much more efficient.

::Phantom bullets would give us the problem of having to inform them somehow of a hit so they can [promptly] self-destruct instead of continuing to pass through things… unless you're suggesting the bullets themselves do llCastRay and short circuit the physics system. That sounds like a terrible hack, though. Shouldn't it be more efficient to let the physics engine do its thing, rather than going through the twisty little passages of LSL VMs? --[[User:Michelle Resistance|Michelle Resistance]] 17:02, 6 July 2010 (UTC)

Regarding the matter of rezzing a bullet and then using the posjump trick (assuming that refers to the llSetPrimitiveParams hack where you repeatedly set the prim's position in a second call), that will actually be substantially less inefficient in 1.40 (when we finally get it right!). The reason is that in the past, each time you set the prim's position, the physics world would be updated, sometimes many many times in a frame. That is no longer the case (only the final position is actually used).

::"[[PosJump]]" actually refers to a different >10m movement hack than what you're talking about, which is known as "[[WarpPos]]". PosJump is very much preferable, as the LSL script doesn't have to waste time and memory calculating a series of intermediate steps… but it doesn't work with llSetLinkPrimitiveParamsFast, just the slow variety. --[[User:Michelle Resistance|Michelle Resistance]] 17:02, 6 July 2010 (UTC)

:::Last i tried it did work with llSetLinkPrimitiveParamsFast, did you test it yourself? --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 17:31, 6 July 2010 (UTC)
::::Yes, just a few weeks ago… though now that I think about it, I could have been confusing the issue with that posjump fails when the object is physical. --[[User:Michelle Resistance|Michelle Resistance]] 16:54, 7 July 2010 (UTC)

And yes, an LSL busy loop (e.g., while(TRUE)) is very, very inefficient. It uses as much of the sim's resources as available until it is cut off for the frame. Even the most inefficient event scheme would probably be better than a busy loop.

[[User:Falcon Linden|Falcon Linden]] 03:25, 6 July 2010 (UTC)

::I've found that even a bounded for loop is slower than a timer, in practice. Any idea why this might be? --[[User:Michelle Resistance|Michelle Resistance]] 17:02, 6 July 2010 (UTC)

In LSO it makes sense that using [[changed]] would be faster than the [[link_message]]. The changed event has one parameter, link_message has four; two of which are strings. It takes more computer time to push a link_message event onto a scripts event queue then it does to push a changed event. It takes more time to copy the values into script memory and trigger the event. Mind you, using [[llSetColor]] this way is going to cause a huge number of updates that the sim will try and send to all users in sight of the weapon. For a long time I thought we need a better comm event, no string, no key, just a list. Than I latched onto C# and the idea of building custom events. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 16:21, 8 July 2010 (UTC)

== Possibility to limit list length? ==

I am concerned about the memory issues posed by this function. It was mentioned above, but not really fleshed out. In order to be useful for a combat perspective, you can't really set any of the flags (that is, it must return all agents and objects) so that you know whether there is a wall or some other barrier between yourself and the target. This means that you can get a potentially very long list with a UUID and vector position for each object hit. This could easily eat up several kb of script memory.

However, limiting the function to returning the first object hit (as has been mentioned as the possible final version) also removes some potentially interesting uses of this function. For example, you could have a situation where you get one result if it reaches an avatar unimpeded, another if there is a single object between you and the other av, and then no result if there is more than one object.

Would it be possible to compromise, and add another variable to input into the function to select the total number of objects to return? So you could have:

list llCastRay(vector start,vector end,integer filters,integer flags,integer num_returned)

Where num_returned would be the total number of objects hit, starting with the closest. It could be enumerated starting from 0 so as to match the values in the returned list, or from 1 if you would need to use 0 to set it to no limit.

As for this function making physical projectile combat obsolete, I do not believe that this will happen. I see this as akin to how sculpties have enhanced building: they give builders more options and allow for a greater variety of creative designs, but they have not obviated the use of regular prims. Similarly, I think that this feature may increase the options available when developing combat systems and weapons. However, I think that there are advantages to physical projectiles (such as the ability to code for ballistic trajectory). I have used sensor-based combat systems before (although this has many advantages over those as well), and I have found that those feel a bit too much like playing "laser tag" especially when used over longer distances.

I think that this will create more options for combat, it may allow for new types of combat, but there are always tradeoffs inherent in any system. Raycasting methods will have advantages and disadvantages, they will be more efficient in some ways and less in others. It will be nice to have this as a new option, but I worry about overselling this as a complete replacement. After all, the Mono VM was marketed as being the wave of the future that would make LSL-compiled scripts obsolete. While many scriptors knew to be cautious with a new VM, LL's overhyping of the system created a marketing environment where customers were asking if every product was Mono. This resulted in Mono being used in a vast number of situations where it was not only unnecessary but entirely inappropriate.

I worry about a similar situation unfolding here, where marketing llCastRay as a complete replacement for physical projectiles will encourage non-technical people to demand "those new ray guns LL keeps telling us about, why haven't you been making those?" Then these same people will inevitably come back a week later demanding why the RayCast "bullets" behave differently. All that I am asking is that you please acknowledge that non-technical people will read these announcements without understanding the technical nuance and the inherent tradeoffs. Overhyping something as a "complete replacement" when it is a new feature that allows for new options may only wind up creating new headaches. A new feature that opens new doors and allows for new options for creators is great, it is wonderful. No need to oversell a good thing.

[[User:Jahar Aabye|Jahar Aabye]] 19:24, 5 July 2010 (UTC)

In the final version of llCastRay, if more than 1 hit can be returned I'll be sure to give you the ability to select some kind of limit (even if it's only a binary "first hit or all N hits" choice--where N is definitely a finite number determined by the specification).

Also, if using llCastRay feels too much like laser tag, try adding a small delay before the raycast executes or adding some randomness to the cast's direction. As for the ballistic trajectory, if that's really critical, there are ways to simulate it. For example, you could make 4 ray casts approximating the parabolic curve, but you'd have the possibility of performing an early-out if one of the first casts hits something.

[[User:Falcon Linden|Falcon Linden]] 03:33, 6 July 2010 (UTC)

::Yes, randomness for the direction is easily doable by modifying existing code. What I meant about ballistics isn't just the trajectory, drop, and inaccuracies like random variations in direction. A delay before firing can be done, but one factor in the current projectile combat is that your aim is highly dependent upon the distance to your target and how this relates to the target's movement. With projectiles, it is far easier to hit a close target than a far one, and if the target is moving, this has a disproportionate impact on difficulty with a farther target. This is because of the time that it takes for the bullet to reach the target, because the bullet's travel is not instant.

::Now, because SL physics limits bullet velocity to far less than in real life (our SL bullets are usually 115 m/s while a 5.56mm round from an M16 is well over 900 m/s), the result is that it greatly exaggerates the effects of distance and movement, but distance in SL is always a somewhat arbitrary measurement. So I recognize that physical projectiles are far from perfect, and plenty of people have complained of difficulty when they first try SL combat after experience with other video and computer games that probably are using raytracing or similar technology. But it does add a satisfactory level of difficulty and skill to competitions.

::I know this is probably not feasible, and I certainly don't want it to wind up polluting the code and making everything more difficult, but is there any way to give the ray a specific velocity, rather than being nearly instant? I'm not just talking about a delay between the firing input and casting the ray, but having the ability to set the ray to move at a specified speed so that distance to target matters? I mean, I suppose that I could fire multiple staggered rays to try to imitate this, and have the script read data from each successive ray only between certain distances....but that's gonna get really inefficient really fast, while the simulator is already calculating avatar distance and movement.
--[[User:Jahar Aabye|Jahar Aabye]] 05:47, 7 July 2010 (UTC)

:::Hey Jahar, I see what you're saying, but no, there's no way to slow down the ray, it's a synchronous, instantaneous query into the physics world's current state. You'll just need to come up with a new clever way to inject difficulty into things :) (I'm usually terrible at first person shooters and those have stupid AIs and instantaneous raycasts. I'm sure a group of human enemies can find a way to make hitting them challenging while still being fun, even if the bullets travel faster now.) Also, given that the physics hitbox of a player is pretty narrow, I'm guessing it may be harder than you expect to hit a moving target from the other side of the sim, even with a raycast. But then, I haven't tried.
:::[[User:Falcon Linden|Falcon Linden]] 03:46, 8 July 2010 (UTC)

== Raycast Damage ==

Hey folks,

I've been trying to coalesce some of the most significant suggestions for llCastRay, and one theme that seems consistent is that weapon system makers need a way to be notified when hit by a ray. I'm thinking of two possible features:

1) For integration with LL damage, it might be possible to create another parameter that takes a list of parameters (albeit with a bit more strict requirements than in primparams args due to inefficiencies in list processing). In the future, this could include a version number, but in the meantime, one possible parameter could be RC_DAMAGE which would apply a requested amount of damage to the first object hit if that object is an avatar and if the region is damage enabled, etc.

2) An event, ray_impact, that the caster script could choose to trigger in impacted objects. This would, in principle, alleviate many of the security concerns around raycast-based weapons systems. In the interests of full disclosure, however, I should tell you that (a) I don't know how to create a new event (I'll have to speak to Kelly Linden) and therefore, (b), I don't know if implementing this feature would be prohibitive in terms of engineering time. But let's suppose I <i>could</i> implement this. What information would you want the receiving object to be able to obtain in this event? The fewer the better, so my first instinct would be no information (it's enough to know you were hit). Beyond that, knowing the exact location of the hit could be nice, as would knowing the UUID of the casting object (maybe?) and perhaps receiving bit of user data provided in the llCastRay call. Would that be helpful? How might you use it?

Cheers,

[[User:Falcon Linden|Falcon Linden]] 03:47, 6 July 2010 (UTC)

:: #1 sounds excellent, though it's been notoriously difficult to get people to play fair with LL damage.

:: A ray_impact event would be a godsend. The UUID of the casting object would be essential, and a hit location [and maybe hit normal] would be very useful. Ideally, an appropriate set of llDetected* functions should work inside the ray_impact event similarly to how they're used in a touch event. Might need a new one, like llDetectedRayNormal. Still, just an event with a signature like ray_impact(key id, vector pos, vector norm) would be massively useful. Let's see… I'd be using llCastRay for collision avoidance on robots, and ray_impact would make it easier for the robots to exhibit schooling behaviors. Similarly, such robots could interact with scripted objects in their environment (door controls, moveable boxes?) elegantly. Other uses… target ranges for raycast-based weapons… missile lock detection in fighter combat… assuming we could use it in attachments for impacts to the avatar, combat meters for raycast-based guns… AR-like user interfaces implemented by raycasts from a HUD [though the math for generating such rays may be rather complicated]… line-of-sight communication between objects and avatars… I'm sure there are more that I can't think of at the moment. Bottom line, adding functionality to LSL is a Very Good Thing. --[[User:Michelle Resistance|Michelle Resistance]] 17:46, 6 July 2010 (UTC)

Falcon, I've been silent on this point because I don't agree with the naysayers; <tt>llCastRay</tt> is exactly what I've been needing for the combat system I'm building. For those that want to use Linden Damage, I think <tt>llTakeDamage()</tt> (perhaps accepting negative values to allow for healing) would be valuable, but beyond the scope of this project. I don't personally hold with the logic that it's marginally hard to write non-laggy chat communications, so we should expect people to write non-laggy bullets and guns. It'll require combat to be done differently, so it's not an evolutionary change, but I don't see that as a barrier.

That said, if it can be done, RC_DAMAGE would be a nice thing to have. I do build my weapons to fail down to Linden damage if no supported combat system is found, and if Linden damage is enabled. <tt>ray_impact</tt> would also be nice, especially if it's only explicitly triggered; UUID, impact point, and an arbitrary integer constant sent by the ray caster would be the values I'd see as most useful. Perhaps rather than go the whole list of parameters route for RC_DAMAGE, just add another integer parameter to <tt>llCastRay</tt> that would be used differently with different flags? In any event, not having either of these would in no way dampen my enthusiasm for this feature or impact my plans for using it, assuming it gets deployed. [[User:Jack Abraham|Jack Abraham]] 19:23, 6 July 2010 (UTC)

::I think that suggestion #1, or some similar functionality, would be essential if you want this function to work with the current default LL Damage system. The LL Damage system currently requires a physical collision between an avatar and an object scripted with llSetDamage(). This means that I can simply fire a bullet at an avatar and apply damage, but raycasting alone would not be able to perform any sort of damage without also requiring some sort of bullet unless you add this feature.

::Suggestion #2 also sounds useful, if possible. I suspect that many people will still utilize weapon-meter comms even if you include this function, because there is still greater security there in terms of being able to limit what can do damage within a system. However, Michelle outlines many other excellent uses for including this feature. In addition to making it far easier to construct non-avatar targets, it dramatically increases the potential usage for raycasting beyond just a replacement for projectiles. I was just talking to a plane maker last night about how raycasting could make laser-guided bombs far more interesting, and while that example wouldn't require this extra feature, it does illustrate that raycasting can evolve into so many other things besides just a bullet, and so adding in the feature to detect a raycast may expand the use of raycasting into all sorts of applications beyond what any of us could envision.

::As for what information might need to be passed? Jack's suggestion of adding an all-purpose integer definitely sounds like the most important. Obviously an integer would be required to set damage, and having the ability to send an integer with a raycast would also allow for expanded use outside of LL Damage. It could allow a weapons system to differentiate between raycasts of different "caliber" or allow for raycasts to broadcast a "team" number, or to differentiate between raycasts being used as "projectiles" from those being used as "lasers" or in some other sensing capacity, or a million other situations where the ability to program an object with multiple responses to a raycast would dramatically expand its utility. An integer is also the simplest piece of information that could be added, and you'll need to add it anyways if you add LL Damage functionality.

::The UUID of the originating object would also be useful, as would the owner's UUID. While it may sound redundant, I wonder about situations where the owner of the originating object might not be in the region, I believe that llGetOwnerKey() may not work in those situations, right? So the owner UUID would be important. It might also be useful for llCastRay() to send a UUID of its own choosing, and here I'm thinking of how it is common in SL aviation for planes to be guest-flyable, so the owner of the object may not be the one using it. However, workarounds already exist for this with bullet-based combat systems, so maybe it's not essential. Of course, if it simply broadcast a UUID (or string) of the scriptor's choosing, that would allow whoever is scripting the object to decide whether to send the object UUID, the owner UUID, or the user's UUID, so it might be even better than automatically sending the object and owner UUIDs.

::Finally, it might be useful to include the vector position of the originating point of the raycast. Not where it hits you, but where it was sent from. Granted, if the object/owner/user UUID is included, then llGetObjectDetails() might be used to get this information, but for some instinctive reason that I can't quite figure out at the moment, I feel like this might be a useful thing to add. In the end, though, if you have to include one bit of information, make it all purpose integer that could be used to determine LL Damage or passed to an event. If at the end of the day you can only pass on one piece of info, an integer would give you the most utility with the least overhead.

::[[User:Jahar Aabye|Jahar Aabye]] 06:43, 7 July 2010 (UTC)

:::How about the shooter just sending the info about how the shot originated (also thigns like the gun used etc) via chat and then the potential target(s) calculate whether they were hit or not and adjust their owner health points as needed? (I just thought about that approach, haven't put much thought into it)
::: Btw, does everyone uses gravitiless bullets? I would expect people going for the more realistic stuff would use physical bullets that fly a ballistic trajectory... Can a ballistic arc be used instead of a straight line "ray" with raycasting? --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 06:56, 7 July 2010 (UTC)

::::Tigro, in real life, a 9mm round of typical self-defense ammunition has a muzzle velocity of 1120ft/s or 340m/s. As another commenter pointed out, a 5.56 NATO round (think M16) has a muzzle velocity of about 3000ft/s or 915m/s. Those two rounds would travel a sim diagonal (362m) in 1.06 and 0.4s, respectively. During that time period, if fired horizontally, they would fall about 5.5m and about 0.79m, respectively. Sounds like a lot, except that a pistol wouldn't have a range anywhere near that large in reality (you couldn't POSSIBLY aim a pistol accurately at a target nearly 4 football fields away, at least not by hand, and not without some kind of crazy scope...not to mention that wind would slow it down substantially over that distance) and for the M16, the drop is not significant given the 350m distance being traveled. So while no, you can't use a ballistic arc instead of a straight line, think about whether you really need to. And if you discover you really do, you could always approximate it with 4 line segments.
::::[[User:Falcon Linden|Falcon Linden]] 04:04, 8 July 2010 (UTC)

== Get Alt-Zoom camera cursor position and surface orientation ==

Here is an example I made, how to get the camera cursor position when you Alt-Zoom on any object surface with the '''llCastRay''' function.

The script also calculates the surface orientation at the cursor position and rezes a prim on a top of surface. The Z-Axis of a rezed prim is aligned with the Normal vector of a surface at a given point and the X-Axis points in a way of your camera sight.

To test the script make a new HUD object and put the script below into it. Also put one standard cube prim (named Object) into its inventory. Attach the HUD and Alt-Zoom to any curved surface in region, but not more than 10m far from you. Then click on the HUD and a new prim will be rezed on a top of surface where the Alt-Zoom cursor of your camera points.

<lsl>
//
// Scriptname: Get Alt-Zoom position and Surface Orentation
// Version: 1.0
// Date: 06.07.2010
//
// Description: Gets the position of the camera cursor
// when a user Alt-Zumes on a surface of any object and
// rezes a prim on this point and orients it with a surface
//
// How To: - Create a new HUD (cube), size = X=0.05 y=0.05 Z=0.05
// - Put this script on it and attach it as a HUD
// - Insert a standard prim (Cube 0.5m) into HUD inventory (named as Object)
// - Alt-Zoom with your mouse to any object surface in the region
// - Without moving your camera, click on this HUD
// - You will get the camera cursor position and surface orentation
// - An Object from HUD inventory will be rezed on a top of Alt-Zoomed surface
// perfectly aligned with surface and with X-axis pointed to your line of sight
//
// Tips: To see the camera cursor, enable: Advanced->Character->Show Look At in your Advaned Menu
// Rez a big sphere to make a curved surface in a region and Alt-Zoom on it.
//
// Notes: You must be at least 10m close to Alt-Zoom position (llRezObject() limitation)
// There's no "clamping code" included to cut the rays to be inside of a region
//
// Creator: Teleworm Gelber
//

default
{
state_entry()
{
if (llGetAttached() > 0)
{
llRequestPermissions(llGetOwner(), PERMISSION_TRACK_CAMERA);
}
else
{
llOwnerSay("Attach me as a HUD");
}
}

run_time_permissions(integer permissions)
{
llOwnerSay("Alt-Zoom on any curved surface in the region and then click me to get the Alt-Zoom cursor coordinates and an Object will be rezed there");
}

touch_start(integer total_number)
{
vector camPos; // camera position
rotation camRot; // camera rotation

vector rayEnd; // ray end vector

vector curPos; // Alt-Zoom cursor position
rotation curRot; // Point on a surface rotation (Z-axis = SurfaceNormal, X-axis = line of sight)

vector fwd; // surface Forward vector
vector left; // surface Left vector
vector normal; // surface Normal vector

list rayData; // ray cast return data

if ((llGetPermissions() & PERMISSION_TRACK_CAMERA) != 0)
{
// getting camera location
camPos = llGetCameraPos();
camRot = llGetCameraRot();

// Cast a ray in a line of your sight (10.0 means llRezObject() limitation)
rayEnd = camPos + 10.0 * llRot2Fwd(camRot);

rayData = llCastRay(camPos, rayEnd, 0, RC_GET_NORMAL);

if (llList2Integer(rayData, -1) > 0) // check status code
{
// get the Alt-Zoom cursor position and orentation
curPos = llList2Vector(rayData, 1);
normal = llList2Vector(rayData, 2);

// calculate axis for point oirentation
left = llVecNorm(normal % llRot2Fwd(camRot));
fwd = left % normal;

curRot = llAxes2Rot(fwd, left, normal);

llOwnerSay("Alt-Zoom Position: " + (string) curPos);
llOwnerSay("Point Rotation: " + (string) curRot);

// rez an Object on a top of hit surface, 0.25 means the prim center offset from surface (0.5m cube)
llRezObject("Object", curPos + <0.0, 0.0, 0.25> * curRot, ZERO_VECTOR, curRot, 0);
}
else
{
llOwnerSay("Nothing hit, try again");
}
}
else
{
llOwnerSay("Attach me as a HUD first");
}
}

on_rez(integer par)
{
llResetScript();
}
}</lsl>

--[[User:Teleworm Gelber|Teleworm Gelber]] 23:08, 6 July 2010 (UTC)

== Inaccurate (buggy) position and normal ==

I don't really have time for this, ... but I tried it out with a quick script (see below)
and my conclusion is that the place that is reported for the hit is very inaccurate at times.
It certainly isn't equal to the physical (collision) shape of objects, for example the place
another physical object would lay, or where you'd stand if you stood on top of a prim with
your avatar, and often it's just near random (actually, this is clearly a bug).

The script that I used in my objects is:

<lsl>
vector center;
float distance = 15.0;

rez_marker(vector pos, vector normal)
{
llRezObject("Marker", pos, ZERO_VECTOR, llRotBetween(<0,0,1>, normal), 0);
}

probe(vector direction)
{
//llSay(0, "direction = " + (string)direction);
vector start = center + llVecNorm(direction) * distance;
list results = llCastRay(start, center, RC_REJECT_AGENTS|RC_REJECT_PHYSICAL|RC_REJECT_LAND, RC_GET_NORMAL);
if (llList2Integer(results, -1) > 0)
{
//llSay(0, "llCastRay returned " + (string)results);
vector pos = llList2Vector(results, 1);
vector normal = llList2Vector(results, 2);
rez_marker(pos, normal);
}
else
{
llSay(0, "llCastRay FAILED!");
}
//rez_marker(start);
}

init()
{
}

default
{
state_entry()
{
init();
}

on_rez(integer param)
{
init();
}

touch_start(integer total_number)
{
if (llDetectedKey(0) != llGetOwner())
return;

center = llGetPos();
vector direction = <1,0,0>;
float alpha;
for (alpha = 0.0; alpha < 360.0; alpha += 10)
{
vector eul = <0, 0, alpha * DEG_TO_RAD>;
rotation quad = llEuler2Rot(eul);
probe(direction * quad);
}
}
}
</lsl>

Put it in an object together with an object named "Marker".
The Marker object should be a (red) sphere of size 0.1 x 0.1 x 0.01.

The script will rez the Marker object on the surface of the
object you put it in, with it's flat side outwards. If you test
this with a cube of 10x10x10 you'll understand what is the idea :p.

Next test it with a Cylinder of size 3.4 x 4 x 3.342
Taper X and Y both 1.00, Top Shear X = 0.30, and Y = 0.0
(the rest default)... and see the deviations.

Try many more funny shaped objects to see loads and loads of
bugs and inaccuracies.

--[[User:Aleric Inglewood|Aleric Inglewood]] 0:55, 7 July 2010 (UTC)

You know, part of me hopes you're right--and that there's nothing I can do about it. Shapes like you're describing are terrible for the physics engine (tons of triangles, some of the degenerate, etc.). That said, I'll take a look at the physics debugger we have and see what's going on tomorrow. I suspect that the physics representation just isn't quite what you think it is. We'll see. Either way, thanks for bringing it to my attention.

[[User:Falcon Linden|Falcon Linden]] 03:41, 7 July 2010 (UTC)

:As Teleworm points out below, the problem here is in your script, not in the llCastRay. You should check the hit list to find the hit with the UUID matching the scripted object's key and use that. You may still get more than one hit if you're near the edge of a triangle or if your shape is not convex, however.
:[[User:Falcon Linden|Falcon Linden]] 04:07, 8 July 2010 (UTC)

==Simple Raytracer==

[[File:Snapshot_2983.png|left|256px]]
I did this a few days ago, it's pretty nifty!

--[[User:Moy Loon|Moy Loon]]

Not just nifty, bloody awesome! Btw, notice the way the two thin cylinders show as boxes. We replace long, thin cylinders with boxes. Can you take a photo with an avatar? :)
[[User:Falcon Linden|Falcon Linden]] 04:09, 8 July 2010 (UTC)

[[File:Avmeshforms.png|256px]]

== Visualizing rays for debugging? ==

Would it be possible to have the server send to the client the exact position of the begin and end points of the ray (so the client can render the ray itself) to help with debugging? (like trying to figure out ray positioning for a complex shaped linkset that needs close rays) I imagine it would be somthing like, the client tells the server it wants the rays, then the server will send the info for all rays owned by the avatar, and the client will render them as beacon like lines that fade gradually (the fading time would be a debug setting), perhaps add a bit of animation tot he beam like those pulses for the "cheesy beacon" for TP targets and tracking people on the map, to indicate the direction of the ray. To cope with packet loss, each time the client receives ray data it will tell the server whether to continue or stop, or perhaps just keep sending the request every N seconds and if the server don't get a request for a few N seconds it stops sending the info to that client. --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 16:59, 7 July 2010 (UTC)

:I wish. Sorry, that's out of the scope of this project (which is intended to require a minimum amount of development time. So far, I think I've spent <10hrs coding it, and I'm trying to keep it under 20 total.
:[[User:Falcon Linden|Falcon Linden]] 04:20, 8 July 2010 (UTC)

You could also just rez an object to 'visualize' it, learn about llRotBetween, and how to split things up into 10m chunks! --moyloon

== Edge of sim returning usefull results ==

How about if when the ray hits the edge of the sim, position will be the intersection of the ray with the edge (since it can't go past it), and the UUID will be one constant if there is another sim on the other side of the edge, and another constant if it leads into the void? --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 20:02, 7 July 2010 (UTC)

Sorry, that's just a little too hacky and out of scope for this one. :) Would be interesting, though! Feel free to submit a jira for interrogating the region as to its neighboring sims. That might be a useful function.
[[User:Falcon Linden|Falcon Linden]] 04:11, 8 July 2010 (UTC)

== Phantom getting hit? ==

Could anyone confirm if phantom objects are really not being ignored please? --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 23:18, 7 July 2010 (UTC)

Yes, this is a bug that I will fix when I have time. Shouldn't be too hard.
[[User:Falcon Linden|Falcon Linden]] 04:11, 8 July 2010 (UTC)

: Even flexies are getting hit, but the the normals seem to be messed up (in my preliminary tests it seems the normals returned for flexies all point up regardless of where you hit them) --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 05:29, 8 July 2010 (UTC)
:: Flexies attached to phys linksets seem to be harder to hit (they also got a funky collision but just with the ground apparently, nothing but lucky rays and the ground seems to collide with them, i'm not 100% sure, but i think in H4 not even the ground touches physical flexies) --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 05:44, 8 July 2010 (UTC)

Not hugely surprising, if phantom is getting picked up. Flexies don't have a flexible physics rep, I think it's just a box or something. I'll have to look into it, but probably not before next week. Curious, though, what about trees? (Note that a tree's physics shape is a very narrow box, so you'd have to cast right in the middle of the tree.)

[[User:Falcon Linden|Falcon Linden]] 05:36, 8 July 2010 (UTC)

Haha, whoops. I looked at my code and it's a one line bug. I could fix it now, but it's not critical and it wouldn't get updated on Aditi for a few days anyway. But rest assured, it should be a quick and easy one. :)
[[User:Falcon Linden|Falcon Linden]] 05:49, 8 July 2010 (UTC)

:Would it be possible to add a checkbox or a setting that scripts can set to keep flexies colliding with the ground when desired? I've jsut made a random toy that it's kinda fun to watch that without flexies colliding with ground but nothing else wouldn't work quite the same (i'm asking for a somthign liek a checkbox/hidden switch because i can imagine that if this behavior isn't present in H4 some stuff might break if it's kept). No biggie if it has to be fixed though. --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 07:04, 8 July 2010 (UTC)

:::This reminds me of one existing (Agni) edge case that might be useful to clear up with this. Currently if an avatar sits on an object, and that object then sets VolumeDetect to TRUE, the physics engine sets the avatar to phantom, and it does not register any hits on the avatar, even to the point of rendering the avatar invulnerable with regards to LL Damage. I had not thought to test this with RayCasting, but I am wondering what the intended effect will be in terms of how rays will interact with these phantom avatars. For additional information, see [http://jira.secondlife.com/browse/SVC-1253 SVC-1253] which has sort of lingered in limbo, probably because there are more important things to fix. However, if the raycasting code is still being written, it'd be nice to prevent this sort of unintended behavior before it even begins.
:::[[User:Jahar Aabye|Jahar Aabye]] 03:27, 9 July 2010 (UTC)

:::The sitting-phantom glitch with llVolumeDetect already has some odd behaviors, if you enable physics on the linkset. When physical, the avatars behave something like tiny points of solid material, snagging on objects that the linkset passes through. It's very odd. I suppose I should bring some example code around and shoot rays at it, an' see what happens?
:::--[[User:Michelle Resistance|Michelle Resistance]] 16:19, 13 July 2010 (UTC)

== Some good news for llCastRay ==

I was playing with the script from Aleric Inglewood and tried to figure out what causes this strange inaccurate positions and normals. And I figured out that the main reason is the Marker size and shape and not the physic engine.

In the example of Cylinder of size 3.4 x 4 x 3.342, the ray hits a Marker which was previously rezed one step before and not the surface of the cylinder. That is the reason, why were Normals wrong oriented. I modify the script in such a way that I numbered all Markers with llSetText.

The second problem is inaccurate position. A marker is always placed about 3-5 cm '''above''' a surface, and not exactly on it on a flat surface. This can be seen on a cube object. On a sphere, this error is smaller. And in a shape of this deformed cylinder sometimes markers appears below surface and becomes invisible, but never more than 5cm.

To correct the Aleric experiment, just make a smaller marker. And when all markers are rezed, resize the cylinder to become little smaller to see all markers. If you zoom with your camera very close, you can see that all markers follow the orientation of polygones that define the object shape.

--[[User:Teleworm Gelber|Teleworm Gelber]] 23:40, 7 July 2010 (UTC)

Good catch. I came to the same conclusion about Aleric's script, but I cheated (I have a way of visualizing the raycasts and the whole physics scene :).

As for the inaccurate position, it's not inaccurate per se. It's just not what you expect. Most shapes in the physics engine (anything that isn't a perfect cylinder or perfect sphere, as I recall) has an additional radius of 5 or 10cm (I can never remember which). This is why if you stack physical boxes they'll have a gap between them. We use raycasts for sitting, but we specifically account for the radius in that code and in a few other places (like foot IK). There are a few other idiosyncracies around raycast results. For example, for most shape a ray parallel to its surface will not return a hit, nor will a ray terminating exactly at its surface or a ray originating inside the shape (unless it's a concave shape made of triangles, in which case the same holds true, but it's the individual triangle the ray begins inside that won't be hit).

[[User:Falcon Linden|Falcon Linden]] 04:18, 8 July 2010 (UTC)

== Can we have this on the maingrid pretty please? ==

I know this is experimental etc, but would it be possible to port the ray code to a sim version avaible on the maingrid and offer a sandbox sim with this hybrid version so we can play with ray with our main invs, live groups, chatting with friends inworld etc? --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 00:19, 8 July 2010 (UTC)

Sorry, no. We're not set up for doing that sort of thing. We can bring your agni inventory over to Aditi (contact Oskar), but you'll lose anything you currently have on Aditi.
[[User:Falcon Linden|Falcon Linden]] 04:21, 8 July 2010 (UTC)

:I know, the beta grid inventory is one way copy of the main grid inv, everything gets overwritten when it's refreshed; i would rather not have to keep exporting the stuff i make there when i want to keep them though. --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 07:09, 8 July 2010 (UTC)

== Just saying TY ==

TY ;-) Will be cool. Keep it up Falcon.

== just letting you know ==

I'll be out of town this week, won't be able to read the stuff here nor log in to test stuff, cya. --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 20:57, 10 July 2010 (UTC)

== Cast Ray vs. Ray Cast ==

The function name proposed is "llCastRay" but the constants start "RC" as in "Ray Cast". Would make sense to have them be consistent (as in "CR"). It's annoying keeping [[llMessageLinked]] and [[link_message]] straight. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 16:40, 15 July 2010 (UTC)

:I second that motion. I'm hoping this functionality is introduced and however it comes will be better than not coming at all but, while the opportunity exists to craft it to be as clean and user friendly as possible, that opportunity should be taken. Although this seems like a tiny issue (link_message vs llMessageLinked OR llSetLinkPrimitiveParamsFast *fingers gasp for breath* (although at least it wasn't llSetLinkPrimitiveParametersFast)) there is no good argument in favor of making function or event names insensible whereas there are good arguments in favor of them being simple and easy to write and remember. Now is the time to get that right. Still hugely in favor of the functionality though so if you MUST call it something complex and irritating, go right ahead ;-) -- '''[[User:Fred_Gandt|Fred Gandt]]''' <sup><small>([[User talk:Fred_Gandt|talk]]|[[Special:Contributions/Fred_Gandt|contribs]])</small></sup> 07:13, 17 July 2010 (UTC)

Hey guys,

The logic is that the method, llCastRay, is a verb phrase ("cast a ray"), whereas the parameters are noun/adjective phrases ("Ray Cast Reject Agents", "Ray Cast Reject Terrain"). Does that make sense to you?
[[User:Falcon Linden|Falcon Linden]] 06:39, 19 July 2010 (UTC)

::Hey Falcon :-)

:Grammatically correct it may be but, fiddly. Muscle memory etc. llCastRay(CR_summit_summit) just flows better. It's really only the _summit_summit that matters at the end of the day. If there were flags that were ''BOTH'' RC_ ''AND'' CR_ (depending on grammatical doobrywotsits) then cool; but, if there will only be ''EITHER'' CR_ ''OR'' RC_ I for one would prefer to go along with the CR_ simply so I don't need to think about my old English teachers in the middle of writing a statement. *not terribly concerned but, interested* -- '''[[User:Fred_Gandt|Fred Gandt]]''' <sup><small>([[User talk:Fred_Gandt|talk]]|[[Special:Contributions/Fred_Gandt|contribs]])</small></sup> 10:35, 19 July 2010 (UTC)

:: I like the gramaticly correct approach, saves time when reading a script, and once you get used to it it flows as smoothly as anything else. It somtimes brings a smile to my face when i realise what i'm writting makes sense even if i didn't understand what the words make happen under the hood. And the more consistent LSL is the better, it already goes the gramaticly correct route elsewhere, so it would be expected it would also do it here. --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 20:48, 19 July 2010 (UTC)

:::Tigro...An example of LSL being grammatically correct elsewhere would be, what? Perhaps the well known functions llGiveFolderOfInventoryListed or llSendMessageToLinkInSet?
::::Falcon (since I'm already here)...I was thinking that since the world at large (when thinking about ray-casting) thinks of Ray-Casting rather than Casting-Rays it would prolly be even simpler to name the function llRayCast. *shrugs* TBH, whatever the parts end up being called it's how they work that matters most. Awesome of you to be trying to get this out. Hear's (now) quietly hoping. -- '''[[User:Fred_Gandt|Fred Gandt]]''' <sup><small>([[User talk:Fred_Gandt|talk]]|[[Special:Contributions/Fred_Gandt|contribs]])</small></sup> 04:02, 20 July 2010 (UTC)
::::: llMessageLinked isn't gramaticly correct?

== ray_impact event vs. http ==

I've been thinking about the asserted need for a ray_impact event to determine if you've been hit by a raycast. Babbage suggested that instead of creating a new ray_impact event (which is trickier than any of us might like), the same goals could be accomplished using the existing HTTP url system. The idea was that you'd set up a system as follows for securely communicating the results of the ray cast:

1) Users wear a hit detection script that acquires an HTTP-in URL and stores it in its description.
2) For weapons builders, you provide a copy, no-mod (and thus unreadable) script (call it a "firing script") that has a link_message event that the weapon builders' scripts can use to talk to it. This script also contains a secret key known to the hit detection scripts.
3) The weapon script sends a link message to the firing script with the requested start/end position of the ray. The firing script (which is secure because it was written by the system creator) then casts a ray (if the start/end points are allowed based on game rules). If it detects a hit, it gets the target's hit detection url from the target's description and sends an HTTP POST with the details, including a secret code to verify authenticity.

What would prevent this from being a viable alternative to a ray_impact event? (Obviously, it generalizes to other uses equally well.)
If you think it will be too slow or have another fault, could you code up a simple, testable example?

Thanks!

:Something similar could be done using llRegionSay by sending the message on a frequently changing, random channel. The synchronization on channel would be performed by llRegionSay'ing a new random channel number periodically, with the number encrypted using a key shared by all interested/authorized scripts. This would seem a lot simpler/faster than the HTTP idea.

::I think a ray_impact would be a useful event, but by no means necessary. There's any number of ways to securely communicate script to script using chat, http, reading one another's descriptions, carrier pigeon, etc., with llSHA1String or llMD5String and a password providing authentication. If ray_impact is any trouble, drop the idea; don't let it stand in the way of getting us llCastRay. It would be simpler to update existing combat meters using a new event, I think, but I don't think that should be a barrier. [[User:Jack Abraham|Jack Abraham]] 07:23, 22 July 2010 (UTC)

== Change Reject constants to be inclusive ==
Many, if not all other, LL calls use constants OR'd together in a positive sense to change a scripts' behavior.
This is the only function where I have seen constants used to reduce what the function does.

I'd suggest changing the RC_REJECT constants by eliminating the _REJECT_ portion and also adding a new constant, something along the lines of RC_ALL.

A "normal" call would have the ALL constant unless you only wanted a subset of actions, in which case your OR together the constants you need.

What do people think? [[User:Jonathan Yap|Jonathan Yap]] 10:01am, 24 July 2010 (UTC)

:Although unusual (this is just my opinion) rejection rather than inclusion seems like a perfectly reasonable way around things. I wonder if it might be more efficient too. Analogy: Compact discs: When a CD has bonus tracks that are often disruptive when listening to an otherwise complete listening experience, it is typical to avoid being disturbed after the album is finished that we need to ''include'' all the album tracks in a programmed playlist before starting the playback. I have often wished that I could ''exclude'' the few bonus tracks instead. I would go so far as suggesting that bonus tracks should be (in what seems an illogical fashion) the first tracks indexed on the CD so that no playlist programming is required at all; We simply start playback at track 4 to avoid playing the 3 bonus tracks. So although unusual and unexpected, an alternative way might be more efficient and simpler to use.
::This however is not a compact disc so, my greatest concern is with how well it works and how efficient it is as code. If there is NO difference in efficiency at all between rejection and inclusion, for the sake of continuity I would certainly agree with [[User:Jonathan Yap|Jonathan]] insofar that the ''normal'' way to construct a function by ''inclusive'' constants would be preferable. -- '''[[User:Fred_Gandt|Fred Gandt]]''' <sup><small>([[User talk:Fred_Gandt|talk]]|[[Special:Contributions/Fred_Gandt|contribs]])</small></sup> 08:26, 25 July 2010 (UTC)

== Optimizing Simulations ==

Well, I got quite a few ideas that surround this issue, and I have tried to narrow it doesn't to a simple concept that describes a pattern how to use functionality, like llCastRay(), to optimization simulations. I blogged more details here: [http://icyspherical.blogspot.com/2010/07/optimizing-simulations-with-basic.html Icesphere Blog]. Let's not confuse this with a common ray-tracer. I want the client end to contact a prim on the simulator to demonstrate the basic pattern. The prim just needs to cast rays and send data back to the client. The client-side fills in the details. This first phase would only need to get a rough scene layout. Close objects probably can be gathered with a scanner and some further objects can be done with llCastRay() (can't cross sims yet, but someday maybe). Hopefully, use http client/server methods to communicate with detected objects.

Now with that basics above, scripts added into detected objects could further describe details of the scene through client/server methods. I've seen other LSL raytracers, that didn't use llCastRay(), that used scripts to store "material" data and thought... cool!

Posted some vulgar code here: [[User:Dzonatas_Sol/HttpCastRayLLSD]] [[User:Dzonatas Sol|Dzonatas Sol]] 05:52, 28 July 2010 (UTC)

== Possibility of a "Fast" trace ==

Hi Falcon.

ty ty ty ty ty ty :D (Now that I got that off my chest :p)

I've got a bit of a suggestion, is it possible to add a llCastRayFast which only determines if there is something within the filter that's in the way between point A and point B.

E.g. xyz avatar wants to go to sleep but a requirement to goto sleep in a hud is that the avatar is sheltered from the elements, the script does a trace looking to see if the avatar has a clear shot at the sky or not, if not the avatar is under cover.

I really hope the hands of god (LL) allow this to make it into the maingrid.

Look forward to catching you on the test grid :)

Cheers,
Lastro

edit: Also see my user page for some code I've done, which works how I would expect it to (appart from it detecting the target object)

Another idea would be the ability to do a ray trace between two object/agent/etc UUIDs. --[[User:Lastro Greenwood|Lastro Greenwood]] 00:54, 7 August 2010 (UTC)

User:Lastro Greenwood

2010-08-07T00:38:44Z

Lastro Greenwood:

User:Lastro Greenwood

2010-08-07T00:35:43Z

Lastro Greenwood: /* Scratch Pad */

User:Lastro Greenwood

2010-08-07T00:31:01Z

Lastro Greenwood: /* Lastro Greenwood's Page */

== Lastro Greenwood's Page ==
Hey everyone, I'm Lastro Greenwood.

I specialise in software development but can kinda build.

== Scratch Pad ==
<lsl>integer getnumobj(list traceres)
{
return (integer)llList2String(traceres,llGetListLength(traceres)-1);
}

integer isVisible(vector start, vector finish)
{
list res = llCastRay(start,finish,0,0);
integer numobj = getnumobj(res);

if(numobj == 0)
return TRUE;

return FALSE;
}

default
{
state_entry()
{

}

touch_start(integer total_number)
{
vector pos = llGetPos();
vector finalpos = llDetectedPos(0);
if(isVisible(pos,finalpos) == TRUE)
llOwnerSay("I can see clearly now!");
else
llOwnerSay("Something is in my way!");
}
}</lsl>

Talk:LlCastRay

2010-08-06T04:52:24Z

Lastro Greenwood: /* Possibility of a "Fast" trace */ new section

Mono

2010-06-26T02:06:39Z

Lastro Greenwood: /* How LSL scripts work */ corrected typo

{{Help |Glossary=*}}

{| align="right" style="text-align: center" width="375"
| <videoflash>cGoM9p7q1jk</videoflash>
|-
| '''[http://vidtuts.s3.amazonaws.com/Understanding-Mono.mp4 DOWNLOAD this video in high-quality!]''' and<br /> '''[[Mono_demos|watch more videos of Mono in action]]'''
|}

'''"Mono for Second Life" refers to a simulator upgrade which can dramatically speed the running of scripts — especially calculation intensive ones.''' The Linden Scripting Language ( [[LSL Portal | LSL]] ) has not changed in any way<span class="TablePager_nav">[[#FAQ-Differences|*]]</span>, so all of your existing scripted objects and attachments continue to function as before, only now they will have the opportunity to run faster. The key to this improvement is an open-sourced scripting engine called [http://www.mono-project.com/Main_Page Mono].

'''Mono is now live on the main grid with server version 1.24.3'''

<br/>
== How LSL scripts work ==

Linden Lab server programs, known as ''simulators'' or ''sims'', run all LSL scripts. When you teleport, or region cross, your new region's sim takes on the task of running all your scripted attachments. But a sim cannot understand LSL directly -- the language was designed for human readability, not machine. So before the script can be executed, it must be turned into a machine readable format. This process is called ''compilation'', and the resulting machine-readable version of the script is called ''bytecode''. LSL scripts are compiled when they are created by resident-programmers. The bytecode itself is stored on the Linden Lab asset servers and never needs to be referred to directly by residents. Instead, when you rez a scripted object, the simulator for the region you are in notes the script(s) in the object, and requests the appropriate bytecode from the asset database. The simulator program has several parts, and the part which runs the script bytecode is called the LSL scripting engine or virtual machine.

In today's Second Life, scripts are everywhere: from simple rotating objects to complicated vehicles, vendors, or attachments that respond to chat commands. For many regions the scripting engine is kept busy trying to execute hundreds of scripts all at once. As the number and complexity of scripts in a region rises, so do the demands upon the simulator. After a certain point the scripting engine starts taking up so much processing time that the rest of the simulator (particularly the physics engine) bogs down, resulting in server-side lag. Thus, anything that can speed up the execution of scripts can push out the point where server lag starts to occur.

=== Enter Mono ===
Mono is an open-source scripting engine with a proven record of speed and versatility. But switching engines requires a compiler that can turn LSL scripts into Mono bytecode. This is tricky, because the goal is to make scripts running under Mono behave exactly like scripts running under the original engine. This desire for backward compatibility required an extraordinary amount of testing.

== Mono on the main grid ==
Thanks to the efforts of the beta test residents, and the Linden development and QA teams, Mono was deployed to the main grid in [[Release_Notes/Second_Life_Server/1.24#Release_Notes_for_Second_Life_Server_1.24.3_.28August_29th.2C_2008.29:| server version 1.24]] on 29 August 2008.

The Mono Viewer changes were first available in the 1.21 client, and are now present in all [http://secondlife.com/corporate/tpv.php allowed] SL viewers. The viewer changes include a checkbox on the script edit dialog (which allows you to make a script compile to Mono), a Tools menu item to allow you to recompile to Mono all the scripts in your selection, and a change to simulator statistics to show events per second instead of instructions per second.

Another viewer dependency concerns the "Script perf" line in the statistics bar (ctrl-shft-1). In older viewers (1.20 and lower) this line will no longer contain useful data. In 1.21 and later viewers this line becomes "Script events" and gives the number of events handled per second.

Once Mono has been live on the main grid for several months Linden Lab may turn off compilation to the original scripting engine. At that point all new and edited scripts will be Mono. However, the servers will also maintain the original scripting engine to enable old scripts to run as before, but run as Mono as soon as they are edited.

== Mono benefits ==
Performance benchmark tests show that Mono is up to 220 times faster than LSL2. The benchmarks were math-intensive scripts typically used to evaluate performance. For ordinary scripts, the performance gains are much more humble.

Mono uses more memory than the typical LSL bytecode. It offsets this by introducing dynamic memory allocation. LSL2 allocates a full 16KB for all scripts, even simple "Hello, Avatar" ones. Mono allocates only the memory it needs. In tests on typical regions it turns out that the combination of Mono using more memory, but allocating memory better, is about a wash as far as overall memory footprint goes.

In some extreme cases Mono scripts can use up to four times the memory as LSL2 scripts. To maintain backwards compatibility, the script size limit has been increased from 16KB to 64KB.

'''Mono tip:'''
Mono can do bytecode sharing. Thus multiple copies of scripts with the same asset id will only take up as much room as one instance. Imagine some script that you use a dozen times on your land. If each of the objects containing the script is separately compiled from text source, you will use up a dozen times the script's size of memory. But if instead you simply drag a copy of the single, already compiled script into each of the dozen objects, then no matter how many copies exist they only take up the size of one script (plus data) in memory.

== How to use Mono ==

Mono is now fully deployed to the main grid with server 1.24.3. All allowed SL viewers have the interface to create Mono scripts.

* '''Log in to Second Life with a Release or Release Candidate viewer'''
* '''Create/edit a script and compile it to Mono'''
** Create an object and add a new script to it
** Edit the script from the object's contents tab.
** On the script editing dialog you will see a new checkbox at the bottom "Mono". Check it.
** Hit Save to recompile this script to Mono.
** You may now treat this script like any other. It will automatically run in the Mono runtime, regardless of ownership transfers or viewer version.
** To convert a Mono script back to ordinary LSL2, uncheck the checkbox.
* '''To convert a number of scripted objects all to Mono at once'''
** Rez all the scripted objects
** Use the select tool to select them all.
** From the Tools menu select Recompile Selection / Mono.

After you have converted a scripted object to Mono you will need to do a full QA run. Though Mono is compatible with old LSL2, there are timing differences which may cause object behavioral changes. Test your objects thoroughly before releasing Mono versions.

'''To report Mono issues, use JIRA'''
* Public JIRA [https://jira.secondlife.com/secure/CreateIssue!default.jspa create issue]
* If an issue already exists, and it appears to be the same failure, then simply add your information as a comment and attachment to that issue.
* If not, open a new SVC ticket for each bug you find. In the ticket summary please use the word "Mono" so that we can filter for them.
* In addition to your description of the problem please attach your script itself, or (ideally) a smaller script which illustrates the difference in behavior between the two scripting engines.
* Link your JIRA to the meta JIRA.

== Testing ==
During the integration of Mono we have used tests to ensure there are no regressions. For the current version of the regression test see [[LSL Language Test]]. This effectively serves as the specification of LSL.

There are tests for library call bindings in [[LSL Library Call Test 1]] and [[LSL Library Call Test 2]]. This is split to overcome the memory limitations.

[[Event test script]]

There are several benchmarks to test the performance. They are available here:
*[[LSL Recursion Benchmark]]
*[[LSL Mandelbrot Benchmark]]
*[[LSL Partial Sums Benchmark]]
*[[LSL NSieve Benchmark]]
*[[LSL NSieve Bits Benchmark]]

== FAQs ==
Section for questions.
; Can you give a few examples scripts where Mono's speed increase is readily apparent? : These calculation intensive scripts run considerably faster under Mono: [[LSL_Recursion_Benchmark]], [[LSL_Mandelbrot_Benchmark]], [[LSL_Partial_Sums_Benchmark]],[[LSL_NSieve_Benchmark]], [[LSL_NSieve_Bits_Benchmark]].
; As far as previously purchased LSL scripts, why do I have to wait for the scripter to convert the script to run on Mono, why can’t I just do this myself? : The increase in speed provided by Mono can cause problems with objects using communication between multiple scripts and there are a few cases where we have had to make Mono behave slightly differently to LSL. It's much safer to have the original scripter convert and '''test''' the scripts.
; Will scripts compiled to Mono work on an older version of the viewer? : Yes. You only need a viewer version 1.21 or later if you want to make Mono scripts. You can run Mono scripts from any viewer since Mono actually runs on the server.
; Is there an indicator of some kind to tell me that a script is running on Mono? How can I tell? : No. It's very difficult to work out whether objects and all the objects they contain use Mono scripts, so we haven't attempted to display it.
; Given that OpenSim runs on Mono, will LL implementing Mono expedite interoperability between the two worlds? : We are talking to OpenSim developers about script interoperability based on Mono.
; Has the available memory for scripts changed? (Currently 16k in LSL2 VM) : For the same LSL script the Mono bytecode and original (LSL2) bytecode will be of different size. In order to be compatible with all known scripts, we have expanded the size ceiling for Mono to be 64k. This is ok to do for Mono because unlike LSL2, Mono allocates memory dynamically, whereas all LSL2 scripts occupy 16K. Mono scripts only allocate the memory that they need.
; 64K? Wow, isn't that going to encourage inefficient scripting? : We hope that the change will promote more efficient scripting. Currently programmers have to get around the 16K limit by using multiple scripts, and a lot of cycles get spent on passing data between those scripts. With a single script that would not be necessary.
; Are there other ways to make my scripts even more memory efficient when using Mono? ; : Indeed, Mono can do what's called bytecode sharing. Suppose you have a region which uses many instances of the same script, like XYText or Puppeteer, for example. As long as all the instances share the same asset id, the bytecode will only be added to memory once, and shared by all the copies. Key to making this work is ensuring that you simply copy the scripts (or the objects the scripts are within) after they have been saved for the final time. If you have purchased a script that is used many times, ask the creator for a Mono version, and then copy that version into the objects. It's important that you copy the scripts, so that the asset id is the same. If you recompile each instance separately, they will get different asset ids and the engine won't be able to share the bytecode.
; Will I have to manually convert all my objects to using Mono, or is there an automated tool? : Yes, you must manually invoke compilation to Mono. Though you can make use of the Tools Menu to recompile all scripts in selection to Mono.
; Can I keep my scripts running on the original scripting engine forever? : We have no plans to eliminate the original engine. This will be re-examined after Mono has been live on the Main Grid for a while. But right now it is easier to continue to support the original scripting engine than to migrate all scripts.
; Will I be able to write scripts in languages besides LSL since Mono supports lots of languages? : Eventually. Right now our goal is to make Mono completely compatible with the original scripting engine for LSL scripts.
; Will LSL be getting real language features with this change? (ie arrays, references/pointers, includes/imports)
: No. The LSL language is not changing with this update.
; In the original scripting engine scripts are compiled on the viewer then uploaded, will that change with Mono? : Yes, Mono compilation is done in a distributed fashion on the sim hosts.
; Related to the above, I use a "clever trick" to upload my compiled bytecode in LSL2 with out the correct script text. What will happen to scripts I uploaded in this way when converted to Mono? Will I be able to continue to use my "clever trick" for Mono scripts? : The Mono compiler looks only at the script text. The Mono engine will only run bytecode which has been compiled by our Mono compiler. You will not be able to run any uploaded Mono bytecode.
; What about ''bytecode'' scripts whose ''LSL code'' has been lost, ie scripts that still run, but result in "Script missing from database." when you try to edit them? Is there any possibility of bytecode translation, or are these scripts stuck in the original scripting engine forever?
: There are currently no plans to allow byte code translation of LSL scripts, only compiling from source. This may be considered depending on Resident demand.
; <span id="FAQ-Differences"></span>What are the known differences between the LSL2 and Mono compilers and runtimes?
: We have not tried to make Mono 100% compatible with the original engine. At least not to the point of duplicating any of the tricks or hacks that LSL2 allowed. Below are listed some known behavioral differences. Add to the list as more are discovered.
:* Unicode support. From Strife Onizuka "In LSO LSL, the entire Unicode range was supported by complying to RFC 2279 (about 2 billion possible characters). Mono supports RFC 3629 which supplants RFC 2279 and limits the Unicode range to the first 1,114,112 character codes. This directly effects these functions: [[llBase64ToString]], [[llUnescapeURL]]. Strings being passed from LSO scripts to Mono scripts will become corrupted (in a reliable way) if they contain characters outside the limited Unicode range." -- {{Jira|SVC-1960}}
:* Dividing by zero - LSL2 errors on divide by zero, Mono uses value "Infinity" and does not error. ''Under server 1.30, this is an error under both environments, watch {{Jira|SVC-4805}} for updates.''
; <span id="FAQ-Recompile"></span>After Mono launches why not recompile *all* scripts everywhere on the Grid to Mono?
: While it is certainly appealing to have only one compiler and runtime to support, practical concerns make this not feasible. Here's a list of the difficulties that give us pause:
:* We do not have the text asset (the LSL code) for all running scripts. These "bytecode only" scripts would stop working.
:* The automatic recompile would restart all scripts. Many scripts are meant to run continuously without restarting.
:* Mono scripts have a different timing profile than the original (usually faster). This will introduce behavior differences which will lead to some scripts breaking, often in subtle ways.
:* Some scripts take advantage of undocumented "features" of LSL2. We did not strive for 100% compatibility in such situations, but rather made Mono behave as sensibly and predictably as possible.
:* As a result of both reasons above, scripts need QA work after they have been recompiled. Residents who code and sell LSL scripts will have to test and possibly adjust the behavior of Mono versions of their scripts. If conversion were automatic they would not be reimbursed for their QA effort. With manual recompilation the Resident scripters can sell Mono versions of their scripts as an upgrade, after they have tested and modified them.
:* Recompiling all scripts would play rather heavy-handedly with the permissions system. If someone has made and sold a script as "no-modify", an automatic recompilation would violate their policy. While some scripters would be ok with this, many would not.
; Is Mono still available on the preview grid? : Yes, see [[Mono/Beta FAQ]].

== Mono Memory Myths ==
'''NOTE:''' The following has been commented on since by the OpenSim wiki - Miguel was testing an idle region without any background activity or users. It is not a representitive test. See more at [http://opensimulator.org/wiki/Mono]

Experience with Mono in Opensim has led to the widespread belief that Mono on Linux is an extreme memory hog compared to .NET on MS Windows. This belief has been countered by the creator of Mono, [http://en.wikipedia.org/wiki/Miguel_de_Icaza Miguel de Icaza], after he performed direct tests on 14th June 2009 in Vista 32, Linux 32, and Linux 64. His results and advice were posted on [http://pastebin.ca/1460383 pastebin], and are repeated here since that site is not intended for persistent publication:

A third follow up.

With the help from the guys on #opensim on irc.freenode.org I got myself a sample virtual world from:

http://opensimworlds.com/index.php?part=worlds

I used "Nu Athens" a free download and loaded it up on 3 configurations:

Vista, running 32 bit OpenSim
Linux, running 64 bit OpenSim
Linux, running 32 bit OpenSim

And then I loaded all the four files provided in the zip file using the command:

load oar FILE.tar.gz

The results are as follows:

Vista/32: 115 megs + 5 meg helper process (OpenSim.vhost.exe)

Mono/32: 92 megs, after a few minutes of inactivity, it goes down to 87 megs.

Mono/64: 122 megs, after a few minutes of inactivity, it goes down to 89 megs.

The garbage collector is responsible for the difference in memory usage between the load finished
and waiting (I ran into this problem because I came to measure again after a few seconds and the
size had been reduced).

The Vista system remains at 120 megs total for the same world.

So Mono on Linux on both 32 and 64 bit configurations is consuming less memory than Vista, some
40 megs out of 120, or one third less memory.

Perhaps the difference is in the version of Mono that we are running. I am running with Mono 2.4,
and the OpenSim documentation implies that OpenSim can work with systems like Mono 1.2.6 which is
primitive by our standards (that was released more than two years ago).

In Mono 2.0, Mono 2.2 and Mono 2.4 we introduced many memory reduction features. From using
precise collection for the HEAP, to reducing the size of generics-heavy code to reduction in code
size generated and runtime metadata tables.

I would appreciate if you could post a correction to your data in the main article, as it seems to
have spread and this could negatively impact the perception of the Mono's community work towards
making a great .NET implementation for Unix.

Miguel

* PS. Miguel is measuring RSS (not VSIZE), for reasons explained [http://opensimulator.org/wiki/Talk:Mono in an earlier post].

[[Category:Features]]
[[Category:Performance]]

User:Lastro Greenwood

2010-06-22T10:25:58Z

Lastro Greenwood: Created page with '== Lastro Greenwood's Page == Hey everyone, I'm Lastro Greenwood. I specialise in software development but can kinda build.'

== Lastro Greenwood's Page ==
Hey everyone, I'm Lastro Greenwood.

I specialise in software development but can kinda build.

LSL Protocol

2010-06-22T10:24:16Z

Lastro Greenwood: /* Known chat channels */

{{LSL Header|ml=*}}
==Script protocols and known chat channels==

<div id="box">
<div style="padding: 0.5em 0.5em 1.5em">
Some times, scripts in Second Life send messages to one another to exchange information or coordinate behavior. The rules for that conversation are a ''protocol''. Being able to say "/1show" or "/1hug lee" are examples.

Such protocols use a common [[chat channel]]. The examples above use channel 1. They could just as easily have used any other number, but a user (and other objects) have to have some way to find the correct number.

Some protocols, such as combat systems, are quite complicated and could be better documented. This page can be used to help prevent conflicts and allow multiple programmers to coordinate the protocol definitions.

Protocols can also be note card systems and systems that use object names.
</div>
</div>

<div id="box">

== Protocol list ==
<div style="padding: 0.5em">
Add a protocol here if it is widely used, or might be sometime in the future.

A protocol in this list should also have its own pages where the protocol is defined in some detail.
</div>

{| {{Prettytable}}
|-
|{{Hl2}}| '''Name'''
|{{Hl2}}| '''Creator'''
|{{Hl2}}| '''Description'''
|-
|| [[LSL Protocol/Cool_Hud_Protocol|Cool Hud]]
|| {{User|Henri Beauchamp}}
|| Universal Hud protocol.
|-
|| [[LSL Protocol/ListMessage|ListMessage]]
|| Anonymous
|| Send and receive lists, non-lists, non-results, verb-not-found, and partially evaluated Polish expressions.
|-
|| [[LSL Protocol/LockMeister System|LockMeister System]]
|| Kyrah Abattoir
|| Used to coordinate different parts of bondage toys.
|-
|| [[LSL Protocol/EasyTalk]]
|| Salahzar Stenvaag
|| |Very Easy and simple communication protocol. Use it to simply coordinate llSay/llRegionSay/llListen objects, as well as linked set
|-
|| [[LSL Protocol/RestrainedLoveAPI|RestrainedLove viewer API]]
|| Marine Kelley
|| Use the features of the RestrainedLove viewer through llOwnerSay() calls.
|-
|| [[LSL Protocol/Restrained Love Relay Specs|RestrainedLove viewer relay spec]]
|| Marine Kelley
|| Allow your furniture or cages to issue commands to the user's RestrainedLove viewer
|-
|| [[LSL Protocol/Restrained Life Open Relay Group|RestrainedLove viewer open relay spec]]
|| Open Relay Group
|| A superset of the RestrainedLife viewer relay spec with useful extensions created and maintained by the community.
|-
|| [[LSL Protocol/P Vendor Linked Messages API & Environment|P Vendor Linked Messages API & Environment]]
|| Zep Palen
|| Allows an owner of the P Vendor system to develope custom vendors and use the API for input/output
|-
|| [[User:Nexii_Malthus/Script_API|Script API]]
|| Nexii Malthus
|| A protocol to provide a useful communication layer between LSL scripts and supported clients, as well as a useful and purposeful feature set. (Vertical Life and Plywood clients currently)
|-
|| [[LSL Protocol/Ganymedia OpenMAIP v1.0 Specification|OpenMAIP]]
|| Ganymede Ceriaptrix
|| ''Note: Specification is presently incomplete.'' Ganymedia OpenMAIP (Metaverse Application Internetworking Protocol) provides a TCP/IP-like routing and service-oriented message exchange protocol across multiple transport methods (including cross-simulator and cross-grid); allowing scripts to advertise their available functions, and relevant commands, to external and/or third-party scripts and viewers. Controlled access to closed functions is provided via RC4 challenge-response authentication. OpenMAIP also provides an optional RC4 cryptography layer, further extensible to public-private key DHSS.
|}
----

==Known chat channels==
This list is intended to reduce the number of scripts using the same chat channel number.
Please try and keep them in sequence.
{| {{Prettytable}}
|-
|{{Hl2}}| '''Channel'''
|{{Hl2}}| '''Creator'''
|{{Hl2}}| '''Description'''
|{{Hl2}}| '''Messages'''
|-
|| 1, 4, 5, 9
|| Unknown
|| Very common in poseballs
|| "hide", "show"
|-
|| 4
|| {{User|Mo Noel}}
|| Default channel for chat redirection like in gags or other voice manipulating tools
|-
|| 5
|| Psistorm Ikura
|| PsiCorp Products
|-
|| 6
|| grumble Loudon
|| pre-appended text and say it.
|| "/6 hello" becomes "/me Lion says: hello"
|-
|| 8
|| {{User|Henri Beauchamp}}
|| Cool Collar command channel
|-
|| 9
|| DCS And Most Modern SLRPG Frame Works
|| Command channel for user commands for Combat Systems/ SLRPG Frameworks like DCS
|| /9on /9 reset /9<power> etc
|-
|| 10
|| [[ACE BnT]]/[[IntLibber Brautigan]]
|| Ancapistan Capital Exchange ATM user interface channel
|| "balance","withdraw","help"
|-
|| 11
|| {{User|Mo Noel}}
|| Default channel of chat command interface of MoDesign products
|-
|| 12
|| Unknown
|| title and status of damage meter (combat system)
|-
|| 20
|| Unknown
|| SafeZone interface (combat system)
|-
|| 22
|| {{User|Henri Beauchamp}}
|| Cool Cuffs command channel
|-
|| 22
|| {{User|unknown}}
|| OOC Textiness. Says what you type.
|-
|| 22
|| {{User|Corvan Nansen}}
|| Chat Enhancer. Out Of Character speech.
|-
|| 33
|| {{User|Henri Beauchamp}}
|| Cool Nipples command channel
|-
|| 33
|| unknown
|| Collar
|-
|| 35
|| {{User|Corvan Nansen}}
|| Chat Enhancer Command channel.
|-
|| 36
|| {{User|Corvan Nansen}}
|| Ultimate Titler Command channel.
|-
|| 42
|| unknown
|| Common channel used by wiki example scripts
|-
|| 42, 55, 66, 77
|| Psistorm Ikura
|| Aventity avatar scripts
|-
|| 44
|| {{User|Corvan Nansen}}
|| Chat Enhancer. In Character speech.
|-
|| 45, 54
|| Ilobmirt Tenk
|| FOSSL Vending System Client/Server default command channel
|-
|| 55
|| {{User|Henri Beauchamp}}
|| Cool Chastity Belt command channel
|-
|| 63
|| {{User|FlipperPA Peregrine}}
|| FlipTitle and "Flip mod" Franimation commands
|-
|| 66
|| Travis Lambert
|| BanLink default chat command channel
|-
|| 66
|| {{User|Henri Beauchamp}}
|| Cool Diaper command channel
|-
|| 66
|| {{User|Corvan Nansen}}
|| Chat Enhancer. In Character emotes.
|-
|| 69
|| {{User|Henri Beauchamp}}
|| Cool Penis & Cool Pussy command channel
|-
|| 77
|| {{User|Marine Kelley}}
|| Real Restraints and similar BDSM equipment
|-
|| 77
|| Xarrk Dagger
|| KAIIA Systems devices default chat command channel
|-
|| 88
|| Cadroe Murphy
|| Used by ShapeGen and other building tools
|-
|| 88
|| {{User|Corvan Nansen}}
|| Chat Enhancer. Narration channel.
|-
|| 88
|| {{User|Sharie Criss}}
|| Owners plugin for Marine Kelley's Real Restraint equipment. Chat command channel.
|-
|| 99
|| unknown
|| Dance Bracelets
|-
|| 100
|| {{User|Mo Noel}}
|| Channel used to ask the user for chat line entries from within usual dialog sessions
|-
|| 100-999 (Randomly chosen periodically)
|| {{User|Corvan Nansen}}
|| Ultimate Titler. Title setting channel.
|-
|| -666
|| {{User|Dimentox Travanti}}
|| [[DCS]]: Unit to Hud Status Update Channel
|-
|| 777
|| Hank Ramos
|| [[Universal Translator]]: channel to allow users to open a dialog-box using a chat command on channel #777. Only accepted command on this channel is "translator" and all other chat is ignored. Allows user to silently bring up dialog by hiding command as "/777 translator".
|-
|| 888
|| Xarrk Dagger
|| KAIIA Systems device identification channel
|-
|| 2776
|| Tdub Dowler, Riden Blaisdale
|| Used for transmitting a csv list of keys for use in sim wide radars
|-
|| 4123 - 4130
|| {{User|Lastro Greenwood}}
|| Used by the Life Support System
|-
|| 9001, 908070
|| Mystical Cookie
|| MystiTool gesture commands, patch installers
|-
||10748, -10748
|| Lee Ponzu
|| Commonly used in scripts by Ponzu
|-
|| 31984
|| {{User|Coraa Prior}}
|| ACME interface (combat system)
|-
||-8888
||{{User|Kyrah Abattoir}}
||LockMeister communications channel
|-
||-9119
||Lillani Lowell
||LockGuard communications channel
|-
||-426956
||{{User|Ganymede Ceriaptrix}}
|| Ganymedia Open Metaverse Application Internetworking Protocol (OpenMAIP): Broadcast Communications Channel (<code>MAIP_BROADCAST</code>). Used for public OpenMAIP service discovery queries. Region-wide. See the [[LSL Protocol/Ganymedia OpenMAIP v1.0 Specification|Ganymedia OpenMAIP v1.0 Specification]] for further information.
|-
||-504xxx
||Gal Canning
||only whispered inter-prim communication
|-
||-888888
||{{User|Henri Beauchamp}}
||Cool Hud communications channel
|-
||-2766532
||Hank Ramos
||[[Universal Translator]]: "back-channel" for inter-translator communications. This is an encrypted channel that passes translation and command-control messages between translators that are linked together to spread the translation load and HTTP communications.
|-
||-23000xxxx
||Cyphr Bellic
||Default BelliCorp public safety communications. Typically encrypted. UsesRegionSay. User may change some channels, however some are hardcoded.
|-
||-1812221819
||{{User|Marine Kelley}}
||RestrainedLife relay communications channel
|-
||-828983023
||{{User|Very Keynes}}
||VK-NET Public Channel for Inter Network Communication and Local Network Address Acquisition.
|-
|}

LSL Protocol

2010-06-22T10:23:27Z

Lastro Greenwood: /* Known chat channels */

{{LSL Header|ml=*}}
==Script protocols and known chat channels==

<div id="box">
<div style="padding: 0.5em 0.5em 1.5em">
Some times, scripts in Second Life send messages to one another to exchange information or coordinate behavior. The rules for that conversation are a ''protocol''. Being able to say "/1show" or "/1hug lee" are examples.

Such protocols use a common [[chat channel]]. The examples above use channel 1. They could just as easily have used any other number, but a user (and other objects) have to have some way to find the correct number.

Some protocols, such as combat systems, are quite complicated and could be better documented. This page can be used to help prevent conflicts and allow multiple programmers to coordinate the protocol definitions.

Protocols can also be note card systems and systems that use object names.
</div>
</div>

<div id="box">

== Protocol list ==
<div style="padding: 0.5em">
Add a protocol here if it is widely used, or might be sometime in the future.

A protocol in this list should also have its own pages where the protocol is defined in some detail.
</div>

{| {{Prettytable}}
|-
|{{Hl2}}| '''Name'''
|{{Hl2}}| '''Creator'''
|{{Hl2}}| '''Description'''
|-
|| [[LSL Protocol/Cool_Hud_Protocol|Cool Hud]]
|| {{User|Henri Beauchamp}}
|| Universal Hud protocol.
|-
|| [[LSL Protocol/ListMessage|ListMessage]]
|| Anonymous
|| Send and receive lists, non-lists, non-results, verb-not-found, and partially evaluated Polish expressions.
|-
|| [[LSL Protocol/LockMeister System|LockMeister System]]
|| Kyrah Abattoir
|| Used to coordinate different parts of bondage toys.
|-
|| [[LSL Protocol/EasyTalk]]
|| Salahzar Stenvaag
|| |Very Easy and simple communication protocol. Use it to simply coordinate llSay/llRegionSay/llListen objects, as well as linked set
|-
|| [[LSL Protocol/RestrainedLoveAPI|RestrainedLove viewer API]]
|| Marine Kelley
|| Use the features of the RestrainedLove viewer through llOwnerSay() calls.
|-
|| [[LSL Protocol/Restrained Love Relay Specs|RestrainedLove viewer relay spec]]
|| Marine Kelley
|| Allow your furniture or cages to issue commands to the user's RestrainedLove viewer
|-
|| [[LSL Protocol/Restrained Life Open Relay Group|RestrainedLove viewer open relay spec]]
|| Open Relay Group
|| A superset of the RestrainedLife viewer relay spec with useful extensions created and maintained by the community.
|-
|| [[LSL Protocol/P Vendor Linked Messages API & Environment|P Vendor Linked Messages API & Environment]]
|| Zep Palen
|| Allows an owner of the P Vendor system to develope custom vendors and use the API for input/output
|-
|| [[User:Nexii_Malthus/Script_API|Script API]]
|| Nexii Malthus
|| A protocol to provide a useful communication layer between LSL scripts and supported clients, as well as a useful and purposeful feature set. (Vertical Life and Plywood clients currently)
|-
|| [[LSL Protocol/Ganymedia OpenMAIP v1.0 Specification|OpenMAIP]]
|| Ganymede Ceriaptrix
|| ''Note: Specification is presently incomplete.'' Ganymedia OpenMAIP (Metaverse Application Internetworking Protocol) provides a TCP/IP-like routing and service-oriented message exchange protocol across multiple transport methods (including cross-simulator and cross-grid); allowing scripts to advertise their available functions, and relevant commands, to external and/or third-party scripts and viewers. Controlled access to closed functions is provided via RC4 challenge-response authentication. OpenMAIP also provides an optional RC4 cryptography layer, further extensible to public-private key DHSS.
|}
----

==Known chat channels==
This list is intended to reduce the number of scripts using the same chat channel number.
Please try and keep them in sequence.
{| {{Prettytable}}
|-
|{{Hl2}}| '''Channel'''
|{{Hl2}}| '''Creator'''
|{{Hl2}}| '''Description'''
|{{Hl2}}| '''Messages'''
|-
|| 1, 4, 5, 9
|| Unknown
|| Very common in poseballs
|| "hide", "show"
|-
|| 4
|| {{User|Mo Noel}}
|| Default channel for chat redirection like in gags or other voice manipulating tools
|-
|| 5
|| Psistorm Ikura
|| PsiCorp Products
|-
|| 6
|| grumble Loudon
|| pre-appended text and say it.
|| "/6 hello" becomes "/me Lion says: hello"
|-
|| 8
|| {{User|Henri Beauchamp}}
|| Cool Collar command channel
|-
|| 9
|| DCS And Most Modern SLRPG Frame Works
|| Command channel for user commands for Combat Systems/ SLRPG Frameworks like DCS
|| /9on /9 reset /9<power> etc
|-
|| 10
|| [[ACE BnT]]/[[IntLibber Brautigan]]
|| Ancapistan Capital Exchange ATM user interface channel
|| "balance","withdraw","help"
|-
|| 11
|| {{User|Mo Noel}}
|| Default channel of chat command interface of MoDesign products
|-
|| 12
|| Unknown
|| title and status of damage meter (combat system)
|-
|| 20
|| Unknown
|| SafeZone interface (combat system)
|-
|| 22
|| {{User|Henri Beauchamp}}
|| Cool Cuffs command channel
|-
|| 22
|| {{User|unknown}}
|| OOC Textiness. Says what you type.
|-
|| 22
|| {{User|Corvan Nansen}}
|| Chat Enhancer. Out Of Character speech.
|-
|| 33
|| {{User|Henri Beauchamp}}
|| Cool Nipples command channel
|-
|| 33
|| unknown
|| Collar
|-
|| 35
|| {{User|Corvan Nansen}}
|| Chat Enhancer Command channel.
|-
|| 36
|| {{User|Corvan Nansen}}
|| Ultimate Titler Command channel.
|-
|| 42
|| unknown
|| Common channel used by wiki example scripts
|-
|| 42, 55, 66, 77
|| Psistorm Ikura
|| Aventity avatar scripts
|-
|| 44
|| {{User|Corvan Nansen}}
|| Chat Enhancer. In Character speech.
|-
|| 45, 54
|| Ilobmirt Tenk
|| FOSSL Vending System Client/Server default command channel
|-
|| 55
|| {{User|Henri Beauchamp}}
|| Cool Chastity Belt command channel
|-
|| 63
|| {{User|FlipperPA Peregrine}}
|| FlipTitle and "Flip mod" Franimation commands
|-
|| 66
|| Travis Lambert
|| BanLink default chat command channel
|-
|| 66
|| {{User|Henri Beauchamp}}
|| Cool Diaper command channel
|-
|| 66
|| {{User|Corvan Nansen}}
|| Chat Enhancer. In Character emotes.
|-
|| 69
|| {{User|Henri Beauchamp}}
|| Cool Penis & Cool Pussy command channel
|-
|| 77
|| {{User|Marine Kelley}}
|| Real Restraints and similar BDSM equipment
|-
|| 77
|| Xarrk Dagger
|| KAIIA Systems devices default chat command channel
|-
|| 88
|| Cadroe Murphy
|| Used by ShapeGen and other building tools
|-
|| 88
|| {{User|Corvan Nansen}}
|| Chat Enhancer. Narration channel.
|-
|| 88
|| {{User|Sharie Criss}}
|| Owners plugin for Marine Kelley's Real Restraint equipment. Chat command channel.
|-
|| 99
|| unknown
|| Dance Bracelets
|-
|| 100
|| {{User|Mo Noel}}
|| Channel used to ask the user for chat line entries from within usual dialog sessions
|-
|| 100-999 (Randomly chosen periodically)
|| {{User|Corvan Nansen}}
|| Ultimate Titler. Title setting channel.
|-
|| -666
|| {{User|Dimentox Travanti}}
|| [[DCS]]: Unit to Hud Status Update Channel
|-
|| 777
|| Hank Ramos
|| [[Universal Translator]]: channel to allow users to open a dialog-box using a chat command on channel #777. Only accepted command on this channel is "translator" and all other chat is ignored. Allows user to silently bring up dialog by hiding command as "/777 translator".
|-
|| 888
|| Xarrk Dagger
|| KAIIA Systems device identification channel
|-
|| 2776
|| Tdub Dowler, Riden Blaisdale
|| Used for transmitting a csv list of keys for use in sim wide radars
|-
|| 4123 - 4130
|| Lastro Greenwood
|| Used by the Life Support System
|-
|| 9001, 908070
|| Mystical Cookie
|| MystiTool gesture commands, patch installers
|-
||10748, -10748
|| Lee Ponzu
|| Commonly used in scripts by Ponzu
|-
|| 31984
|| {{User|Coraa Prior}}
|| ACME interface (combat system)
|-
||-8888
||{{User|Kyrah Abattoir}}
||LockMeister communications channel
|-
||-9119
||Lillani Lowell
||LockGuard communications channel
|-
||-426956
||{{User|Ganymede Ceriaptrix}}
|| Ganymedia Open Metaverse Application Internetworking Protocol (OpenMAIP): Broadcast Communications Channel (<code>MAIP_BROADCAST</code>). Used for public OpenMAIP service discovery queries. Region-wide. See the [[LSL Protocol/Ganymedia OpenMAIP v1.0 Specification|Ganymedia OpenMAIP v1.0 Specification]] for further information.
|-
||-504xxx
||Gal Canning
||only whispered inter-prim communication
|-
||-888888
||{{User|Henri Beauchamp}}
||Cool Hud communications channel
|-
||-2766532
||Hank Ramos
||[[Universal Translator]]: "back-channel" for inter-translator communications. This is an encrypted channel that passes translation and command-control messages between translators that are linked together to spread the translation load and HTTP communications.
|-
||-23000xxxx
||Cyphr Bellic
||Default BelliCorp public safety communications. Typically encrypted. UsesRegionSay. User may change some channels, however some are hardcoded.
|-
||-1812221819
||{{User|Marine Kelley}}
||RestrainedLife relay communications channel
|-
||-828983023
||{{User|Very Keynes}}
||VK-NET Public Channel for Inter Network Communication and Local Network Address Acquisition.
|-
|}