• Bitte schaltet eure Ad Blocker aus. SLinfo kann nur betrieben werden, wenn es durch Werbung Einnahmen erzielt. Vielen Dank!!
  • Wir freuen uns, wenn du dich in unserem Forum anmeldest. Bitte beachte, dass die Freigabe per Hand durchgeführt wird (Schutz vor Spammer). Damit kann die Freigabe bis zu 24 Stunden dauern.
  • Wir verwenden Cookies, um Inhalte und Anzeigen zu personalisieren, Funktionen für soziale Medien anbieten zu können und die Zugriffe auf unsere Website zu analysieren. Sie geben Einwilligung zu unseren Cookies, wenn Sie unsere Webseite weiterhin nutzen.

Wie lernt man LSL am besten?

Carla Collazo

Aktiver Nutzer
Hallo, ich kann nicht viel LSL, ich glaube, mir fehlt die Begabung und wenn etwas sehr schwer ist, dann zieht es einen natürlich eher zu anderen Dingen. Aber zumindest habe ich es so weit gebraucht, dass ich die einfacheren Scripte, die im Umlauf sind, lesen kann und so abändern wie ich sie brauche. Das ist für meinereins schon viel. Wie?

- Es gibt noch gratis Kurse. Ich war bei den NCI-Kursen, sind Englisch. Da lernt man Englisch beiläufig gleich mit, ist doch nicht so schlecht.
- Scripte besorgen, probieren, probieren, probieren
- Nachfragen: In den Scripter-Gruppen und auch einmal hier. Aber zum Nachfragen sollte man sich schon damit beschäftigt haben, dass man auch weiß, was man wissen will und mit der Antwort was anfangen kann. Die Frage: "Ich will ein Script machen, das bügelt, abwäscht und die Zeitung holt, wie mache ich das?" beantwortet wohl keiner gern. Wenn man sagt: "Ich habe ein Script, das bügelt, abwäscht und die Zeitung holt, aber es legt mir die Zeitung verkehrt herum auf den Tisch, ich glaube, da ist ein Fehler in Zeile 46, bitte schaut Euch das einmal an", dann kann man meist auch mit Hilfe rechnen. Zumindest meine Erfahrung.

Geld habe ich keins gebraucht. Kurse waren mir ein Trinkgeld wert, wenn nicht, fliegt man aber auch nicht raus. Lesen und probieren kostet nichts, wenn man höflich und sinnvoll fragt, kriegt man auch Antworten. Also, Geld ist imho nicht das Problem.
 

Baertram Beerbaum

Aktiver Nutzer
LSL lernt man, wie jede andere Programmiersprache, am besten in kleinen Schritten.

Ich habe einige erlebt, die versucht haben ohne jede Kenntniss ein großes Projekt umzusetzt. Das war dann immer schwer bis verzweifelt unmöglich.

Deshalb kleine Schritte.
Hier einige Beispiele auf der Basis eines einfachen Primes.

- "Hello world" prime spricht mit allen, dann mit dem Owner, und dann per IM beim rezzen
- "Hello World 2" prim spricht bei Touch und anderen events
- Prime lernt das Hören dann das differenzierte Hören
- Primeveränderung (Farbe, Größe, etc) durch Events

Dabei ist das lsl Wiki auf einem zweiten Monitor sehr hilfreich.

Wenn man die ersten Grundlagen !!! ausprobiert !!! hat, ist es dann Zeit sich einmal querlesend durchs Wiki zu wühlen um einen groben Überblick über die möglichen Funktionen zu bekommen.

Einige versuchen immer freie Scripte zu nutzen und zu verändern. Das führt zwar schneller zu Ergebnissen, aber man lernt halt nicht wirklich etwas. Die wenigsten Scripte sind sauber dokumentiert und ohne Dokumentation und ohne echte LSL Kenntnisse ist es oft sehr schwer die Funktionsweise nachzuvollziehen.
Aus gut dokumentierten Beispielscripten kann man aber viel lernen wenn man sich vorher die nötigsten Grundlagen erarbeitet / erspielt hat.

Was wichtig ist, man muss sich die Zeit dafür nehmen. Programmieren lernt man nicht im Vorbeigehen, für die Meisten ist es Arbeit.
 

