nyuuzyou/wikis huggingface dataset:
LSL Portal To-do

__NOTOC__
   WORK IN PROGRESS
Work in Progress
== To-Do ==
Use this page to keep track of what is still needed. Format as required.
# Add articles to pertinent categories.
# Add articles to categories to mark what work needs to be done to them.
#* Embellish articles so they no longer fall under those categories (and remove them from the category)
== Work Categories ==
These categories are used to indicate that an article needs work done to it.
Category 	Description
:Category:LSL Needs Example	Needs an example written, to do this set the 'example' variable equal to a multi-line block of lsl text. Once an example is supplied the page is automatically removed from this category.
:Category:LSL FixMe 	These pages have something wrong or seriously missing from them.
:Category:LSL Stub 	These articles are just too short and should be expanded upon.
== LSL Categories in Need of Work ==
These categories are missing functions or need content.
:Using templates is currently optional on Category pages. There are a lot more LSL categories but these are the ones that come to mind as needing the most work. -- Strife Onizuka
Category	Stub	Pages	Description
 	 	 	Needs descriptions written.
 	 	 	Missing functions and needs description written.
 	 	 	Needs functions that are prim attributes (not Object attributes)
 	 	 	Needs functions that are object attributes (not Prim attributes)
LSL Portal To-do/es

__NOTOC__
   TRABAJO EN CURSO
Trabajo en curso
== Cosas que hacer ==
Use esta página para monitorear el trabajo pendiente. Formatee cuando se necesario.
# Añada artículos a las categorías pertinentes. 
# Añada artículos a las categorías para marcar que trabajo todavía falta. 
#* Embellezca los artículos para que no estén bajo esas categorías (y remuevalos de la categoría). 
== Categorías de Trabajo ==
Estas categorías se usan para indicar que un artículo necesita trabajo. 
Categoría 	Descripción
:Category:LSL Needs Example	Necesita un ejemplo escrito. Para hacer esto declare la variable 'example' igual a un bloque multilíneas de texto de lsl. Cuando se suministra un ejemplo la página se remueve automáticamente de esta categoría.
:Category:LSL FixMe 	Estas páginas tienen errores o falta mucha información en ellas.
:Category:LSL Stub 	Estos artículos son muy cortos y deben expandirse.
== Categorías de LSL que necesitan trabajo ==
A estas categorías les faltan funciones o necesitan contenido. 
:Usar plantillas es opcional en las páginas de categoría. Hay muchas otras categorías de LSL pero estas son las que pienso que necesitan más trabajo. -- Strife Onizuka
Categoría	Talón	Páginas	Descripción
 	Sí 	No 	Necesita descripciones escritas.
 	Sí 	Sí 	Faltan funciones y necesita descripción escrita.
 	Sí 	No 	Necesita contenido similar a
 	Sí 	Sí 	Necesita funciones que sean atributos prim (no atributos de Object)
 	Sí 	Sí 	Necesita funciones que sean atributos object (no atributos de Prim)
LSL Portal To-do/ja

__NOTOC__
   進行中の作業
進行中の作業です。
== すべきこと ==
何がさらに必要なのか記録するためにこのページをつかいましょう。書式が併せて必要です。
# 適切なカテゴリに項目を加えましょう。
# 必要な作業が完了したときは、印をカテゴリの項目に付けましょう。
#* もはや分類されるカテゴリがない項目には飾りをつけましょう。（項目が無いカテゴリは除去しましょう）
== 作業カテゴリ ==
これらのカテゴリは、項目の必要な作業進度表示に使われます。
カテゴリ 	解説
:Category:LSL Needs Example	有効な複数行ブロックのLSLテキストと、同等の例を揃えての書き込みが必要です。
:Category:LSL FixMe 	これらのページはいくつかの間違いもしくは重大な欠点があります。
:Category:LSL Stub 	これらの項目はあまりに短すぎるので展開させるべきです。
== LSLカテゴリにて必要な作業==
これらのカテゴリは関数が存在しないか、コンテンツが必要です。
:テンプレートはカテゴリページ上では基本的に補助として使いましょう。多くのLSLカテゴリがあるなかで、かなりの作業を必要としていると思われるものがあります。 -- Strife Onizuka
カテゴリ 	部分単位 	ページ単位 	説明
 	はい 	いいえ 	説明の書き込みが必要です。
 	はい 	はい 	関数が存在せず、説明の書き込みが必要です。
 	はい 	いいえ 	類似コンテンツのが必要です。
 	はい 	はい 	（オブジェクト要素ではない）プリム要素の関数が必要です。
 	はい 	はい 	（プリム要素ではない）オブジェクト要素の関数が必要です。
