[LOGX]

Momentan gibt es noch keine offizielle Unterstützung für Gothic 1. Ich benutze aber problemlos die Dateien aus dem Development-Branch vom LeGo SVN. Damit funktioniert bei mir soweit alles (was ich davon benutze) problemlos: Ich konnte, unter Benutzung von Hooks, FrameFunctions, ConsoleCommands und Views, Gothic 1 komplett durchspielen. "Nicht offiziell unterstützt" sage ich deshalb, weil noch nicht alle Pakete ausgiebig getestet wurden.

Wenn du die Dateien aus dem dev-Branch für Gothic 1 verwenden willst, musst du die Datei EngineAdr_G2.d aus deinem Verzeichnis löschen.

Vielen Dank für den Tipp! Kompiliert erstmal fehlerfrei. Welche Funktion muss ich denn zur Initialisierung von LeGo aufrufen? Und wo sollte ich das im Optimalfall in G1 tun? Ein Init_Global() wie in der LeGo-Readme beschrieben kann ich in den G1-Skripten leider nicht finden. Ich benötige die Listen-Implementation von LeGo in G1.

[Lehona]

Ich bin mir ziemlich sicher, dass die Listen nicht initialisiert werden müssen, d.h. das sollte sofort lauffähig sein.

Um LeGo zu initialisieren (falls du noch andere Sachen verwenden möchtest) gibt es in G1 leider keine so gut geeignete Stelle wie die INIT_Global(), man wird also wohl nicht drumherum kommen, den LeGo_Init-Eintrag in jede INIT_XXX()-Funktion zu schreiben (oder zumindest indirekt - man kann sich ja seine eigene INIT_Global() bauen, die dann aus jeder INIT_XXX() aufgerufen wird).

Edit: Ja, es gibt keine Initialisierung für die Listen.

[Umfi]

Etwas spät aber hier nun eine Lösung:

func void changeTradeValueDisplay() {
    var oCItem itm; itm = _^(EBX); // Displayed item
    var oCNpc npc; npc = _^(MEM_InformationMan.npc); // Trading NPC

    // Overwrite the display of the item value
    MEM_WriteInt(/*esp+144h-ach*/ ESP+152, 19); // E.g. new value: 19 gold
};

const int oCItemContainer__DrawItemInfo = 7369937; //0x7074D1
HookEngineF(oCItemContainer__DrawItemInfo, 7, changeTradeValueDisplay);

changeTradeValueDisplay wird nur aufgerufen, wenn man sich auf der rechten Seite (Spielerinventar) des Tradingmenus befindet und überschreibt nur den Anzeigewert. Den tatsächlichen Verkaufswert muss man nach wie vor überschreiben.
Seltsamerweise ist standardmässig die horizontale Position der Wert-Anzeige im Infofenster nicht immer an der selben Stelle (vgl. z.B. Bögen und Pfeile). Das ist schon immer so und hat glaube ich was mit der Itemkategorie zutun. Möglicherweise kann es daher zu Problemen kommen mit vielstelligen Werten (alles bis drei einschl. dreistellig passt aber immer).

Vielen Dank, funktioniert super!

[Fisk2033]

Weiß nicht, ob ich es hier oder im ScriptBin fragen soll, aber irgendwie ists ja eine Funktion die komplett auf LeGo aufbaut. Ich hab gestern Screefade ausprobiert. Erstmal den Effekt finde ich super und er ist genau das, was ich in dieser Situation benötige. Problem ist nur der Ablauf.
Eigentlich sollte es so sein:
1. Held beginnt Dialog mit NPC
2. Gespräch zwischen NPC/Held ist erledigt
3. Screenfade beginnt und wirkt
4. Held und NPC werden weg teleportiert
5. Screenfade wird wieder ausgeblendet

Momentan wird der Screenfade, aber als aller erstes ausgeführt. Sprich der Dialog findet im Blackscreen statt. Wie krieg ich den wirklich erst ausgeführt, wenn die Dialoge alle durch sind?

[mud-freak]

Momentan wird der Screenfade, aber als aller erstes ausgeführt. Sprich der Dialog findet im Blackscreen statt. Wie krieg ich den wirklich erst ausgeführt, wenn die Dialoge alle durch sind?

Hast du es schon mit AI_Function probiert?

[Fisk2033]

Hast du es schon mit AI_Function probiert?

Ich Dummkopf. *Facepalm-Smiley*

Danke, wie konnte ich das nur vergessen >.<

[Lehona]

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.

In der Tat.

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.

