Banner left   Banner center   Banner right

Germanenglish Home · News · Diary · Screenshots · Documentation (Wiki) · Downloads · Guestbook · Forum

Home · Benutzer registrieren · Suchen · Statistik · FAQ · Benutzerliste

Zur Zeit online: keiner ausser dir

 X-Force - Fight For Destiny - Forum —› X-Skript / Developer-Pack —› Fragen zu Typen/Funktionen/Prozeduren...

Seite: << [1] 2

Autor Mitteilung
verfasst am: 02.08.2009, 19:39
Spielsatz Alliances

Registrierdatum: 14.07.2004, 14:47

 Beiträge: 1185
Also entweder reden wir völlig aneinander vorbei, oder wir reden vom gleichen ^^
Ich für meinen Teil hatte jedenfalls vor, zu Beginn des Effekt (also im laufenden Einsatz, nicht vor/beim Erstellen des selbigen) Autoplay auf true zu stellen. Wenn ich dich recht verstehe, dann würde das vermutlich ein Einmischen durch den Spielers verhindern, aber nicht das Soldier_ai-Skript starten.
Also genau das, worum es mir ging.
verfasst am: 02.08.2009, 20:32
Admin, Spielsatz GalWar

Registrierdatum: 31.08.2005, 21:51

 Beiträge: 5595
Zitat: sujin
Ich für meinen Teil hatte jedenfalls vor, zu Beginn des Effekt (also im laufenden Einsatz, nicht vor/beim Erstellen des selbigen) Autoplay auf true zu stellen.

Eben - und Natter sagte ja dass er nicht bestätigen kann ob das klappt:
Zitat: Natter
Eventuell lässt sich das durch das Setzen von AutoPlay=true vermeiden, das müsste mal jemand ausprobieren

Soweit ich das verstanden habe, wurde das Autoplay eingeführt um vor Beginn des Einsatzes gesetzt zu werden - momentan weiß niemand was passiert wenn es während des Einsatzes verändert wird...
verfasst am: 03.08.2009, 01:51 · Edited by: Natter
Programmierer, allgemeines

Registrierdatum: 06.06.2004, 17:19

 Beiträge: 3186
Zitat: DirkF

Soweit ich das verstanden habe, wurde das Autoplay eingeführt um vor Beginn des Einsatzes gesetzt zu werden - momentan weiß niemand was passiert wenn es während des Einsatzes verändert wird...

Doch, ich weiß schon, was dabei passieren sollte - die MovingListe wird automatisch geleert. Die Frage ist lediglich, ob der Spieler in der kurzen Zeit eigene Befehle an die Einheiten geben kann (z.B. neues Bewegungsziel setzen). Vermutlich braucht man einen extra Befehl, um alle Spieleraktionen zu deaktivieren (Gepäck aufrufen, Minikarte, Einheitenbefehle ...)
verfasst am: 05.08.2009, 10:07
Registrierdatum: 11.06.2009, 18:38

 Beiträge: 84
Ich hätte mal eine Frage zu Inttostr

Bin beim durchstöbern der Referenz darauf gestoßen

es gibt ja inttostr, diese Funktion konvertiert eine Zahl in einen string:
function inttostr(i: Int64): string;

Was zur Hölle ist dann int64tostr???
function Int64ToStr(i: Int64): string;

Soweit ich das beurteilen kann ist dass exakt dasselbe

Ist es also nur irgendeine alte Dateileiche, die man nicht benutzen sollte oder hat sie irgendeinen Nutzen?

Das gleiche gilt auch für stringtoint64...
verfasst am: 05.08.2009, 10:39 · Edited by: sujin
Spielsatz Alliances

Registrierdatum: 14.07.2004, 14:47

 Beiträge: 1185
Ich hab nicht alle Wertbereiche im Kopf, aber afaik ist int64 der größte Integer-Typ (sollte jedenfalls größer sein als ein "normaler" Integer auf nem 32-Bit-System [hab grad nachgeguckt: -9223372036854775808..9223372036854775807 <- das ist schon ganz nett ^^]), den Delphi/Pascal zu bieten hat.
Eigentlich braucht man das Kommando nur, wenn man ohnehin mit einem Int64 arbeitet, was nur selten der Fall sein sollte (normaler Integer sollte für 24/25 Zwecke groß genug sein, um praktisch niemals überzulaufen). Aber falls man mal der Meinung ist, man bräuchte unbedingt so viel Platz... und müsse das dann auch noch zu nem String konvertieren oder in einen String packen, schreibt halt zwei Zahlen da dran.

