[mud-freak]

Was sind denn die Namen von Workaround Helper und Bloodsplats?

Allgemein wäre es eventuell hilfreich, irgendwo zu sammeln, welche Patches es gibt, was sie bewirken, und wie man sie wegen Inkompatibilität ausschließen kann. (Die Call-Skripte haben wir z.B. auch in LoA schon drin und sollten daher wohl den Patch ausschließen. Andere Mods haben vermutlich die Bloodsplats aus LeGo bereits aktiviert.)

Wenn ihr im Konsolenskript keine eigenen Änderungen vorgenommen habt, sollte der Workaround Helper keine Probleme machen. Er beinhaltet zusätzlich noch ein Skript zum Markieren von Dialogen als (un-)gehört. Der Bloodsplats-Patch sollte keine Probleme machen, wenn die LeGo-Bloodsplats schon in der Mod vorhanden sind.

Die Namen ihrer VDF sind: Workaround und Bloodsplats.

[Zocker01]

Ninja ist jetzt ein Jahr alt
Am Moddertreffen stelle ich Ninja 2.0 vor. Dieses ist leichter zu handhaben und sichert bessere Kompatibilität. Danach überschwemme ich euch mit einem Haufen von spannenden neuen Patches, die nur darauf warten veröffentlicht zu werden.

Kommen die in den nächsten Tagen nach und nach, oder wie?

[Tentarr]

Glückwunsch zum Release, bin auch schon sehr gespannt

Kommt nun bald auch die Veröffentlichung von dem Zauberpaket? Möchte mein eigenen Projekt sobald als möglich umsetzen

[Fisk2033]

Glückwunsch zum Release. Weiterhin erstaunlich wie du zur Stange hältst und immer wieder was neues kommt!

[mud-freak]

Kommt nun bald auch die Veröffentlichung von dem Zauberpaket? Möchte mein eigenen Projekt sobald als möglich umsetzen

Ich war ein wenig verwirrt was du mit Zauberpaket meinst. Denn es gibt ein komplett anderes Projekt mit dem Namen. Du meinst wahrscheinlich das First Mage Kit (dt. Name Magie Hilfe Kasten), das ich neulich erwähnt habe?


Ich habe zurück geblättert und mir dein Vorhaben noch einmal angeschaut. Ich würde da ein wenig anders heran gehen:

Du möchtest einfach den Manaverbrauch vom Schrei-der-Toten-Zauber ändern, richtig? Das macht meiner Meinung nach nur Sinn in Mods, in denen dieser Zauber auch existiert und vorkommt. In anderen Mods müsstest du dir den Zauber erst ercheaten, um ihn zu benutzen. Das ist meiner Meinung nach ein völlig anderes Vorhaben. Würdest du den Zauber in jede Mod zur Verfügung haben wollen, würde das einen komplett eigenständigen Zauber voraussetzen (damit er keine Abhängigkeiten von möglicherweise nicht existierendem Material hat). Damit wird der ursprüngliche Zauber, wenn er in Mods existiert aber nicht länger verändert und der gesamte Patch erfüllt nicht mehr seinen ursprünglichen Zweck.

Daher würde ich einfach einen Patch erstellen mit folgenden zwei Funktionen. Diese enthalten keinerlei Abhängigkeiten.
Existiert der Schrei-der-Toten-Zauber in einer Mod, so werden diese Funktionen ersetzt und somit die Manakosten, existiert der Zauber nicht (oder wurde umbenannt), passiert einfach gar nichts. Ich denke das ist am sinnvollsten.

func int Spell_Logic_Skull(var int manaInvested)
{
    if (Npc_GetActiveSpellIsScroll(self) && (self.attribute[ATR_MANA] >= /*SPL_Cost_Scroll*/ 5))
    {
        return SPL_SENDCAST;
    }
    else if (self.attribute[ATR_MANA] >= 250)
    {	
        return SPL_SENDCAST;
    }
    else //nicht genug Mana
    {
        return SPL_SENDSTOP;
    };
};

