United Script Tutorial - Diskussions-Thread

[Mr.Gee]

Ein kleiner Hinweis zum Thema von mir:

Ist vermutlich für einige ein alter Hut, ich habe jedenfalls eine weile gebraucht bis ich dahinter gekommen bin

Wird

@ <RetVar/IF/START> <RefObj> call script <Script Name>:<Parameter>

ohne Variable aufgerufen als z.B
@ =[This] -> call sript '!ship.cmd.attack.std' : the victim=$target do not follow in new sector=[false]

wartet das aktuelle script bis der call befehl bzw. das aufgerufene script beendet wurde.

wird hingegen START vorne angestellt z. B

@ START [This] -> call sript '!ship.cmd.attack.std' : the victim=$target do not follow in new sector=[false]

wird in diesem Beispiel das script !ship.cmd.attack.std gestartet, jedoch läuft das aktuelle script weiter ohne auf eine Rückmeldung zu warten.

[jnrk]

Guter und wichtiger Einwand, bin auch über dieses Prob gestolpert, komme aber vor lauter Tutorial nicht mehr zum Scripten

Ich habs unter X.3.1 eingefügt.

BZ,
jnrk

[M.Kessel]

Ein kleiner Hinweis zum Thema von mir:

Ist vermutlich für einige ein alter Hut, ich habe jedenfalls eine weile gebraucht bis ich dahinter gekommen bin

Wird

@ <RetVar/IF/START> <RefObj> call script <Script Name>:<Parameter>

ohne Variable aufgerufen als z.B
@ =[This] -> call sript '!ship.cmd.attack.std' : the victim=$target do not follow in new sector=[false]

wartet das aktuelle script bis der call befehl bzw. das aufgerufene script beendet wurde.

wird hingegen START vorne angestellt z. B

@ START [This] -> call sript '!ship.cmd.attack.std' : the victim=$target do not follow in new sector=[false]

wird in diesem Beispiel das script !ship.cmd.attack.std gestartet, jedoch läuft das aktuelle script weiter ohne auf eine Rückmeldung zu warten.

Es ist noch ein bischen kniffliger. wenn das Script starten auf einem anderen Object ausgeführt wird, dann beendet sich das rein ge-call-te script, wenn das Aufrufscript endet.

Es ist also unerlässlich, bei den Start eines scriptes auf fremden Objektes ein START voranzustellen, damit es auch nach beenden des "anwerfscriptes" noch weiterlaufen soll. (wer hat da gesagt, scripten ist einfach )

[jnrk]

So Ihr lieben Leutz,

so langsam nähere ich mich dem Tutorial-Ende, weil hier schlicht und ergreifend auch mein sehr begrenztes X2-(Script)Wissen zur Neige geht.

Also Tutorialschreiber, Autoren, Scripter und Modder... gebt Euch ein Ruck... her mit nützlichen Routinen, erweiterten Kapiteln oder Ausführungen zu bestimmten Themengebieten. Jeder Beitrag, da bin ich mir sicher, wird die Zukunft von X2 verbessern.
Und selbst wenn der lautet: "jnrk, Du hast da und dort totalen Bockmist gebaut" her damit.

Dieses Tutorial ist ein Werk von uns Allen an Uns selbst und vor allem für jene die nach uns kommen und dieses Forum, X2 und die Gemeinschaft bereichern.

jnrk

[Metuelisator]

Tja es sind wohl mehr die kleinen Tricks wo jeder immerein aha hat, wie z.B. dr Schnipsel über dockedat die Station abzufragen. Ich mach das immer mit is docked, da wird ja auch die Station zurückgegeben auf der man ist.

Hm eine Doku zum runterladen hätte immer das Prob net aktuell zu sein.
Würde vielleicht ein read-only Forum für sowas in Frage kommen?

