Die vom Editor angezeigten ID's für UFOs etc. sind vorzeichenlose 32-Bit-Zahlen von 0 bis 4294967295.
Im XScript sind die Variablen aber vorzeichenbehaftete 32-Bit-Zahlen von -2147483648 bis +2147483647.

Als Ergebnis gibt es einige UFO-IDs, die bei einer entsprechenden Zuweisung einen Fehler produzieren.
Der Fehler ist derselbe ob man für die Variablentypen Longword oder Integer setzt.

Gibt es irgendeine Cast-Anweisung oder einen Variablentypen mit der man die IDs trotzdem korrekt zuweisen/verwalten kann?

hast du schon mal versucht, die ufo-id in einer konstanten zu speichern? da muss man keine datentypen eingeben, bei mir hat das immer funktioniert.

Welche Variablen denn. Also vorzeichenlosen 32-Bit Typen kannst du Cardinal nehmen. Ansonsten ist auch eine Eingabe in Hex ($01AB z.b.) möglich. Ansonsten ist der Weg von Arne auch ganz gut :)

Ich hatte eine direkte Ziffernzuweisung versucht, also

speicher:=4294957296;

Das ergab dann den Fehler, egal wie ich die Variable definierte - cardinal oder Hexwerte hab ich nicht versucht.

@ArneL: auch bei IDs am oberen Ende der Skala? Die UFOs mit den niedrigen IDs haben bei mir auch geklappt...

Hmmm, auch auf die Gefahr hin, mich lächerlich zu machen. Aber ich seh da spontan noch ein ganz anderes Problem. Was nützt es DirkF, wenn er die ID irgendwie speichern kann. Beim Aufruf von ufo_api_GetUFModelByID() würde eine Variable vom Typ cardinal doch wieder in LongInt umgewandelt werden, befor die Funktion abgearbeitet wird, oder? Denn dann könnte man entsprechende IDs überhaupt nicht verarbeiten.

liegt ja auch außerhalb des Bereiches ;)

Ich werde es mir mal in Ruhe anschauen.

Die Zahl oben ist fiktiv - das Problem ist mit der ID des kleinen Scouts aufgetaucht, die ist ähnlich groß.
Kann schon im GWIv001.pak überprüft werden (im aktuellen v003 gibt es auch noch ein zweites UFO mit so hoher ID, die anderen UFOs haben niedrigere IDs) ...

wenn du damit ids > +2147483647 meinst, ja. bei 3188438447 hat es funktioniert

Hmm, ich hab mir das jetzt nochmal angesehen. DirkF hat recht, die zu großen IDs werden entsprechend in negative Werte umgewandelt (das dürfte letztlich auch mit den als Konstante definierten IDs passieren). Nur sehe ich irgendwie nicht, wo das Problem liegt. Denn um das UFO dann tatsächlich zu erzeugen, wird die negative ID (zumindest bei mir) offensichtlich trotzdem richtig interpretiert, was ja auch nicht verwundert (falls X-Force wirklich nur mit positiven Int-Werten arbeitet, dürfte die negative ID vor der Verarbeitung natürlich intern wieder in eine positive umgewandelt werden). Die von mir getesteten UFOs (z.B. Doom aus dem defaullt) wurden zumindest trotz negativer ID korekt erzeugt.

Mittlerweile weiß ich echt nicht mehr wo das Problem liegt ;)

Also die Funktionen, die eine ID erwarten sind als LongWord (für PascalScript ist Cardinal=LongWord) definiert. Nicht zu verwechseln mit LongInt. LongWord ist vorzeichenlos.

Funktioniert nicht, weil 4294957296 ausserhalb des Bereiches liegt. So wie du ja selbst geschrieben hast:Mit diesen Zahlen sollte es auch klappen. Und wie gesagt, wenn du diese Werte in einer Variablen speichern willst nimm Cardinal bzw. LongWord (ist ja beides dasselbe).

Umgewandelt wird da nichts. Die binäre Darstellung bleibt erhalten und wird nur unterschiedlich interpretiert (eben mit oder ohne Vorzeichen).

Hmm, die Zahl liegt schon noch im Bereich, aber da sie eh nur fiktiv war/ist, spielt das wohl keine Rolle. Davon mal abgesehen sollte das ganze aber auch problemlos mit LongInt klappen, da die binäre Darstellung ja erhalten bleibt. Ist es denn zu einer Fehlermeldung gekommen?

