[Bisasam]

Hallo,

ich habe das Problem, dass wenn ich den Prota von meinem Schiff auf eine Insel schicke, die Dialoge auf der Insel nicht mehr die Länge des Gesprochenen haben. Selbst wenn die Sprachausgabe vorbei ist, bleibt der Text im Untertitel noch ca. 5 Sekunden stehen (die Sounddatei ist nicht so lang, das habe ich geprüft).

Das Seltsame ist, dass das anscheinend nur auf dieser Welt passiert. In meiner anderen Welt sind die Untertitel und die Sprachausgabe perfekt synchron.
Desweiteren werden keine Sounds beim Kapitelwechsel abgespielt, obwohl ich genau die gleiche Funktion nutze wie vorher. In der einen Welt hört man was, in der anderen nicht.

Der Unterschied zwischen den beiden Welten ist, dass es viele Vobs in Form von Bäumen und Pflanzen gibt und (und das ist wohl ausschlaggebend) dass ich auf dem Schiff eine Musikzone habe, aber nicht auf der Insel.

Können fehlende Musikzonen etwa dafür sorgen, dass sowas passiert? Kann ich mir nicht so recht vorstellen.

Soundvobs für Wasserfallgeräusche gibt's aber und die funktionieren auch.

[Lehona]

Wenn du schon so eine Vermutung hast, probier's doch aus? Ich könnte mir zumindest durchaus vorstellen, dass das dazu führen könnte. Wer weiß ob PB getestet haben was passiert, wenn es keine einzige Musikzone in der Welt gibt - das ist im Originalspiel vermutlich einfach nie vorgekommen.

[mud-freak]

Handelt es sich um Gothic 1 und benutzt du LeGo?

[Bisasam]

In dem Fall Gothic 2 und ja ich nutze LeGo.

[mud-freak]

In Gothic 1 in Verbindung mit LeGo kann das Dialog-System kaputt gehen, wenn man in Hooks oder FrameFunctions Hlp_GetNpc benutzt (Details siehe hier). Das war mein erster Gedanke, aber mit Gothic 2 ist mir das aber noch nicht begegnet. Ich schätze also nicht, dass es daran liegt.

[Lehona]

In Gothic 1 in Verbindung mit LeGo kann das Dialog-System kaputt gehen, wenn man in Hooks oder FrameFunctions Hlp_GetNpc benutzt (Details siehe hier). Das war mein erster Gedanke, aber mit Gothic 2 ist mir das aber noch nicht begegnet. Ich schätze also nicht, dass es daran liegt.

Sieht so aus als bräuchten die Hooks eine Möglichkeit, den Kontext zu sichern/wiederherzustellen. Du hattest ja bereits eine Version vorgeschlagen, yINSTANCE_HELP und die aktive Instanz (MEM_GetUseInstance()) sollten da wohl auch noch rein.

[Bisasam]

Ich nutze Hlp_GetNpc in G1 nur in einem FrameTrigger, der mit der Welt verbunden ist. Also einer mit nem oCTriggerscript und ner Target-Schleife. Hatte da bisher noch keine Probleme.
In so einem Fall würde ich also von Framefuncs zu der obigen Methode wechseln.

[mud-freak]

Ich nutze Hlp_GetNpc in G1 nur in einem FrameTrigger, der mit der Welt verbunden ist. Also einer mit nem oCTriggerscript und ner Target-Schleife. Hatte da bisher noch keine Probleme.
In so einem Fall würde ich also von Framefuncs zu der obigen Methode wechseln.

Nein, mach dir da nicht unnötige Arbeit. Ein Fix dafür ist im Grunde schon unterwegs.

Sieht so aus als bräuchten die Hooks eine Möglichkeit, den Kontext zu sichern/wiederherzustellen. Du hattest ja bereits eine Version vorgeschlagen, yINSTANCE_HELP und die aktive Instanz (MEM_GetUseInstance()) sollten da wohl auch noch rein.

Die könnte man vielleicht auch einfach auf den Stack legen, wobei ich nicht weiss an welcher Adresse ÿINSTANCE_HELP liegt. Ich habe nur umständliche Ideen.

var zCPar_Symbol sym; sym = _^(MEM_ReadIntArray(currSymbolTableAddress, 0));
var int addr; addr = sym.offset;

// Oder
var int addr; addr = _@(NULL);

