User:Daemonika Nightfire/Scripts/Grundlagen

Grundsaetzlicher Aufbau

Ja ich weiss, ziemlich bescheuert ein Bild von einem Script auf einer scripting Wiki zu zeigen. Aber, vergleichen wir mal das linke Bild mit dem rechten Bild, dann wird ersichtlich worauf ich hinaus will.

Bild 1 (LSL Script)	Bild 2 (Aktenschrank)
Die beiden Bilder sind ein Versuch eine sinnbildliche Vorstellung davon zu vermitteln, wie ein Event basierendes LSL Script strukturiert ist. Wenn wir uns vorstellen, das der default State (Tuerkies) der Aktenschrank selbst ist und die einzelnen Events (Blau) durch die Schubladen repraesentiert werden, brauchen wir nur noch die Befehle (Rot) in die Schubladen hinein legen. Jede Schublade (Event) stellt ein tatsaechliches Ereigniss dar, worauf das Script reagieren kann. Die Reihenfolge der Events ist nicht festgelegt, du kannst nach eigenen Beduerfnissen bestimmen an welcher stelle deine Events stehen sollen. Im direkten Vergleich ist es voellig egal welche Schublade oben steckt und welche unten. Innerhalb eines Events spielt die Reihenfolge jedoch eine sehr grosse Rolle. Weil ein Script im Event alles der Reihe nach von oben nach unten abarbeitet, kann es zu seltsamen bzw. falschen Ergebnissen fuehren, wenn die Reihenfolge nicht stimmt. Du kannst z.B. nicht mit einer ID arbeiten, wenn du sie nicht vorher abgefragt hast. Das Script auf der linken Seite kann mit der aktuellen konfiguration bis zum Sankt Nimmerleins Tag so stehen bleiben, ohne das irgend etwas passiert. Erst wenn jemand das Object clickt reagiert der touch_start Event und alles was sich darin befindet wird abgearbeitet.

Bestandteile

• Den modularen Aufbau eines Scriptes habe ich oben mit dem Aufbau eine Aktenschranks verglichen.
• Nun schauen wir uns noch einmal das obere linke Bild an. Dort habe ich die Formatierung senkrecht mit Farben gekennzeichnet, welche wir in einem richtigen Script so nicht zu sehen bekommen. Mir geht es in diesem Beispiel darum zu verdeutlichen, wie die Einrueckungen der einzelnen Module zu verstehen sind. In der ersten Spalte befindet sich ueblicherweise der State und in der zweiten Spalte die jeweiligen Events. Ab der dritten Spalte koennen wir uns im Grunde austoben, aber auch hier empfehle ich eine saubere Formatierung.
• Eine Ausnahme dieser Formatierung bilden global angelegte Funktionen & Variablen, welche dann fuer das gesamte Script gueltig sind. Details dazu findest du in den jeweiligen Tutorials fuer Variablen und Funktionen.

States ^{(Aktenschrank)}

• Der erste und wichtigste State (Status) welcher default genannt wird ist unser all umfassender Aktenschrank und sollte sich immer in der ersten Spalte unserer gedachten Tabelle befinden. Ohne diesen State geht gar nichts. Bei einem einfachen Script befindet sich direkt darunter eine geoeffnete klammer und ganz am Ende des Scriptes eine geschlossene, um den State abzuschliessen. In einem State kann sich immer nur ein gleichnamiger Event gleichzeitig befinden.
• Nun haben wir die Moeglichkeit, in einem Script mehrere Aktenschraenke uebereinander zu stellen. Das bedeutet, wir koennen mehrere States verwenden. Dabei ist es wichtig, das weitere States nicht default heissen, sondern state irgendwas und ebenfalls nur einmal pro Name existieren. In jedem weiteren State koennen wir dann jeden Event noch einmal pro Name verwenden.
• Weiter fuehrende informationen ueber States und ein Beispiel wie man im Script den State wechselt findest du hier: State.

Events ^(Schublade)

• Nun folgen die Events (Ereignisse), wofuer die zweite Spalte unserer gedachten Tabelle vorgesehen ist. Auch hier besitzt jeder einzelne Event eine eigene geoeffnete Klammer darunter und eine geschlossene Klammer, wo wir den Event enden lassen moechten.
• Einige Events reagieren auf Interaktion mit einem Avatar, andere koennen Automatisiert werden und wieder andere werden durch einen Befehl ausgeloest.
• Ab hier koennen in einem Event bereits Befehle verwendet werden, welche dann in der Regel automatisch in die dritte Spalte eingerueckt werden, wie man oben auf dem linken Bild schon erkennen kann.
• Natuerlich gibt es auch hierzu weiter fuehrtende Informationen: Events

