• 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.

Scripten Lernen (Deutsch)

Wer hat Interesse, Scripte zu verstehen?


  • Umfrageteilnehmer
    19
  • Umfrage geschlossen .
Da ich gestern mal nicht dabei war (Peter) habe ich hier zwei Anmerkungen zu der Prozedur "Suchen". Dies funktioniert alles, da das gesuchte Prim vorhanden ist.

Die Prozedur "Suchen" hat in dem Fall, dass das gesuchte Prim nicht vorhanden ist (Tippfehler oder was auch immer), zwei Probleme. Zum einen ist die Antwort in dem Fall nicht belegt. Es bleibt einfach der vorher vorhandene Wert erhalten. Zum anderen meine ich, dass der Schleifenzähler am Ende nicht mit "<=" sein darf, weil dann im letzten Durchlauf mit i = Anzahl_Links durchlaufen wird, was zum Fehler führt, da ja nur Links von 0 bis Anzahl_Links - 1 vorhanden sind. Es müßte auf "<" in der while-Bedingung geprüft werden.
 
huhu, das was du beschreibst sind wir gestern abend tatsaechlich durchgegangen und haben genau diese Fehler gehabt.
Nur < fuehrte zu dem Fehler, das der letzte Prim nicht gefunden wurde.
Mit <= funktionierte es, aber selbst mit <= kann man einen aehnlichen Fehler hebei fuehren, wenn man in der while die ++ hinter das i setzt.

Das die Schleife keine Nicht-Vorhandenheit beruecksichtig liegt einfach daran, das wir einen Prim mit dem richtigen Namen voraussetzen.
Wird in der Chat-Meldung der NULL_KEY zurueck gegeben, wissen wir gleich das kein prim gefunden wurde und nachgearbeitet werden muss.

Dann habe ich erklaert, das wir nicht mit 0 anfangen zu zaehlen, weil ein Linkset keine 0 besitzt.
Darum starten wir den integer i mit 1.

Der integer Anzahl_Links gibt nur den absoluten wert von 5 zurueck, wenn wir 5 Prims verlinken. Eine 0 ist in der Reihenfolge ueberhaupt nicht vorhanden, darum brauchen wir nicht den Umweg ueber 0 bis -1 gehen, sondern koennen gleich von 1 bis Ende zaehlen.

LG
Dae
 
Zuletzt bearbeitet:
@Brigitt Loening
Darauf bin ich anfangs auch rein gefallen. :)
Die 0 gibt es nur bei Objecten die NICHT verlinkt sind. Also ein einzelner loser Prim/Mesh/Sculpt hat die LinkNummer 0.
Sobald du einen weiteren Prim anlinkst, wechselt der Root sofort von LinkNummer 0 zu 1 und das eine Child ist die 2.

@surini
Freut mich sehr, das es dir gefallen hat :)

LG
Dae
 
huhu ihr suessen,

am Ende des vergangenden Kurses wurden 2 Wuensche geaeussert, auf meine Frage welches Projekt wir als naechstes in Angriff nehmen.
Zum einen war es der TipJar und zum anderen der Vendor.
Das trifft sich sehr gut, denn das ist im grunde beides das gleiche und gibt uns wieder die Moeglichkeit mehr ueber Objekt-Verhalten unter bestimmten Voraussetzungen zu erfahren.

Kommenden Sonntag den 16.9.2018 um 20 Uhr auf Bay of Surreality befassen wir uns erst mit dem TipJar (Donation Box) und anschliessend mit dem Vendor.
Wenn noch etwas Zeit uebrig ist, versuchen wir dann den Vendor noch mit einem Partner-Split auszustatten.

LG
Dae
 
TipJar vs. Vendor

huhu ihr suessen,

unglaublich das 2 so kleine Scripte tatsaechlich so abendfuellend sein koennen, doch ich hoffe alle hatten Spass.
Da waren zwischendurch auch einige konstruktive Anmerkungen, die ich hier ebenfalls erwaehnen moechte.
Nun aber erst mal die beiden Scripte, die fast identisch sind doch grund verschieden genutzt werden.
Zum Vergleich erst mal ganz ohne Kommentare.