Und grade die kleinen Codeschnipsel und/oder auch Scripts mit vielen und klaren Kommentaren bringen oft ein aha. Wenn ein paar gute Scripte mit vernünftigen Kommentaren zum anschauen da liegen bringt das bestimmt auch was. Durch Verbesserungsvorschläge würden dann oft gebrauchte Routinen solange gefeilt bis sie von jedem nutzbar und fehlerfrei sind.
Ich würde auch gerne was zusteuern wüsste aber im Moment nicht, wörüber ich mich in einem Tutorial auslassen sollte.

[Moonraven]

So...mein erste Beitrag...alles was ich bisher zum Thema Soundnachrichten
rausgefunden hab.

http://www.codersland.de/sound1.html

Das ganze als Link weils doch etwas größer ist:)

[ticaki]

Du bekommst einen für deine Arbeit.

ABER teile es auf mehr Seite auf. Das dauert ja

[jnrk]

@Moonraven
Ist übernommen. Dank Deiner Arbeit der Soundbereich so wie ich das sehe komplett. Vielleicht gibts da ja noch ein paar nette Codeschnipsel und Witziges, kA.

@ticaki
Ich trage ja nur die gemeinsame Arbeit an einem Punkt zusammen und leiste dabe meinen bescheidenen Beitrag. Für ein vom Leser schreib ich doch alles

[Moonraven]

Ähm...also alles war das sicher noch nicht.

Bisher hab ich ja "nur" die Sprachausgabe:) weiteres wird aber noch folgen:)


Aufteilung ?....jo...werd ich ma machen:) Lokal fällt das mit der Ladezeit nicht so auf.*gg

[ticaki]

Mit Aufteilen meinte ich übrigens BEIDE

Es wirkt halt übersichtlicher wenn aufgeteilt ist und zum Ausdrucken kann man ja noch eine komplette Variante als Link anbieten.

[BurnIt!]

Sehr schön - ist doch schon eine Menge Info, die sich da angesammelt hat

Größere Posten, die noch fehlen sind die Befehlsliste (und optimal natürlich mit kurzer Beschreibung zu jedem Befehl - Mike und ich haben da schon angefangen) und eine einheitliche Struktur.

Mit einheitlicher Struktur meine ich z.B. selbes Farbschema für alle Bereiche - von mir aus <RefObj> im orange und <RetVar> immer hellblau oder eben anders - nur gleichmäßig.

Jetzt wäre es noch sinnvoll das ganze etwas umzusortieren (man könnte jetzt "chronologische Reihenfolge" sagen)
z.B. sollten die Basisdinge wie "was sind Variablen", "was sind Schleifen", "wie mache ich Bedingungen" doch eher am Anfang stehen.
Scripte ins Spiel einhängen kommt erst später - schließlich muss man erstmal ein Script haben, bevor man es einhängen kann.

[jnrk]

@BurnIt!
Ich meld mich als Freiwilliger für die Strukturanpasungen
Gib mir bitte eine Struktur/Layout vor, sowie der Kapitelreihenfolgen...dann setzt ich mich gerne an diese Fleißaufgabe.

Zur Reihenfolge mein Vorschlag:

I. BurnIt!-Aktivierung des Scripteditors
X. jnrk's Programming Tutorial
IV. Vanoblis - Der ScriptDebugger - Anleitung (v1.3 UPDATED)
II. Scripts ins Spiel einhängen
------Bits'n Bytes Nützliche Routinen-------
---------Externe Referenzen / Anhang--------------
-----Befehlsreferenz----------

Die Indizes müssen auch irgendwie anders. Wie bisher siehts noch wie Hack aus, weil ichs ja erstmal in eine !=optimale Reihenfolge gebracht habe, so wie die Infos ankamen.

Gruß,
Sascha

[BurnIt!]

Ja, der Vorschlag klingt gut.
Ganz ans Ende sollte dann die Befehlsreferenz.

An und für sich sagt mir das Farbschema, das derzeit in der Befehlsreferenz verwendet wird recht zu - aber das ist natürlich Geschmackssache.
Für ein Layout sollte klar sein, wie das fertige Produkt aussehen soll.
Eine Webseite? Eine PDF Datei? Ein Windows Helpfile? Ein Forenthread?

