User:Samia Bechir

2008-01-12T13:21:13Z

Samia Bechir: /* Languages */

Hello, I'm Samia
[[Image:Samia.jpg|Hello I'm Samia]]

==About Me==

French, Born 02/02/2007, I share my SL time between 4 main activities :
* Having fun with my SL friends
* Helping other residents
* Designing SL clothings
* Shopping (yes I'm an addict)

== Helping Residents ==

I recently joined the '''Second Life Mentors'''

[[SL_Volunteer_Mentor_Linguists]] IM me anytime for requests about translations from/to french.

I also help french residents, with :

* The '''French Helpers''' team, you can find us at the French Helpers Café on Threlkeld

* The '''Coopération Française''' team, in the group chat and at the cooperation francaise HQ on Area 51

== Projects ==

Contributing to the LSL wiki translation project. Which proves one can translate something without understanding any part of it^^

[[LSL_Portal_Translation_Project]]

==Contact==

e-mail : samia.bechir@mac.com

==Useful (or useless^^) groups==

* Trying to find the clothing you want ? ask the '''French Fashion Victims''' group

* Running SL on a Mac ? the '''Macintosh users''' group is very active and friendly

* You spend more time editing your typos than actually writing ? The '''Keyboard Disabled''' group will warmly welcome you

==Languages==

* French

* English (not too bad at it, but... if it comes to technical words, and specifically computer things, I might return a *Lack of English vocabulary error*)

{{ISO 639-3/cat-speaking/Volunteers|eng}}
{{ISO 639-3/cat-speaking/Volunteers|fra}}

User:Samia Bechir

2008-01-12T13:17:57Z

Samia Bechir: /* Languages */

User:Samia Bechir

2008-01-12T13:14:35Z

Samia Bechir:

2008-01-09T22:26:53Z

State/fr

2007-12-11T19:56:57Z

Samia Bechir:

{{Multi-lang}}
{{LSL Header}}
<div style="float:right">__TOC__</div>
En LSL, la plupart des scripts attendent sans rien faire jusqu'à ce qu'ils reçoivent une information ou qu'ils détectent un changement dans leur environnement.
A tout moment, le script est dans un état ('''state'''), et réagira a des événements (events) ou des informations en fonction de ce que le programmeur aura déterminé.
Par ailleurs, un script peut contenir deux états différents, ou plus, et réagir différemment aux événements ou aux informations, selon l'état dans lequel il est placé à ce moment.

L'état principal est l'état par défaut (default). Quand un script est compilé, réinitialisé ou chargé, c'est l'état dans lequel il ira par défaut.
Apres la définition de l'état par défaut, d'autres états peuvent être définis, de façon à ce que le script réagisse différemment aux événements
{{#vardefine:name|état
}}{{#vardefine:p_jump_state_desc|nom de l'état actif
}}{{#vardefine:p_label_state_desc|nom de l'état
}}{{#vardefine:p_events_desc|un ou plusieurs événements ({{LSLGC|Events|events}})
}}{{#vardefine:header_title|événement { {{LSL Param|events}} } default
}}{{#vardefine:header_text|{{{!}}
{{LSL DefineRow|événement|événements|{{#var:p_events_desc}}}}
{{!}}}
Définit l'état par défaut.
}}{{#vardefine:constants_nb|
<div id="box">
<h2>state {{LSL Param|label_state|cible}} { {{LSL Param|events}} }</h2>
<div style="padding: 0.5em">
{{{!}}
{{LSL DefineRow|nom|cible|{{#var:p_label_state_desc}}}}
{{LSL DefineRow|événement|événements|{{#var:p_events_desc}}}}
{{!}}}
Définition de l'état '''cible''' (target).
</div>
</div>
{{!}}-
{{!}}
<div id="box">
<h2>state {{LSL Param|jump_state|cible}};</h2>
<div style="padding: 0.5em">
{{{!}}
{{LSL DefineRow|nom|cible|{{#var:p_jump_state_desc}}}}
{{!}}}<br/>
Quand un "état cible" est rencontré au cours de l'exécution, et que l'état "actuel" et l'état "cible" sont différents :
#Actionne [[state_exit]] dans l'état actuel s'il existe, et efface la chaîne d'événements.
#Change l'état pour ''cible'', tous les [[listen]]s sont arrêtés.
#Actionne [[state_entry]] dans l'état ''cible'' s'il existe.
Si l'état ''cible'' est le même que l'état ''en cours'' state, il n'y a pas de changement d'état, ni aucune conséquence.
</div>
</div>
}}{{#vardefine:examples|
<pre>
default
{
touch_start(integer a)
{
state hello;
}
}

state hello
{
state_entry()
{
llOwnerSay("Coucou");
state default;
}
state_exit()
{
llOwnerSay("Au revoir");
}
}
</pre>
}}{{#vardefine:notes|
}}{{#vardefine:caveats|*Lors du changement d'état:
**tous les [[listen]]s sont arrêtés.
**la chaine d'événements (events) est effacée
*L'état ''default'' doit être défini avant tous les autres.
*Les états ne peuvent pas contenir directement de fonctions ou de variables, il ne doit y avoir que des définitions d'événements dans le contenu de l'état.
}}{{#vardefine:helpers|
}}{{#vardefine:also_header|<h3>Keywords</h3>
{{{!}}
{{LSL DefineRow||[[jump]]|}}
{{LSL DefineRow||[[return]]|}}
{{!}}}
}}{{#vardefine:also_footer|
}}{{#vardefine:also_functions|
}}{{#vardefine:also_events|
{{LSL DefineRow||[[state_entry]]|}}
{{LSL DefineRow||[[state_exit]]|}}
}}{{#vardefine:also_articles|
}}{{#vardefine:also_tests|
}}{{#vardefine:location|
}}{{LSL Generic}}{{LSLC|Flow Control}}{{LSLC|Script}}

State/fr

2007-12-11T19:35:43Z

Samia Bechir: en cours de traduction par Samia

{{Multi-lang}}
{{LSL Header}}
<div style="float:right">__TOC__</div>
En LSL, la plupart des scripts attendent sans rien faire jusqu'à ce qu'ils reçoivent une information ou qu'ils détectent un changement dans leur environnement.
A tout moment, le script est dans un état ('''state'''), et réagira a des événements (events) ou des informations en fonction de ce que le programmeur aura déterminé.
Par ailleurs, un script peut contenir deux états différents, ou plus, et réagir différemment aux événements ou aux informations, selon l'état dans lequel il est placé à ce moment.

L'état principal est l'état par défaut (default). Quand un script est compilé, réinitialisé ou chargé, c'est l'état dans lequel il ira par défaut.
Apres la définition de l'état par défaut, d'autres états peuvent être définis, de façon à ce que le script réagisse différemment aux événements
{{#vardefine:name|state
}}{{#vardefine:p_jump_state_desc|name of a state to run
}}{{#vardefine:p_label_state_desc|state name
}}{{#vardefine:p_events_desc|one or more {{LSLGC|Events|events}}
}}{{#vardefine:header_title|default { {{LSL Param|events}} }
}}{{#vardefine:header_text|{{{!}}
{{LSL DefineRow|event|events|{{#var:p_events_desc}}}}
{{!}}}
The default state definition.
}}{{#vardefine:constants_nb|
<div id="box">
<h2>state {{LSL Param|label_state|target}} { {{LSL Param|events}} }</h2>
<div style="padding: 0.5em">
{{{!}}
{{LSL DefineRow|label|target|{{#var:p_label_state_desc}}}}
{{LSL DefineRow|event|events|{{#var:p_events_desc}}}}
{{!}}}
'''target''' state definition.
</div>
</div>
{{!}}-
{{!}}
<div id="box">
<h2>state {{LSL Param|jump_state|target}};</h2>
<div style="padding: 0.5em">
{{{!}}
{{LSL DefineRow|label|target|{{#var:p_jump_state_desc}}}}
{{!}}}<br/>
When a ''state target;'' is encountered at runtime, if the ''current'' state and the ''target'' state are different:
#Trigger [[state_exit]] in the current state if it exists and clear the event queue.
#Change state to ''target'', any [[listen]]s are unregistered.
#Trigger [[state_entry]] in the ''target'' state if it exists.
If ''target'' state is the same as the ''current'' state, no state change occurs nor do any of the side effects.
</div>
</div>
}}{{#vardefine:examples|
<pre>
default
{
touch_start(integer a)
{
state hello;
}
}

state hello
{
state_entry()
{
llOwnerSay("Hello");
state default;
}
state_exit()
{
llOwnerSay("Goodbye");
}
}
</pre>
}}{{#vardefine:notes|
}}{{#vardefine:caveats|*On state change:
**All [[listen]]s are released.
**The event queue is cleared
*The ''default'' state must be defined before all others.
*States cannot have user functions or variables inside their immediate scope, only event definitions may be inside a states scope.
}}{{#vardefine:helpers|
}}{{#vardefine:also_header|<h3>Keywords</h3>
{{{!}}
{{LSL DefineRow||[[jump]]|}}
{{LSL DefineRow||[[return]]|}}
{{!}}}
}}{{#vardefine:also_footer|
}}{{#vardefine:also_functions|
}}{{#vardefine:also_events|
{{LSL DefineRow||[[state_entry]]|}}
{{LSL DefineRow||[[state_exit]]|}}
}}{{#vardefine:also_articles|
}}{{#vardefine:also_tests|
}}{{#vardefine:location|
}}{{LSL Generic}}{{LSLC|Flow Control}}{{LSLC|Script}}

LSL Portal Translation Project

2007-12-11T19:20:09Z

Samia Bechir: /* State */

LSL Portal Translation Project

2007-12-11T19:14:03Z

Samia Bechir: /* LSL_Variables */

LSL Portal Translation Project

2007-12-11T19:12:56Z

Samia Bechir: /* LSL_Errors */

LSL Variables/fr

2007-12-11T19:11:13Z

Samia Bechir: Première traduction en Français *non vérifiée*

{{Multi-lang}}
{{LSL Header}}

Une '''variable''' est un élément dans lequel une information (nombre, chaine de caractères...) est stockée.

Une variable a un nom, un type et une valeur. Le nom commence par une lettre, et les conventions sont les mêmes qu'on C ou en Java. Les majuscules sont prises en compte : "X" est différent de "x"

le LSL est un langage fortement structuré par types. Cela veut dire que les variables doivent etre déclarées par types, et qu'elles ne peuvent contenir que des valeurs correspondant à ce type. Cependant, une variable liste peut contenir des valeurs de n'importe quel autre type.

Quelques exemples:
<pre>
integer nombre = 2;
float virgule = 1.2;
string mot = "Nutella";
List mots = ["Ceci", "est", "une", "liste"];
List differente = ["une liste peut contenir différents types de valeurs comme", 2, 1.2, <0.4, 0.8, 1.6>];
vector vecteur = <1,6,2>;
</pre>

== Champ d'action des variables ==
Le nom de la variable est utilisé depuis l'endroit ou elle apparaît pour la premiere fois jusqu'à la fin de la partie dans laquelle elle est, ou la fin du script pour les variables globales. Un nom de variable ne peut pas etre défini deux fois dans la même partie, mais le nom peut être redéfini dans une partie, et remplacer le meme nom utilisé dans les autres parties.
Comme dit precedemment, la sémantique est très proche de celle utilisée en C ou en Java.
Ainsi, le code qui suit pourra etre compilé et exécuté :

<pre>
integer i = 50;
default {
state_entry() {
string i = "Coucou !"; //Cela sera accepté lors de la compilation, contrairement à Java ou C++.
llOwnerSay(i); //Dira "Coucou !". Il n'y a plus moyen d'obtenir la variable globale i.
}
}
</pre>
== Voir aussi ==
* [[string]]
* [[key]]
* [[integer]]
* [[float]]
* [[list]]
* [[vector]]
* [[rotation]]

LSL Errors/fr

2007-12-11T18:45:26Z

Samia Bechir: Première traduction en Français *non vérifiée*

{{Multi-lang}}
{{LSL Header}}

==Messages d'erreur pendant l'exécution (Run-time error)==

L'exécution du script s'arrête, et vous avez un message d'erreur en chat : "Script run-time error", suivi d'un autre message d'erreur tel que :

===Script run-time error: Heap Error (erreur de tas)===

Evitez le non-sens. Par exemple, ne faites pas une liste à une seule entrée qui est le résultat d'une routine qui ne renvoie pas de résultat.

===Script run-time error: Lists may not contain lists (les listes ne peuvent pas contenir de listes)===

N'essayez pas d'ajouter une liste dans une liste.

===Script run-time error: Math Error (erreur mathématique)===

Float ou Integer divisé par zéro, etc.

===Script run-time error: Stack-Heap Collision (collision entre tas et pile)===

La pile est entrée en collision avec le tas ou le bytecode.

Chaque script s'exécute en utilisant 16 Ko de mémoire, partagée entre bytecode, tas et pile.

Vous pouvez provoquer une collision si vous compilez trop de scripts, ce qui produit trop de bytecode. Le script est compilé et sauvegardé sans erreur, mais lorsque vous rezzez un objet qui contient ce script, il crashe, immédiatement ou durant l'exécution.

Voir [[llGetFreeMemory]].

===Exemples de scripts provoquant Run-time error===

Compilez et exécutez ces exemples pour obtenir les messages d'erreur pendant l'exécution (run-time error en chat).

<pre>
default
{
state_entry()
{
llOwnerSay((string) [llOwnerSay("bye")]); // Script run-time error: Heap Error (erreur de tas)
}
}
</pre>

<pre>
default
{
state_entry()
{
list once = [];
list twice = [once, once]; // Script run-time error: Lists may not contain lists (les listes ne peuvent pas contenir de listes)
}
}
</pre>

<pre>
default
{
state_entry()
{
float one = 1.0;
float zero = 0.0;
float quotient = one / zero; // Script run-time error: Math Error (erreur mathématique)
llOwnerSay((string) quotient);
}
}
</pre>

<pre>
default
{
state_entry()
{
list entries = [0];
while (TRUE)
{
entries += entries; // Script run-time error: Stack-Heap Collision (collision tas/pile)
llOwnerSay((string) llGetListLength(entries));
}
}
}
</pre>

==messages d'erreur pendant la compilation (Compile-time error messages)==

L'interface de SL peut rejeter du code qui vous paraissait pourtant clair, et vous renvoyer une erreur puis un message d'explication.

===ERROR : Mauvais type (Type mismatch)===

Vous devez définir chacune des composantes .x .y .z .s d'un vecteur ou d'une rotation, vous ne pouvez pas les allouer en une seule fois avec une liste, par exemple :

<pre>
default
{
state_entry()
{
vector vec = (vector) [1, 2, 3]; // ERROR : Type mismatch (mauvais type)
llOwnerSay((string) vec);
}
}
</pre>

===ERROR : erreur de mémoire (Byte code assembly failed -- out of memory)===

Chaque script doit être d'une taille raisonnable.

Par exemple, le compilateur dira que le script est trop grand si vous utilisez trop de else/if en cascade.

<pre>
demoElseIfCompileError(integer count)
{
if (count == 0)
{
;
}
else if (count == 1)
{
;
}
else if (count == 2)
{
;
}
...
... // ERROR : Byte code assembly failed -- out of memory
... // or ERROR : Syntax error
...
else if (count == ...)
{
;
}
}
</pre>

La limite à partir de laquelle un script est trop long varie étonnamment. Par exemple, cette limite variait dans un rapport de 1 à 30 dans les clients SL d'août 2007. Plus précisément le client Windows acceptait 22 else/if et refusait s'il y en avait 23, alors que le client MacOs en acceptait 692 et rejetait à partir de 693.

Les limites de compilation varient en fonction du système d'exploitation en raison des limites propres ceux ci sur la taille de ce qui peut être copié.
Tous les résidents peuvent exécuter les scripts écrits par ceux dont la limite est la plus élevée, mais les résidents qui auront une limite plus basse ne pourront pas sauver les changements qu'ils y feraient.

Voir [[llGetFreeMemory]], [[llMessageLinked]].

===ERROR : erreur de syntaxe (Syntax error)===

Evidement, le compilateur attend de vous une orthographe et une ponctuation impeccables.

Là aussi, la taille du script peut jouer. Etonnamment, le compilateur peut vous renvoyer un message "syntax error", au lieu de vous informer poliment qu'il s'agit d'un problème de taille avec un message "out of memory" "byte code assembly failed", quand vous avez fait un script de taille excessive.

Par exemple, le client Windows d'aout 2007 renvoyait Syntax error au dela de 22 else/if en cascade, et meme parfois au delà de 18, en fonction de ce qu'il y avait d'autre dans le script.

LSL Errors/fr

2007-12-11T18:28:18Z

Samia Bechir: /* ERROR : Type mismatch */

{{Multi-lang}}
{{LSL Header}}

==Messages d'erreur pendant l'exécution (Run-time error)==

L'exécution du script s'arrête, et vous avez un message d'erreur en chat : "Script run-time error", suivi d'un autre message d'erreur tel que :

===Script run-time error: Heap Error (erreur de tas)===

Evitez le non-sens. Par exemple, ne faites pas une liste à une seule entrée qui est le résultat d'une routine qui ne renvoie pas de résultat.

===Script run-time error: Lists may not contain lists (les listes ne peuvent pas contenir de listes)===

N'essayez pas d'ajouter une liste dans une liste.

===Script run-time error: Math Error (erreur mathématique)===

Float ou Integer divisé par zéro, etc.

===Script run-time error: Stack-Heap Collision (collision entre tas et pile)===

La pile est entrée en collision avec le tas ou le bytecode.

Chaque script s'exécute en utilisant 16 Ko de mémoire, partagée entre bytecode, tas et pile.

Vous pouvez provoquer une collision si vous compilez trop de scripts, ce qui produit trop de bytecode. Le script est compilé et sauvegardé sans erreur, mais lorsque vous rezzez un objet qui contient ce script, il crashe, immédiatement ou durant l'exécution.

Voir [[llGetFreeMemory]].

===Exemples de scripts provoquant Run-time error===

Compilez et exécutez ces exemples pour obtenir les messages d'erreur pendant l'exécution (run-time error en chat).

<pre>
default
{
state_entry()
{
llOwnerSay((string) [llOwnerSay("bye")]); // Script run-time error: Heap Error (erreur de tas)
}
}
</pre>

<pre>
default
{
state_entry()
{
list once = [];
list twice = [once, once]; // Script run-time error: Lists may not contain lists (les listes ne peuvent pas contenir de listes)
}
}
</pre>

<pre>
default
{
state_entry()
{
float one = 1.0;
float zero = 0.0;
float quotient = one / zero; // Script run-time error: Math Error (erreur mathématique)
llOwnerSay((string) quotient);
}
}
</pre>

<pre>
default
{
state_entry()
{
list entries = [0];
while (TRUE)
{
entries += entries; // Script run-time error: Stack-Heap Collision (collision tas/pile)
llOwnerSay((string) llGetListLength(entries));
}
}
}
</pre>

==messages d'erreur pendant la compilation (Compile-time error messages)==

The SL GUI may reject some code that you feel is perfectly clear, printing ERROR at you and then explaining with some further complaint.

===ERROR : Mauvais type (Type mismatch)===

Vous devez définir chacune des composantes .x .y .z .s d'un vecteur ou d'une rotation, vous ne pouvez pas les allouer en une seule fois avec une liste, par exemple :

<pre>
default
{
state_entry()
{
vector vec = (vector) [1, 2, 3]; // ERROR : Type mismatch (mauvais type)
llOwnerSay((string) vec);
}
}
</pre>

===ERROR : Byte code assembly failed -- out of memory===

You must make each script reasonably small.

For example, the compiler says you typed too much script if you cascade too many else-if's:
<pre>
demoElseIfCompileError(integer count)
{
if (count == 0)
{
;
}
else if (count == 1)
{
;
}
else if (count == 2)
{
;
}
...
... // ERROR : Byte code assembly failed -- out of memory
... // or ERROR : Syntax error
...
else if (count == ...)
{
;
}
}
</pre>

How much script is too much script can vary astonishingly. For example, the 2007-08 Second Life clients varied as much as 30X, from one to the next. Specifically, the Windows client accepted 22 else-if's and refused 23 else-if's, while Mac OS X was accepting 692 else-if's and refusing 693 else-if's.

Compilation limits that vary by operating system in effect work as a copy-restriction mechanism. Any resident can run the script compiled by the less limited compiler, but residents who have only the more limited compiler cannot save changes to the source.

See [[llGetFreeMemory]], [[llMessageLinked]].

===ERROR : Syntax error===

You must punctuate the script and spell the words of the script as will please the compiler, of course.

Also you must make each script reasonably small. The compiler may astonishingly complain of a "syntax" error rather than politely complaining more specifically of an "out of memory" "byte code assembly failed" error, when you make a script unreasonably large.

For example, the 2007-08 Windows Second Life client complained of a Syntax error if you cascaded too many else-if's. The exact limits enforced can vary astonishingly. For example, the 2007-08 Windows Second Life client sometimes accepted as many as 22 cascaded else-if's, but also sometimes rejected as few as 19 cascaded else-if's, depending on other details of the script.

Programmers who learned LSL on one compiler may feel that that compiler's limits are reasonable, ''e.g.'', up to five hundred cascaded else-if's in Mac OS X, while programmers trained on another compiler may feel instead that only its significantly different limits are reasonable, ''e.g.'', no more than a dozen cascaded else-if's in Windows.

LSL Errors/fr

2007-12-11T18:21:16Z

Samia Bechir: en cours de traduction par Samia

{{Multi-lang}}
{{LSL Header}}

==Messages d'erreur pendant l'exécution (Run-time error)==

L'exécution du script s'arrête, et vous avez un message d'erreur en chat : "Script run-time error", suivi d'un autre message d'erreur tel que :

===Script run-time error: Heap Error (erreur de tas)===

Evitez le non-sens. Par exemple, ne faites pas une liste à une seule entrée qui est le résultat d'une routine qui ne renvoie pas de résultat.

===Script run-time error: Lists may not contain lists (les listes ne peuvent pas contenir de listes)===

N'essayez pas d'ajouter une liste dans une liste.

===Script run-time error: Math Error (erreur mathématique)===

Float ou Integer divisé par zéro, etc.

===Script run-time error: Stack-Heap Collision (collision entre tas et pile)===

La pile est entrée en collision avec le tas ou le bytecode.

Chaque script s'exécute en utilisant 16 Ko de mémoire, partagée entre bytecode, tas et pile.

Vous pouvez provoquer une collision si vous compilez trop de scripts, ce qui produit trop de bytecode. Le script est compilé et sauvegardé sans erreur, mais lorsque vous rezzez un objet qui contient ce script, il crashe, immédiatement ou durant l'exécution.

Voir [[llGetFreeMemory]].

===Exemples de scripts provoquant Run-time error===

Compilez et exécutez ces exemples pour obtenir les messages d'erreur pendant l'exécution (run-time error en chat).

<pre>
default
{
state_entry()
{
llOwnerSay((string) [llOwnerSay("bye")]); // Script run-time error: Heap Error (erreur de tas)
}
}
</pre>

<pre>
default
{
state_entry()
{
list once = [];
list twice = [once, once]; // Script run-time error: Lists may not contain lists (les listes ne peuvent pas contenir de listes)
}
}
</pre>

<pre>
default
{
state_entry()
{
float one = 1.0;
float zero = 0.0;
float quotient = one / zero; // Script run-time error: Math Error (erreur mathématique)
llOwnerSay((string) quotient);
}
}
</pre>

<pre>
default
{
state_entry()
{
list entries = [0];
while (TRUE)
{
entries += entries; // Script run-time error: Stack-Heap Collision (collision tas/pile)
llOwnerSay((string) llGetListLength(entries));
}
}
}
</pre>

==messages d'erreur pendant la compilation (Compile-time error messages)==

The SL GUI may reject some code that you feel is perfectly clear, printing ERROR at you and then explaining with some further complaint.

===ERROR : Type mismatch===

You must name the .x .y .z .s components of a vector or rotation that you're assigning, you can't assign them all at once from a list, for instance:

<pre>
default
{
state_entry()
{
vector vec = (vector) [1, 2, 3]; // ERROR : Type mismatch
llOwnerSay((string) vec);
}
}
</pre>

===ERROR : Byte code assembly failed -- out of memory===

You must make each script reasonably small.

For example, the compiler says you typed too much script if you cascade too many else-if's:
<pre>
demoElseIfCompileError(integer count)
{
if (count == 0)
{
;
}
else if (count == 1)
{
;
}
else if (count == 2)
{
;
}
...
... // ERROR : Byte code assembly failed -- out of memory
... // or ERROR : Syntax error
...
else if (count == ...)
{
;
}
}
</pre>

How much script is too much script can vary astonishingly. For example, the 2007-08 Second Life clients varied as much as 30X, from one to the next. Specifically, the Windows client accepted 22 else-if's and refused 23 else-if's, while Mac OS X was accepting 692 else-if's and refusing 693 else-if's.

Compilation limits that vary by operating system in effect work as a copy-restriction mechanism. Any resident can run the script compiled by the less limited compiler, but residents who have only the more limited compiler cannot save changes to the source.

See [[llGetFreeMemory]], [[llMessageLinked]].

===ERROR : Syntax error===

You must punctuate the script and spell the words of the script as will please the compiler, of course.

Also you must make each script reasonably small. The compiler may astonishingly complain of a "syntax" error rather than politely complaining more specifically of an "out of memory" "byte code assembly failed" error, when you make a script unreasonably large.

For example, the 2007-08 Windows Second Life client complained of a Syntax error if you cascaded too many else-if's. The exact limits enforced can vary astonishingly. For example, the 2007-08 Windows Second Life client sometimes accepted as many as 22 cascaded else-if's, but also sometimes rejected as few as 19 cascaded else-if's, depending on other details of the script.

Programmers who learned LSL on one compiler may feel that that compiler's limits are reasonable, ''e.g.'', up to five hundred cascaded else-if's in Mac OS X, while programmers trained on another compiler may feel instead that only its significantly different limits are reasonable, ''e.g.'', no more than a dozen cascaded else-if's in Windows.

2007-12-04T17:22:19Z

Samia Bechir: /* Rotating Vectors */

{{Multi-lang}}
{{LSL Header}}{{RightToc}}

'''***** PAGE EN COURS DE TRADUCTION PAR SAMIA *****'''

=Rotations=
Le type LSL '''rotation''' est utilisé pour représenter une orientation en 3D (nous nous efforçons d'écrire le nom des types en '''gras''').
Une orientation, ou angle en 3D, est représentée par un objet mathématique appelé un {{LSLG|quaternion}}. Considérons les quaternions comme un ensemble de 4 nombres, dont trois représentent la direction à laquelle l'objet fait face et la quatrième son pivotage vers la droite ou vers la gauche autour de cette direction. Le principal intérêt d'utiliser les quaternions est qu'ils ne sont pas sujets à la perte de degré de liberté ([http://fr.wikipedia.org/wiki/Gimbal_Lock gimbal lock]).
Pour le fonctionnement interne complexe des mathématiques des quaternions, voir {{LSLG|quaternion}}.
Pour une liste de fonctions ou d'évènements liés aux rotations, voir {{LSLG|Rotation Synopsis}}.
Il y a aussi des informations sur la façon de faire tourner des textures sur la page {{LSLG|texture}}s.

==Autres représentations==
Une autre façon de représenter une rotation est d'utiliser 3 nombres, <X, Y, Z>, qui représentent de combien (en [[radians]]) l'objet tourne autour de trois axes. C'est par exemple utilisé dans la fenêtre de modification et est généralement facilement visualisé par les gens. Notez que ces trois nombres sont de type '''vector''' et non de type '''rotation''', bien que cela puisse représenter la même information. On appelle cela les rotations d'Euler.

Une troisième façon de faire est d'utiliser trois vecteurs, qui vont indiquer vers où sont orientés l'avant, le dessus et le coté gauche. En réalité, il n'y a besoin que de deux de ces vecteurs, le troisième découlant des deux premiers.

Il y a de bonne raisons de préférer la version à quatre nombres, la '''rotation''', bien qu'elle soit plus compliquée à s'approprier pour des débutants. Il existe des fonctions qui permettent de convertir facilement d'une représentation à une autre.

==La règle de la main droite==
Dans LSL, toutes les rotations sont effectuées suivant la '''règle de la main droite'''. Avec votre main droite, pointez l'index vers la direction de l'axe X positif, le majeur à angle droit de l'index pointera alors en direction de l'axe Y positif, et le pouce, à angle droit des deux autres, pointera vers l'axe Z positif.
Lorsque vous modifiez un objet, les trois flèches de couleur pointent vers le coté positif de chacun des axes (X rouge, Y vert, Z bleu).

[http://fr.wikipedia.org/wiki/Règle_de_la_main_droite Règle de la main droite]

Gardez votre main en position, c'est utile pour autre chose : trouver de quel côté est l'axe positif. Fermez le poing et sortez le pouce en direction du coté positif de l'axe qui vous intéresse. Vos autres doigts sont repliés dans le sens des axes positifs. Les rotations autour des axes X, Y et Z sont géréralement appelées roulis, tangage et lacet, en particulier lorsqu'il est question de véhicules.

[http://fr.wikipedia.org/wiki/Pilotage_d%27un_avion Roulis, tangage et lacet]

==Dans le monde ou localement==
Il est important de différencier les '''rotation'''s relatives au monde et la '''rotation''' relatives à l'objet lui-même.
Dans la fenetre de modifications, vous pouvez passer de l'une à l'autre. Dans un script, il faut convertir l'une en l'autre pour obtenir le comportement souhaité.

Pour scripter la '''rotation''' d'un prim non lié, utiliser :

<div id="box"><div style="padding: 0.5em">
{| cellpadding=0 cellspacing=0
|-
|rotation myRot ||= {{LSLG|llGetRot}}();||// charge la rotation par rapport au monde dans myRot
|}
</div></div>

== Rotations combinées ==

Pour combiner des '''rotations''', on utilise les opérateurs '''multiplier''' et '''diviser'''.
Ne pas utiliser les opérateurs addition ou soustraction, qui ne donneront pas le résultat attendu.
L'opération '''multiplier''' s'applique à la rotation dans la direction positive, l'opération '''diviser''' effectue une rotation négative.
Il est également possible d'obtenir une rotation négative directement, en utilisant le signe - : X.s = -X.s.

A l'inverse d'autres entrées comme {{LSLG|float}}, l'ordre dans lequel les opérations sont effectuées est important. [http://en.wikipedia.org/wiki/Commutative non-commutative].
La raison en est simple : l'ordre dans lequel on effectue des rotations est importante en RL.
Par exemple, si vous avez une flèche avec quatre plumes, qui commence à la rotation <0, 0, 0> avec sa queue comme origine, elle sera alignée sur l'axe X avec sa pointe dans la direction X positive, ses plumes seront alignées sur les axes Z et Y, et les axes de la fleche seront alignés sur les axes dans le monde.
Nous allons la faire tourner de 45 degrés autour de l'axe X et de 30 degrés autour de l'axe Y, mais en changeant l'ordre.

D'abord, après une rotation de 45° autour de l'axe X, la flèche sera toujours alignée le long de l'axe X, et l'aura pas bougé, elle aura simplement pivoté autour de son axe, donc les plumes seront à 45° des axes.
Ensuite, la faire tourner de 30° autour de l'axe Y la fera pointer de 30° vers le bas (par rapport à l'axe X - souvenez vous que la règle de la main droite fait qu'une rotation positive va vers le bas)
La flèche finit par être pointée de 30° vers le bas, sur le même plan vertical qu'au départ, mais en ayant pivoté sur elle même, ce qui fait que les plumes ne sont plus alignées vers le haut et le bas.

Si on effectue les modifications dans l'autre ordre, en commençant par une rotation de 30° sur l'axe Y, la flèche va pencher vers le bas par rapport au plan XY. Notez qu'elle n'est plus alignée par rapport à son axe X : Donc, son axe X et celui du monde ne sont plus alignés l'un par rapport à l' autre. Une rotation de 45° autour de l'axe X la fera pivoter autour de sa queue, la pointe tournera de 45° vers le haut et la droite en suivant un cône de 30° dont l'axe est aligné avec l'axe positif dans le monde.

Le résultat est clairement différent de celui de la premiere rotation, alors que seul l'ordre dans lequel les rotations ont été effectuées a changé.

Pour effectuer une rotation constante, vous devez définir une valeur '''rotation''', ce qui se fait en créant un {{LSLG|vector}} avec comme composants les angles X, Y, Z en radians (cela s'appelle un angle d'Euler), puis en le convertissant en '''rotation''' avec la fonction {{LSLG|llEuler2Rot}}.
Vous pouvez aussi créer directement une rotation native : la partie réelle est le cosinus de la motié de l'angle de rotation, et la partie vectorielle l'axe normalisé de rotation multiplié par le sinus de la moitié de l'angle de rotation.
Pour passer d'une rotation à un angle d'Euler, {{LSLG|vector}} utilise {{LSLG|llRot2Euler}}.

'''NOTE:''' les angles dans LSL sont en radians, pas en degrés, mais vous pouvez facilement les convertir avec les constantes prédéfinies [[#RAD_TO_DEG|RAD_TO_DEG]] et [[#DEG_TO_RAD|DEG_TO_RAD]].
Pour une '''rotation''' de 30 degrés autour de l'axe X par exemple :

<div id="box"><div style="padding: 0.5em">
{| cellpadding=0 cellspacing=0
|-
|rotation rot30X ||= {{LSLG|llEuler2Rot}}(<30, 0,0> * DEG_TO_RAD);||// convertit les degrés en radians, puis convertit ce {{LSLG|vector}} en une rotation, rot30x
|-
|{{LSLG|vector}} vec30X ||= {{LSLG|llRot2Euler}}(rot30X );||// retransforme la rotation en un {{LSLG|vector}} (avec les valeurs en radians)
|}
</div></div>

== Rotations Locales ou Globales ==

Les rotations '''Locales''' sont effectuées autour des axes de l'objet lui-même, dans les directions avant/arriere, droite/gauche et bas/haut, quelque soit l'orientation de l'objet dans le monde qui l'entoure. Les rotations '''Globales''' sont effectuées autour des axes du monde, Nord/Sud, Est/Ouest, plus haut/Plus bas.
Vous pouvez visualiser la différence en faisant tourner un prim, puis en le modifiant, et en changeant les réglages d'axes entre local et global : regardez comment les flèches de couleur changent.

Dans LSL, la différence entre une rotation '''locale''' ou '''globale''' réside dans l'ordre dans selon lequel les '''rotations''' seront traitées dans le state.

Ce script effectue une rotation '''locale''' en plaçant une constate '''rotation''' de 30° à gauche de la '''rotation''' de l'objet. C'est identique à la première opération effectuée dans l'exemple précédent, cela fait pivoter la flèche autour de son axe long.

<div id="box"><div style="padding: 0.5em">
{| cellpadding=0 cellspacing=0
|-
|rotation localRot = ||rot30X * myRot;||// effectue une rotation locale en multipliant une constante de rotation par une rotation dans le monde.
|}
</div></div>

Pour effectuer une rotation '''globale''', utiliser les mêmes valeurs '''rotation''', mais dans l'ordre opposé. Cela correspond à la seconde rotation du deuxième exemple, avec la flèche qui qui pivote vers le haut et la droite autour de l'axe X du monde.

<div id="box"><div style="padding: 0.5em">
{| cellpadding=0 cellspacing=0
|-
|rotation globalRot || = myRot * rot30X;||// effectue une rotation globale en multipliant une rotation dans le monde par une constante de rotation.
|}
</div></div>

== Another way to think about combining rotations ==

You may want to think about this '''local''' vs '''global''' difference by considering that '''rotations''' are done in evaluation order, that is left to right except for parenthesized expressions.

In the localRot case, what happened was that starting from <0, 0, 0>, the rot30X was done first, rotating the prim around the world X axis, but since when it's unrotated, the local and global axes are identical it has the effect of doing the rotation around the object's local X axis. Then the second '''rotation''' myRot was done which rotated the prim to its original rotation, but now with the additional X axis rotation baked in. What this looks like is that the prim rotated in place around its own X axis, a '''local''' rotation.

In the globalRot case, again starting from <0, 0, 0>, first the object is rotated to its original rotation, but the object's axes and the world's axes are no longer aligned! So, now the second '''rotation''' rot30x does exactly what it did in the local case, rotates the object 30 degrees around the world X axis, but the effect is to rotate the object through a cone around the world X axis since the object's X axis and the world's X axis aren't the same this time. What this looks like is that the prim pivoted 30 degrees around the world X axis, hence a '''global''' rotation.

'''Division''' of '''rotations''' has the effect of doing the rotation in the opposite direction, multiplying by a 330 degree '''rotation''' is the same as dividing by a 30 degree '''rotation'''.

==Using Rotations ==

You can access the individual components of a '''rotation''' '''R''' by '''R.x, R.y, R.z, & R.s''' ('''not''' R.w). The scalar part R.s is the cosine of half the angle of rotation. The vector part (R.x,R.y,R.z) is the product of the normalized axis of rotation and the sine of half the angle of rotation. You can generate an inverse '''rotation''' by negating the x,y,z members (or by making the s value negative). As an aside, you can also use a '''rotation''' just as a repository of {{LSLG|float}} values, each '''rotation''' stores four of them and a {{LSLG|list}} consisting of '''rotation''' is more efficient than a {{LSLG|list}} consisting of {{LSLG|float}}s, but there is overhead in unpacking them.

<div id="box"><div style="padding: 0.5em">
{| cellpadding=0 cellspacing=0
|-
|rotation rot30X ||= {{LSLG|llEuler2Rot}}(<30, 0,0> * [[#DEG_TO_RAD|DEG_TO_RAD]] );||// Create a rotation constant
|-
|rotation rotCopy ||= rot30X;||// Just copy it into rotCopy, it copies all 4 float components
|-
|float X ||= rotCopy.x;||// Get out the individual components of the rotation
|-
|float Y ||= rotCopy.y;||
|-
|float Z ||= rotCopy.z;||
|-
|float S ||= rotCopy.s;||
|-
|rotation anotherCopy ||= <X, Y, Z, S>;||// Make another rotation out of the components
|}
</div></div>

There is a built in constant for a zero '''rotation''' [[#ZERO_ROTATION|ZERO_ROTATION]] which you can use directly or, if you need to invert a '''rotation R''', divide [[#ZERO_ROTATION|ZERO_ROTATION]] by '''R'''. As a reminder from above, this works by first rotating to the zero position, then because it is a divide, rotating in the opposite sense to the original '''rotation''', thereby doing the inverse rotation.
<div id="box"><div style="padding: 0.5em">
{| cellpadding=0 cellspacing=0
|-
|rotation rot330X ||= <-rot30X.x, -rot30X.y, -rot30X.z, rot30X.s>;||// invert a rotation - NOTE the s component isn't negated
|-
|rotation another330X ||= [[#ZERO_ROTATION|ZERO_ROTATION]] / rot30X;||// invert a rotation by division, same result as rot330X
|-
|rotation yetanother330X ||= <rot30X.x, rot30X.y, rot30X.z, -rot30X.s>;||// not literally the same but works the same.
|}
</div></div>

==Single or Root Prims vs Linked Prims vs Attachments ==

The reason for talking about single or linked prim rotations is that for things like doors on vehicles, the desired motion is to move the door relative to the vehicle, no matter what the rotation of the overall vehicle is. While possible to do this with global rotations, it would quickly grow tedious.
There are generally three coordinate systems a prim can be in: all alone, part of a {{LSLG|linkset}}, or part of an {{LSLG|attachment}}. When a prim is alone, i.e., not part of a {{LSLG|linkset}}, it acts like a root prim; when it is part of an {{LSLG|attachment}}, it acts differently and is a bit broken.

{{LSLRotGetSet}}

==Rotation de Vecteurs ==

Dans LSL, faire pivoter un {{LSLG|vector}} est très utile quand vous voulez faire bouger un objet suivant un arc de cercle, mais que le centre de la rotation n'est pas le centre de l'objet.

Ca peut sembler très compliqué, mais c'est beaucoup plus simple qu'il n'y paraît.
Rappelez vous de la partie ci dessus sur la rotation de [[#Combining Rotations|dart]], et remplacez la flèche par un {{LSLG|vector}} dont l'origine est la queue de la flèche, et dont les composants X, Y, and Z indiquent la position de la pointe de la flèche. Faire tourner la flèche autour de sa queue fait bouger sa pointe suivant un arc dont le centre est la queue de la flèche. De la même façon, faire tourner un {{LSLG|vector}} qui représente un décalage par rapport au centre du prim le fait pivoter suivant le meme arc.
L'objet pivote autour d'une position qui est décalée par rapport au centre du prim par le {{LSLG|vector}}.

<div id="box"><div style="padding: 0.5em">
{| cellpadding=0 cellspacing=0
|-
|rotation rot30X ||= {{LSLG|llEuler2Rot}}(<30, 0,0> * [[#DEG_TO_RAD|DEG_TO_RAD]] );||// crée une constante de rotation, 30 degrés autour de l'axe X
|-
|vector offset ||= <0, 1, 0>;||// décale d'un mètre dans la direction Y positive
|-
|vector rotatedOffset || = offset * rot30X;||// fait tourner le vecteur décalé pour obtenir le mouvement donné par la rotation
|-
|vector newPos || = {{LSLG|llGetPos}}() + rotatedOffset;||// fait bouger le prim en fonction du vecteur décalé et tourné
|}
</div></div>

'''Nota Bene:''' Ceci est un mouvement, donc prenez garde aux problèmes qui se posent lorsqu'un objet est bougé hors du monde, sous le sol, de plus de 10 mètres, etc...

== Constantes ==
=== [[ZERO_ROTATION]] ===
ZERO_ROTATION = <0.0, 0.0, 0.0, 1.0>;<br/>
Une constante de rotation correspondant à un angle d'Euler de <0.0, 0.0, 0.0>.

=== [[DEG_TO_RAD]] ===
DEG_TO_RAD = 0.01745329238f;<br/>
Une constante float qui donne l'angle en radians quand on la multiplie par l'angle en degrés.
A float constant that when multiplied by an angle in degrees gives the angle in radians.

=== [[RAD_TO_DEG]] ===
RAD_TO_DEG = 57.29578f;<br/>
Une constante float qui donne l'angle en degrés quand on la multiplie par l'angle en radians.

[[Category:LSL_Types/fr|Rotation]][[Category:LSL_Math/fr]][[Category:LSL_Math/3D/fr]][[Category:LSL_Constants/fr]]

Rotation/fr

2007-12-04T17:09:40Z

Samia Bechir: /* Constants */

{{Multi-lang}}
{{LSL Header}}{{RightToc}}

'''***** PAGE EN COURS DE TRADUCTION PAR SAMIA *****'''

=Rotations=
Le type LSL '''rotation''' est utilisé pour représenter une orientation en 3D (nous nous efforçons d'écrire le nom des types en '''gras''').
Une orientation, ou angle en 3D, est représentée par un objet mathématique appelé un {{LSLG|quaternion}}. Considérons les quaternions comme un ensemble de 4 nombres, dont trois représentent la direction à laquelle l'objet fait face et la quatrième son pivotage vers la droite ou vers la gauche autour de cette direction. Le principal intérêt d'utiliser les quaternions est qu'ils ne sont pas sujets à la perte de degré de liberté ([http://fr.wikipedia.org/wiki/Gimbal_Lock gimbal lock]).
Pour le fonctionnement interne complexe des mathématiques des quaternions, voir {{LSLG|quaternion}}.
Pour une liste de fonctions ou d'évènements liés aux rotations, voir {{LSLG|Rotation Synopsis}}.
Il y a aussi des informations sur la façon de faire tourner des textures sur la page {{LSLG|texture}}s.

==Autres représentations==
Une autre façon de représenter une rotation est d'utiliser 3 nombres, <X, Y, Z>, qui représentent de combien (en [[radians]]) l'objet tourne autour de trois axes. C'est par exemple utilisé dans la fenêtre de modification et est généralement facilement visualisé par les gens. Notez que ces trois nombres sont de type '''vector''' et non de type '''rotation''', bien que cela puisse représenter la même information. On appelle cela les rotations d'Euler.

Une troisième façon de faire est d'utiliser trois vecteurs, qui vont indiquer vers où sont orientés l'avant, le dessus et le coté gauche. En réalité, il n'y a besoin que de deux de ces vecteurs, le troisième découlant des deux premiers.

Il y a de bonne raisons de préférer la version à quatre nombres, la '''rotation''', bien qu'elle soit plus compliquée à s'approprier pour des débutants. Il existe des fonctions qui permettent de convertir facilement d'une représentation à une autre.

==La règle de la main droite==
Dans LSL, toutes les rotations sont effectuées suivant la '''règle de la main droite'''. Avec votre main droite, pointez l'index vers la direction de l'axe X positif, le majeur à angle droit de l'index pointera alors en direction de l'axe Y positif, et le pouce, à angle droit des deux autres, pointera vers l'axe Z positif.
Lorsque vous modifiez un objet, les trois flèches de couleur pointent vers le coté positif de chacun des axes (X rouge, Y vert, Z bleu).

[http://fr.wikipedia.org/wiki/Règle_de_la_main_droite Règle de la main droite]

Gardez votre main en position, c'est utile pour autre chose : trouver de quel côté est l'axe positif. Fermez le poing et sortez le pouce en direction du coté positif de l'axe qui vous intéresse. Vos autres doigts sont repliés dans le sens des axes positifs. Les rotations autour des axes X, Y et Z sont géréralement appelées roulis, tangage et lacet, en particulier lorsqu'il est question de véhicules.

[http://fr.wikipedia.org/wiki/Pilotage_d%27un_avion Roulis, tangage et lacet]

==Dans le monde ou localement==
Il est important de différencier les '''rotation'''s relatives au monde et la '''rotation''' relatives à l'objet lui-même.
Dans la fenetre de modifications, vous pouvez passer de l'une à l'autre. Dans un script, il faut convertir l'une en l'autre pour obtenir le comportement souhaité.

Pour scripter la '''rotation''' d'un prim non lié, utiliser :

<div id="box"><div style="padding: 0.5em">
{| cellpadding=0 cellspacing=0
|-
|rotation myRot ||= {{LSLG|llGetRot}}();||// charge la rotation par rapport au monde dans myRot
|}
</div></div>

== Rotations combinées ==

Pour combiner des '''rotations''', on utilise les opérateurs '''multiplier''' et '''diviser'''.
Ne pas utiliser les opérateurs addition ou soustraction, qui ne donneront pas le résultat attendu.
L'opération '''multiplier''' s'applique à la rotation dans la direction positive, l'opération '''diviser''' effectue une rotation négative.
Il est également possible d'obtenir une rotation négative directement, en utilisant le signe - : X.s = -X.s.

A l'inverse d'autres entrées comme {{LSLG|float}}, l'ordre dans lequel les opérations sont effectuées est important. [http://en.wikipedia.org/wiki/Commutative non-commutative].
La raison en est simple : l'ordre dans lequel on effectue des rotations est importante en RL.
Par exemple, si vous avez une flèche avec quatre plumes, qui commence à la rotation <0, 0, 0> avec sa queue comme origine, elle sera alignée sur l'axe X avec sa pointe dans la direction X positive, ses plumes seront alignées sur les axes Z et Y, et les axes de la fleche seront alignés sur les axes dans le monde.
Nous allons la faire tourner de 45 degrés autour de l'axe X et de 30 degrés autour de l'axe Y, mais en changeant l'ordre.

D'abord, après une rotation de 45° autour de l'axe X, la flèche sera toujours alignée le long de l'axe X, et l'aura pas bougé, elle aura simplement pivoté autour de son axe, donc les plumes seront à 45° des axes.
Ensuite, la faire tourner de 30° autour de l'axe Y la fera pointer de 30° vers le bas (par rapport à l'axe X - souvenez vous que la règle de la main droite fait qu'une rotation positive va vers le bas)
La flèche finit par être pointée de 30° vers le bas, sur le même plan vertical qu'au départ, mais en ayant pivoté sur elle même, ce qui fait que les plumes ne sont plus alignées vers le haut et le bas.

Si on effectue les modifications dans l'autre ordre, en commençant par une rotation de 30° sur l'axe Y, la flèche va pencher vers le bas par rapport au plan XY. Notez qu'elle n'est plus alignée par rapport à son axe X : Donc, son axe X et celui du monde ne sont plus alignés l'un par rapport à l' autre. Une rotation de 45° autour de l'axe X la fera pivoter autour de sa queue, la pointe tournera de 45° vers le haut et la droite en suivant un cône de 30° dont l'axe est aligné avec l'axe positif dans le monde.

Le résultat est clairement différent de celui de la premiere rotation, alors que seul l'ordre dans lequel les rotations ont été effectuées a changé.

Pour effectuer une rotation constante, vous devez définir une valeur '''rotation''', ce qui se fait en créant un {{LSLG|vector}} avec comme composants les angles X, Y, Z en radians (cela s'appelle un angle d'Euler), puis en le convertissant en '''rotation''' avec la fonction {{LSLG|llEuler2Rot}}.
Vous pouvez aussi créer directement une rotation native : la partie réelle est le cosinus de la motié de l'angle de rotation, et la partie vectorielle l'axe normalisé de rotation multiplié par le sinus de la moitié de l'angle de rotation.
Pour passer d'une rotation à un angle d'Euler, {{LSLG|vector}} utilise {{LSLG|llRot2Euler}}.

'''NOTE:''' les angles dans LSL sont en radians, pas en degrés, mais vous pouvez facilement les convertir avec les constantes prédéfinies [[#RAD_TO_DEG|RAD_TO_DEG]] et [[#DEG_TO_RAD|DEG_TO_RAD]].
Pour une '''rotation''' de 30 degrés autour de l'axe X par exemple :

<div id="box"><div style="padding: 0.5em">
{| cellpadding=0 cellspacing=0
|-
|rotation rot30X ||= {{LSLG|llEuler2Rot}}(<30, 0,0> * DEG_TO_RAD);||// convertit les degrés en radians, puis convertit ce {{LSLG|vector}} en une rotation, rot30x
|-
|{{LSLG|vector}} vec30X ||= {{LSLG|llRot2Euler}}(rot30X );||// retransforme la rotation en un {{LSLG|vector}} (avec les valeurs en radians)
|}
</div></div>

== Rotations Locales ou Globales ==

Les rotations '''Locales''' sont effectuées autour des axes de l'objet lui-même, dans les directions avant/arriere, droite/gauche et bas/haut, quelque soit l'orientation de l'objet dans le monde qui l'entoure. Les rotations '''Globales''' sont effectuées autour des axes du monde, Nord/Sud, Est/Ouest, plus haut/Plus bas.
Vous pouvez visualiser la différence en faisant tourner un prim, puis en le modifiant, et en changeant les réglages d'axes entre local et global : regardez comment les flèches de couleur changent.

Dans LSL, la différence entre une rotation '''locale''' ou '''globale''' réside dans l'ordre dans selon lequel les '''rotations''' seront traitées dans le state.

Ce script effectue une rotation '''locale''' en plaçant une constate '''rotation''' de 30° à gauche de la '''rotation''' de l'objet. C'est identique à la première opération effectuée dans l'exemple précédent, cela fait pivoter la flèche autour de son axe long.

<div id="box"><div style="padding: 0.5em">
{| cellpadding=0 cellspacing=0
|-
|rotation localRot = ||rot30X * myRot;||// effectue une rotation locale en multipliant une constante de rotation par une rotation dans le monde.
|}
</div></div>

Pour effectuer une rotation '''globale''', utiliser les mêmes valeurs '''rotation''', mais dans l'ordre opposé. Cela correspond à la seconde rotation du deuxième exemple, avec la flèche qui qui pivote vers le haut et la droite autour de l'axe X du monde.

<div id="box"><div style="padding: 0.5em">
{| cellpadding=0 cellspacing=0
|-
|rotation globalRot || = myRot * rot30X;||// effectue une rotation globale en multipliant une rotation dans le monde par une constante de rotation.
|}
</div></div>

== Another way to think about combining rotations ==

You may want to think about this '''local''' vs '''global''' difference by considering that '''rotations''' are done in evaluation order, that is left to right except for parenthesized expressions.

In the localRot case, what happened was that starting from <0, 0, 0>, the rot30X was done first, rotating the prim around the world X axis, but since when it's unrotated, the local and global axes are identical it has the effect of doing the rotation around the object's local X axis. Then the second '''rotation''' myRot was done which rotated the prim to its original rotation, but now with the additional X axis rotation baked in. What this looks like is that the prim rotated in place around its own X axis, a '''local''' rotation.

In the globalRot case, again starting from <0, 0, 0>, first the object is rotated to its original rotation, but the object's axes and the world's axes are no longer aligned! So, now the second '''rotation''' rot30x does exactly what it did in the local case, rotates the object 30 degrees around the world X axis, but the effect is to rotate the object through a cone around the world X axis since the object's X axis and the world's X axis aren't the same this time. What this looks like is that the prim pivoted 30 degrees around the world X axis, hence a '''global''' rotation.

'''Division''' of '''rotations''' has the effect of doing the rotation in the opposite direction, multiplying by a 330 degree '''rotation''' is the same as dividing by a 30 degree '''rotation'''.

==Using Rotations ==

You can access the individual components of a '''rotation''' '''R''' by '''R.x, R.y, R.z, & R.s''' ('''not''' R.w). The scalar part R.s is the cosine of half the angle of rotation. The vector part (R.x,R.y,R.z) is the product of the normalized axis of rotation and the sine of half the angle of rotation. You can generate an inverse '''rotation''' by negating the x,y,z members (or by making the s value negative). As an aside, you can also use a '''rotation''' just as a repository of {{LSLG|float}} values, each '''rotation''' stores four of them and a {{LSLG|list}} consisting of '''rotation''' is more efficient than a {{LSLG|list}} consisting of {{LSLG|float}}s, but there is overhead in unpacking them.

<div id="box"><div style="padding: 0.5em">
{| cellpadding=0 cellspacing=0
|-
|rotation rot30X ||= {{LSLG|llEuler2Rot}}(<30, 0,0> * [[#DEG_TO_RAD|DEG_TO_RAD]] );||// Create a rotation constant
|-
|rotation rotCopy ||= rot30X;||// Just copy it into rotCopy, it copies all 4 float components
|-
|float X ||= rotCopy.x;||// Get out the individual components of the rotation
|-
|float Y ||= rotCopy.y;||
|-
|float Z ||= rotCopy.z;||
|-
|float S ||= rotCopy.s;||
|-
|rotation anotherCopy ||= <X, Y, Z, S>;||// Make another rotation out of the components
|}
</div></div>

There is a built in constant for a zero '''rotation''' [[#ZERO_ROTATION|ZERO_ROTATION]] which you can use directly or, if you need to invert a '''rotation R''', divide [[#ZERO_ROTATION|ZERO_ROTATION]] by '''R'''. As a reminder from above, this works by first rotating to the zero position, then because it is a divide, rotating in the opposite sense to the original '''rotation''', thereby doing the inverse rotation.
<div id="box"><div style="padding: 0.5em">
{| cellpadding=0 cellspacing=0
|-
|rotation rot330X ||= <-rot30X.x, -rot30X.y, -rot30X.z, rot30X.s>;||// invert a rotation - NOTE the s component isn't negated
|-
|rotation another330X ||= [[#ZERO_ROTATION|ZERO_ROTATION]] / rot30X;||// invert a rotation by division, same result as rot330X
|-
|rotation yetanother330X ||= <rot30X.x, rot30X.y, rot30X.z, -rot30X.s>;||// not literally the same but works the same.
|}
</div></div>

==Single or Root Prims vs Linked Prims vs Attachments ==

The reason for talking about single or linked prim rotations is that for things like doors on vehicles, the desired motion is to move the door relative to the vehicle, no matter what the rotation of the overall vehicle is. While possible to do this with global rotations, it would quickly grow tedious.
There are generally three coordinate systems a prim can be in: all alone, part of a {{LSLG|linkset}}, or part of an {{LSLG|attachment}}. When a prim is alone, i.e., not part of a {{LSLG|linkset}}, it acts like a root prim; when it is part of an {{LSLG|attachment}}, it acts differently and is a bit broken.

{{LSLRotGetSet}}

==Rotating Vectors ==

In LSL, rotating a {{LSLG|vector}} is very useful if you want to move an object in an arc or circle when the center of rotation isn't the center of the object.

This sounds very complex, but there is much less here than meets the eye. Remember from the above discussion of rotating the [[#Combining Rotations|dart]], and replace the physical dart with a {{LSLG|vector}} whose origin is the tail of the dart, and whose components in X, Y, and Z describe the position of the tip of the dart. Rotating the dart around its tail moves the tip of the dart through and arc whose center of rotation is the tail of the dart. In exactly the same way, rotating a {{LSLG|vector}} which represents an offset from the center of a prim rotates the prim through the same arc. What this looks like is the object rotates around a position offset by the {{LSLG|vector}} from the center of the prim.

<div id="box"><div style="padding: 0.5em">
{| cellpadding=0 cellspacing=0
|-
|rotation rot30X ||= {{LSLG|llEuler2Rot}}(<30, 0,0> * [[#DEG_TO_RAD|DEG_TO_RAD]] );||// create a rotation constant, 30 degrees around the X axis
|-
|vector offset ||= <0, 1, 0>;||// create an offset one meter in the global positive Y direction
|-
|vector rotatedOffset || = offset * rot30X;||// rotate the offset to get the motion caused by the rotations
|-
|vector newPos || = {{LSLG|llGetPos}}() + rotatedOffset;||// move the prim position by the rotated offset amount
|}
</div></div>

'''Nota Bene:''' Doing this is a move, so don't forget about issues of moving a prim off world, below ground, more than 10 meters etc.

== Constantes ==
=== [[ZERO_ROTATION]] ===
ZERO_ROTATION = <0.0, 0.0, 0.0, 1.0>;<br/>
Une constante de rotation correspondant à un angle d'Euler de <0.0, 0.0, 0.0>.

=== [[DEG_TO_RAD]] ===
DEG_TO_RAD = 0.01745329238f;<br/>
Une constante float qui donne l'angle en radians quand on la multiplie par l'angle en degrés.
A float constant that when multiplied by an angle in degrees gives the angle in radians.

=== [[RAD_TO_DEG]] ===
RAD_TO_DEG = 57.29578f;<br/>
Une constante float qui donne l'angle en degrés quand on la multiplie par l'angle en radians.

[[Category:LSL_Types/fr|Rotation]][[Category:LSL_Math/fr]][[Category:LSL_Math/3D/fr]][[Category:LSL_Constants/fr]]