func void Spell_Cast_Skull()
{
    if (Npc_GetActiveSpellIsScroll(self))
    {
        self.attribute[ATR_MANA] = self.attribute[ATR_MANA] - /*SPL_Cost_Scroll*/ 5;
    }
    else
    {
        self.attribute[ATR_MANA] = self.attribute[ATR_MANA] - 250;
    };

    self.aivar[AIV_SelectSpell] += 1;
};

Damit die neuen Manakosten auch richtig im Inventar angezeigt werden, reicht folgender Code.

instance ItRu_Skull(C_Item) {
    COUNT[1] = 250;
    TEXT[2] = "";
};

[Zocker01]

Wie beeinflussen Ninja 2.0 und die kommenden Patches eigentlich die Systemanforderungen von Gothic 1&2? Ich zocke momentan auf einem alten Notebook, wo weder der Renderer noch Returning 2.0 laufen würden, und würde gerne wissen, ob eine Stapelung diverser Patches auf Ninja-Basis zu Performanceproblemen oder Ähnlichem führen können.

edit:
Werden in den nächsten Tagen/Wochen mehrere Patches kommen und ist einer davon ein "Sneak-Kill/Schleichangriff"-Patch?

[mud-freak]

Wie beeinflussen Ninja 2.0 und die kommenden Patches eigentlich die Systemanforderungen von Gothic 1&2? Ich zocke momentan auf einem alten Notebook, wo weder der Renderer noch Returning 2.0 laufen würden, und würde gerne wissen, ob eine Stapelung diverser Patches auf Ninja-Basis zu Performanceproblemen oder Ähnlichem führen können.

Ninja ändert an Systemanforderungen und Performance nichts.

Bei den Patchen genau so.
Erst ab etwa über 100 großen Patches (groß = freies Zielen, die anderen bisher sind alle klein) gleichzeitig kann unter Umständen das Starten von Gothic etwas länger dauern - das Spielen bleibt aber unbeeinflusst. Im realistischen und merklichen Rahmen ändern die Patches also nichts.

Werden in den nächsten Tagen/Wochen mehrere Patches kommen..

Ich werde in den nächsten Tagen noch 4 Patches veröffentlichen, zwei davon finde ich selbst recht nützlich.

..und ist einer davon ein "Sneak-Kill/Schleichangriff"-Patch?

Nein.

[Zocker01]

Danke für die Infos! Sehr fein.

[Tentarr]

Ich war ein wenig verwirrt was du mit Zauberpaket meinst. Denn es gibt ein komplett anderes Projekt mit dem Namen. Du meinst wahrscheinlich das First Mage Kit (dt. Name Magie Hilfe Kasten), das ich neulich erwähnt habe?


Ich habe zurück geblättert und mir dein Vorhaben noch einmal angeschaut. Ich würde da ein wenig anders heran gehen:

Du möchtest einfach den Manaverbrauch vom Schrei-der-Toten-Zauber ändern, richtig? Das macht meiner Meinung nach nur Sinn in Mods, in denen dieser Zauber auch existiert und vorkommt. In anderen Mods müsstest du dir den Zauber erst ercheaten, um ihn zu benutzen. Das ist meiner Meinung nach ein völlig anderes Vorhaben. Würdest du den Zauber in jede Mod zur Verfügung haben wollen, würde das einen komplett eigenständigen Zauber voraussetzen (damit er keine Abhängigkeiten von möglicherweise nicht existierendem Material hat). Damit wird der ursprüngliche Zauber, wenn er in Mods existiert aber nicht länger verändert und der gesamte Patch erfüllt nicht mehr seinen ursprünglichen Zweck.

Daher würde ich einfach einen Patch erstellen mit folgenden zwei Funktionen. Diese enthalten keinerlei Abhängigkeiten.
Existiert der Schrei-der-Toten-Zauber in einer Mod, so werden diese Funktionen ersetzt und somit die Manakosten, existiert der Zauber nicht (oder wurde umbenannt), passiert einfach gar nichts. Ich denke das ist am sinnvollsten.

func int Spell_Logic_Skull(var int manaInvested)
{
    if (Npc_GetActiveSpellIsScroll(self) && (self.attribute[ATR_MANA] >= /*SPL_Cost_Scroll*/ 5))
    {
        return SPL_SENDCAST;
    }
    else if (self.attribute[ATR_MANA] >= 250)
    {    
        return SPL_SENDCAST;
    }
    else //nicht genug Mana
    {
        return SPL_SENDSTOP;
    };
};