btw, die Standard-Integertypen sollten alle abwärtskopatibel sein (mit IntToString64 sollte man auch nen Byte umwandeln können).
verfasst am: 05.08.2009, 12:18
Admin, Spielsatz GalWar

Registrierdatum: 31.08.2005, 21:51

 Beiträge: 5595
inttostr ist der Befehl zur Umwandlung der Basis-Integergröße, int64tostr ist dagegen der Befehl, der immer einen 64-Bit-Integer umwandelt.

Die Basisintegergröße ist aber abhängig vom System, von den Compilereinstellungen etc. Früher war ein Integer oft 8 oder 16 Bit, und selbst heute arbeiten viele Programme noch mit 32-Bit-Integer als Grundgröße...

Das bei XForce die Basis-Integergröße gerade 64 Bit ist dürfte daran liegen, dass Natter mit Vista kompliert - früher war der Integer definitiv kleiner, siehe die Variablengrenzen im Tutorial...
verfasst am: 05.08.2009, 16:11 · Edited by: sujin
Spielsatz Alliances

Registrierdatum: 14.07.2004, 14:47

 Beiträge: 1185
Woran kann es liegen, wenn TUFO.NearestEnemy immer nil ist?
Wird nur im Scanbereich des UFOs gesucht?

Bei meinen Test habe ich noch vorm spawnen des UFOs ein Flugzeug rausgeschickt, es war also auf jeden Fall eins auf dem Geoscape... nur sicherlich nicht im Scanbereich (der ist nämlich auf 0).

Edit: Ja, genau daran liegt es, mit mehr Sensorreichweite klappt es. Frage geklärt.
verfasst am: 05.08.2009, 16:19
Admin, Spielsatz GalWar

Registrierdatum: 31.08.2005, 21:51

 Beiträge: 5595
Zitat: sujin
Woran kann es liegen, wenn TUFO.NearestEnemy immer nil ist?
Wird nur im Scanbereich des UFOs gesucht?

Volltreffer, deshalb ist der Scanbereich ja definiert ;-)
verfasst am: 01.07.2010, 20:29
Spielsatz Alliances

Registrierdatum: 14.07.2004, 14:47

 Beiträge: 1185
Ich vermute, TOffer.Organisation ist der Index des Landes, dass das Angebot unterbreitet hat - kann das jemand bestätigen oder ggf. korrigieren?
verfasst am: 03.07.2010, 13:31 · Edited by: sujin
Spielsatz Alliances

Registrierdatum: 14.07.2004, 14:47

 Beiträge: 1185
Keiner? Wirklich keiner? Na gut, ich werde ja beim Testen sehen, ob es den gewünschten Effekt hat.

Dann halt das nächste Thema:
TDXPage.OnCanClose: TCanCloseEvent; wobei TCanCloseEvent = procedure(Sender: TOBJECT; var CanClose: Boolean);
Ich vermute mal, das ist ein Callback, der beim schließen der Seite aufgerufen wird und über canClose (pass-by-reference ist cooool) bestimmten kann, ob's ignoriert wird oder die Seite sich wirklich schließt. Wobei ich nicht verstehe, warum man dass nicht als function(Page: TDXPage): Boolean; umsetzt...
Oder hab ich die ganze Sache falsch verstanden?
verfasst am: 03.07.2010, 16:29
Spielsatz Alliances

Registrierdatum: 14.07.2004, 14:47

 Beiträge: 1185
Und wo wir schon dabei sind, gleich nochwas...
Gibt es eine Möglichkeit, den Spieler einen Punkt auf der Weltkarte auswählen zu lassen, wie es z.B. beim Basisbau passiert?
verfasst am: 19.07.2010, 18:28 · Edited by: Kreks
Registrierdatum: 22.08.2008, 15:51

 Beiträge: 403