LSL Portal To-do/ko

__NOTOC__
   진행중
진행중인 작업.
== 진행 절차 ==
편집에서 무엇이 필요한지를 지속적으로 파악하고 기록하기 위해 본 페이지를 사용한다. 다음 양식에 따라 실행한다.
# 적절한 분류에 항목을 더할 것.
# 어떤 작업이 더 이루어져야 문서가 완결이 되는지를 표시해주는 특별한 분류를 추가로 더한다.
#* 이후 문서가 해당 분류에 더 이상 포함되지 않을 수 있게 내용을 추가하고 다듬는다(완료되면 해당 분류를 문서에서 제거한다).
== 작업 분류 ==
이 분류들은 해당하는 종류의 작업이 문서에 더 추가되어야 함을 표시하기 위해 사용된다.
분류 	해설
 	예제가 필요한 문서. 'example' 변수는 스크립트 코드를 쓰기 위한 lsl text와 같은 구문이며 거기에 예제를 추가하면 된다. 예제가 추가되면 이 분류는 문서에서 자동으로 삭제된다.
 	문서에 무언가가 잘못되었거나 중대한 결함이 있을 때 사용한다.
 	문서가 너무나 간략하여 최소한의 내용이 좀 더 추가되어야 할 경우.
== 추가작업이 필요한 LSL 분류들 ==
아래 분류들은 빠진 함수들이 있거나 정보가 좀 더 필요하다.
:분류 화면에서 서식을 사용하는 것은 현재 필수적이지는 않다. 다음 분류들이 현재 가장 시급히 처리되어야 할 것들이다. -- Strife Onizuka
분류 	너무 짤막한가 	분류에 설명이 존재하는가 	해설
 	예 	아니오 	설명이 작성되어야 한다.
 	예 	예 	빠진 함수들이 있고, 설명이 작성되어야 한다.
 	예 	아니오 	과 유사한 내용의 꾸림정보가 필요하다.
 	예 	예 	(물체 속성이 아닌) 프림 속성의 함수 설명들이 필요하다.
 	예 	예 	(프림 속성이 아닌) 물체 속성의 함수 설명들이 필요하다.
LSL Portal Translation Project

__NOTOC__
 Do NOT translate this page. This could result in out-of-sync versions
== Welcome to the LSL Portal Translation Project! ==
This is a community effort to provide a multi-lingual translation of the LSL Portal. Please feel free to edit and add languages to the set.
== How to participate ==
LSL Scripters can participate in this project by choosing a wiki page and translating it into the language(s) they speak fluently. Templates are much harder to translate and can be done by people with more experience and knowledge of the templates syntax.
To discuss LSL portal translation, refer to the discussion page. Language-specific topics should be discussed on the proper subpage of the LSL_Portal_Translation_Team page.
To make coordination easier, discuss technical problem, and provide mutual help, there is also an inworld group named "LSL portal translation". Please subscribe to it ('Open Enrollment' is disabled, ask a group owner to join).
== Procedure to translate a page ==
* Choose a page to translate.
* The {{Multi-lang}} tag might need to be included in the English page. If you are not familiar with this wiki, feel free to ask for assistance.
* Edit the English page just to copy (Ctrl-C or Cmd-C) its "wikilang" contents
* Click the link of the page you have chosen to translate. In the URL bar of your navigator, add a /xx language code. This is how you create the language subpage. Example: LSL_Tutorial/fr to create a french translation of LSL_Tutorial. 
* In the edition area, paste the English version that you copied earlier (Ctrl-V or Cmd-V) and start translating it
* Insert your translation in place of the original content to achieve the same page layout.
* You might need to adapt the calls to templates - ask for assistance about the templates that have already been adapted to your language.
====Language Codes====
Code 	Language 	Tranlation
by 	Belorussian 	Беларускі
da 	Danish 	Dansk
de 	German 	Deutsch
el 	Greek 	ελληνικός
es 	Spanish 	Español
fr 	French 	Français
he 	Hebrew 	עִברִי
it 	Italian 	Italiano
ja 	Japanese 	日本語
ko 	Korean 	한국어
nl 	Dutch 	Nederlands
no 	Norwegian 	Norsk
pl 	Polish 	Polski
pt 	Portuguese 	Português
ru 	Russian 	Русский
sv 	Swedish 	svensk
uk 	Ukrainian 	Українська
zh-Hans	Chinese (Simplified) 	中文(简体)‬
zh-Hant	Chinese (Traditional)	中文(繁體)‬
----
Category:Localization
LSL Portal Translation Team/fr