LeGo bietet EventHandler, damit erreicht man alle Funktionen, die sich für eine bestimmte Adresse angemeldet haben Muss man nur eben Funktionen schreiben, die auch einen Ptr anstatt Handle akzeptieren.

[mud-freak]

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 versuche gerade die Vorgehensweise zu verstehen. Wäre es dann sinnvoll,...

1. ... die Register wie gehabt in Deaduls-Variablen zur Verfügung zu stellen
2. ... globale Instanzen (yINSTANCE_HELP, self, other, ...?) und Register in Deadalus zu sichern
3. ... den Stack in Deadalus zu sichern
4. ... den Stack dann zu leeren (weil einige Externals einen leeren Stack erwarten)
5. ... alle hookenden Deadalusfunktionen (mittels EventHandler) aufzurufen
6. ... dann den Stack wieder zu leeren (weil einige Externals den Stack nicht ordentlich aufräumen)
7. ... dann den Stack aus der Deadalus-Sicherung wiederherzustellen
8. ... die Register und globale Instanzen wiederherzustellen
9. ... die manipulierten Deadalus-Variablen wieder zurück in die Register schieben (CX, DI und AX)

Wenn man die ganzen Sichererungen in Deadalus dann noch in einem Stack-ähnlichem Datentyp anlegt, wäre sie auch vor rekursiven Hooks geschützt. Gibt es in Deadalus (bzw. Ikarus) schon Stack-ähnliche Datentypen?

Habe ich das soweit richtig zusammen gefasst?


EDIT: Vielleicht würden für die Sicherungen Arrays mit diesen bereits existierenden Funktionen genügen:

MEM_ArrayPush(array, value);
value = MEM_ArrayPop(array);

[Teron Gorefiend]

schön zu sehen dass es was neues für G1 gibt denn meine Pläne G1 als G2 Mod zu machen kann ich vergessen, die Weltenumwandlung und Spacer klappen einfach nicht, Was würde ich für eine G1 als G2 mod geben

Habe zwar schonmal gefragt wegen Schadernsberechnung in G1 ändern (thread), aber das war relativ lange her sodass ich nochmal nachfrage ob es inzwischen für G1 möglich ist.

[mud-freak]

Ich habe mich mal hingesetzt und die Hooks neu implementiert. Hier eine kleine Übersicht wie sie nun funktionieren:

Nach wie vor wird aus der zu hookenden Engine-funktion herausgesprungen. An der neuen Adresse werden allerdings die Register nicht direkt in Deadalus-Variablen kopiert sondern einfach mit pushad der anschliessend aufgerufenen Verteilerfunktion als Funktionsparameter zur Verfügung gestellt.
Mit locals(); wird der Kontext in lokale Deadalus-Variablen gesichert: Die Registervariablen (für rekursive Hooks), die globalen Instanzen (falls diese überschrieben werden) - um rekursive Hooks zu ermöglichen.
Bevor die auf dem Stack liegenden Werte dann überschrieben und nach der Verteilerfunktion wieder in die Register geschoben werden (popad), werden die hookenden Deadalus-Funktionen von der Verteilerfunktion aufgerufen - nun aber mittels eines EventHandlers. Das hat vier Vorteile:

1. Nun wird zwischen jeder hookenden Deadalus-Funktion der Kontext wiederhergestellt, die Register werden aber nicht wie zuvor jedes mal hin und her kopiert, sondern erst nachdem alle hookenden Deadalus-Funktionen durchlaufen wurden.
2. Mit dem Pushen eines Puffers auf dem Datenstack (zehn mal Token_PushInt 0) vor jedem Funktionsaufruf soll verhindert werden dass unartige Funktionen etwas vom Stack poppen (ich hoffe das kommt nie mehr als zehn mal vor).
3. Nach jedem Funktionsaufruf wird der Datenstackpointer wiederhergestellt, um das was vom Puffer noch da ist verschwinden zu lassen und um auf dem Stack liegen gebliebene Daten zu verwerfen. Der Stackpointer zeigt also genau dahin wo er vorher drauf gezeigt hat.
4. Als netter Nebeneffekt ist es nun nicht mehr notwendig darauf zu achten, dass Hooks genau nur einmalig Initialisiert werden.
   Folgendes ist nicht mehr nötig:
   

   const int once = 0;
   if (!once) {
       HookEngineF(0x123456, 5, foo);
       once = 1;
   };

   Im Folgenden hooken foo() und bar() jeweils nur einmal die Adresse 0x123456. Alle weiteren identischen Initialisierungen werden ignoriert. Die Reihenfolge bleibt aber bestehen: erst wird foo() dann wird bar() auf gerufen.
   

   HookEngineF(0x123456, 5, foo); // Initialize hook and add foo() to EventHandler
   HookEngineF(0x123456, 5, foo); // Ignore
   HookEngineF(0x123456, 5, bar); // Add bar() to EventHandler
   HookEngineF(0x123456, 5, foo); // Ignore
   HookEngineF(0x123456, 5, bar); // Ignore
   HookEngineF(0x123456, 5, foo); // Ignore