Ich knüpf mal an den allgemein gehaltenen Thread-Titel an.
Es geht um Anwendung der Funktion TMission.CallProcedure(). Ich möchte UFOs skripten, die als Trägerschiffe fungieren und mehr als nur Begleitschutz UFOs erzeugen können, sondern wirklich kommandieren (@DirkF: so wie ich das sehe, haben deine Eariol-Lichter kein eigenes Skript, sondern werden vom Träger gesteuert? Stimmt das?) und dass diese Begleitschiffe auch fähig sind eigene Entscheidungen zu treffen und auch Rückmeldungen geben können.
Also hab ich mir folgendes gedacht: Die UFO AIs sind ja nichts anderes als TMission Objekte, die ich abfragen kann und über CallProcedure müsste ich Anweisungen und Objekte übertragen können, allerdings bin ich mir nicht ganz sicher wie das Funktionieren soll, da der zweite Parameter ein array_of __Pointer ist und die Doku dazu nichts hergibt. Kann jemand die folgende Pseudocodezeile richtig hinschreiben? Danke.
CallProcedure('FlyTo', TPoint); //Bewirkt, dass das UFO zum angegeben Punkt fliegt


@Sujin: ich kenne keine solche Funktion aber man könnte ein Workaround mit einem Flugzeug machen, dass einen Punkt markiert und so abfragen, welche Stelle der Spieler gewählt hat.
verfasst am: 19.07.2010, 18:45
Spielsatz Alliances

Registrierdatum: 14.07.2004, 14:47

 Beiträge: 1185
Ja, die Lichter werden vom Träger-Skript mitgesteuert.

Versuch's ruhig mal - ich denke aber, einfacher wäre es, das mit Events zu regeln. Dazu gibt's ein Skript namesn GEN03usercall in der scripts.pak und ich habe selber was ähnliches gebastelt, was jetzt hier im Forum herumfliegt.
verfasst am: 19.07.2010, 20:11
Admin, Spielsatz GalWar

Registrierdatum: 31.08.2005, 21:51

 Beiträge: 5595
Nein, das Trägerskript ist momentan eher ein Platzhalter.
Die Eariol benutzen das ACC92eariol-Skript, aber das ist nicht die geplante Lösung.

Was die Call-Prozeduren angeht: ich bin von den Event-Signalen gewechselt auf die Call-Steuerung, weil dies in vielen Punkten besser abläuft, auch wenn es etwas komplexer ist.

ACC91drone im Galwar ist das Skript, was später einmal unter anderem die Eariol steuern soll, neben verschiedenen anderen Funktionen. Dort findest Du auch mehr als genug Demos für die Call-Prozeduren.
Der "Array of Pointer" kann für jede Call-Funktion anders definiert werden, aber die aufgerufene Funktion benötigt genau dieselbe Definition für die Übergabevariablen (Reihenfolge, Variablentypen). Das sollte im Drone-Skript relativ gut beschrieben sein.

Falls Du Fehler im (noch nicht sauber arbeitenden) Drone-Skript findest, würde ich mich über ein Feedback freuen...
verfasst am: 20.07.2010, 13:34
Registrierdatum: 22.08.2008, 15:51

 Beiträge: 403
Funktioniert einfacher als gedacht...

Irgendwas falsches habe ich in deinem Skript nicht gefunden, aber ich weiß auch nicht wo nach ich suchen sollte.
verfasst am: 20.07.2010, 19:55
Admin, Spielsatz GalWar

Registrierdatum: 31.08.2005, 21:51

 Beiträge: 5595
Zitat: Kreks
Irgendwas falsches habe ich in deinem Skript nicht gefunden, aber ich weiß auch nicht wo nach ich suchen sollte.

Die offensichtlichen Fehler sind auch schon lange behoben - das Skript macht im realen Ablauf nicht ganz das, was es soll - die Anzahl gestarteter Dronen und deren Verhalten stimmt nicht und bricht irgendwann ab.
Und ich hatte überlegt ob es vielleicht ein Fehler ist, den ich aus "Betriebsblindheit" nicht sehe, aber der jemand anderem sofort ins Auge springt...

Seite: << [1] 2




Du musst dich registrieren um auf dieses Thema zu antworten.
Login :: » Name » Passwort

Ladezeit (sec.): 0.030 · Powered by miniBB 1.6 with parts of 1.7 © 2001-2003