[Degenerated]

Hmm, doch anscheinend schon. Es werden alle gespeichert, die keine flags gesetzt haben.

Flags gibt es für: const, return, classvar, external und merged.

Lokales dürfte also doch gespeichert werden.

[Lehona]

Hmm, doch anscheinend schon. Es werden alle gespeichert, die keine flags gesetzt haben.

Flags gibt es für: const, return, classvar, external und merged.

Lokales dürfte also doch gespeichert werden.

Gut, sonst hätte ich jetzt fehlerhaften Code berichtigen müssen.

Ist 'return' das Flag für Funktionen, die nicht 'void' als Rückgabewert haben? Und was zur Hölle ist 'merged'?

[Degenerated]

Muss ich schauen welche Symbole soetwas gesetzt haben, bin nur leider noch in der Uni. Später also mehr dazu

[werauchimmer]

Ist 'return' das Flag für Funktionen, die nicht 'void' als Rückgabewert haben?

Ja.

Und was zur Hölle ist 'merged'?

Es würde mich auch interessieren, wofür das gedacht war, verwendet wird es aber scheinbar nicht.


Edit@NicoDE: Danke für die Info.

[NicoDE]

Es würde mich auch interessieren, wofür das gedacht war, verwendet wird es aber scheinbar nicht.

Soweit ich mich erinnere, ging es um zusammengeführte Symbole/Variablen aus unterschiedlichen DATs (wäre halt nett gewesen, "HERO" aus der Gothic-Parser-Instanz auch in der Menu-Parser-Instanz zu haben - wurde dann halt über Namenskonventionen der Menu-Item-Instanzen geregelt).
Wurde nicht implementiert/verwendet, wie auch externe Variablen.

[Bisasam]

Wenn alles gespeichert wird, warum sind meine var strings nach dem neustart dann immer leer? Also ich meine wenn ich speichere, Spiel beende und dann Spielstand lade.

[Degenerated]

Wenn alles gespeichert wird, warum sind meine var strings nach dem neustart dann immer leer? Also ich meine wenn ich speichere, Spiel beende und dann Spielstand lade.

Genauer gesagt werden alle nicht-const globalen integervariablen gespeichert. Nur der Vollständigkeithalber. Soweit ich weiß kannst du aber mit LeGos PermMem auch andere Dinge abspeichern.

Deswegen

[Bisasam]

Deswegen

Da hast du mich verwirrt. Ich dachte du hättest meine Antwort bezüglich der Strings korrigieren wollen.

[werauchimmer]

Apropos verwirren, mit Strings kann man übrigens den Gothic-Compiler dazu bringen, eine nicht funktionierende Gothic.dat zu erstellen.
Man braucht nur einen Zeilenumbruch in einen String einzubauen, der wird vom Parser akzeptiert, d.h. ein Start über die GothicStarter_mod.exe mit "Skripte parsen" wird problemlos funktionieren, wogegen ein Start ohne parsen scheitert, weil beim Auslesen der Strings aus der Gothic.dat der Zeilenumbruch (#10) als Ende des Strings gilt und die restlichen Zeichen des Strings fehlinterpretiert werden, bzw. zum Absturz führen.
Theoretisch könnte man auf diese Weise auch versuchen, sinnvollen Code in die Gothic.dat zu injizieren, das scheitert dann aber daran, dass die Anzahl der Symbole oder Codepositionen nicht mehr stimmen etc.

[Lehona]

Apropos verwirren, mit Strings kann man übrigens den Gothic-Compiler dazu bringen, eine nicht funktionierende Gothic.dat zu erstellen.
Man braucht nur einen Zeilenumbruch in einen String einzubauen, der wird vom Parser akzeptiert, d.h. ein Start über die GothicStarter_mod.exe mit "Skripte parsen" wird problemlos funktionieren, wogegen ein Start ohne parsen scheitert, weil beim Auslesen der Strings aus der Gothic.dat der Zeilenumbruch (#10) als Ende des Strings gilt und die restlichen Zeichen des Strings fehlinterpretiert werden, bzw. zum Absturz führen.
Theoretisch könnte man auf diese Weise auch versuchen, sinnvollen Code in die Gothic.dat zu injizieren, das scheitert dann aber daran, dass die Anzahl der Symbole oder Codepositionen nicht mehr stimmen etc.

Nette Idee, aber ich glaube es ist einfacher, entweder den Code zur Laufzeit zu verändern (der Bytecode ist ziemlich simpel - Ikarus enthält viele Beispiele, wie man das sinnvoll nutzen kann) oder direkt einen Patcher zu schreiben (Gottfried hat mal etwas geschrieben, was effektiv Ikarus in die Menü-Scripte injiziert hat, weil da keine Externals vorhanden sind).