Miyo Darcy

Nutzer
Einige versuchen immer freie Scripte zu nutzen und zu verändern. Das führt zwar schneller zu Ergebnissen, aber man lernt halt nicht wirklich etwas.

Ich finde man lernt schon sehr viel daraus. Ok evtl unter der vorraussetzung das man schon etwas vorwissen hat. Aber man lernt wirklich viel daraus.

Ich finde besonders einfach haben es diejenigen, welche sich zu DOS Zeiten noch ihre autoexec.bat, config.sys oder irgendwelche anderen batch dateien geschrieben haben. Da ist dann meist schon ein generelles Gefühl dafür da, wie ein Computer Befehle interpretiert.

Kommt es dann noch dazu, das man wie in meinem Fall von einem Freund einige Schritte qBasic und VisualBasic in der Vergangenheit beigebracht bekommen hatte und dies evtl. in einer Schule sogar noch vertieft hat (EDV Unterricht), dann kann man einen riesen Schritt überspringen wenn man eine neue Sprache wie LSL erlent. Und zwar genauer gesagt das ganze Vorgeplänkel wie "Wie versteht dich ein Computer eigentlich?", "0 und 1? Wo ist der Unterschied?", "Was ist eigentlich eine Funktion für den Computer?" usw.

Die meisten meiner Freunde mit ähnlicher Vorgeschichte, verstehen heute Codefetzen sehr wohl, so das einige dieser auch Modder in größeren Spielen geworden sind (Mein Bruder z.B bei Victoria 2 und Hearts of Iron 3, wo der nicht-hardprogrammierte Code je nach Datei ähnlichkeit mit LUA und C hat).

Ich habe auch bei mehreren Spielen schon Codeschnippsel verändert und konnte einiges daraus lernen.Anfangs waren mir solche snippets immer fremd wenn ich mal in einer Datei rumgeluschert habe. Heute jedoch ist es mir garnicht mehr so fremd sondern oftmals kann ich Code sogar schon wie eine englische Geschichte sehr gut verstehen. Teilweise sogar bei neuen Dateien bzw. Sprachen die ich so vorher noch nicht kannte (kürzlich LUA wegen World of Warcraft).

Wenn man also die Struktur eines Programmes verstanden hat.. (Scopes, Events, Trigger & Functions usw.), und die weiteren Elemente, dann würde ich dir leider widersprechen und behaupten das man damit eine große Menge bewegen kann. Denn Funktionen und all das kann man sich einfach aus jedem Wiki oder aus einer API besorgen. Nur allein damit und mit wenig Programmierkenntnissen lassen sich bereits Welten bewegen. :mrgreen:

Zurück zu Second Life bin ich der Meinung das diese "Freebie Scripts" sehr hilfreich sind. Meiner Meinung nach sogar teilweise aufschlussreicher als die vielen Guides die es gibt. Versteht mich nicht falsch.. es gibt sehr gute Guides. Aber dann gibt es auch wieder die Guides, welche sich gleich am Anfang über 4 Seiten mit "zuanfangs" erstmal völlig irrelevanten Konzepten beschäftigt, die der "Schüler" so oder so noch nicht verstehen kann weil im das gesamte Vokabular noch fehlt. Ich rede hier über die Guides die gleich in der ersten Zeile mit Vokabeln wie "Trigger, Scopes.. oder auch Variablen usw" anfangen.

Es gibt Guides die machen gleich am Anfang so eine große Wissenschaft daraus, das der Leser eher Frust statt Lust zum lernen bekommt.

Das muss meiner Meinung nach irgendwie anders funktionieren. Viel besser Funktioniert das lernen da meiner Meinung nach mit Guides die ein Script posten welches in den weiteren Schritten erklärt werden. Also halb Theorie und halb Praxis. Also dinge die man sich gleich in ein Objekt packen kann um überhaupt zu sehen was passiert um sie mit der Theorie danach dann zu verstehen.

Ich bin der Meinung selbst ein simples "HelloWorld" programm würde der Leser im Leben nicht verstehen, wenn er den Code nicht auch ausprobieren könnte. Wenn man darüber gleich mit einer Seite Theorie beginnt ohne einmal etwas vom Code zu zeigen, dann wachsen böhmische Wälder.
Und leider hab ich sehr viele Guides gesehen, die genau so beginnen.

