Ja, wie denn? Records gehen problemlos, von denen mache ich auch gelegentlich Gebrauch. Aber sobald ich das unscheibare reserved word "class" verwenden will, hagelt es Fehlermeldungen.
Es läuft immer darauf hinaus, dass vor class ein identifier muss... was wie wo?
Ich habe mich hauptsächlich mit X-Skript aka Pascal-Script und weniger mit dessen großen Bruder Pascal beschäftigt, aber ein wenig habe ich schon mitbekommen... zum Beispiel, dass eine Klasse ungefähr so deklariert wird:

MyClass = Class(ParentClass)
  // Felder
  // Methoden
  // etc
end;

Wie deklariere ich bitte in Pascal-Skript eine Klasse? Oder, anders gefragt: Ist es überhaupt möglich, in eigene Klassen zu erstellen?

Nein.

Schade. Macht ein paar Sachen ein Stückchen komplizierter, zum Beispiel die Übergabe zusammenhängender Daten (records z.B.) zwischen Skripten. Ein Objekt könnte man immer auf TObject zurückführen und als global Object übergeben... hm, außer...

Wäre es besonders aufwendig, Arrays als globale Variablen zuzulassen?
Falls ja: Wäre es besonders aufwändig, ein Objekt mit beispielsweise einem Integer-, String- und Extended- und Boolean-Array einzuführen, das an sich erstmal keine Funktion im Hauptprogramm hat? Quasi nur für Skripte, die gerne mehrere Werte gleichzeitig übergeben würden.
Bevor jemand andere Baustellen erwähnt: Ich würde dann selbst versuchen,das umzusetzen.

schon gruselig, dass ich gerade dieselbe Frage ein paar Tage zuvor stellen wollte.


Kannst doch einen Array in einer Unit global festsetzen... wieso das Ganze also noch aufwändiger gestalten?




was genau schwebt dir vor? Ich bin mir nicht ganz sicher was du mit diesen Vorschlägen beabsichtigst.

Schonmal TDataHolder angschaut? Löst natürlich nicht alle Probleme - aber kleinere feste Strukturern sind damit schon möglich.

Das geht natürlich immer. Problem ist, der Array ist dann immer und überall global, wo die Unit benutzt wird... und damit ist auch der identifier belegt. Außerdem geht es mir gegen den Strich, mehr globale Variablen zu verwenden als unbedingt notwendig. Bei Spielsatzglobalen nicht ganz so streng, weil sie ihre eigenen Namespace haben...

Wenn ich das wüsste ^^
Bei den meisten meiner Fragen zur Skriptsprache geht es erstmal um spontane Gedankeneyperimente, nicht um ein konkretes Problem... ich schaff mir meine Probleme dann, wenn ich weiß, wie ich sie lösen kann ;-)
In diesem Fall ging es natürlich um Skriptübergreifende Arrays... Hauptanwendungsgebiet dürfte Spielsatzsteuerung sein.

TDataHolder sagt mir nicht wirklich was, aber der Name klingt vielversprechend. Zu schade, das das Wiki grade schrott ist o.O
-------------
Warning: fopen(ger_wiki.d/.flock) [function.fopen]: failed to open stream: Permission denied in /www/htdocs/xfdoc/index.php on line 655

Warning: Cannot modify header information - headers already sent by (output started at /www/htdocs/xfdoc/index.php:655) in /www/htdocs/xfdoc/index.php on line 421
PmWiki can't process your request

Cannot acquire lockfile

We are sorry for any inconvenience.

Return to this site's home page

http://www.pmichaud.com/ref/PmWiki/Lockfile

Ich glaub, dazu steht auch noch nichts im Wiki (das Problem mit dem Wiki dauert eventuell noch ein paar Tage, bis DirkF Zeit hat, sich das näher anzusehen). Sollte aber halbwegs selbsterklärend sein. Das Objekt muss mit Create erzeugt werden, und dann kann man je nach Bedarf mit den Methoden neue "Eigenschaften" ergänzen. Hauptproblem daran - keine Arrays. Macht also imho nur bei fixen Strukturen Sinn (oder man wandelt den Array immer in einen String um). Schau einfach mal in medit bei den Objekttypen.

Das Wiki-Problem war wohl rein Server-Seitig, heute geht es wieder ohne dass ich was gemacht hätte.
Übrigens war mir das aufgefallen, als ich gerade wegen TDataHolder gucken wollte, was davon im Wiki steht ;-)

Nicht allzuviel, leider:
XSkriptReferenz.TypTDataHolder

Man kann ein Objekt erzeugen und diesem verschiedene Variablen anhängen. Dazu gehört aber genausowenig ein Array wie das bei den globalen Variablen der Fall ist.
Dieses Objekt kann man dann auch in einer globalen Objekt-Speicherstelle ablegen und dadurch von allen Skripten aus darauf zugreifen, solange das Skript das diesen DataHolder verwaltet auch weiterhin im Hintergrund läuft.