Zum einen der TipJar:
Code:
integer Total = 0;

default
{
    state_entry()
    {
        llSetPayPrice(0, [5, 10, 20, 50]);
    }

    money(key id, integer payment)
    {
        Total += payment;
        llSetText(llKey2Name(id) + " zahlte " + (string)payment + "L$\nTotal: " + (string)Total + "L$", <0,1,0>, 1.0);
    }
}

Zum andern der Vendor:
Code:
integer Preis = 15;

default
{
    state_entry()
    {
        llSetPayPrice(PAY_HIDE, [Preis, PAY_HIDE, PAY_HIDE, PAY_HIDE]);
    }

    money(key id, integer payment)
    {
        if(payment == Preis)
        {
            llGiveInventory(id, llGetInventoryName(INVENTORY_OBJECT, 0));
        }
    }
}

Nun folgt der TipJar mit Kommentaren:
Der Befehl im state_entry bewirkt ein individuelles Bezahl-Menue, welches bei angegebenen Werten wiefolgt aussieht:
Zahlfeld TipJar.PNG

TipJar mit Kommentaren:
(Inworld im Script leserlicher)
Code:
// Globale Variable zum zusammen rechnen aller Zahlungseingaenge
integer Total = 0;

default
{
    state_entry() // Der state_entry Event wird beim speichern und resetten ausgefuehrt
    {
        // Individuelles Zahlfeld mit manueller Eingabe und allen 4 Bezahl-Button
        // Bei allen 5 Eintraegen handelt es sich um integer (Ganzzahl)
        llSetPayPrice(0, [5, 10, 20, 50]);
    }

    money(key id, integer payment) // Der money Event erkennt wer (key id) und wieviel (integer payment) einzahlt.
    {
        // Folgende Zeile rechnet den aktuellen Zahlungseingang mit der variable Total zusammen
        Total += payment;
 
        // Individueller Hovertext
        // Egal wie der Text aufgebaut wird, beim mixen von Text und Variablen muss auf die + Zeichen geachtet werden.
        // An welcher stelle zwischen den Gaensefuessen ein Leerschritt rein muss, wird im Hovertext ersichtlich.
        llSetText(llKey2Name(id) + " zahlte " + (string)payment + "L$\nTotal: " + (string)Total + "L$", <0,1,0>, 1.0);
    }
}

Als wir nun diesen Hovertext besprachen, kam die Frage auf, was ein unsichtbarer Hovertext fuer einen Sinn macht.
Aus konventioneller Sicht macht das absolut keinen Sinn.
Doch fuer Scripter ist diese Moeglichkeit hochinteressant.
Im Hovertext lassen sich versteckt bis zu 256 zeichen ablegen und mittels llGetPrimitiveParams wieder abrufen.
Ob das nun gewollt ist weiss ich nicht, jedenfalls haben die Lindens uns mit dieser Moeglichkeit eine enorme Speichererweiterung spendiert. ;)

Nun der Vendor:
Auch hier vewenden wir den gleichen Befehl im state_entry wie beim Tipjar, doch mit anderen Vorgaben.
Das PAY_HIDE versteckt alle ungenutzten Bezahlmoeglichkeiten und sieht folgendermassen aus:
Zahlfeld Vendor.PNG

Vendor mit Kommentaren:
(Inworld im Script leserlicher)
Code:
// Global angelegter Preis, um diese Variable nicht im Script suchen zu muessen
// Fuer andere Preise muss diese Zeile manuell angepasst werden.
integer Preis = 15;