Darf ich meinerseits vorschlagen nicht meine Einleitung aus dem Forum zu verwenden sondern eher die, aus der bisherigen "offiziellen" Doku (die PDF Datei aus dem Modkit)?

Was die Indizes betrifft können die Hauptkategorien ja mit A,B,C,D etc. benannt werden und die Unterpunkte dann mit normalen arabischen Ziffern.
Ich würde übrigens nicht versuchen die Nummerierung der ScriptKommandos durchzuhalten - aus zuverlässigen Quellen weiss ich, dass damit zu rechnen ist, dass die Befehle in Zukunft alphabetisch im Spiel sortiert werden um es leichter zu machen einen Befehl zu finden, wenn man schon weiss wie er lautet.

[Metuelisator]

Moin,

Vorschlag zum Layout: eine einfache Webseite so ähnlich wie
http://www.webware.at/German/3calc/frconten.htm
wäre flexibel und leicht zu erweitern.
Eine Übersicht auf der ersten, die einzelnen Punkte auf Unterseiten.
Dem Acrobat bin ich nicht so zugeneigt, zum Laden brauch der ewig (ich Dummbeutel habe meine alte Version gelöscht) und Grafiken einbinden, Farben usw. geht in html ja auch. Ein Anzeigeprg hat ja auch jeder auf seinem Rechner.
Und wenn diese Seite online gestellt ist anstatt von jedem runtergeladen wird, sind updates kein Prob und niemand verpasst eins. Sowas sollte sogar ich hinkriegen also falls Bedarf, biete ich meine Hilfe an.

so denn

[Metuelisator]

Moin,

habe noch einen kleinen Tip, der es vielleicht auch wert ist aufgenommen zu werden.

Gerade bei grösseren Scripts ist die Fehlersuche nicht immer einfach.
Solange man an einem Script arbeitet kann man mit Zwischenmeldungen von wichtigen Variablen einen möglichen Fehler schneller finden.

also weist man seinem Script zu Anfang ein Argument "debugmode" vor, unter Eingabe "Number", string debugmode.
Beim starten des Scripts gibt man "0" fur debugmode aus, "1" für debugmode ein an.

Im Script selbst kann dann an beliebig vielen Stellen

if $debugmode = 1
write to playerlogbook $wichtigeVariable1
write to playerlogbook $nochwichtigereVariable2
usw....
end

eingesetzt werden. Diese Aufrufe müssen auch später nicht unbedingt aus dem Script rausgenommen werden wenn es erstmal läuft.

Ist nicht komplett auf meinem Mist gewachsen, bin in der Handel MK3 über was ähnliches gestolpert.

so denn

[rhaes]

@jrnk

soweit ich mich erinnern kann sollte mal Schleifen rückwärts zählen lassen, da dies schneller ist als eine Addition. Zumindest ist das auf Assembler und C Ebene so. Wie es in Scripts ist, kann ich nicht beurteilen. Aber könnte man mal testen. Könnte ja sein, dass da bei vielen Schleifen doch noch 1 % Performance herauskommt.

[jnrk]

@Metuelisator
Hab heut Nacht mit BurnIt! gechatet, sein Vorschlag, da das Tut offenbar offiziel wird/werden sollte/könnte, es diesem Layout anzupassen. Damit einher gingen auch die Aufteilung in mehrere Seiten/Kapitel, was die Ladezeiten natürlich deutlich verbessert. Mitsamt der Kapitelnavigation (evtl. sogar Unterkapitel) Links, ist jeder Inhalt schnell und einfach zugänglich. Das ganze dann nochmal als DL zum Offline lesen und unterstütz von einem Diskussionsthread.

Was hälst Du / Ihr davon ?

@rhaes
Du hast natürlich Recht, werde es in X.2.3 erweiterte Schleifen einarbeiten. Einsteiger direkt mit sowas zu erschlagen kommt wohl sonst nicht so gut. Genaugenommen besteht der Performancegewinn darin das Schleifen auf 0 runtergezählt werden. Wenn ein Wert auf 0 runter ist wird ein Flag gesetzt und der Vergleich Wert==0 sparen.
Bsp ungefähr so in ASM