Wo ich noch unsicher bin, ist bei der Sicherung von ÿINSTANCE_HELP. Das Symbol selbst führte bei mir in Deadalus zu einem Syntaxfehler (instHlpBak = _@(ÿINSTANCE_HELP);). Ob folgender Ansatz richtig ist, weiss ich allerdings nicht, weil hier nur der Offset (Datenzeiger) des Instanzsymbols gesichert wird.

    // Get address of yINSTANCE_HELP by symbol index 0
    const int instHlpAddr = 0;
    if (!instHlpAddr) {
        instHlpAddr = MEM_GetSymbolByIndex(0)+zCParSymbol_offset_offset;
    };

    // Also secure global instances
    // [...]
    var int iHlpBak;  iHlpBak  = MEM_ReadInt(instHlpAddr); // Is the correct way to do this?

    // [...]

    // Restore global instances in between function calls
    // [...]
    MEM_WriteInt(instHlpAddr, iHlpBak);

Mich würde freuen, wenn ein Paar/paar prüfende Augen die Revision im dev-Branch im SVN anschauen könnten. Insgesamt sind es nicht viele Zeilen.

Moddern rate ich mit der neuen Implementierung vorsichtig zu sein, bis ein Zweiter meinen Code angeschaut hat, weil viele LeGo-Paket auf Hooks aufbauen.


EDIT: An der Benutzung von Hooks ändert sich übrigens nichts und die Implementierung ist Rückwärts-kompatibel.

EDIT2: Eine weitere Unsicherheit habe ich vergessen: In der alten Implementierung von Hooks lassen sich nur ECX, EAX und EDI duch die Deadalus-Funktion manipulieren. ESI, EBX und EDX aber nicht. Gibt es dafür einen Grund?

[Lehona]

Sehr gute Arbeit!

Ich bin ein wenig überrascht, dass zCParser::CallFunc beliebige Parameterzahlen vom Stack poppt (natürlich anhand der Daedalus-Funktionssignatur), aber umso besser, wenn es so simpel ist

Deine Sicherung von ÿINSTANCE_HELP sieht korrekt aus - MEM_AssignInst() macht im Prinzip auch nur das.
Vermutlich sollte man noch die momentane Instanz sichern (siehe MEM_Get/SetUseInstance() in EngineAdr_G2.d), aber das muss am besten direkt am Anfang/Ende der Funktion passieren, weil man das Symbol sonst selber überschreibt bevor man es speichern kann. Eventuell funken einem hier die locals() dazwischen - das müsste man ausprobieren.

EDIT2: Eine weitere Unsicherheit habe ich vergessen: In der alten Implementierung von Hooks lassen sich nur ECX, EAX und EDI duch die Deadalus-Funktion manipulieren. ESI, EBX und EDX aber nicht. Gibt es dafür einen Grund?

Ja und zwar einen ganz einfachen: Wir waren nicht klug genug, um den Stack zu benutzen um die Register zu setzen/lesen, d.h. ich habe alle Opcodes dafür von Hand rausgesucht. Da das relativ lästig war, hab ich das eher nach Bedarf gemacht

[mud-freak]

Habe zwar schonmal gefragt wegen Schadernsberechnung in G1 ändern (thread), aber das war relativ lange her sodass ich nochmal nachfrage ob es inzwischen für G1 möglich ist.

Ja, das sollte funktionieren. Im selben Forenthread, den du verlinkt hast gibt es später einen Post mit einer Portierung für Gothic 1.
Wie du LeGo in Gothic 1 zum Laufen bringst, findest du hier in diesem Thread ein paar Posts über deinem. Dazu sei nochmals gesagt, dass keine Stabilität für den Development-Branch von LeGo gewährleistet ist.

Vermutlich sollte man noch die momentane Instanz sichern (siehe MEM_Get/SetUseInstance() in EngineAdr_G2.d), aber das muss am besten direkt am Anfang/Ende der Funktion passieren, weil man das Symbol sonst selber überschreibt bevor man es speichern kann. Eventuell funken einem hier die locals() dazwischen - das müsste man ausprobieren.