Cette page liste les traducteurs en français participant au LSL Portal Translation Project et leurs commentaires pour le bon déroulement de la traduction française.
Mise à jour 21 Avril 2009: Le projet se poursuit maintenant à French_speaking_Linguists/Project/LSL_Portal_Translation
== Traducteurs du LSL Portal en français ==
Catherine Pfeffer
Ales Beaumont
Jeff Kelley
Olivier hildyard
Fana Dechou
Forest Klaar
Samia Bechir
Audrey Bisani
Ol Obscure
== Notes sur les questions spécifiques au français ==
* Fait: Il faut structurer la liste en <DIV>, elle devient trop grosse à l'édition. Fait le 05 Dec 2007. Il devient plus simple de changer le statut d'une page sans risquer la démolition de la liste entière.
* Catherine nous signale que Les Titres de Sections en Majuscules est une convention typographique anglaise est que la bonne typographie française est Les titres de sections en majuscules.
* Pour les liens intra-langues, on préfèrera [[Integer/fr|Entier]] à [[Integer/fr]]. Voir Project:Languages.
LSL Portal Translation Team/pt

Esta página lista os tradutores em português participantes do Projeto de Tradução do Portal LSL, seus comentários e sugestões para um bom desenvolvimento da tradução do portal em português. Se você traduziu alguma página do portal LSL e deseja incluir seu nome aqui, por favor edite esta página para sua inclusão.
== Tradutores do Portal LSL em português ==
* Agathos Frascati
== Notas e informações sobre questões específicas às traduções em português ==
Category:Ajuda Portal
LSL Protocol/EasyTalk

