Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Programmier Richtlinien als Hilfe für eigene Scritpe
#1
Hallo zusammen,



ich hab mal angefangen paar Programmier Richtlinien aufzuschreiben, die mir bei der Erstellung von LSL Scritpen helfen.

Sie basieren auf Erfahrung mit eigenen Scripten sowie auch bei Fehlersuche und Portierung von freien LSL/SL Scripten.

Klar kann man manches anders machen, darüber läßt sich begründet diskutieren.

Ich sehe das nur mal als initiale Betankung, die gerne der Ergänzung bedarf.

Gut wäre bekannte Probleme mit Befehlen mit aufzulisten, die uns Stunden der Fehlersuche gekostet haben- um anderen das Leid zu ersparen.

Ich nummeriere die Empfehlungen, um Bezugnahmen zu erleichtern.



01- Modularen Code schreiben der einzeln prüfbare (Sub-)Funktionen aufruft. Mit Rückgabe Werten der Funktionen arbeiten.


02- Kurze prägnante Scripte die nur die Sollfunktion umsetzten (Prüfbaren Code schreiben!). Nicht benutzte Funktionen herauslöschen

03- Möglichst auf Notecards verzichten (Handling ist aufwendig und Fehlerträchtig)

04- Scripte möglichst alle im Root Prim unterbringen (mit Linkset Befehlen alles aus dem Rootprim steuern)

05- Kommunikation über Chatkanäle mit ChildPrims meiden/minimieren (Listen Befehl meiden!)

06- Eingabe Module und Ausführungs Routinen in verschiedene Funktionsblöcke trennen, aber in einem Script belassen.

07- Ein Script Lösung wo nur möglich ( spart inter Script Kommunikation und damit Fehler und Lag)

08- Mit Stati arbeiten (Status Standby, Status Aktiv,....) um Funktionen/ScriptLast an und aus zu schalten, wo dies Sin macht.

09- Scripte immer in Standby starten, und nur bei Bedarf aktiven Status einnehmen.

10- Nach Beenden der Scriptnutzung immer einen Reset durchführen um definierten Standby Zustand einzunehmen und temporär benutzten Speicher frei zu geben

11- Scripte die im Aktiv Modus viele Ressourcen benötigen ( Bewegung, Kommunikation, …) sollten nur für den Zeitraum aktiv werden wenn tatsächlich auch User auf der Sim Aktiv sind.

12- Auch Partikel sind eine Ressource, die auf der Sim reduziert eingesetzt, und nur bei Sichtbarkeit aktiviert werden sollen.

13- Poser ohne Posebälle sollten bevorzugt werden, da die Kommunikation zwischen Posebällen und Hauptscript verloren gehen kann, und das zur Störung des gesamten Script Systems der Sim führt.

14- gut kommentieren aber keine Romane schreiben. Kommentare in gleicher Zeile rechts wie Code

15- nach Möglichkeit MultiLanguage per Konzept unterstützen

16- Timer nehmen wo lange auf das Eintreffen von Events gewartet wird, aber nicht für sehr kurz aufeinander folgende Events

17- Physik Bewegung bevorzugen wo Objekte sanft bewegt werden sollen

18- Versionierung betreiben damit User später Unterschiede in Scriptständen leicht erkennen

19- Bei Transfer von SL Scripten beachten das die Präprozessor Direktiven hier anders funktionieren. Wertezuweisung direkt bei der Deklarationen vor dem Script, können zu Compiler Fehlern führen.

20- Verschachtelte Funktionen in einer Zeile auflösen. Es können anderer Werte als in Sl entstehen, weil die Bearbeitung in anderer Reihenfolge stattfindet


21- Portable Scripte schreiben - Physik Parameter Unterschiede der 4 Physik Enigines bedenken.
Antworten }
Thanks given by: Achim


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste