Für das Verständis von Prozeduren und Funktionen hilft dir vielleicht:

http://www.dsdt.info/grundlagen/sprache/prozfunk.php

Generell gibts einiges unter http://www.dsdt.info/grundlagen/sprache/ was man direkt in Pascal Script auch machen kann, vor allem die Grundlegenden Sachen.

Ach ja - fast hätte ich das übersehen.
Das klappt oben sowieso alles nicht im Spiel, weil UFO.FlyToPoint ein kommando ist, sorry.

D.h. wenn FlyToPoint wie beschrieben mehrfach hintereinander aufgerufen wird, dann ist das soviel wie innerhalb einer Sekunde die Befehle "Flieg nach X", "Stop - nein flieg nach Y", "Stop-Nein, flieg nach Z" usw, ohne das sich das UFO überhaupt vom Platz bewegt.

Du musst nach jedem Befehl FlyToPoint erstmal auf das event CommandComplete warten, erst dann hat das UFO den angegebenen Punkt erreicht.

Ich weiß. Aber ein Fehler ist es nicht, also hatte ich es bei was auprobieren überall reingenommen. Später hab ich mich aber wieder dagegen entschieden.

Übergeben: Ich muss also beim Prozedur-Aufruf in Klammern die Variablen schreiben, die mitgenommen werden sollen, und hinter die Prozedur in Klammern die (neuen) Variablen in der gleichen Reihenfolge?

Genau - wobei Du aber beachten musst das beim Aufruf eine Datenkette mit Kommatrennung übergeben wird, während in der Funktionsdefinition in der Klammer die Variablendefinitionen liegen, die wie jede Variablendefinition auch mit Semikolon abgeschlossen/getrennt sein muss (nur das letzte bzw. einzige Semikolon fällt weg)

Und es muss jeweils die Reihenfolge der Datentypen identisch sein, sonst kriegst Du einen type mismatch.
Wenn Du dagegen die Zuordnung zweier identischer Datentypen verwechselst, dann hast Du einen logischen Fehler - der Compiler akzeptiert das, aber die Funktion arbeitet nicht mehr so wie geplant...

Aber guck erstmal das Du das Skript ohne Zwischenlandung und ohne unit, nur mit flytopoint in ordnung bringst - die eventfunktionen passend zu programmieren ist schon aufwendig genug ohne weitere Fehlerquellen...

Und wie? Die Prozedur einfach aufrufen oder was? Hab keine Ahnung, wie man ein nicht-Zeitabhängiges Warten macht. Nicht den Hauch einer Vermutung um genau zu sein :D

z.B. in UKI001scout (verkürzt):

// Funktion für das Ereignis "CommandComplete"
procedure UKICommandComplete(sender:TObject);
var
  UFO:TUFO;
begin
  UFO:=TUFO(sender);
  AllNewCommand(UFO);
  UFO.FlyToPoint(PositionNear(UFO.position,10));
end;

procedure StartMission;
var
  UFO:TUFO;
begin
  UFO:=UKI_AAgetUFO;
  UFO.UserKI:=true; //Abschalten automatischer Aktionen  UFO.FlyToPoint(PositionNear(UFO.position,10));
  register_event(@UKICommandComplete, UFO, EVENT_ONUFOCOMMANDCOMPLETE);

Die Startmission schickt das UFO zum nächsten Punkt, setzt die Überwachung auf "CommandComplete" und beendet sich.
Wenn das UFO am Ziel angekommen ist, wird die bei dem Event CommandComplete eingetragene Funktion aufgerufen, die dann den nächsten Befehl gibt - und sich wieder beendet, um auf das nächste CommandComplete zu warten.

Wenn Du verschiedene Kommandos in einer bestimmten Reihenfolge geben willst, dann speicherst Du am besten in UFO.KIstep den jeweils durchgeführten letzten Befehlsschritt ab. Dafür wurde die nämlich eingeführt, siehe z.B. UKI003Lander - fünfmal FlytoPoint, danach Landung.

Wichtig ist das pro Event "CommandComplete" nur ein einziger Befehl an das UFO gegeben werden kann. Wenn Du da mehrere gibst, dann zählt nur der letzte (und wird ausgeführt, sobald die Eventfunktion durchgelaufen ist, nicht während das Skript aktiv ist)

Also mal sehen...
EVENT_ONUFOCOMMANDCOMPLETE
sagt dem UFO, wenn du fertig bist mit dem jetzigen Befehl mache
UKICommandComplete
das wiederum dem UFO mit
AllNewCommand(UFO);
sagt, dass es einen neue Befehl kriegt, der danach aufgeführt ist.
Danach ist die Prozedur, die durch das registerEvent aufgerufen wurde vorbei und es geht weiter im Code - und wenn ich da irgenwas einbaue ohne ein weiteres
EVENT_ONUFOCOMMANDCOMPLETE
dann wird das sofort ausgeführt - in diesem Fall würde die Bewegung nach
(PositionNear(UFO.position,10));
gar nicht erst stattfinden. (Falls es ein Befehl ist, der auf die Bewegung Einfluss hat)
Soweit richtig?

Du darfst in Deinem Code nur ein einziges
register_event(@UKICommandComplete, UFO, EVENT_ONUFOCOMMANDCOMPLETE);
haben, und auch nur eine einzige Funktion UKICommandComplete - alles andere führt zu Müll.

Alle Befehle hinter der register_event werden ausgeführt, bevor das UFO auch nur den ersten Schritt von dem FlyToPoint vorher macht - die Kommandoausführung setzt erst ein, wenn die Funktion StartMission komplett beendet ist.

Solange Du irgendeinen Befehl im Skript laufen hast, macht das UFO gar nichts. Erst wenn sich das Skript als "Aktion abgeschlossen" meldet, wird der zuletzt gegebene Befehl durch das UFO ausgeführt. Und sobald dieser Befehl beendet ist, erhält das Skript über den Event CommandComplete erneut die Möglichkeit, einen einzigen Befehl (neben beliebigen Skriptinternen Verwaltungsfunktionen) an das UFO zu geben.
Und wenn irgendetwas das UFO stört sodass es den Befehl nicht ausführen kann, kommen die anderen Events und können überprüft werden, z.B. wenn das UFO in eine Basisverteidigung hineinfliegt und getroffen wird.

Der UKI-Befehl AllNewCommand ist lediglich ein leerer Platzhalter für alle Ideen, die man als Spielsatzersteller mit dem UFO im Falle eines neuen Kommandos zusätzlich machen will - momentan passiert da gar nichts und das hat keinerlei auswirkungen auf das UFO. Ich hab lediglich vergessen das beim kopieren aus der Template zu löschen.

Das gilt übrigens für alle All...-Funktionen in den UKI-Scripten. Dies sind Verwaltungsfunktionen für Spielsatzbesonderheiten und nur teilweise gefüllt, z.B. ziehen die AllCreate-Befehle im Galwar die internen Baukosten des UFOs für alle UFOs von den passenden Resourcen der jeweiligen Rasse ab.

Dann wäre es an der Zeit, das mal übersichtlich und allgemein verfügbar zu erklären.
Ein Grund, warum ich so viele Fragen stelle, und warum keiner mit dem script anfangen will ist, dass nirgendwo was erklärt ist. Selbst wenn einer die Sprache kann, steht er ständig vor der Frage "was brauche ich für was", und darauf gibt es keine Antwort. Ich selbst traue mir jedenfalls nicht zu, große Erklärungen zu machen. Dieser Einschätzung stimmst du sicherlich zu...

Also, soweit ich das KIstep verstehe:
Mit 1,2,3,4,5 etc. werden "Zeitpunkte" festgelegt, in der das UFO X ausführen soll.
Dazu muss in der Ausführung dann immer noch hochgezählt (oder anders festgelegt) werden.
Es muss also jeder UFO-Befehl einzeln stehen mit einem entsprechendem Zählbefehl. (ausgenommen ev. Schleifen, falls das vom Ablauf her funktioniert).

Du solltest Dir angewöhnen, die zwei Gruppen von Methoden zum UFO auch sprachlich zu unterscheiden - das hilft beim Verständnis.

Wenn Du von UFO-Befehlen sprichst, dann sollten dies Skiptbefehle sein wie z.B. UFO.escape, die Problemlos auch inner halb von Schleifen etc. ausgeführt werden sollten.
Und UFO-Kommandos sind dann diejenigen Skriptbefehle, die Handlungen des UFOs im Geoscape ausführen lasse soll.

Du kannst die Ziffern in UFO.KIstep als die Zeilennummern für die Befehlsausführung einfacher über case realisierter UFO-Programmierungen betrachten - und sie sind keineswegs absolut notwendig sondern nur bei aufwendigeren Programmen. Genau genommen könnte man dies auch in normalen Variablen unterbringen - die Verwendung von Eigenschaften von TUOFO erlaubt aber die Kontrolle mehrerer UFOs innerhalb eines einzigen Skriptes und ist einfach konsistenter.

Meine Scouts z.B. brauchen keine KIstep, da sie nur Zufallskurse fliegen und wenn ein UFO bestimmte Befehle abwechselnd nutzen soll dann geht das auch besser ohne KIstep.

ber ansonsten ja, in einer Seuqenz einer KI darf immer nur ein einziges UFO-Kommando gegeben werden.

*harsch klingende Worte - Warnung* Und du solltest dir angewöhnen zu bedenken, dass die meisten Leute die scriptbefehle nicht von vorn bis hinten kennen und deshalb auf Erklärungen angewiesen sind.
Aber das hab ich oft genug gesagt... ohne gute Erklärungen in der online-doku werden du du und Natter auf Ewigkeiten die einzigen bleiben, die mehr machen als scripte zu kopieren. (Und ein anderer kann die Erklärungen ja auch nicht machen. Jim klammer ich mal an dieser Stelle aus.)

Jedenfalls bin ich jetzt so schlau wie zuvor.
Fangen wir mal mit der KIstep an:
darin wird ein integer Wert gespeichert. Steckt noch irgendwas mehr dahinter? Irgendeine Eigenschaft?

Was zum Teufel sorgt nun dafür, dass ein UFO ein Kommando (wenn ich deine für alle Welt hier neue Definition zu Grunde lege) zu Ende ausführt, und nicht schon mit dem nächsten fortfährt?