func void Spell_Cast_Skull()
{
    if (Npc_GetActiveSpellIsScroll(self))
    {
        self.attribute[ATR_MANA] = self.attribute[ATR_MANA] - /*SPL_Cost_Scroll*/ 5;
    }
    else
    {
        self.attribute[ATR_MANA] = self.attribute[ATR_MANA] - 250;
    };

    self.aivar[AIV_SelectSpell] += 1;
};

Damit die neuen Manakosten auch richtig im Inventar angezeigt werden, reicht folgender Code.

instance ItRu_Skull(C_Item) {
    COUNT[1] = 250;
    TEXT[2] = "";
};

Danke dir für die Antwort.
Dieses Problem habe ich dann so auch gelöst.
Das Magekit würde ich mir dennoch gerne Ansehen, da ich inzwischen auch an neuen Zaubern arbeite.

[mud-freak]

Danke dir für die Antwort.
Dieses Problem habe ich dann so auch gelöst.

Wenn du magst, kann ich gern noch einmal drüberschauen, bevor du den Patch im Moderationsforum veröffentlichst :)

[Kirides]

Schau dir mal das an: Translation Patch. Wenn der Kontext nicht wichtig ist (Reihenfolge der Symbol gibt meist genug Kontext), ist das die einfachste (und vollständige) Methode.

Wenn ich das richtig verstehe, würde ein Patch auf dieser Basis nach einem Update der Scripte nicht weiter funktionieren. Aber es wäre dennoch notwendig dies zu verwenden, weil (meine ich mich zu errinnern) die Tagebucheinträge innerhalb von Methoden erzeugt werden, und keine Konstanten sind, welche man einfach "überschreiben" könnte.

Kodierung ist kein Problem, solang du alle Dateien korrekt abspeicherst. Wenn du in dem Patch die richtigen Fonts mitlieferst (wie im Link beschrieben), ist der Patch komplett.

Also wie gehabt, die korrekte Ziel CodePage (in dem Fall Windows-1252 für Westeuropäisch) als Dateiencoding verwenden, mit einer Font, welche die Westeuropäischen Zeichen beinhaltet.

Wenn du trotzdem Item-Namen usw. in Instanzen (anstatt als nur deren Inline-Symbol zur Verfügung stellen willst), brauchst du die Originalskripte und dann kannst du dir die Mühe sparen ein neues Tool zu programmieren, denn das wurde schon in Spine implementiert.

Spine habe ich mir bis jetzt noch nicht angeschaut. Prüfe ich ggf. heute Abend mal.

Hierzu müsste ich theoretisch nicht einmal viel Aufwand betreiben, durch meine Arbeit am Daedalus Language Server habe ich einen Parser für Daedalus und könnte hier sehr leicht die ganzen Instanzen zusammensammeln und entsprechend in Patch-form ausgeben. Hier könnte ich sogar, die original Scripte komplett überarbeiten und alle string-Konstanten welche nicht über globale Variablen bzw. Konstanten verwendet werden, durch eine jeweilige const string austauschen.
z.b.
const string patch_diary_[Fortlaufende Tagebuch Nummer])

Dann könnte man die Scripte "einfach" neu-kompilieren und Patches in jeder Sprache durch diese neuen Konstanten realisieren und müsste sich nicht auf die generierte Symbol ID verlassen

Ich denke schon wieder viel zu viel Vielleicht gibt's ja schon etwas das dies kann, oder besser

[mud-freak]

Wenn ich das richtig verstehe, würde ein Patch auf dieser Basis nach einem Update der Scripte nicht weiter funktionieren. Aber es wäre dennoch notwendig dies zu verwenden, weil (meine ich mich zu errinnern) die Tagebucheinträge innerhalb von Methoden erzeugt werden, und keine Konstanten sind, welche man einfach "überschreiben" könnte.

Genau. Das sind was ich als Inline-Symbole bezeichnet habe und die in der DAT als ÿ26291 usw. auftauchen. Für jeden String, der nicht in einer Variable oder in einer Konstante definiert wird, wird solch ein Symbol automatisch angelegt. Vergleiche dazu das Beispiel aus der dem Link.

