[Release] Grey the Dog - NPC für BG1

[Lumorus]

Und ich meine, dass die Lindwurmquest doch nichts mit BG1NPC zu tun hat. Da ist seine Quest doch die an der Feuerweinbrücke (damsel in distress) oder verwechsle ich da was?

Die Lindwurmquest gehört schon zum Original BG1 - die "Damsel-in-Distress-Quest an der Feuerweinbrücke stammt aber aus dem NSC-Project.
Die Jagd nach dem Lindwurm ist der Grund, warum man ihn im Mantelwald antrifft.

Ich finde beide Portraits von Grey toll - mal wieder eine gute Arbeit,@Acifer

 

[Jastey]

Grey updatet zur v9! Das neue Portrait hatte ich ja schon erwähnt. Vielen Dank nochmal an @Acifer !
Auch Grey hat einen kleinen Quest, der mit Belegarm startet. Er erschnüffelt natürlich auch in SoD alle relevanten Dinge (Brages Quest, Safanas Quest, Suche nach Skie, die verschwundenen Flüchtlinge in der erstan Campgegend.)
Grey hat nicht genug Reaktionen auf Spielereignisse, als dass hierfür die Road to Discovery-Mod benötigt würde.

Changelog:
-SoD content completed.
-new default portrait added, by Acifer.
-2 new components: Crossmod, alternate portraits.
-7th PMM mode improved.
-Minor bugfixes.

 

[Lumorus]

Greys neues Portrait passt sehr gut zu ihm - ich habe es zur Probe bei der Installation als Standard gelassen.
Das ist wie gemacht zu einem Kriegshund.

 

[Lumorus]

Juhuuu, die Fey Note wird nun wie vorgesehen entfernt - und da es eine Behörde ist wohl auch richtig abgestempelt und abgelegt.

Die neue Funktion, dass man 7. Begleiter nun anweisen kann in der Nähe zu bleiben, habe ich mit Grey getestet, weil der mal öfter aus der Reihe tanzt als Brandock (muss ich mir jetzt Gedanken machen, wer von beiden der bessere Hund ist? )
Dass man Grey sagen kann, er soll in Sichtweite bleiben, bzw. muss es nicht mehr, klappt ohne Probleme und ist sehr praktisch!
Leider fürchte ich, hat die Funktion auch eine Schwachstelle: Während dem spielen habe ich gemerkt, dass es öfter vorkam, dass das Spiel, wenn man Grey länger in Sichtweite bleiben lässt, beim speichern (sowohl Autosave, Quicksave und manuelles speichern) mit einer Fehlermeldung abstürzt, die so etwas wie "abnormal Command" oder so ähnlich enthält.
Die Abstürze kommen eher zufällig, mal erst nach einer längeren Zeit, nachdem man mehrmals ohne Probleme speichern konnte, aber manchmal auch sehr schnell nach dem Neuladen.
Das wohl blödeste daran ist, dass der Spielstand, den man speichern wollte, nicht mehr vorhanden, bzw. gelöscht ist, nachdem man das Spiel nach dem Absturz neu gestartet hat...

Ich bin mir aber nicht wirklich 100% sicher, dass es an der Funktion liegt, vermute es aber, weil ich lange keinen Absturz erlebt habe, als ich Grey angewiesen habe, dass er nicht mehr in Sichtweite sein muss. Nachdem ich es wieder versucht und Grey wieder befohlen hatte, in Sichtweite zu bleiben, brauchte es nicht lange, und das Problem war zurück

Voll Doof ist, dass ich leider vergessen habe, einen Screenshot von der Fehlermeldung zu machen. Ich versuche das in einem separaten Spielstand nachzuholen

 

[Jastey]

Danke für die Rückmeldung!
Das mit dem Crash beim Speichern ist mehr als ärgerlich. Das Skript, das dahinter steckt, ist recht kurz:

IF
    ActionListEmpty()
    InMyArea(Player1)
    !Range(Player1,15)
THEN
    RESPONSE #100
        MoveToObject(Player1)
END

Momentan arbeite für diese Skripte mit dem DEFAULT script slot für das Folgen und dem GENERAL script slot für die Handlungen in einem Kampf. In der BG:SoD habe ich hier bisher keine Kurruption der Saves gehabt.

Könntest Du das noch etwas systematischer testen?

Ich bin da mit meinem Latein am Ende, was da das Problem sein könnte, außer die alte Engine kommt nicht damit zurecht, dass ein Familiar diese Skriptslots belegt hat o.ä.

 

[Lumorus]

Könntest Du das noch etwas systematischer testen?