Pure Praxis hilft aber oft auch nicht. Das muss ich zugeben. Ich habe den 100% Praxis Schritt gewählt und Code verstehe ich heut teilweise. Leider dann aber auch oft nur teilweise so das ich mir Schnipsel aus irgendwelchen Wikis zusammen bauen kann, aber ein Code nicht von Grund auf selbst bauen kann. Mir fehlt also die oben erwähnte Wissenschaft, die ich eigentlich nicht mag. Den theoretischen Teil sollte ich nun also schleunigst Nachholen, und wenn ich das tun würde, könnte sich mein "potential" vermutlich erst entfalten. :mrgreen:

Das alles schreib ich also nun als jemand der Code lesen und oft verstehen kann (zur not auch mit hilfe von Api/Doku/Wiki), aber einen reinen Code von 0 auf nicht selbst schreiben kann.

Die wenigsten Scripte sind sauber dokumentiert und ohne Dokumentation und ohne echte LSL Kenntnisse ist es oft sehr schwer die Funktionsweise nachzuvollziehen.

Wie oben etwas zu ausführlich beschrieben, bin ich da der gegenteil Meinung. Verstehen kann man die dinge oft wunderbar, nur hilft das alles nicht zu lernen den Code mal ganz alleine ohne Templates zu schreiben. Da liegt jetzt mein Problem und deswegen muss ich wenn ich will die Theorie nun bald mal nachholen.

Aus gut dokumentierten Beispielscripten kann man aber viel lernen wenn man sich vorher die nötigsten Grundlagen erarbeitet / erspielt hat.

Da stimme ich dir dann total zu. Ich glaub das ist sogar der beste Weg.

Was wichtig ist, man muss sich die Zeit dafür nehmen. Programmieren lernt man nicht im Vorbeigehen, für die Meisten ist es Arbeit.

Geb ich dir auch recht. Wobei man auch Lust haben sollte. Die "Lust" sollte sogar noch mehr im Vordergrund stehen als die Zeit.

Ich spiele seit über 18 Jahren Gitarre und bringe gerade meiner kleinen Schwester das Gitarre spielen bei.

Das Problem ist, das sie etwas merkwürdige Gründe hat, warum sie das gerne lernen würde. Sie ist in einer Klicke wo die Leute Rock- bzw, Gitarrenmusik hören.
Irgendwie hab ich das Gefühl sie will es nur deshabl lernen um einen gewissen Status in der Klicke zu erhalten. Es kommt mir vor als würde sie es für andere lernen wollen, statt für sich selbst.

Ich kann bisher noch nicht erkennen das sie selbst daran lust empfindet. "Es wäre zu cool wenn ich meinen Freunden was vorspielen könnte".. sie sieht es also als modischen Aspekt. Und genau das ist falsch.

Jetzt hat sie mitbekommen das es Zeit kostet um zu lernen. Sie merkt jetzt das nicht in einem Jahr schafft. Ich hab ihr auch erzählt das man es nichtmal in 18 Jahren schafft. Man könnte das ganze Leben lernen. Die Frage ist nur ob man das will. Ob man es dann überhaupt noch als "lernen" bezeichnet, oder eher als "spaß haben am Spielen".

Letzteres fehlt bisher bei ihr. Und ich weiß es jetzt schon... sie wird aufgeben. Freiwillig fragt sie mich schon nicht mehr. Ich muss sie rufen mittlerweile. Es ist für sie "lernen".. nicht "lust daran haben".

Ob ich also etwas als "arbeiten" oder "vergnügen"... als "lernen" oder "spielen" ansehe, das allein macht schon den gewissen unterschied. Genau das zeigt schon ob man es wirklich will oder nicht.

Ist es eine qual die man überstehen muss um dann später im Mittelpunkt zu stehen? Oder ist es etwas lustiges was einem bereits zu anfang schon spaß macht?