edit: Die Seite wird ja immer breiter :( Kannst du irgendwas machen? Ich glaub das liegt an deinem code-schnipsel oben, da sind zwei Zeilen in einer, wenns geht mach maln enter

Sie waren nicht harsch gemeint - dafür sind sie aber notwendig.
Es gibt nicht allzuviele verschiedene Methoden von TUFO, und es ist von ziemlich elementarer Bedeutung zu wissen, welches davon Kommandos sind und welches normale Befehle.
(HuntObject und FlytoPoint sind momentan die einzigen direkten Kommandos. ClearDestination ist zwar theoretisch auch eins, aber ein "Mache nichts mehr" ist als Stopp-Befehl keiner Zeitdauer unterworfen)


Es gibt nur eine Sache die dafür sorgt: Der Skripter, der nach jedem Kommando das Skript auslaufen lässt und kein weiteres Kommando gibt.
Oder anders ausgedrückt: Jedes Kommando wird unter genau der Bedingung automatisch zu Ende geführt, das der Skripter kein neues Kommando in derselben Zeitsequenz gibt. Das einzige was ein Kommando normalerweise vorzeitig abbrechen kann, ist ein vorzeitiges weiteres Kommando des Skripters.
(Es gab zwar noch einen Fehler im Eventsystem, bei dem noch offen ist ob Natter's umstellung im Code das behebt, aber das kann man erstmal ausklammern).

Und deshalb ist es ja so wichtig das der Skripter weiß, was der Skriptbefehle die Geoscape-Kommandos sind - das sind diejenigen Befehle die er nicht durch mehrfache Verwendung blockieren/abbrechen darf.

Vielleicht zur Verdeutlichung mal einen Zeitablauf im Programm:
1.) Spiel läuft, bis Skript durch Event gestartet wird.
2.) Startmission läuft bei absolut gestopptem Spiel, bis diese Skriptfunktion beendet ist. Hier werden die Eventfunktionen definiert und eventuell ein Kommando gegeben.
3.) Geoscape läuft weiter, bis eines der vordefinierten Events eintrifft - UFO führt in dieser Zeit das zuletzt gegebene Kommando aus.
4.) Event stoppt den Geoscape und ruft die Eventfunktion des Skriptes auf. Diese kann machen was sie will - aber solange sie arbeitet ist der Geoscape-Zeitablauf gestoppt.
Erst sobald sie keine Skriptbefehle mehr abarbeitet, geht der Geoscape weiter
5.) Im Geoscape wird das zuletzt im Skript gegebene Kommando ausgeführt und das Skript ruht, bis eines der Events auftritt - gehe zu 4.)

Das jeweils letzte gegebene Kommando in einem Skript wird immer solange ausgeführt, bis es entweder zuende ist oder aber ein anderes Event unterbricht - aber die Ausführung beginnt erst, NACHDEM der Skripter jeglichen sonstigen Skriptbefehl beendet hat.



Nein - genauso wie auch das usertag und der KIName ist das eine vom Hauptprogramm selber absolut ignorierte Speicherzelle, deren Sinn nur durch die Verwendung im Skript entsteht.
Theoretisch könntest Du da auch eintragn wieviel Fracht eines items das Flugzeug schleppt oder sonstwas - das Skript ist die einzige Stelle wo diese Werte abgefragt werden. Und im Falle von KIstep und KIName ist das auch die einzige Stelle wo diese Werte gesetzt werden (bei usertag kann man das ja im Editor setzen und im Skript verändern)

Hoffentlich ist die Seite bald zu Ende... Ich mach mal per Hand Zeilenumbrüche.
Würde das so funktionieren:
In der Starmission geb ich ein FlytoPoint-Kommando und registriere EVENT_ONUFOCOMMANDCOMPLETE
Nach der Bewegung wird diese Funktion aufgerufen.
Darin steht dann case of KIStep
1 FlytoPoint, KIStep+1
2 FlytoPoint, KIStep+1
3 FlytoPoint, KIStep+1, function Zwischenlandung
etc. je nach Anzahl der beabsichtigten Landungen.
zum Schluss dann UFO.escape

Theoretisch könnte ich dann bei 2 noch 20 messages erscheinen lassen,
Forschungen verfügbar machen etc. aber nur ein Kommando geben?

Wenn wir an dieselben Befehle denken dann ist das soweit korrekt.
Ich habe schon im Tutorial-Bereich eine Seite für einen zeitlichen Ablaufplan vorbereitet, da sich da auch durch die neuen GUI-Befehle was ändert, aber noch keine Zeit gehabt das zu schreiben...

XSkriptTutorial.Kapitel6

Das sollte einiges erklären

Wie ist das, wenn ich dem UFO im CommandComplete kein Kommando gebe,
sondern nur etwas wie KIStep+1, weil eine Bedingung nicht erfüllt ist (über Land bei der Landung z.B.)
wird dann Command Complete erneut gestartet?
Wenn ich so überlege, würde das dann ja einen Abbruchbefehl für CommandComplete nötig machen, also wohl nicht.
Funktioniert dann ein UFO.FlyToPoint(PositionNear(UFO.position,0));