Bedingungen ^{(Akten-Mappe)}

• Die einfachsten Bedingungen sind if, else if & else. Sinngemaess vergleiche ich das immer mit Frage, andere Frage & alles andere.
• Bedingungen reihen sich ebenfalls schon ab der dritten Spalte in unser Script ein, Befehle die sich in einer Bedingung befinden, ruecken darin automatisch in die vierte Spalte.
• Vorsicht mit der else, grunsdaetzlich sehe ich diese Bedingung in Second Life als unsauberen Programmierstiel und potentielle Fehlerquelle an. Die else sollte man nur dann verwenden, wenn man explizit wuenscht jede weitere moegliche Bedingung als nicht zutreffend zu definieren. Das bedeutet, die Verwendung von if & else if sind voellig ausreichend und lassen dem Script keinen Spielraum fuer Reaktionen bei falschen Anforderungen.
• Weitere Informationen zu diesem Thema sind im folgenden Link: if

Befehle ^(Dokument)

• Befehle sind die ausfuehrbaren Anweisungen unserer Scripte, und koennen sich schon ab der dritten Spalte im Script einreihen.
• Wenn wir uns die Befehle mal genauer ansehen, stellen wir fest, das sie sich abgesehen vom ll am Anfang auch in der Schreibweise gleichen. Grundsaetzlich sind in den Befehlen die Anfangsbuchstaben der einzelnen Woerter Gross geschrieben und die einzelnen Woerter weisen darauf hin, was der Befehl im Grunde macht.
• Nehmen wir uns als Beispiel mal das Get, heisst es wir bekommen einen Wert, bei dem Set setzen wir bestimmte Parameter, bei einem Detected wird etwas erkannt. Natuerlich gibt es noch viel mehr, doch das sollte fuer den Anfang erst einmal reichen, um einen kleinen Ueberblick auf der Functions Seite zu erhalten.
• Wenn ein Befehl richtig geschrieben wird aendert er automatisch die Farbe in Rot, danach musst du lediglich mit der Maus darauf zeigen, um eine kleine Info zu erhalten, welche Variablen der jeweilige Befehl erfordert.

Variablen ^(Inhalt)

• Wir haben sieben verschiedene Variablen, dessen Bedeutung im Grunde durch die jeweiligen Befehle bestimmt wird. Ob ein vector nun eine Farbe oder eine Koordinate ist, erkennst du eigentlich erst im Zusammenhang mit dem Befehl.
• Die Kategorie der Variablen selbst ist festgelegt und immer in dunkel-gruen dargestellt, doch bei den Bezeichnungen (Namen) dahinter haben wir sehr grossen Spielraum. Natuerlich macht es Sinn, Bezeichnungen zu waehlen die auf den Verwendungszweck deuten. In der folgenden Tabelle habe ich Bezeichnungen gewaehlt, die deutlich machen um was fuer eine Variable es sich genau handelt.

Variable	Beispiel	Info
string Text =	"bla bla bla";	Kommunikation
integer Ganzzahl =	1;	Optional begrenzt, beachte die Limits (Channel: -2147483648, 0, 2147483647)
float Kommazahl =	1.0;	Optional begrenzt, beachte die Limits (siehe vector)
vector Koordinate =	<1.00000, 1.00000, 1.00000>;	Optional begrenzt, beachte die Limits (Objects: min. <0.01, 0.01, 0.01> max. <64.0, 64.0, 64.0>)
rotation Quaternion =	<0.00000, 0.00000, 0.00000, 1.00000>;	Migraene Quaternion / Mit diesem Converter geht das leichter. (Lass den Server rechnen.)
key UUID =	"61ee201a-81cf-4322-b9a8-a5eb8da777c2";	Ein Key/UUID (universal unique identifier) kann alles sein LSL_Key
list Liste =	["bla bla bla", 1, 1.0, <1.00000, 1.00000, 1.00000>, <0.00000, 0.00000, 0.00000, 1.00000>, "61ee201a-81cf-4322-b9a8-a5eb8da777c2"];

• Zum Thema Gueltigkeit von Variablen findest du hier ausfuherliche Beispiele: Variable Tutorial