// Oder
var int addr; addr = _@(ÿINSTANCE_HELP);

Oder geht das noch einfacher (liegt es immer an der selben Adresse im Speicher)?




Bisasam, konntest du dein ursprüngliches Problem hier aus dem Thread schon weiter eingrenzen?

[NicoDE]

Sieht so aus als bräuchten die Hooks eine Möglichkeit, den Kontext zu sichern/wiederherzustellen.

Ja, rekursive Hooks sind bislang ein Problem, aber nicht nur das. In den Hook-Funktionen sollte man wahrscheinlich auch aufpassen, dass man nichts auf dem Stack liegen lässt (passiert schnell, wegen nicht verwendetem Rückgabewert und/oder Stack-Fehlern bei bestimmten Externals). Es könnte passieren, dass eine laufende Skriptfunktion durch die Ausführung eines Skript-Hooks gestört wird (ich denke, dass das genau das ist, was mit GFA im alten Lager passiert ist, da dort ständig sehr viele Skriptfunktionen aufgerufen werden). Leider hatte ich noch keine Zeit, mir das technische Problem im Detail anzusehen.

ps: "ÿINSTANCE_HELP" ist ein ganz normales Symbol, welches automatisch vom ZenGin-Parser angelegt wird. Da dies immer als erstes passiert, ist es immer das Symbol mit dem Index 0. Da es sich um einen gültigen Symbolnamen handelt, kann man ihn einfach im Skript per Namen verwenden.
pps: zCPar_Symbol::SetUseInstance setz zCPar_Symbol::instance_sym und zCPar_Symbol::instance_adr (beides globale Variablen). Wäre blöd, wenn nur eine gesichert/wiederhergestellt wird (und bei der Wiederherstellung hat man das Henne-Ei-Problem, man darf danach nicht auf Klassenvariablen zugreifen, da es sonst wieder überschrieben wird...)

[Lehona]

LeGo bietet MEM_SetUseInstance(ptr) an, das setzt Index und Adresse der "UseInstance", damit sollte das also funktionieren. Das sollte die UseInstance höchstens beim ersten Aufruf von MEM_WriteInt() überschreiben (wegen des Bootstrappings in Ikarus), aber das ist ja sowieso nie der Fall, wenn bereits eine Hook angelegt wurde.

Die könnte man vielleicht auch einfach auf den Stack legen...

Dem Gothic Datenstack kann man nicht trauen ;-) Nico hat ja schon erwähnt, wie schnell plötzlich zusätzliche Werte auf dem Stack landen können. Andersrum gibt es auch Funktionen, die sich darauf verlassen, dass der Stack leer ist (Von einem leeren Stack poppen -> 0).

Ich denke man wird den Kontext in einem eigenen Stack sichern müssen (nicht-persistenter Speicher sollte ja reichen). Vermutlich sollten wir die Hooks umbauen, so dass nicht direkt die angegebene Funktion aufgerufen wird sondern bloß eine feste Funktion, die die eigentliche Funktion dann als Parameter bekommt (irgendwie doof zu beschreiben, ich hoffe du verstehst was ich meine). Dann kann man sich leicht um so Kram wie Kontextsicherung kümmern. Vielleicht reicht es auch schon, wenn man locals() in besagter Funktion aufruft und ein paar der globalen Variablen (v.a. self/other) zusätzlich sichert.

[mud-freak]

Vermutlich sollten wir die Hooks umbauen, so dass nicht direkt die angegebene Funktion aufgerufen wird sondern bloß eine feste Funktion, die die eigentliche Funktion dann als Parameter bekommt (irgendwie doof zu beschreiben, ich hoffe du verstehst was ich meine).

Ja, das ist mir auch in den Sinn gekommen, weil mein zusätzlicher Assembly-Code das ganze etwas lang und unübersichtlich gemacht hat. Dabei könnte man auch umbauen, wie mehrere Funktionen an der selben Adresse hooken. Bisher werden dabei ja die Register vor und nach jedem einzelnen Funktionsaufruf hin- und hergeschoben. Etwas ähnliches wie das Foreachhandle-Konstrukt wie in den Framefunctions wäre da vielleicht auch nicht schlecht.

Vielleicht könnten wir das in den LeGo-Thread verlegen; hier geht es ja um ein (womöglich) komplett unabhängiges Problem mit den Dialogen in Gothic 2.