MEM_Get/SetUseInstance() war schon drin. Ich habe es aber jetzt mal wie du sagst zu Beginn bzw. am Ende der Funktion aufgerufen. Ich habe mich nicht komplett in locals() reingefuchst, aber weil MEM_GetUseInstance() nun vor locals() aufgerufen wird, habe ich es in einer temporären Variable zwischengespeichert, damit es nach einer Umspeicherung anschliessend von locals() vernünftig auf den Peudostack gelegt wird (ich hoffe das habe ich richtig verstanden), siehe HookEngine.d in Rev 140 Zeile 36 und Zeile 63.
Testen kann ich das ganze leider nicht, weil ich keine Adresse kenne an der das beim Hooken zu einem Problem werden könnte. Die Sicherung der anderen globalen Instanzen scheint aber zu funktionieren; Den Bug den Nico mit den Dialogen im alten Lager in GFA entdeckt hatte, bezieht sich nur auf yINSTANCE_HELP und ist mit der neuen Implementierung gefixt.

[Fisk2033]

Ich habe mich mal hingesetzt und die Hooks neu implementiert. Hier eine kleine Übersicht wie sie nun funktionieren:
[...]

Ich weiß ja noch, wer mir Ende 2016 geschrieben hat, dass er ab dem 31.12 in Ruhestand gehen wird und hauptsächlich nur noch auf PN's antwortet.

Spaß bei Seite, danke das du weiterhin so tolle und vor allem ausführlich dokumentierte Arbeit.

[Lehona]

MEM_Get/SetUseInstance() war schon drin. Ich habe es aber jetzt mal wie du sagst zu Beginn bzw. am Ende der Funktion aufgerufen. Ich habe mich nicht komplett in locals() reingefuchst, aber weil MEM_GetUseInstance() nun vor locals() aufgerufen wird, habe ich es in einer temporären Variable zwischengespeichert, damit es nach einer Umspeicherung anschliessend von locals() vernünftig auf den Peudostack gelegt wird (ich hoffe das habe ich richtig verstanden), siehe HookEngine.d in Rev 140 Zeile 36 und Zeile 63.
Testen kann ich das ganze leider nicht, weil ich keine Adresse kenne an der das beim Hooken zu einem Problem werden könnte. Die Sicherung der anderen globalen Instanzen scheint aber zu funktionieren; Den Bug den Nico mit den Dialogen im alten Lager in GFA entdeckt hatte, bezieht sich nur auf yINSTANCE_HELP und ist mit der neuen Implementierung gefixt.

Du könntest einfach in einer Instanz-Funktion eine External aufrufen, die eine Hook auslöst. In Instanz-Funktionen wird die UseInstance nur einmal ganz am Anfang gesetzt (deswegen gibt es in Buffs.d auch eine Funktion "SAVE_GetFuncID()"), da sollte das also relativ auszuprobieren sein (sonst müsste man sich schon irgendetwas relativ exotisches konstruieren). Wenn nach der Hook die Attribute noch richtig zugeteilt werden, stimmt alles.

Das der Bug im alten Lager gefixt ist, ist super

Spaß bei Seite, danke das du weiterhin so tolle und vor allem ausführlich dokumentierte Arbeit.

Dem schließe ich mich an. Und dass die Entwicklung von LeGo jetzt etwas öffentlicher statt findet ist auch super - ich bin mir sicher dass die Arbeit "im stillen Kämmerlein" einige Leute abgeschreckt hat. Dabei würde ich mich freuen, wenn hier noch mehr Menschen etwas (auch kleine Dinge!) beitragen oder überhaupt Probleme/Ideen diskutieren.
Das ist eine hervorragende Möglichkeit, um seine Kenntnisse im Scripten auf die Probe zu stellen

[mud-freak]

Du könntest einfach in einer Instanz-Funktion eine External aufrufen, die eine Hook auslöst.

Guter Vorschlag. Die Erklärung hat mir auch nochmal das grundlegende Problem etwas verständlicher gemacht. Ich habe das mal getestet und die UseInstance bleibt erhalten. Die Änderung an den Hooks sollte also (die uns bekannten) Probleme alle beseitigt haben.


Ich habe mich heute mal dran gesetzt alle Pakete (ausser Dialoggestures, Sprite und Render) auf Gothic 1 Kompatibilität zu prüfen, zu testen und ein paar Fehler zu beheben. Meiner Meinung könnte es also dann bald das nächste LeGo-Release mit "offizieller" Gothic 1 Unterstützung geben.
(Ich selbst bin da natürlich etwas heiss drauf, denn die Veröffentlichung von GFA Version 1.0 setzt die Neuerungen in LeGo voraus.)