Momentan besteht der Hauptnutzen imho darin, dass man über den Dataholder auch größere Datenmengen global zugreifbar machen kann, ohne für jeden Einzelwert die Liste der globalen Variablen zu verlängern.
Allerdings denke ich das damit noch einige Tricks möglich sein dürften, die bisher noch niemandem eingefallen sind - und man kann diesen Bereich von X-Skript später auch noch erweitern...

Du kannst einen String als Array missbrauchen in dem du die einzelnen Werte mit zB ';' trennst. Über string_util_explode (oder so ähnlich) kannst du das Konstrukt auseinander nehmen.

Rumtricksen kann man immer. Aber wenn es sauber geht, würd ich es gerne sauber erledigen ;-) Geht außerdem nur für String-Arrays ohne Probleme. Für Integer-Arrays braucht man schon ein StrToInt pro Element. Booleans brauchen eine extra Funktion, die z.B. für String "true" den Zustand true zurückgibt... und floats dürften sehr kompliziert werden.

Und bevor wer auf die Idee kommt... über

for i:=0 to 5 do
  game_apiregister_global_xxx('name['+StrToInt(i)+']');

müssen wir garnicht erst reden. Stellt euch einfach vor, wie die Global-Var-Liste dann nach ausgiebiger Verwendung dieses Wegs aussieht...

TDataHolder ist tatsächlich fast das, was ich mir gewünscht habe =) Es ist wirklich kein Hexenwerk, die mit ein paar kleinen Funktion genauso arbeiten zu lassen wie Arrays... ich sag nur function GetDataholderFloat(Dataholder,'name',index): Double;
Muchas Gracias!

Interessant wäre auch, ob TDataHolder auch mit Events zusammenarbeitet, oder als Missionsobjekt (mission_api-StartWithObject).

Genau dabei ist aber der Dataholder von Vorteil. Er arbeitet ähnlich wie die Globalen Variable, wird aber nicht in der globalen Liste aufgeführt.
Wenn man also den DataHolder in ein eigenes Verwaltungsskript legt und die entsprechenden Befehle extern aufruft, dann kann man dies problemlos nutzen ohne die Globalen Listen zu überladen...

Rein theoretisch müsste es gehen, oder? Ist ja ein Erbe von TObject, genau wie alle anderen. Schwebt dir da was konkretes vor?

Bingo!

Ja, dass das mal jemand ausprobiert. Hauptgrund für TDataHolder war damals, den Austausch größerer Datenmengen zu erleichtern. Bei einem Event könnte man dann mehrere Parameter übergeben, und über das Missionsobjekt könnte man ohne trickserei (z.B. castanweisungen) ganz einfach mehrere Steuerwerte an ein neues Skript übergeben.

Anwendungsbeispiel wäre z.B. der Laptop im Smirkovich (das und die Missionsverwaltung im Smirkvich waren der Grund, warum Jim_Raynor TDataHolder eingebaut hat). Man könnte dann Mails direkt als User-Event an das Skript schicken - inklusive Betreff und Inhalt. Derzeit läuft das alles umständlich über eine einzige globale Stringvariable (in der die Betreffzeilen angehängt werden), aus der dann beim öffnen des Laptops immer die eigentliche Struktur aufgebaut wird. Beliebige Mails sind damit nicht möglich. Dadurch ist der Laptop auch nicht ohne weiteres für andere Spielsätze übernehmbar.

procedure ChangeMail(Sender: TOBJECT);
begin
  ShowMail(MailList[CompMailList.ItemIndex]);
end;

procedure ShowMail(Betreff : String);
var
  i: Integer;
begin
  case '"'+Betreff+'"' of
    eM_EU_WiederAufbau  : CompTextViewer.Text:=Mail_Neuanfang_01;
    eM_Alexandrow_01 : CompTextViewer.Text:=Mail_Alleingelassen_01;
    eM_Alexandrow_02 : CompTextViewer.Text:=Mail_Alleingelassen_02;
    eM_Alexandrow_03 : CompTextViewer.Text:=Mail_Alleingelassen_03;
    else  CompTextViewer.Text:='Fehler im Skript. eMail-Betreff konnte nicht zugeordnet werden';
  end;
end;

procedure EnterLaptopPage(Sender: TObject);
begin
  MailList.CommaText:=game_api_GetString('eMails');
  // verhindert einen negativen ListenIndex, falls 'eMails' =''
  if (MailList.Count>0) then
  begin
    ShowMail(MailList[0]);

    CompMailList.Items:=MailList;
    CompMailList.OnChange:=@ChangeMail;
  end;
end;