Also wie gehabt, die korrekte Ziel CodePage (in dem Fall Windows-1252 für Westeuropäisch) als Dateiencoding verwenden, mit einer Font, welche die Westeuropäischen Zeichen beinhaltet.

Nein. Wenn du bspw. russische Texte schreibst, speicherst du die Datei in 1251 ab.

Spine habe ich mir bis jetzt noch nicht angeschaut. Prüfe ich ggf. heute Abend mal.

Hierzu müsste ich theoretisch nicht einmal viel Aufwand betreiben, durch meine Arbeit am Daedalus Language Server habe ich einen Parser für Daedalus und könnte hier sehr leicht die ganzen Instanzen zusammensammeln und entsprechend in Patch-form ausgeben. Hier könnte ich sogar, die original Scripte komplett überarbeiten und alle string-Konstanten welche nicht über globale Variablen bzw. Konstanten verwendet werden, durch eine jeweilige const string austauschen.
z.b.
const string patch_diary_[Fortlaufende Tagebuch Nummer])

Dann könnte man die Scripte "einfach" neu-kompilieren und Patches in jeder Sprache durch diese neuen Konstanten realisieren und müsste sich nicht auf die generierte Symbol ID verlassen

Ich denke schon wieder viel zu viel Vielleicht gibt's ja schon etwas das dies kann, oder besser

Das hört sich alles sehr über-kompliziert an, wenn es dir nur darum geht die Übersetzung als Patch zu erstellen. Denn dort sind nur die Strings an sich wichtig. Instanzen usw. brauchst du gar nicht. Bei einem Patch wirst du nicht drumherumkommen, mit Inline-Symbolen zu arbeiten. Von daher kannst du dir einfach, wie in dem Link beschrieben alle Stringsymbole aus der DAT extrahieren lassen. Dann erhältst du so eine D-Datei (Beispiel aus der Dokumentation in französisch):

const string print_newlogentry = "Nouvelle entrée de journal";
const string topic_cortezmisenakapone = "UV: Un nouveau départ";
const string info_stadt = "La ville d'Ahssûn";
const string ÿ26291 = "Entrée de journal en ";
const string ÿ26299 = "LoA Trucs & astuces: ";
const string topic_tipps = "LoA: Trucs et astuces";
const string info_questbezeichner = "LoA: Trucs et astuces";
const string kapwechsel_1 = "Chapitre 1";
const string kapwechsel_1_loa_text = "Pas un bon début";
const string dialog_ende = "Je vais aller ... (FIN)";
const string dialog_back = "(retour)";
const string ÿ76380 = "Comment je vais voir le prince?";
const string ÿ76390 = "Que dois-je savoir sur cet endroit?";
const string ÿ76398 = "Pourquoi parlez-vous de la ville 'actuelle'?";
const string ÿ76404 = "Où puis-je me procurer de nouveaux vêtements?";
const string ÿ82532 = "Comment ai-je fini ici?";
const string ÿ71379 = "Peux-tu m'apprendre quelque chose?";
// ...

Die enthält alle Strings der ganzen Content-Skripte (das gleiche dann noch einmal für die Menü-Skripte) schon im richtigen Daedalus-Format. Dann kannst du diese Strings ggf. durch einen Übersetzer jagen und die Datei genau so wie sie ist, in einen Patch packen - fertig. Dann das selbe analog für die Dialogzeilen (vgl. Dokumentation).

Übersetzt du nicht per Hand, brauchst du nicht wissen, ob es sich bei einem String um eine Item-Beschreibung handelt. Ich bezweifele sowieso, dass dir diese Information besonders viel bringt. Da die Symbol in der Parser-Reihenfolge in die D-Datei extrahiert werden, wird der Kontext meiner Erfahrung nach meist aus den darüber und darunter liegenden Strings klar.


PS: Das Beispiel aus der Dokumentation (LoA in französisch) ist sehr schnell umzusetzen. Ich glaube kaum, dass man eine Übersetzung schneller erstellen kann.

[Kirides]