default
{
    state_entry() // Der state_entry Event wird beim speichern und resetten ausgefuehrt
    {
        // Individuelles Zahlfeld mit nur einem einzigen Bezahl-Button ohne manueller Eingabemoeglichkeit
        // Der erste Bezahl-Button verwendet den global angelegten Preis.
        llSetPayPrice(PAY_HIDE, [Preis, PAY_HIDE, PAY_HIDE, PAY_HIDE]);
    }

    money(key id, integer payment) // Der money Event erkennt wer (key id) und wieviel (integer payment) einzahlt.
    {
        // Folgende Zeile vergleicht die aktuelle Einzahlung mit dem vorgegebenen Preis
        // Stimmt beides nicht ueberein, bekommt der Kunde gar nichts.
        if(payment == Preis)
        {
            // Dieser Befehl gibt dem einzahlenden (key id) das erste Objekt aus dem Inhalt des Vendors.
            // Man kann auch den Namen des Objects direkt bestimmen llGiveInventory(id, "Object-Name");
            // Doch bei der aktuellen Variante ist kein Eingriff im Script beim aendern des Objekts erforderlich.
            llGiveInventory(id, llGetInventoryName(INVENTORY_OBJECT, 0));
        }
    }
}

Bei diesem Script brachte Peter den Einwand, das ein Individuelles Bezahl-Menue auch gekuerzt angelegt werden kann.
llSetPayPrice(PAY_HIDE, [Preis]);
Hier bei verzichtet man lediglich auf die angabe PAY_HIDE fuer die ungenutzten Button und traegt in die Liste nur die Variable fuer den Preis ein.

In wie weit sich Kriminelle mit illegalen Viewern nun die Button und oder das manuelle Zahlfeld zurueck holen koennen, kann ich nicht sagen.
Darum verwende ich der volstaendigkeithalber ausschliesslich den kompletten Befehl und gehe sogar noch einen Schritt weiter.

Nun sehen wir im aktuellen Vendor Script, das eine Ausgabe des Objects nur dann erfolgt, wenn die Einzahlung mit dem Preis ueberein stimmt.
In der Wiki gehe ich sogar so weit, das ich mich fuer die Spende bedanke, wenn jemand versucht mich zu bescheissen.
http://wiki.secondlife.com/wiki/User:Daemonika_Nightfire/Scripts/Vendor#Default_Vendor
Der entsprechende Code dafuer sieht wiefolgt aus:
Code:
money(key id, integer payment)
    {
        // Absolut wichtig! Nur wenn die Zahlung mit dem Preis ueberein stimmt, sollte das Produkt ausgegeben werden!
        if(payment == prize)
        {
            llGiveInventory(id, object);
        }
        else if(payment != prize) // <--- *** Anti Hacker Option ***
        {
            // Sollte es dennoch jemand mit einem gehackten Viewer schaffen sich das manuelle Zahlfeld anzeigen zu lassen,
            // bedankt sich der Vendor hoeflich fuer die Spende und gibt kein Produkt aus.
            llShout(0,"Thanks for your donation, " + llKey2Name(id) + "!");
        }
    }

Das war es erst einmal wieder und ich bedanke mich bei allen Teilnehmern fuer die rege beteiligung, es hat Spass gemacht. :)

Natuerlich koennen auch hier wieder Fragen oder konstruktive Bemerkungen Einzug erhalten.
Schliesslich sind wir hier im Forum und nicht in der Wiki.
LG
Dae​
 
Zuletzt bearbeitet:
huhu ihr suessen,

fuer den Sonntag am 30.09.2018 um 20 Uhr auf Bay of Surreality habe ich folgendes geplant.

Wir nehmen uns noch mal den einfachen Vendor vor, und basteln da ein Partner-Split rein.
Wer dabei gut aufpasst, kann damit ebenfalls den TipJar erweitern.

Anschliessend machen wir eine offene Runde.
Einfach mal bissl Fachsimpeln und besprechen was euch so interessiert.

LG
Dae
 
oh weh hab es verpasst , dabei hab ich es sogar bei mir gepostet . und die skripte vorbereitet.
zum glück behandeln wir das thema nochmal , und vl kann man ja eine kleine wiederholung machen ... das wäre super, natürlich nur wenn alle einverstanden sind:)
 
Zuletzt bearbeitet:
Für eine offene Runde stelle ich mal die Verwendung des LSL-Editors zur Diskussion. Ja, ja, ich weiß Daemonika mag ihn nicht ;) Aber es kann ja jeder selbst entscheiden, ob er ihn verwenden will. Ich habe auch gerade für Neulinge die Erfahrung gemacht, dass er doch sehr hilfreich sein kann um seine Fehler zu finden. Wenn man ihn mal installiert hat, ist er sehr leicht mit einem Tastendruck erreichbar. Ich verwende ihn nicht ständig, aber wenn ich mal wieder blind für den "Syntax Error" bin und vor Verzweiflung in meine Schreibtischplatte beißen will, bewahrt er mich vor Zahnausfall.