Im LeGo-Wiki gibt es nun ein Beispiel für die ConsoleCommands. Das ist nicht das sinnvollste Beispiel, aber es zeigt ganz gut wie einfach solche Befehle erstellt werden können.

Da die Hooks jetzt etwas anders funktionieren, kann man sie nun auch während des Spiels (komplett) entfernen. Das will ich aber gar nicht so sehr an die grosse Glocke hängen, weil es einfach nicht so viel Sinn macht.

[Fisk2033]

Im LeGo-Wiki gibt es nun ein Beispiel für die ConsoleCommands. Das ist nicht das sinnvollste Beispiel, aber es zeigt ganz gut wie einfach solche Befehle erstellt werden können.

@Lehona wäre es eigentlich möglich so einen "letzte Änderung" Button einzufügen, wie im Editing-Wiki: (https://wiki.worldofgothic.de/doku.p...tart&do=recent) ich hab "neue" Artikel wie Buffs nur durch Zufall gefunden. Eventuell lässt sich sowas ja ganz einfach einfügen, aber wäre auch kein Weltuntergang wenn nicht.

[NicoDE]

Den Bug den Nico mit den Dialogen im alten Lager in GFA entdeckt hatte, bezieht sich nur auf yINSTANCE_HELP und ist mit der neuen Implementierung gefixt.

Vielen Dank für die ganze Arbeit (insbesondere die Portierung auf G1 und die Überarbeitung der Hooks)! Ich werde nächste Woche auch endlich wieder zum Testen kommen

[Teron Gorefiend]

Ja, das sollte funktionieren. Im selben Forenthread, den du verlinkt hast gibt es später einen Post mit einer Portierung für Gothic 1.
Wie du LeGo in Gothic 1 zum Laufen bringst, findest du hier in diesem Thread ein paar Posts über deinem. Dazu sei nochmals gesagt, dass keine Stabilität für den Development-Branch von LeGo gewährleistet ist.

EDIT: ok weiß beim besten willen nicht, was da gestern schief ging aber momentan scheint wieder alles zu klappen.

[Lehona]

@Lehona wäre es eigentlich möglich so einen "letzte Änderung" Button einzufügen, wie im Editing-Wiki: (https://wiki.worldofgothic.de/doku.p...tart&do=recent) ich hab "neue" Artikel wie Buffs nur durch Zufall gefunden. Eventuell lässt sich sowas ja ganz einfach einfügen, aber wäre auch kein Weltuntergang wenn nicht.

Möglich wäre das sicherlich, aber so gar nicht mein Gebiet Am Wochenende hab ich vielleicht Zeit, mir das mal ganz kurz anzuschauen - aber tendenziell eher nicht. Neuerungen in LeGo werden aber ja sowieso immer hier im Thread gepostet (den du ja sicherlich verfolgst ) - insofern sollte das ja eigentlich reichen.

[mud-freak]

Ich habe eine kleine Spielerei anzubieten (nicht lohnenswert für den ScriptBin). Eigentlich sollte das ein Beispiel für die ConsoleCommands im LeGo-Wiki werden, allerdings eignete sich das nicht so gut.

Mit Eingabe von "shutup" kann man einen laufenden Dialog komplett beendet (egal, ob Choices anstehen oder mehrere Dialogzeilen). Sicherlich nur für Testzwecke sinnvoll, z.B. wenn man ständig vergisst Xardas aus der Startup zu entfernen. Vielleicht kann es der ein oder andere gebrauchen. Der Code setzt LeGo_ConsoleCommands und LeGo_FrameFunctions voraus.

func void _shutUp() {
    if (InfoManager_HasFinished()) {
        FF_Remove(_shutUp);
        return;
    };

    var C_NPC slf; slf = _^(MEM_InformationMan.npc);
    Npc_ClearAIQueue(hero);
    Npc_ClearAIQueue(slf);
    AI_StopProcessInfos(slf);
};
func string shutUp(var string _) {
    if (InfoManager_HasFinished()) {
        return "No dialog running";
    };
    if (TRIA_Running) {
        return "Trialogs not supported";
    };

    // Continuously cancel OUs until they are all gone. (FF instead of loop, because the next OU is started after this frame.)
    FF_ApplyOnce(_shutUp);

    return "Done";
};

Und in der Init_Global den Konsolenbefehl registrieren:

CC_Register(shutUp, "shutup", "Stop any dialog in progress");