Das alleine sollte man sich bei allem Fragen. Wenn man auf diese Frage mit einem Wohlbefinden antworten kann, dann tut man gerade genau das, was einem wichtig ist. Man hat freude daran und wenn man es nun auch noch vertieft, dann wird man noch viel mehr Freude daran haben. Unendlich viel Freude.

Das schreib ich als Gittaristin und nicht als Scripterin (Was ich eh noch nicht so wirklich bin) :mrgreen: Aber ich dachte diese Theorie würde hier passen.

Entschuldigt meinen etwas zu langen Text. Das kann bei mir mal schnell passieren wenn ich ein Thema interessant finde.

Sicher hätte es auch kürzer sein können. Aber ich rede und schreibe nunmal sehr gerne. Ich mag eine leichte briese Philosophie. Hoffe es hat niemanden gestört. :)
 

Shirley Iuga

Forumsgott/göttin
Meiner Erfahrung (Tutor/Betreuer für Erstsemester ohne Erfahrung im Programmieren) nach lernt man das Programmieren am leichtesten, wenn man zuerst mal kurz die Grundlagen durchgeht.

Also z.B. "Was ist ein String oder ein Float oder ein Integer", "was haben Integer mit den Natürlichen Zahlen zu tun und Floats mit den Rellen". Dabei gehts nicht darum einen Float samt Mantisse und Exponent manuell berechnen zu können, man sollte nur grob wissen mit welchen Dingern man es in Programmen generell und überhaupt zu tun hat. Einfach mal 10 bis 15 Minuten (oder auch mehr, je nach dem eben) das ganze in Beispielscripten ansehen/im Wiki durchlesen, wie auch immer. Anschließend sollte man sich ein noch klein bisschen mit den Strukturen in den Programmen beschäftigen, also z.B. "was bedeuten diese ganzen Klammern", "was ist ein Event" (in LSL), "was ist ein State" (in LSL), "was ist eine if-Anweisung und was ist eine for-Anweisung". Auch da wirklich nur die grundlegendsten Grundlagen und am besten mit Beispielprogrammen ansehen und z.B. in einem guten Editor die jeweils zusammengehörenden Klammern zeigen. Einfach damit man weiß was so eine Klammer ist.

Man muss zwar nicht ins Detail gehen, aber man sollte schon grob vestehen wie die imperative Programmierung z.B. in C#, Java oder LSL, bei der Schritt für Schritt genau vorgegeben wird was genau ein Programm machen soll so generell funktioniert. Grobes Verständnis fürs Programmieren an sich, keine 100 Details und Tricks und Hacks. Es geht nicht darum binäre Suchbäume zu verstehen, oder gar die Notation kontextfreier Grammatiken, sondern einzig und allein darum einfach die generelle Grundstrukturen in Programmen an sich mal gesehen zu haben. Und mehr als eine Stunde oder so sollte man das ganze "grundlegende Basics"-Programm auch nicht machen. Es geht schließlich nicht darum, das danach alles zu kennen und zu können. Nur, wie gesagt, darum sowas mal gesehen zu haben.

Und wer schon mal mit irgendwelchen ähnlichen Programmiersprachen zu tun hatte, der kann bis hier her alles überspringen, einfach weil er das alles schon kennt.

Mit diesem für das Programmieren lernen IMO unbedingt notwendigem Grundlagenwissen kann man dann hergehen und einfach mal irgendwelche LSL Scripte hernehmen (möglichst kurze zu Anfang..., z.B. das SL "Hello World" Script) analysieren und deren Funktionsweise in eigenen Worten oder mit einfachen Diagrammen und Ablaufplänen nachvollziehen. Dabei kann man dann auf die Klammern und States und Events auch im Detail eingehen. Natürlich tauchen dann immer wieder LSL-Funktionen auf die man nicht kennt, oder Events, die man noch nicht gesehen hat, aber da kann man einfach im Wiki nachsehen was z.B. die llSay() Funktion macht oder was ein "touch_start" event ist. Oder irgendwen fragen, der das weiß.