Er kann einige sehr nützliche Dinge, die der interne Editor von SL leider nicht kann, insbesondere:
  1. mehrere Fehlermeldungen gleichzeitig anzeigen
  2. genauere Fehlermeldungen geben
  3. Hinweisen, welche Klammern einander zugeordnet werden
Installation
-------------
Herunterladen: https://sourceforge.net/projects/lsleditor/ im Webbrowser eingeben und auf den grünen Knopf "Download" klicken

Installieren: Ich ziehe es vor in C: Programme (x86) ein Verzeichnis LSLEditor anzulegen und LSLEditor.exe dort hinein zu kopieren.

Im SL-Viewer einstellen: Unter "Erweitert > Debug Einstellungen anzeigen" nach "ExternalEditor" suchen. Dort eintragen inklusive Gänsefüßchen: "C:\Program Files (x86)\LSLEditor\LSLEditor.exe" %s

Alternativ für Firestorm-Viewer: Eine Datei mit Namen xyz.lsl anlegen. Rechte Maustaste darauf und "Öffnen mit" auswählen und "Andere App auswählen" klicken. Ein Kreuzchen machen bei "Immer diese App zum Öffnen von .lsl-Dateien verwenden. Dann "weitere Apps" und ganz nach unten scrollen und "Andere App auf diesem PC suchen". Dann nach C:\Programme (x86)\LslEditor navigieren und LslEditor.exe auswählen. Dies scheint etwas umständlich, aber der Vorteil ist, das man es nie wieder machen muss, auch nicht wenn eine neue Version des SecondLife-Viewers kommt.

Verwendung
---------------
Aufrufen: im geöffnetetn Script-Fenster unten auf "Bearbeiten" klicken

Skript prüfen: Die Taste F6 drücken. Die aktuelle Version 2.56 scheint einen Fehler zu haben, dass sie beim ersten Prüfen behauptet, alles sei in Ordnung. Dann einfach mal ein Leerzeichen eingeben und sofort wieder löschen und dann F6 noch einmal drücken.

Klammern zuordnen: Stellt man den Cursor hinter eine schließende oder öffnende Klammer, dann wird die zugehörige andere Klammer durch einen grauen Klotz markiert. Klammerfehler lasse sich so schneller finden

Abspeichern: Im LSL-Editor File > Save sl_script_...

Beim Abspeichern wird auch in SL das Script abgespeichert.
 
Zuletzt bearbeitet:
@Canis Canning
Einverstanden, dann uebernimmst du nach dem Vendor-Script fuer diese Stunde die Leitung, denn ich kann nichts unterrichten, womit ich keine nennenswerten Erfahrungen habe.

Uebrigens, ich habe nicht gesagt ich mag den Editor nicht, ich habe gesagt ich mag ihn nicht benutzen.
Das ist ein kleiner aber feiner Unterschied. :p

LG
Dae
 
@ Dae
Ich dachte ja eigentlich nicht ans Unterrichten des LSL-Editors, sondern im Rahmen des Fachsimpelns mal darüber zu reden was dafür oder dagegen spricht ihn zu verwenden. Aber wenn es die Kursteilnehmer möchten, dann nehme ich auch die Herausforderung an ihn vorzustellen. Das habe ich ich hier ja schon ein wenig textuell versucht. Es wäre übrigens, wenn Voice unbedingt erwartet wird, das erste Mal, dass ich in SL voicen würde.:rolleyes:

@aviva: Der Gedanke von mir war, dass es gerade für die Teilnehmer des Anfänger-Kurses von Dae interessant sein könnte den Editor auszuprobieren. Ich habe bei der Teilnahme an zwei Stunden ihres wirklich tollen Unterrichts gesehen, dass es doch für viele schwierig ist, Fehler im Programmcode zu finden. Ich habe auch für zwei Freunde mal Scripting in SL unterrichtet und diese haben selbst den Editor gefunden und fanden ihn eine große Erleichterung.