--------

funktioniert in einem case das:
case UFO.KIstep of
>6 and <15:
oder muss ich jede Zahl einzeln eintragen?

Nein, da das UFO danach kein Kommando mehr hat, dass es erfüllen kann.

Ja, theoretisch müsste dann jedes Mal wieder CommandComplete aufgerufen werden. Kann mich aber auch irren, von daher vielleicht einfach mal testen.
Allerdings würde es dazu führen, dass jede Minute das Skript aufgerufen wird. Besser wäre es dann vielleicht einen Timer zu setzen.

P.S: Statt UFO.FlyToPoint(PositionNear(UFO.position,0)); kann man auch UFO.FlyToPoint(UFO.Position) nehmen ;)

KIstep wird im Programm selber nie überprüft. Wenn Du das nicht überprüfst, dann passiert damit auch nichts. Insbesondere wird natürlich keinerlei Event ausgelöst.

CommandComplete ist ein Ereignis, keine Funktion - das wird nie gestartet, sondern immer nur bei genau definierten Bedingungen als Eventsignal gesendet.

Als Programmfunktion arbeitet das natürlich einwandfrei - ob es das macht was Du glaubst das es machen würde weiß ich nicht, da ich nicht weiß was Du in dem Moment erreichen willst - allerdings denke ich nicht, da dies ein ziemlich unsinniges Konstrukt ist...

Einfach nur, dass CommandComplete wieder dran ist. Ich versuch gerade, den Ablauf hinzukriegen, und da ich (auch später ev. noch veränderbare) Variablen habe, ist das etwas komplizierter. Im Moment sieht es so aus (und sollte zumindest von der Reihenfolge klappen, Kosmetik hab ich noch nicht überprüft. ;)): Begin bei 5 durch UFO:KIStep:=5; in StartMission

procedure UKICommandComplete(Sender:TObject);
var
  UFO:TUFO;
begin
  UFO:=TUFO(sender);
  case UFO.KIstep of
          <4:
             begin
                  UFO.KIStep:=UFO.KIStep+1;
                  UFO.FlyToPoint(PositionNear(UFO.position,20));
             end;
           4: UFO.KISTep:= 6;
           5: UFO.KIStep:= UFO.KIStep-Flugzahl1;
           6: begin
                if (Landezahl>0 and earth_api_PointOverLand(UFO.Position)=true) then
                  begin
                    Zwischenlandung(UFO);
                    UFO:KIStep:= 15;
                    Landezahl:= Landezahl-1;
                  end;
                  else UFO:KIStep:= 3;
  >6 and <14:
              begin
                  UFO.KIStep:=UFO.KIStep+1;
                  UFO.FlyToPoint(PositionNear(UFO.position,20));
              end;
          14: UFO:KISTep:= 20;
          15:
              begin
                UFO.KIStep:= UFO.KIStep-Flugzahl2-1;
              end;
    16,17,18:
              begin
                UFO.KIStep:=UFO.KIStep+1;
                UFO.FlyToPoint(PositionNear(UFO.position,20));
              end;
          19: UFO.escape;
          20: UFO.KIStep:= UFO.KIStep-Flugzahl3-1;

Irgendwie komme ich mir gerade vor, alsob ich Apfelmus mit Gips-Deko-Birnen vergleichen muss...

Diese angefragte Zeile befindet sich nirgendwo in dem gezeigten Skript oben. Du hast im Originalpost sogar noch extra die 0 hervorgehoben, aber in dem Skript arbeiten alle Befehle mit größeren Zahlen.
Das Skript hat zwar eine ungewöhnliche Verteilung in der Zahlenlogik, sollte aber kein Problem sein - schließlich gibt es dort ja nirgendwo UFOs die auf der Stelle bleiben sollen...