Klar, mache ich gerne!
Wie genau meinst Du systematischer testen?

 

[Jastey]

Danke! Also, ist es nur das "folge mir" Skript. oder auch ein anderes, wenn das nicht aktiv ist. Passiert es auch mit brandock (falls Du den dabei hast). Wird es wieder besser, wenn Grey dann nicht mehr dabei ist bzw. nicht mehr folgen soll etc.

Ich füchte, wenn es wirklich an den Skripten liegt, dann ist das ein Problem dass ich nicht wirklich lösen kann. Das einzige was mir einfällt ist, den Skriptblock in sein normales Override Skript zu legen und es durch variablen an- bzw. auszumachen; also kein extra Skript in anderen Skriptslots dafür zu verwenden. Weil ich mir einfach nicht vorstellen kann, dass es an dem Skriptblock selbst liegt. Der ist eigentlich gnaz "normal".

 

[Lumorus]

Also, ist es nur das "folge mir" Skript. oder auch ein anderes, wenn das nicht aktiv ist. Passiert es auch mit brandock (falls Du den dabei hast). Wird es wieder besser, wenn Grey dann nicht mehr dabei ist bzw. nicht mehr folgen soll etc.

Ah, dann hatten wir den gleichen Gedanken! Ich wollte es nämlich noch mit Brandock und später auch mit Husam versuchen, ob es bei ihnen auch nur der Folge-Befehl ist und das Problem vorkommt.

 

[Jastey]

@Lumorus ich wollte das mit dem Crash beim Spreichern mit Grey testen, und meine BGT-Installation crashed nun immer, auch ohne Mods. Es ist die BGT-Installation, die ich von meinem Windows7-rechner auf meinen neue Win10-Installation kopiert habe. Da ich mit einer ähnlichen, kopierten Installation auch viele Graphikabstürze in @Acifer s Silverrealms-Mod hatte habe ich gerade den bösen Verdacht, dass Deine BGT eventuell an etwas Ähnlichem leidet, und die Abstürze nicht (unbedingt) mit den Mods (Grey / Acifers Graphiken) zusammenhängt.
Bei mir sieht die Fehlermeldung so aus, und kommt, nachdem der Speicherkreis zu ungefähr zwei Dritteln gefüllt ist.

Spoiler

Das hängt bei mir ganz sicher mit den graphischen Einstellungen und den unter einem anderen Betriebssystem installierten BGII/BGT-Spielen zusammen.

 

[Morywen]

Hm, könnte zum einem an der Version des Visiual Studios liegen, es wäre auch möglich, dass unter den Einstellungen der Windows Programme der Legacy Mode nicht aktiviert ist. Bei mir haben alle BGT Installationen unter Win 10, auch die von Win 7 übernomme funktioniert. Auch wenn ich, wegen defekter CD die Schlüssel von Hand einfügen musste.

 

[Jastey]

@Morywen danke für die Tipps. Ich habe gerade einfach zu wenig Motivation, mich darum zu kümmern. Ich habe die BGT-Installationen um die Resourcen zugänglich zu haben, und wenn ich doch nochmal wirklich darauf testen möchte werde ich in den sauren Apfel beißen müssen.
Aber gut zu wissen, dass ich eventuell die Installation mit den richtigen Einstellungen "retten" kann, bzw. dass eine Neuinstallation eventuell gar keine Verbesserung bringen könnte!

 

[Lumorus]

@Jastey Oh, das war gut, danke Dir!
Was Du schreibst, kann tatsächlich auch bei mir der Fall gewesen sein, denn davor hatte ich ja das Peoblem mit den Abstürzen in bestimmten Gebieten - von denen sich ja inzwischen herausgestellt hat, dass das an den fehlenden Animationenn aus IA lag - einer meiner möglichen Lösungen bestand darin, an den Einstellungen herumzuschrauben ...
Ich weiss zwar nicht mehr, was die genaue Fehlermeldung war, aber ich denke, es war die gleiche, die Du hier eingefügt hast.
Eskam inzwischen auch bei mir zu einem Absturt mit dieser Meldung, OHNE, dass einer der 7. Begleiter den Befehl hatte, in Sichtweite zu bleiben.

Ich habe nun die ganze Installation gelöscht - die ohnehin fehlerhaft war - und setze eine neue auf. Mal sehen, ob das Problem dann immer noch besteht.

 

[Maus]

Bei Grey in meiner Version (V8) läuft wieder was falsch: er spawnt nicht in ID bei den Dryaden.

Und:
!HasItem("c#grpaw12","C#Grey") // Grey
!HasItem("c#grpaw15","C#Grey") // Grey
!HasItem("c#grpaw25","C#Grey") // Grey