LG Miri
 
Ich war immer ein Freund der Nutzung des Originals, aber offline programmieren und testen mit LSLeditor kann schon was.
Die Frage ist, ob ein weiteres "Produkt" das Leben der Anfänger vereinfacht oder ob zuerst mal Grundlagen da sein sollten.
Ich freue mich mal auf die Vorstellung und Diskussion drüber.

Fehlersuche ist überhaupt eine spezielle Sache - hier sollte von Anfang an mehr auf formale Konsequenz (Einrückungen, Klammerung) und Dokumentation (Kommentarzeilen) geachtet werden.
 
Die wirklich schwer zu findenden Fehler kommen bei größeren Programmen (Skripten) eh erst, wenn der Compiler keine Fehler mehr findet.

Da hilft dann nichts anderes als "selber denken" (und evtl. probieren).
 
@Canis Canning
Du warst ja nicht von Anfang an dabei und ich vergass zu erwaehnen, das wir den LSL Editor bereits in einer frueheren Stunde angesprochen hatten.
Also der Editor wurde mal kurz beilaeufig erwaehnt, doch wir hatten uns damals dagegen entscheiden, weil es erst einmal wichtig war, die Grundlagen an sich zu verstehen.
Wenn man die Grundlagen nicht versteht, nuetzt der LSL Editor ueberhaupt nichts, da man nicht weiss, wie man auf eventuelle Fehler reagieren muss.

Nach aktuellem Stand bin ich mittlerweile dafuer, kann es aber wie gesagt nicht selbst uebernehmen, da ich keine Erfahrungen damit habe.
Vor knapp 10 Jahren habe ich den LSL Editor mal ausprobiert und kam damit nicht zurecht, oder es hat mir nichts gebracht.
Dazu kam noch der Grundgedanke, das ich lieber Inworld Scripte, statt mich mit noch einem externen Programm auseinandersetzen zu muessen.

LG
Dae
 
Geade eben berichtet mir May Sonnenkern (gute langjaehrige Freundin und meine Managerin) stolz wie sie dank der Kurse eigene Scripte auf die Beine stellt.
Nebenbei erzaehlt sie mir, das es interessant ist, fuer was man gewisse funktionen alles nutzen kann.

Darauf hin habe ich ihr gesagt:
[10:37:37] Daemonika Nightfire: so viele verschiedene scripte gibt es gar nicht
[10:37:47] Daemonika Nightfire: schau mal hier wie wenig events es nur gibt
[10:37:47] Daemonika Nightfire: http://wiki.secondlife.com/wiki/Category:LSL_Events
[10:38:07] Daemonika Nightfire: und da alles, aber wirklich alles was man in sl scripten kann auf events basiert, gleichen sich viele scripte
[10:38:15] Daemonika Nightfire: nur die extras sind ueberall unterschiedlich

Wie zum Beispiel der Vendor und der Tipjar.
Beide nutzen die selbe Basis.

Oder nehmen wir mal ganz dreisst den Textur Hud (ebenfalls hier im Thread) als Beispiel.
Warum Dreist?
Na ganz einfach, was glaub ihr wohl wie z.B. der Maitreya Hud funktioniert?

Ich hoffe dadurch bekommt der ein oder andere wieder einen AHA Moment.

LG
Dae
 
Drum ist das Thema Copyright auf Scripts so eine Sache - es gibt eine Anzahl Funktionen und die verwenden alle - nur das drumherum ist halt vielleicht spezifisch. Textur draufmachen hat also nicht allzu viele Varianten, vorgelagert eine Menüsystem oder ein paar Knöpfe zum drücken und das ists dann. Das man andererseits versucht, den Investitionsaufwand für ein eigenes Script zu schützen und über den höheren Preis einer exklusiven Ware wieder reinzubekommen, ist auch irgendwie verständlich.

Thema LSL Editor: Einen Vorstellungsabend für interessierte wärs allemal wert - ob im oder außerhalb des Script-Kurses ist Planungssache.
 

Users who are viewing this thread

Zurück
Oben Unten