Zu diesem Zeitpunkt muss man aber noch überhaupt nicht in der Lage sein, selbst fehlerfreie Programme/Scripte zu schreiben, es geht vor allem darum erst mal andere LSL Programme zu verstehen. Wenn man dann mal das ein oder andere Programm auf diese Weise analysiert hat und damit ein gewisses Grundverständnis für die Programmierung entwickelt hat - und sich als Nebeneffekt dabei gleich ein bisschen an einen "sauberen" Programmierstil gewöhnt hat, d.h. an eine "saubere" Darstellung im Programmtext, dann kann man auch bald anfangen einfache Aufgaben komplett selbst zu lösen. Z.B. zwei Float Zahlen durch Zufall bestimmen und dann untersuchen welche die Größere ist.

Gleichtzeitig ist man durch das bereits gelernte mehr und mehr in der Lage, immer kompliziertere Scripte untersuchen zu können. Und nach und nach lernt man durch diese Analyse der fremden Scripte immer mehr Dinge kennen, mit denen man bisher nichts zu tun hatte. Sprungmarken/Returns, Scopes, Funktionen etc. pp. Irgendwann untersucht man dann die anderen Scripte nicht mehr auf deren Funktionsweise, sondern eher darauf, wie man das einfacher/besser/effektiver/mit weniger lag machen könnte. Und da kann man dann auch schon ganz passabel selbst scripten/programmieren.


Dieses "Befehl für Befehl auswendig lernen" oder auch das "Erst mal die Studies alles über Floats und deren exakte Umrechnung und Definition nach IEEE 754 lernen lassen" und sowas, das ist meiner Erfahrung nach ziemlich Kontraproduktiv, genau wie das aus der Luft gegriffene "Heute gehen wir if-Schleifen und dabei optimierte Suchstrukturen und Typ II-Grammatiken nach Chomsky durch". So etwas mag für den geübten Informatiker kein Problem sein (und das alles zu kennen wird im 2. Semester Informatik wohl auch als selbstverständlich vorausgesetzt), aber für einen Studi, der z.B. für Bio oder Linguistik (oder eben hier in SL) einfach nur bisschen programmieren können will, für den ist das schlicht ein Overkill.

Allerdings ist es bei dieser ganzen Programmiererei trotz alledem ähnlich wie mit dem Taschenrechner:

Selbst wenn man genau weiß wie man das Ding bedienen muss um da irgendwas auf dem Display anzuzeigen oder in einem Script etwas zu berechnen, z.B. das Ergebnis von "26 mod 5" oder den Wert von "cos 35°", bringt das alles nichts, wenn man keine Ahnung hat was das Modulo oder der Cosinus ist. Man muss sicher keine Differentialgleichungen lösen können oder mehrdimensionale Matrizen berechnen, aber wer z.B. in SL Prims mit Skripten gezielt rumschubsen will (etwa um einen Teleporter zu bauen), der kommt um die Grundlagen des 3D Vektorraums nicht wirklich herum. Wobei man sich auch das durchaus selbst in ein oder zwei Nachmittagen beibringen kann, das grundlegende Rechnen mit Vektoren ist in kleinen Schritten nicht halb so kompliziert wie es auf den ersten Blick aussieht. Und das gilt auch für die Trigonometrie, für das Modulo und ähnliche Basics in Mathe, die man eigentlich ständig braucht um mit seinen Scripten konkrete Probleme lösen zu können.
 

Shirley Iuga

Forumsgott/göttin
(...)Einige versuchen immer freie Scripte zu nutzen und zu verändern. Das führt zwar schneller zu Ergebnissen, aber man lernt halt nicht wirklich etwas. Die wenigsten Scripte sind sauber dokumentiert und ohne Dokumentation und ohne echte LSL Kenntnisse ist es oft sehr schwer die Funktionsweise nachzuvollziehen.
Aus gut dokumentierten Beispielscripten kann man aber viel lernen wenn man sich vorher die nötigsten Grundlagen erarbeitet / erspielt hat.
(...)

<SATIRE>
Gute Scripte brauchen keine Kommentare.
</SATIRE>

Aber mal im Ernst:

Eigentlich ist es genau umgekehrt.

Wenn man selbst ein klein bisschen knobeln muss was ein Script/Programm genau in jeder Zeile macht, dann kann man sich die Zusammenhänge in der Sprache letztendlich einfacher merken als bei einem Beispielscript, bei dem alles in Details in Kommentaren erklärt ist.