Code: Select all

             mov cl, 10
schleife: tuirgendwas
             dec cl
             // cmp cl, 0 diese Zeile kann dadurch entfallen
             jnz schleife oder jne schleife (muss nochmal nachsehen)

Unabhängig davon obs in X2-Scripts eine Verbesserung bringt, ist es guter Stil in allen Sprachen.

@Metuelisator Debug
Gute Sache, das läßt sich sogar um mehrere Debuglevel erweitern. Wie wärs fürs mit noch mehr Text aus und nem weitern Beispiel zu mehreren Debugleveln, dann wird da nen richtig schöner Schuh draus. Sag einfach an wo Dus gerne Hin hättest (mein Vorschlag als Extrakapitel ins Programming Tut oder zur Vanoblis Debugging-Ausführung)

[Moonraven]

@ guten Stil

Da muß ich dir leider wiedersprechen. Es ist nicht guter Stil Schleifen die normal vorwärts laufen einfach rückwärts laufen zu lassen, im gegenteil das macht code nur unverständlicher:)

@Performance

Soviel gewinn ist das nicht wirklich, da ein vergleich ein vergleich ist (und die abfrage eines Register-Flags ist auch ein Vergleich !!). Wenn überhaupt ist der Performance-Gewinn nur unwesentlich.

und wenns einen guten Interpreter/Compiler hat (mal ganz allgemein gesprochen), dann setzt er das automatisch um.


Trotzdem find ichs gut das zumindest einige Script-Coder sich um effizents und performance gedanken machen.

[jnrk]

@guter Stiel
Wer bestimmt den ob eine Schleife von vornherein vorwärts oder rückwärts laufen soll ? IdR keiner doch die Verwendung der Schleife selbst. Wenn ich in der Schleife ein Array verarbeiten will, wärs natürlich ungeschickt, einen extra internen "Hochzähler" zu verwenden und außenrum nen dec Schleifenzähler. Hab ich dagegen einen definierte Anzahl an Durchläufen, ist es per dec deutlich einfacher und anschaulicher zu lesen/verstehen und kann mir ggf einen zusätzlichen Schleifenzähler sparen.

X2-Bsp:

Code: Select all

$anzahl THIS get amount of Moskito in cargo bay
while $anzahl > 0
  $gegnermissile = THIS find nearest missile aiming to me 
  THIS fire missile Moskito on $gegnermissile

Auf Krampf dec-Schleifen ist natürlich Murks, aber es passt an vielen Stellen besser (und performanter) als man zunächst denken würde, weil man viel zu oft aber nicht dran denkt, nimmt man immer wieder inc-Schleifen.
FAZIT: Es ist guter Stil zum jeweiligen Problem die passende Schleifenvariante zu verwenden und weil die Dec-Schleifen nicht im Tut drin sind, müssen sie jetzt rein

@Performance
Wäre natürlich interessant zu wissen, wie der Interpreter von Egosoft arbeitet. Besonders im Hinblick auf den Umgang von "calls", denn wenn ich hier einen call auf ein Script mit vielleicht 5 Zeilen Inhalt aufrufe und das Ganze noch in ner gigantischen while-Schleife (zB ein Globalscan nach Schiffen) verpackte, könnten die Performance-Verluste erheblich sein. Oder wie siehst Du das ?

Ist aber ja auch klar, dass ein Script erstmal funktionieren muss, wenns aber wie bei X2 an die "Öffentlichkeit" gelangt, sollte es in fortlaufenden Versionen auch stilistisch/performanter werden. Zu meiner Schande muss ich gestehen, dass ich derzeit mein Hauptaugenmerk auf "Funktioniert" lege.

[Moonraven]

In deinem Beispiel hast du ja recht. Aber da gebietet es auch die Logik.*gg

Bei einem Array kommt es drauf an, ob die Reiehenfolge für die Verarbeitung wichtig ist oder nicht.

Wie du richtig sagst...auf den Sinn und Zweck der Schleife kommt es drauf an.

Deshalb fordere ich

Code: Select all

    For $i = X to Y
    end