Genau. Das sind was ich als Inline-Symbole bezeichnet habe und die in der DAT als ÿ26291 usw. auftauchen. Für jeden String, der nicht in einer Variable oder in einer Konstante definiert wird, wird solch ein Symbol automatisch angelegt. Vergleiche dazu das Beispiel aus der dem Link.

Das stelle ich mir schon sehr angenehm vor, vor allem für die Schlussendlichen Übersetzer.

Wird wohl vorerst darauf hinauslaufen das ich das so übernehmen werde, ist halt nur im Falle von Returning 2 (mit AB) suboptimal, da dieses ständig weiterentwickelt wird und immer wieder mal neue Scripte erstellt werden und eine (rein) automatische Übersetzung aus dem Russischen ins Englische oder Deutsche ist unzumutbar für die Spieler.
Bei über 30.000 Zeilen Text in der Gothic.dat ist das schon ein Kampf für die Übersetzer (Das beinhaltet noch nicht einmal die OU.bin mit 62847 russischen Texten ..., oh man )

Nein. Wenn du bspw. russische Texte schreibst, speicherst du die Datei in 1251 ab.

Naja, in diesem Fall wäre es von Russisch nach Deutsch (Returning 2 mit AB) Daher müsste man die neuen, deutschen, Texte mit 1252 speichern, damit diese auch in einer deutschen Font funktionieren, da ansonsten ß, äöü etc. fehlen würden

Das hört sich alles sehr über-kompliziert an, [...]

Höre ich leider ziemlich häufig auf der Arbeit

Denn [bei einer Übersetzung] sind nur die Strings an sich wichtig. Instanzen usw. brauchst du gar nicht. Bei einem Patch wirst du nicht drumherumkommen, mit Inline-Symbolen zu arbeiten. Von daher kannst du dir einfach, wie in dem Link beschrieben alle Stringsymbole aus der DAT extrahieren lassen. Dann erhältst du so eine D-Datei (Beispiel aus der Dokumentation in französisch): [...]

Ich hatte mir den letzten Punkt eher als Notlösung gedacht, für Scripte welche sehr häufig aktualisiert werden und man sich nicht unbedingt auf die Reihenfolge der Symbole verlassen kann. So könnte ein Mod-Ersteller, welcher keine Konstanten für seine Texte verwendet, seinen Quellcode schnell und einfach umschreiben lassen und zukünftige Patches

[Zocker01]

Ich wollte mal wieder Vorschläge für weitere Patches einwerfen:

- schnelleres Wiederaufstehen nach dem Hinfallen/Umgeworfenwerden, wenn man Akrobatik beherrscht
Derzeit kommt es mir so vor, dass das Aufstehen/Aufspringen mit Akrobatik sogar langsamer ablaufe, als mit Akrobatik.
- Einsammeln von Gegenständen während dem Laufen (z.B. realisiert vom Quickloot-Unionspatch), idealerweise aber nicht mit einer Extrataste, sondern mit der Aktionstaste, die der/die Spieler*in in den Einstellungen selbst festgelegt hat
- Sneakkill/Schleichangriff-Mechanik
- Verbündeten und beschworenen Kreaturen via Tastendruck befehlen, einen anvisierten NPC anzugreifen

Bei der Gelegenheit möchte ich an ältere Ideen erinnern:

- Sprinten (wurde realisiert --> Sprintpatch)
- Seitwärtsrollen für Akrobaten
- permanente Boni nicht in die LP-Kosten einrechnen
- Respawn von Gegnern und/oder Pflanzen
mit/ohne stärkeren Gegnern, pro Kapitelwechsel/pro Schlafen/pro Weltenwechsel
- Schwierigkeitsgrad in verschiedenen Versionen
Attribute, Fähigkeiten und Resistenzen von NPCs dynamisch verändern
- Begleiter-NPCs Waffen geben
- Klaue Beliars für Fernkämpfer nutzbar machen

- prozentuale Heilkraft für Lebensmittel
- verbessertes Brat/Koch-System, also dass man 1, 5, 10 oder alle Fleischkeulen braten kann
- Warte-Funktion wie in TES Oblivion und KO
- Monster counter
- Skillverbesserung durch Skillnutzung
- Auto-Speicher-Funktion wie aus "Xeres' Rückkehr"
- visueller Erfahrungspunkte-Balken
- Zudem fände ich es schön, wenn man so wie in "The Returning 2" die neuen Idle Animationen dazu bekommt, für den Helden und andere NPCs evtl. auch.