Back to Protocol page
==Easy Talk Protocol ==
The problem: coordinate object either using llSay or llMessageLinked in a linkset, using a single channel where objects can understand:
* sender (who generated the message and shoule be possibly replied)
* destination (to select object who should handle the message)
* command (which action to perform)
* free form parameters
Protocol is implemented using a very simple List/String dumping parsification using the character "|" as separator.
Since this is a very easy protocol I just choose this character which is common on keyboards, but very unlikely to be used in general.
It is also very simple to input in notecards and so you can have a very generic message handling and serialization.
Should you feel that "|" is not to be used because conflicting with your schema you can change it with %255, but in this way you lose the notecard serialization.
Also the protocol doesn't handle the float to string problem, which under "normal" situations should not be a big problem.
If you need to have
* "|" character in your strings
* maximum precisions in float (more than 3-4 decimals)
Don't use this or adapt with proper serialization.
On the other hand the advantage are:
* very simple
* low footprint (you can even inline it)
* very fast (no complex serializations needed)
And here the basic code (you can even inline these functions but leaving it as function will allow for refactoring and ease the code understanding):
== Serialization / Deserialization ==
string dumpList(list lst)
{
 return llDumpList2String(lst,"|");
}
list parseString(string str)
{
 return llParseStringKeepNulls(str,["|"],[]);
}
When needing to send a message use the following:
// for linkset:
llMessageLinked(LINK_SET,1,dumpList( [ sME, "TEXT", "SHOW", str, vcolor ]),""); 
// for say channels:
llSay(CHANNEL,dumpList( [ sME, "TEXT", "SHOW", str, vcolor ] );
When needing to execute the command do something like:
 link_message(integer channel,integer num, string message,key id)
 {
 debug("got msg "+message);
 // message has the form [ from, to, cmd, parms ]
 list array=parseString(message);
 string src=llList2String(array,0);
 string dst=llList2String(array,1);
 string cmd=llToLower(llList2String(array,2));
 string parm1=llList2String(array,3);
 string color=llList2String(array,4);
 
 // answers only if we are the target
 if(dst!=sME) return; 
Note the use of sME for each script for rapid deciding it's me.
Each object in the linkset listening area should have unique sME global variable.
Protocol allows for broadcasting messages for special situations:
RESET!!!
for example allowed for resetting all pieces.
LSL Protocol/Restrained Life Relay/How to Test/Relay Test 04

== Objection ==
Verify that the relay cannot be abused to cause the avatar shout something on public chat.
Note: It is not important what is said or if the attacker can completely control the said text. Just causing the avatar to shout anything is a test failure because it can easily be abused. While it is possible to mute the avatars in SL, it is almost impossible to detect the real griever (the world object).
== Instructions ==
# Go to a place with no one in shout range (100m)
# Rez and Click the box
# Do not say anything during the test
== Code ==
integer CHANNEL_RELAY = -1812221819; // Relay Channel
integer CHANNEL_PUBLIC = 0;
integer success;
// looks for the confirmation of the last command
handleRelayResponse(string message)
{
 list tokens = llParseString2List(message, [","], []);
 string question = llList2String(tokens, 2);
 string response = llList2String(tokens, 3);
 if (response == "")
 {
 	return;
 }
 if (question == "@end=n")
 {
	 llSay(CHANNEL_RELAY, "relaytest," + (string) llGetOwner() + ",!release");
 }
 else if (question == "!release")
 {
		// wait a little bit after "!release,ok" to take
		// network lag from the viewer into account
 	llSetTimerEvent(10);
 }
}
// handles avatar chat
handleAvatarResponse(string message)
{
	if (llSubStringIndex(message, "crmwqfxdkjfsakdfh") > -1)
	{
		llSay(0, "FAIL: Avatar said message on public chat");
		success = FALSE;
	} 
}
default
{
 state_entry()
 {
 llListen(CHANNEL_RELAY, "", "", "");
 llListen(CHANNEL_PUBLIC, "", "", "");
 }
 on_rez(integer ignored)
 {
 llSetText(llGetObjectName(), <1, 1, 1>, 1);
 }
 listen(integer channel, string name, key id, string message)
 {
 llOwnerSay(name + ": " + message);
 if ((llGetOwnerKey(id) == id) && (channel == CHANNEL_PUBLIC))
 {
 handleAvatarResponse(message);
 }
 if ((llGetOwnerKey(id) == llGetOwner()) && (channel == CHANNEL_RELAY))
 {
 handleRelayResponse(message);
 }
 }
 touch_start(integer ignored)
 {
 if (llDetectedKey(0) != llGetOwner())
 {
 llSay(0, "Hey, " + llDetectedName(0) + " don't mess with me!");
 return;
 }
 llSay(0, "Trying to cause unwanted chat on public channel, please wait without saying anything...");
		llSetTimerEvent(0);
		success = TRUE;
 llSay(CHANNEL_RELAY, "relaytest," + (string) llGetOwner() 
 	+ ",@sendim=n|@crmwqfxdkjfsakdfh=n"
 	+ "|@getstatus=0|@getStatus=0|@getStatus:=0"
 	+ "|@getstatus=-123|@getStatus=-123|@getStatus:=-123"
 	+ "|@getstatus=y|@getStatus=y|@getStatus:=y"
 	+ "|@getstatus=n|@getStatus=n|@getStatus:=n");
 llSay(CHANNEL_RELAY, "relaytest," + (string) llGetOwner() 
 	+ ",@version=0|@verSion=0|@verSion:=0"
 	+ "|@version=-123|@verSion=-123|@verSion:=-123"
 	+ "|@version=y|@verSion=y|@verSion:=y"
 	+ "|@version=n|@verSion=n|@verSion:=n");
 llSay(CHANNEL_RELAY, "relaytest," + (string) llGetOwner() 
 	+ ",@findfolder=0|@findFolder=0|@findFolder:=0"
 	+ "|@findfolder=-123|@findFolder=-123|@findFolder:=-123"
 	+ "|@findfolder=y|@findFolder=y|@findFolder:=y"
 	+ "|@findfolder=n|@findFolder=n|@findFolder:=n"
 	+ "|@end=n");
 }
	timer()
	{
		if (success)
 	{
 		llSay(0, "PASS: No faked chat on public channel.");
 	}
		llSetTimerEvent(0);
	}
}
LSL Protocol/Restrained Life Relay/editorial changes

This page is for discussion small changes to specification to make it easier to understand.
== require preserve order of commands ==
PS: in the relay requirements, shouldn't we add that the commands must be executed in the same order as they are received? Without this assumption, a furniture maker can never be sure that the victim will be released in the end. --Satomi Ahn 14:35, 23 February 2009 (UTC)
: As it is required to work and a couple of relay implementers (including myself) missed it in their first try, it is worth to mention. --Maike Short 20:21, 23 February 2009 (UTC)
LSL Protocol/Restrained Life Relay/pong handling contradiction

== pong handling contradiction ==
; Proposed Change : Change the point "When relogging, send a 'ping' message (see above) to check the in-world object is still available. If no message after a few seconds (not necessarily a '!pong', any message aimed at the relay can do), release the rules linked to this object." in section "Relay requirements" to: "When relogging, send a 'ping' message (see above) to check the in-world object is still available. If no !pong-message is received form this object, release the rules linked to this object."
; History : Back in 1.014 there was a discussion on the wiki but mostly in world whether it is a good idea to only accept !pong as replay to ping. The reasons behind this proposed change was that it is easier and less error prone for world objects this way. They can easily send a !version when sat on or entered without having to check with @getstatus if the relay is remembering some old restrictions. This way makes it far less likely that people get stuck. So for 1.015 the spec was changed require a !pong reply.
; Current state of the spec since 1.015: Unfortunately I messed up when I edited the wiki page. I change the sections "'ping' relay message and "!pong" object metacommand" and "In-world object requirements". But I overlooked the section "Relay requirements".
; Justification : This will make the spec more consistent. It was the intended change back then and is still valid. I am not aware of any world object that depends on a non !pong message to keep the restrictions. Most relays only accept !pong nowadays, too.
--Maike Short 19:28, 16 April 2009 (UTC)
; Discussion :
I agree that !pong should be a requirement in reply to !ping.
This said, I kept in my relay the principle following which any other reply is a proof that the device is still there and active: it is bad enough that many devices are not fully implementing the *requirements* and are not sending any reply to !ping (and thus relays checking for their presence either regularly or on user request think that the device is no more active or restraining the relay wearer) for neglecting other clues of the device presence. Henri Beauchamp 10:10, 17 April 2009 (UTC)
LSL Protocol/Restrained Life Relay/resetting environment settings

; Problem : Some objects mess with the environment and viewer debug settings (windlight, resolution). Those changes stay in effect after @clear in the current viewer. While it would be nice if the viewer would undo those changes, it does not at the moment (todo: poke Marine).
; Possible Solution : The relay should reset them on release (both !release and if the object is not available anymore). The relay should only do the reset if those settings have been messed with by the world object. Resetting implies going back to the default day-time of the sim with is undesirable in case it is not required. --Maike Short
: The relay could save the current setting (@getsenv, @getdebug) before changing it, allowing later restoration. So as not to re-save previously changed settings a start/end session protocol could be used by the in-world object. !release or loss of object would rollback all enviroment and debug setting changes to the value they held when the start was issued, thus preserving the previous desired state. Viewer support for a save operation or the ability to receive all the settings from a single query, and restoring them in a similar way would be useful and reduce the relay/viewer chatter. If not the relay can implement this using the existing queries. --Psi Merlin
LSL Protocol/Restrained Living Relay/Other Implementations/Maike Short's Relay/Toucher

Back to Maike Short's Relay.
== Tasks of this script ==
There is a situation in which it is desirable to suppress touch events to the root prim: The Lockable script handles them and displays the standard dialog of the Real Restraints. This script, however, can be used by the Extended Controller to enable struggling, squirming and tugging your way out.
So in this case we do not want to see that dialog ever. The workaround is this: The Extended Controller and Lockable script are put into the root prim. The root prim, however, is totally covered by another prim. This prim does not forward touch events to the root prim but sends an linked message instead.
Note: This script is required in the !vision (and @thirdview) prim as well.
== Code ==
<lsl>
integer INTERPRIM_CHANNEL = -1373421730;
default {
 state_entry() {
 llPassTouches(FALSE);
 }
 touch_start(integer i) {
 llMessageLinked(LINK_SET, INTERPRIM_CHANNEL, "touch", llDetectedKey(0));
 }
}
</lsl>
LSL Protocol/Restrained Love Open Relay Group

The purpose of this and other related pages is to create an environment for the development of extensions to the existing Restrained Love Relay specification. The goal is to create an environment where ideas for extending the existing specification can be discussed openly and in the spirit of cooperation and not competition.
A stated aim of the existing relay is that the specification should not include anything that can be done in a script. The goal of this specification is to get as many of those script ideas made as open as possible so that toy builders do not have to invent new and incompatible ways of doing the same thing.
Finally, and perhaps the most important, our thanks go out to Maike Short. Her work on the existing relay specification was tireless and, appears to have been under-appreciated. Her generosity in making her relay code public enabled many others to develop their relays, using her script as a basis.
; Founding Members
* Chloe1982 Constantine
* Ilana Debevec
* Kira Welty
* Kitty Barnett
* Lyssa Daehlie
* Maike Short 
* Monica Jewell
* Nano Siemens
* samatha Congrejo
* Satomi Ahn
* Toy Wylie
LSL Protocol/Restrained Love Open Relay Group/ack

= !x-ack =
STATUS: draft
VERSION: 002
002 Implemented in Dahlia's multirelay (<-- this command is not supported anymore due to llRegionSayTo())
001 Implemented in Satomi's multirelay
!x-ack/quiet: tells the relay to stop sending "ok" and "ko" acknowledgements
!x-ack/verbose: tells the relay to resume sending them
Rationale: reduce relay channel spam, and thus lag, by disabling acknowledgements that the controlling device does not care about.
General syntax: !x-ack[/STRING]*, where STRING is the desired acknowledgement policy.
Behavior requirements:
* This will change the way the relay acknowledge commands, applying the policy given in the argument of the command, thus overriding the core requirement that every command should be acknowledged. There are now, in 002, two policies:
:* verbose: it is the default usual policy for RLV relays
:* quiet: "ok" and "ko" acknowledgements are not sent (other useful replies should still be sent!).
* This behavior change only concerns the acknowledgements to commands from the device issuing !x-ack.
* The possible acknowledgements to "!x-ack" are "ok" to say it was accepted, and "ko" otherwise. The acknowledgement may or may not be sent, depending on the current acknowledgement policy but, in every case, if there is a policy change, its effects start immediately, that is before the relay (does not) acknowledges "!x-ack".
* No matter the active acknowledgement policy, "!release,ok" should be always sent in case of safe-wording (which is not really an acknowledgement because it is not a reply to a command from the controlling device). Same goes for any other message sent at the initiative of the relay.
* The acknowledgement policy is restored on relog.
Example 1:
 C -> R: !x-ack/quiet
 (nothing)
 C -> R: @remoutfit=force
 (nothing)
 C -> R: !x-orgversions
 C <- R: 0002/ack=001
 C -> R: !x-ack/verbose
 C <- R: !x-ack/verbose,ok
 C -> R: @detach:pelvis=force
 R <- C: @detach:pelvis=force,ok
Example 2, a low-lag RLV zone controller:
 C −> *: !x-ack/quiet|@sittp=n|@tplure=n|@tploc=n|@tplm=n|@showworldmap=n|@showminimap=n|@showloc=n
 (Then no relay should answer, but everybody should be restricted. "*" instead of "R" means
 a wildcard was used, as introduced in ORG-0002. Without the wildcard and !x-ack, a lot of
 spam would have been sent to the RLV channel.)