Itemnamen mit 9 Charakter?? Geht nicht, oder? Gibt zumindest ordentliche Warnings in den Skripten.

Da Area-Skript müsste eigentlich durchgelaufen sein, weil ich seine Ausrüstung auf dem Tisch gefunden habe und das ist der letzte Skriptblock.

 

[Jastey]

Itemnamen mit 9 Charakter?? Geht nicht, oder? Gibt zumindest ordentliche Warnings in den Skripten.

Ja, habe ich lokal schon korrigiert.

Das mit dem Spawnen in EET ID geht mir echt auf den Senkel. Ich bin kurz davor, Grey auch aus der Kidnapszene zu entfernen, weil ich der meinung bin, dass das an irgendeinem Effekt liegt, der da auf die Gruppe geworfen wird, aber ich weiß nicht, was ich noch machen soll.
Auf was steht bei Dir Global("C#Grey_Exists","GLOBAL")? Falls es es auf 11 ist, dann versuch ihn nochmal herzucheaten:

C:Eval('MoveGlobalObject("C#Grey",Player1')

 

[Maus]

Der String gibt bei mir einen Error: Player not found. Ich probiere es mal mit MoveGlobal und der ursprünglichen Position.

 

[Maus]

Ok, das hat funktioniert. Aber ich musste noch seinen Dialog fixen, sonst klappte die Sache nicht Die Skripte vllt auch besser noch...

edit: ich lass das mal, da passt zu viel nicht. Ich spekuliere mal drauf, dass er auf der Promenade dazu stößt

 

[Jastey]

Ah stimmt. Eigentlich wäre es einfacher gewesen, die "C#Grey_Exists" auf etwas unter 10 zu setzen, dann führt das Areaskript die Befehle selbst aus.
Wobei ich jetzt nicht verstehe, dass die Skripte und Dialog noch nicht gesetzt war, da der Skriptbock ja schon durchgelaufen war.

 

[Maus]

Oder die Variable war aus einem anderen Grund auf 11. Hab sie auf 9 gesetzt, das hat geholfen. Allerdings kam nach der Aufnahme noch ein Heilzauber "angeflogen" und hat die ganze Gruppe geheilt. Ist das Absicht oder sollte nur Grey geheilt werden?

 

[Jastey]

Wie sollte die Variable "aus einem anderen Grund" auf dem Wert stehen? Außer Du setzt sie von Hand, ist sie in ID auf 11, wenn erst Grey entweder gespawnt oder dorthinverschoben wird (dann ist sie auf 10) und dann entweder seine Pfote bekommt oder schon eine hat (dann ist sie auf 11).
Ja, der Heilzauber war für Grey.

Ich habe für die nächste Version die Zauber, die ihn wieder normal machen sollen, für BGT und EET etwas angepasst. Ich weiß echt nicht, was ich sonst da noch machen soll. Für die Default-NPCs klappts doch auch.

 

[Maus]

Eine ernsthafte Idee habe ich nicht. Möglichkeiten wären aber: es ist der "falsche" Skriptblock gelaufen (sind ja glaube ich 3, die die Variable auf 10 setzen; und ich glaube einer dann von 10 auf 11) oder aber du hast mal mit IncrementGlobal gearbeitet. Das habe ich zwar in seinen Skripten noch nicht gesehen, aber vielleicht mal eher unbewusst oder aus Versehen.

Schauen wir mal den Skriptblock an:

        SetInterrupt(FALSE)
        SetGlobal("C#Grey_Exists","GLOBAL",10)
        ActionOverride("C#Grey",SetDialog("C#Grey2"))
        ActionOverride("C#Grey",ChangeAIScript("",DEFAULT))
        ActionOverride("C#Grey",ChangeAIScript("C#Grey",OVERRIDE))
        MoveGlobal("AR0602","C#Grey",[4245.1985])  // Grey
        ReallyForceSpellRES("SPWM168","C#Grey")  // Heal
        SetGlobal("C#GreyJoined","GLOBAL",0)
        ActionOverride("C#Grey",SetGlobal("C#LevelUp","LOCALS",0))
        ActionOverride("C#Grey",DestroyAllEquipment())
        SetInterrupt(TRUE)

Interrupt wurde ausgeschlossen. Jetzt könnte es sein, dass nach dem Setzen der Variable der Skriptblock nicht mehr weiterläuft. Meine Favoriten wären da die ActionOverride. Von daher vllt die Reihenfolge ändern? Also das MoveGlobal als erstes und dann erst die anderen und den Zauber als Letztes?