[mud-freak]

Ich wollte mal wieder Vorschläge für weitere Ninja-Patches einwerfen:

[...]
- Einsammeln von Gegenständen während dem Laufen (z.B. realisiert vom Quickloot-Unionspatch)
[...]

Darf ich fragen warum du dieses Feature noch einmal separat vorschlägst, obwohl es scheinbar schon realisiert wurde?

[Kirides]

Ich habe mal Ninja 2 mit Returning 2 (AB) getestet.
Nach der Installation von Ninja, bekomme ich beim Starten von Returning ein Konsolenfenster mit folgender Mitteilung (vor der Installation von Ninja nicht passiert)
[Bild: EGNaj.png]
Leider erkenne ich darauf nicht, ob es durch Ninja, oder Returning erzeugt wird.
Der testeshalber erstelle Patch (nur die G2_OU.CSL) funktioniert soweit, die vorhandenen Dialoge sind auf Deutsch (automatisiert übersetzt mit den Dialogdaten von Returning 1.12.9, immer noch eine Menge fehlende Texte)

@mud-freak
Weißt du was es mit diesem Konsolenfenster auf sich hat?

[Zocker01]

Darf ich fragen warum du dieses Feature noch einmal separat vorschlägst, obwohl es scheinbar schon realisiert wurde?

Weil der Unionspatch Kompabilitätsprobleme gemacht hat. Siehe hier und die darauf folgenden 2 Kommentare von gladi und mir.
Mit dem Unionspatch waren in der Mod Weltenwechsel (fast) nicht möglich, es kam zu Mehrfachrespawns und freies Zielen hat nicht funktioniert.
Seit der neuen G2-Installation ohne Union läuft aber alles in der Mod problemlos. Keine Mehrfachrespawns, freies Zielen funktioniert, keine Crashes bei Weltenwechsel.

[mud-freak]

Weißt du was es mit diesem Konsolenfenster auf sich hat?

Nein, das kann ich dir nicht sagen. Es scheint mir so als scheitert das Laden von einer DLL(?). Das geht aber nicht von Ninja aus. Vielleicht schreibt die Mod sehr viel in der EXE herum.

[lali]

Ich schließe mich auch mal an für Vorschläge bezüglich weiterer Ninja Patches:
- Trolle wieder Goblins werfen lassen inklusive dem zugehörigen KI-Verhalten (Goblins flüchten zu Trollen wenn sie unterliegen, damit sie ihnen helfen)
- Truhen und Türen wieder mit Äxten zerstörbar machen wie angekündigt

Und eine Frage. Vielleicht in einem Satz für einen Laien: Basiert Ninja auf Lego? Kann man den Code eines Ninja-Patches ganz einfach wie ein Lego-Skript fest in eine Mod integrieren oder ist das nicht ohne Weiteres möglich und man muss auf die einzelnen .vdfs zurückgreifen?

[mud-freak]

Und eine Frage. Vielleicht in einem Satz für einen Laien: Basiert Ninja auf Lego? Kann man den Code eines Ninja-Patches ganz einfach wie ein Lego-Skript fest in eine Mod integrieren oder ist das nicht ohne Weiteres möglich und man muss auf die einzelnen .vdfs zurückgreifen?

Nein, Ninja basiert nicht auf LeGo. Patches auch nicht (zwingend), die meisten nutzen aber wahrscheinlich mindestens Ikarus, weil sonst aus ihnen heraus nicht so viel möglich ist.

Je nachdem wie ordentlich so ein Patch geschrieben ist, kann man den nötigen Code einfach heraustrennen und in eine Mod integrieren. Dabei stellt sich mir aber die Frage: Warum? Bisher kam das nicht so gut an (siehe freies Zielen in Mods integriert).

Wenn jemand bspw. meine CatInv-Skripte (System aus dem Kategorisierten Inventar) in seine Mod einbauen würde, wäre ich nicht so begeistert.