Einfach weil sich das Gehirn selbst gewonnene Erkenntnisse besser merken kann als einfach verkonsumierte Informationen, die man letztlich nur auswendig lernt.

Wichtig ist dabei nur, dass man den Code auch ein bisschen lesen kann, d.h. Spaghetticode und ähnlicher Murks taugt dafür leider nicht.
 

Johanna Burnstein

Freund/in des Forums
Meiner Erfahrung (Tutor/Betreuer für Erstsemester ohne Erfahrung im Programmieren) nach lernt man das Programmieren am leichtesten, wenn man zuerst mal kurz die Grundlagen durchgeht.

Also z.B. "Was ist ein String oder ein Float oder ein Integer"
[...]
Anschließend sollte man sich ein noch klein bisschen mit den Strukturen in den Programmen beschäftigen, also z.B. "was bedeuten diese ganzen Klammern", "was ist ein Event" (in LSL), "was ist ein State" (in LSL), "was ist eine if-Anweisung und was ist eine for-Anweisung".
[...]
Grobes Verständnis fürs Programmieren an sich, keine 100 Details und Tricks und Hacks. [...] sondern einzig und allein darum einfach die generelle Grundstrukturen in Programmen an sich mal gesehen zu haben.
[...]
Und wer schon mal mit irgendwelchen ähnlichen Programmiersprachen zu tun hatte, der kann bis hier her alles überspringen, einfach weil er das alles schon kennt.
[...]
Mit diesem für das Programmieren lernen IMO unbedingt notwendigem Grundlagenwissen kann man dann hergehen und einfach mal irgendwelche LSL Scripte hernehmen (möglichst kurze zu Anfang..., z.B. das SL "Hello World" Script) analysieren und deren Funktionsweise in eigenen Worten oder mit einfachen Diagrammen und Ablaufplänen nachvollziehen. Dabei

Seh ich genauso (Ich hab mal wild reingekürzt) bzw. Ich kenn es selber auch so. *)

Wie ist die Strucktur, der Aufbau eines Programmes? (Was sollen die ganzen Klammern da?)
Was sind die Werkzeuge? (Datentypen, Operatoren, Kontrollstrukturen, usw)
etc.

Deswegen kucke ich auch immer ein wenig skeptisch auf die üblichen "Hello World" Programme. Solange sie nicht als reine Motivation gedacht sind, konfrontieren sie den Lernenden mit Dingen über die er in dem Momment noch nichts weiss.
(z.B. Finden sich die Funktionen, die in den meisten "Hello World" Programmen zur Ausgabe eben dessen benutzt werden, oft erst recht weit hinten im Lehrmaterial/-plan.)
In folge dessen wird dann bereits im ersten Kapitel angefangen Sachen einfach "abzuschreiben", ohne zu verstehen was dort überhaupt passiert.

Von daher bin ich auch eine Verfechterin des "erstmal die Grundlagen". Auch wenn es erst etwas zäh, trocken und sehr theoretisch erscheint. Aber das praktische Lernen (Learning by doing) kann daran anschließen und vor allem sehr gut darauf aufbauen.

Ist in anderen (Lern) Bereichen nicht anders. In einer Küche wird man auch erstmal den Umgang mit den Werkzeugen Lernen (Gemüse Schneiden z.B.) bevor man an den Herd gelassen wird. Dadurch hat man bereits von begin an die Grundlagen drauf und es muss einem nicht jedesmal Schritt für Schritt erklärt werden wie man Gericht XYZ zubereitet. **)

.

*) auchmalalsübungsleiterindengeldbeutelaufgebessert

**) So jemanden kann man recht früh ein: "Für die Steakpfanne: Hier sind die Putentitt... äh, -brüste, nimmse' noch zwei Filets und ein Steak. Bratkatoffeln sind in der Schublade, Bohnen da. Bitteschön. Viel Spaß" um die Ohren hauen, und das Ding landet 10 Minuten später auf dem Pass.
....Und wenn der jenige sich nicht alzu dämlich angestellt hatt auch 2 Minuten später beim Gast und nicht im Schweineeimer. ;)
 

Users who are viewing this thread

Oben Unten