PS: Und wie hast du überhaupt rausbekommen, dass die Werte "negativ" sind? Bei der Verwendung von inttostr würde LongWord ja als LongInt interpretiert werden, was zu einer "falschen" Anzeige führt. Oder benutzt du die in medit eingebaute Funktion Variablen anzeigen zu lassen?

OK-wenn die Bits erhalten bleiben muss ich einfach nur vorher die kritischen IDs in ihre negativen Zahlenäquivalente umrechnen und die dann verwenden - damit kann ich leben.

Das Problem ist das ich nicht wirklich mit Konstanten arbeiten kann - in der Neueingabe des galaktischen Krieges sind zwar erst 11 UFOs eingegeben, aber die alte Version 0.235 enthielt bereits über 130 UFOs - die kann ich nicht über Namenskonstanten verwalten.

Deshalb hatte ich einen Record-Array aufgesetzt, wo unter anderem das ID als Longword definiert ist. Und irgendwas ist dann anscheinend anders als bei einer Konstantenzuweisung, denn bei einer Anweisung nach dem Motto (verkürzt)

ufolist:Array of Longword;
ufolist[0]:=4280772532;

kriegte ich bei Zugriffen immer die Meldung das die 4280772532 außerhalb des gültigen Bereiches läge.
Und die 4280772532 ist eine echte ID aus meinem Spielsatz, jetzt konnte ich nachschauen.

Allerdings werde ich die Angaben in Zukunft sowieso aus einer Excel-Tabelle in Strings bilden lassen, da ist das kein Problem die kritischen Zahlen mit einem Zusatzbefehl in negative zu verwandeln und diese dann zuzuordnen.

Die "Quelle" für die Wertegrenzen war die Delphi-Source, da hat Jim schon öfter drauf verwiesen als Vorlage für XScript-Befehle. Und das war auch erstmal eine logische Erklärung für das Verhalten...

Hmm, ich glaube, der Fehler liegt da nicht bei der zu großen Zahl. Das "out of range" bezieht sich da vielmehr direkt auf den Array. Ich würde sagen, du musst vorher noch die Länge des Arrays definieren, z.B.

setarraylength(ufolist,130);

Damit sollte es dann (auch ohne Umrechnung in negative Werte) klappen.

Der war schon definiert, und die Fehlermeldung im medit nannte ausdrücklich die Ziffer 4280772532 außerhalb des gültigen Bereiches - mit dem Out of Range des Arrays hatte ich mich vorher herumgeschlagen, da ich vergessen hatte die Konstante GWCufos von 2 auf 11 zu erhöhen (ich hatte ein setarraylength(ufolist,GWCufos) eingebaut).

Aber wie gesagt - ich werde im verlauf der nächsten 2-3 Tage sowieso einige der Skripte umschreiben, mal gucken was danach passiert...

MMh. Sehr komisch alles. hatte bei meinen Tests keine Probleme. Selbst wenn die zahlen ausserhalb des Bereiches lagen, wurden diese zugewiesen und dann halt negativ angezeigt wird ...

Ja, war bei mir genauso. Daher meine Vermutung mit der array-Länge. Vielleicht kannst du Jim ja mal ein Beispiel zukommen lassen?

Ich wollte das machen, sobald ich die Skripte umgeschrieben und angepasst habe - zur Zeit bin ich in einem zwischenstadium, und den alten Zustand wieder herzustellen dauert fast genausolange wie den neuen herzustellen.

Wenn der Fehler durch die Umstellungen nicht von alleine verschwindet, dann melde ich mich nochmal.

Ich habe es aus Zeitmangel noch nicht testen können, aber ich plane das jetzt zu umgehen.

Aufgrund einiger anderer Skriptumstellungen wurde die ursprüngliche Planung eines Datenarrays eher ineffektiv, und in der neuen Programmierung über Datenstrings brauche ich die ID nur für eine einzige IF-Abfrage zur Indexbestimmung.

Und mit strtoint64 ist die einzige verbleibende (ungetestete) Frage, ob ich Longword und int64 direkt im IF vergleichen kann oder eine Cast-Anweisung brauche. Das sollte aber kein Problem mehr sein, und heute Abend kann ich das auch endlich testen...

Your voice is magnificent. https://hearingaidsstaugustine.com

Im really excited about this.. cant wait! moldremovaltucsonaz.com