[Lehona]

Ich habe gestern noch ein bisschen geackert und nach dem Fehler gesucht. Ich bin zu durchwachsenen Ergebnissen gekommen:

Die von dir zitierten Stacktraces sind nicht(!) der Grund für den Absturz, sie sind bloß Warnungen, keine Fehler. Ich bekomme diese Warnungen ebenfalls, ohne dass das Spiel abstürzt. Zumindest die erste (Substrings etc.) lässt sich auch leider nicht umgehen. Edit: Natürlich hattest du gar keine Abstürze, ich wollte bloß sagen, dass die Warnungen einfach zu ignorieren sind.

Ich weiß nicht genau was dir da reinpfuscht (die aktuelle LeGo-Version ist einfach schon ziemlich alt und ich habe damit lange nicht gearbeitet), aber eine Alternative wäre, dass du die WiP-Version nimmst. Entweder ziehst du dir einfach das Repo aus dem EP oder du entpackst einfach die LeGo.zip und ersetzt deine Scripte mit diesen. Ich glaube, dass die Syntax dabei rückwärtskompatibel ist (Und wenn nicht, dann gibt es nur kleine Änderungen), aber du scheinst eh noch nicht viel gemacht zu haben.
Das ist allerdings, wie der Name sagt, eine WiP-Version. Speichern/Laden funktioniert meines Wissens soweit (ich habe keine Auffälligkeiten beobachten können), aus einem neuen Spiel heraus ein Neues Spiel zu starten (d.h. Neues Spiel -> Menü -> Neues Spiel) lässt das Spiel allerdings abstürzen. Da ich das Wochenende ebenfalls keine Zeit haben werde und nächste Woche vermutlich auch keinen wirklichen Zugang zu den Scripten haben werde, dachte ich aber, dass ich a) meinen Fortschritt mal auf den SVN pushe und b) dir das auch sage

[TheEternal]

Weiß nicht, ob das schon jemandem aufgefallen ist, aber wenn man Print_ExtPxl
verwendet und ne Farbe benutzt, dann bleibt die Farbe ab dem ersten Aufruf bis zum Ende des Spiels.

[Fisk2033]

Du meinst z.B. bei Items?
Das könnte glaube ich daran liegen,dass es kein returne oder sowas gibt?
Ich hatte zumindest mal in einem polnischen Forum einen Script gefunden, der zumindest die Items danach immer normal anzeigen lässt.

[Lehona]

Was genau ist denn der Fehler? Die Beschreibung ist etwas dürftig... Welche Schrift bleibt dann für immer in dieser Farbe?

[Fisk2033]

Ich hab mal ein kleines Video aufgenommen und hoffe,dass es als Fehlerbericht reicht.
[Video] in HD schauen,falls man kaum was erkennt
Es scheint (zumindest bei mir) ein allgemeiner Focusnamebug zu sein. Normalerweiße hat das Brot (am Anfang,wenn ich noch keinen farbigen Namen im Fokus hatte) die Standard-weiße Farbe. Danach sieht man ja im Video was passiert.

Ist nicht weiter schlimm,aber vielleicht hats ja was mit dem Problem von Eternal zu tun.

[Lehona]

Das ist tatsächlich ein Bug in der FocusNames.d, allerdings ziemlich leicht behebbar (und auch ziemlich offensichtlich, wenn man mal drüber nachdenkt ).

Wer es fixen möchte: An den Anfang der _FocusNames() einfach folgendes einfügen:

col = Focusnames_Color_Neutral(); //Standardmäßig hat jetzt alles im Fokus diese Farbe. Wer die neutrale Farbe nicht als weiß benutzt, kann col auch auf -1 setzen, damit wird der Fokusname ebenfalls weiß

Er hat aber nichts mit Print_Ext() zu tun.

[Fisk2033]

Ja stimmt...eig. ziemlich einfach, aber Focusnames sind mir eh nicht geheuer...Beim Spielstart haben Items bei mir meist garkeinen Die kann mann dann einfach aufsammeln. Und dann sind sie manchmal wieder ganz normal in neutraler Schrift vorhanden.

[Lehona]

Ja stimmt...eig. ziemlich einfach, aber Focusnames sind mir eh nicht geheuer...Beim Spielstart haben Items bei mir meist garkeinen Die kann mann dann einfach aufsammeln. Und dann sind sie manchmal wieder ganz normal in neutraler Schrift vorhanden.

Ist vermutlich der selbe Ursprung, die Zeile sollte also das Problem ebenfalls beheben. Liegt alles daran, dass Gottfried noch die Einfärbung für Items zwar als Beispiel, aber nicht konkret (d.h. es gibt zwar eine If-Abfrage für Items, da werden sie aber nicht gefärbt) eingebaut hat

[TheEternal]

Also ich konnte den Fehler nicht immer reproduzieren, deswegen ist das, was ich oben geschrieben habe nicht ganz richtig.
Ich habe mit Print_ExtPxl was in lila ausgegeben und in manchen Tests (vllt durch zu schnelles durchskippen durch die Dialoge?) kam es dann zu permanentem wechsel der Standardfarbe zu lila. Also hauptsächlich ist mir aufgefallen, dass dann "Neuer Tagebucheintrag" oder "Spruchrolle erhalten" in lila angezeigt wurden.

habs selber versucht zu fixen, indem ich txt.colored = 0 am Ende gesetzt habe, aber das macht die Farbe komplett weg. Hab ich dann rückgängig gemacht.

Außerdem kommt es dann dazu das Meldungen wie "Neuer Tagebucheintrag" manchmal nicht angezeigt werden trotz des markanten Federkratzens.

[Lehona]

Das Texte, die von PrintScreen() erzeugt werden, ebenfalls eingefärbt werden, ist/war ein bekanntes Problem, das wir bereits gelöst haben. Ich meine mich allerdings daran zu erinnern, dass das im aktuellen Release schon gefixt ist - anscheinend nicht? Ich werde das auch in der aktuellen Version nochmal überprüfen.

Dass Tagebucheinträge einfach nicht auftauchen klingt eher merkwürdig. Wenn du mir einen Weg zeigen kannst, wie ich den Fehler reproduzieren kann, würde das meine Arbeit stark vereinfachen, ansonsten versuch ich's beizeiten einfach selber mal.

[TheEternal]

Das Texte, die von PrintScreen() erzeugt werden, ebenfalls eingefärbt werden, ist/war ein bekanntes Problem, das wir bereits gelöst haben. Ich meine mich allerdings daran zu erinnern, dass das im aktuellen Release schon gefixt ist - anscheinend nicht? Ich werde das auch in der aktuellen Version nochmal überprüfen.

Dass Tagebucheinträge einfach nicht auftauchen klingt eher merkwürdig. Wenn du mir einen Weg zeigen kannst, wie ich den Fehler reproduzieren kann, würde das meine Arbeit stark vereinfachen, ansonsten versuch ich's beizeiten einfach selber mal.

ich probier mal, es zu reproduzieren.

[qiaky]

Also ich hab mich nochmal drangesetzt und mein Problem gedebugged.
Dazu erst zwei kurze Anmerkungen:
1. Ich kann verstehen, dass es nicht gerne gesehen wird, wenn Zeilen aus dem LeGo Skript verändert und dann auch noch veröffentlicht werden. Ich tue das auch nur um dem bekannten Problem auf den Grund zu gehen und hoffe auf Verständnis.
2.@Lehona: Ich habe deinen Post mit LeGo 2.2.3 erst gerade gesehen und die neue LeGo Version ist in dieser Antwort NICHT berücksichtigt.

Das Problem der verzögert aufgerufenen FrameFunctions beruht auf einem Problem beim abspeichern.
Gothics "Systemzeit" startet beim Start einer neuen Gothicsession immer bei 0.
Die FrameFunction Handles speichern ihren nächsten Aufruf unter "next". Dieser Wert benutzt einen - über Legos "Timer.d" verwalteten - absolut Wert der Spielzeit, der bei Neustart von Gothic NICHT wieder bei 0 beginnt, sondern die gesamte Gothiclaufzeit des Savegames wiedergibt.
Ermittelt wird der Wert mit Hilfe der Variablen _Timer und _Timer_Diff.
Aus Legos Timer.d:

//========================================
// [intern] Variablen
//========================================
const int _Timer_Diff = 0;
var int _Timer;
//========================================
// [intern] Initialisierung
//========================================
func void _Timer_Init() {
    _Timer_Diff = MEM_GetSystemTime() - _Timer;
};

//========================================
// Aktuelle Zeit holen
//========================================
func int Timer() {
    if(!MEM_Game.timeStep) {
        if(_Timer_PiM) {
            _Timer_Paused = 2;
            return _Timer;
        };
    };
    if(_Timer_Paused) {
        if(_Timer_Paused == 2) {
            _Timer_Paused = 0;
            _Timer_Init();
        }
        else {
            return _Timer;
        };
    };
    _Timer = MEM_GetSystemTime() - _Timer_Diff;
    return _Timer;
};

Der generelle Gedanke war wohl, beim ersten Laden nach Gothicstart (also bei Lego Initialisierung) die schon gespielte Zeit wieder in _Timer_Diff zu speichern und diese bei jedem Aufruf von Timer() auf die Systemzeit zu addieren (_Timer_Diff nimmt einen negativen Wert an).

Das Problem dabei:

_Timer = MEM_GetSystemTime() - _Timer_Diff; (Timer.d -> func int Timer() )

wird vor

_Timer_Diff = MEM_GetSystemTime() - _Timer; (Timer.d -> func void _Timer_Init())

ausgeführt wird, wenn eine FrameFunction geladen wird. Die vergangene Zeit, die im Savegame als _Timer gespeichert ist, wird also verworfen, bevor sie auf die Variable _Timer_Diff übertragen werden kann.

Somit bleibt ...

_Timer_Diff = 0 , da _Timer = MEM_GetSystemTime() - 0;

...und es kommt zur Verzögerung der FrameFunctions bis die Spielzeit der aktuellen Gothicsession den im FrameFunction Handle gespeicherten next-Wert wieder eingeholt hat. Dies wird im Verlauf des Spiels natürlich eine immer größere Differenz, sodass es irgendwann den Anschein hat, als würde die FrameFunction gar nicht geladen.

Um das Problem zu umgehen, fallen mir spontan zwei Möglichkeiten ein:

1. System mit _Timer_Diff beibehalten und den Wert von var int _Timer übertragen bevor er überschrieben wird

Dann muss man in Lego.d Änderungen vornehmen:

unter
func void LeGo_InitAlways(var int f)
den Block

    if(f & LeGo_Timer) {
        _Timer_Init();
    };

von ganz unten nach ganz oben verschieben:

func void LeGo_InitAlways(var int f) {    
    
    if(f & LeGo_Timer) {
        _Timer_Init();
    };
    
    if(f & LeGo_PermMem) {
        if(Handles) {
[...]
        if(f & LeGo_Cursor) {
            Cursor_Event = Event_Create();
        };
    };
};

Damit ist eine absolute Spielzeit von ca 600h möglich (Millisekunden die in einen signed 32-bit Int passen).

2. Möglichkeit:
die absolute Spielzeit des Savegames nicht mehr berücksichtigen und in der SCRPTSAVE.SAV bei den FFItem Handles unter FFItem.next die Millisekunden abspeichern, die bis zum nächsten auslösen fehlen. Also FFItem.next <= FFItem.delay.
Dazu habe ich noch kaum Überlegungen angestellt und erst recht kein Skript verändert, Ansatzpunkt wäre aber in Framefunctions.d der FFItem_Archiver und FFItem_Unarchiver.
Anmerkung dazu: ich habe keine Ahnung, für was alles der Timer verwendet wird und beziehe mich hier nur auf Framefunctions.

Diese Änderungen habe ich allerdings noch nicht ausführlich getestet.
Aber es ist ein Anfang.

Gruß
qiaky

EDIT: Bessere Lesbarkeit, überdachte Lösungsansätze

[TheEternal]

Also ich habe den Fehler mit der veränderten Schriftfarbe eingrenzen können.

Ich benutze zum printen von besonderen Variablen folgende Funktion:

func void Print_ATTVAR(var string varstr, var int value) {    var int i;
    var string FINAL_STRING;
    FINAL_STRING = varstr;
    FINAL_STRING = ConcatStrings(FINAL_STRING, ": ");
    FINAL_STRING = ConcatStrings(FINAL_STRING, IntToString(value));
    //               x, y, text,   font,        color,                time
    i = Print_ExtPxl(100, 150, FINAL_STRING, FONT_Screen, RGBA(100, 0, 255, 200), 6000);
};

Die Farbe ist lila.
Wenn man die Mod das erste mal startet und etwas mit Print_ATTVAR printet, dann ist alles ok, aber sobald man ein neues Spiel hinterher startet, wird die lila Farbe für alle Standard Strings wie MARVIN-Mode, Sprocherolle gegeben etc benutzt. Außerdem werden Neuer Tagebucheintrag gar nicht erst geprintet, aber das kratzgeräusch der feder kommt noch.
Sie Bild:

Spoiler:(zum lesen bitte Text markieren)

[Bild: ximg.php?fid=11929562]

Durch zu schnelles Skippen der Dialoge habe ich es auch geschafft, dass die Schrift lila bleibt(dies passiert hauptsächlich, wenn die Schrift noch auf dem Screen ist, wenn ein Kapitelwechsel stattfindet). Und das schon beim ersten Spielstart, nach dem .ini start.

[Fisk2033]

Hier auch gleich noch ne Frage.. Würde sich Anim8 eigendlich für ein Segelboot eignen,das von 5-18 Uhr draußen rum fährt, immer wieder mal anhält, angelt und dann weiterfährt?

Wie schauts eig. mit dem Release aus, gibts da schon irgendwas neues? Levitation schwirrt mir immer noch im Kopf rum!

[Nincompoop]

Hallo,
ich fange gerade an, mich mit Lego/Ikarus zu beschäftigen und frage mich, wie man herausfindet, welche Funktionen man braucht und woher man weiß, wie diese aussehen. Das mag zwar etwas verfrüht für mich sein, da ich gerade mal in der Lage bin, die Beispielanwendungen nachvollziehen zu können, aber es interessiert mich doch sehr und könnte vielleicht auch helfen, die Skriptpakete besser zu verstehen.

An einem konkreten Beispiel: Schlösser knacken.
Zuerst kommen natürlich die Überlegungen dazu:
Meine Idee ist es, die Kombination zufällig zu gestalten (das klappt, basierend auf einem Script von Bonne6) aber im Gegenzug sollten Fehler leichter vergeben werden, wenn sie zum ersten auftreten, da es zu dem Zeitpunkt ja reiner Zufall ist.
Zuerst dachte ich daran, für jede einzelne Stelle in der Kombination zu merken, wie oft der Spieler dort bereits "vorbeikam", jedoch bräuchte man dafür wohl für jede Truhe ein Array der länge der Kombination und das ist glaube ich nicht so leicht.
Dann dachte ich, einfach nur zu merken, bis wohin die Truhe bereits geknackt wurde. Das sollte die Engine selbst ja ebenfalls abfragen, sie muss ja wissen, mit welcher Stelle der Kombination sie die Spielereingabe abgleicht. Allerdings wird sie evtl. einfach den String abarbeiten und beim Abbruch fängt sie dann wieder von vorne an, aber selbst dann müsste man sich nur noch für jede Truhe eine Zahl merken, die den Fortschritt angibt. Diese Zahl kann ich mir dann "irgendwo" merken und beim Knacken der Truhe hochzählen, bei einem Fehler dann prüfen, ob ich schon bei "fortschritt" angekommen bin, entsprechend den Dietrich abbrechen lassen und den Zähler zurücksetzen.

Letztlich spaltet sich das Problem in zwei Zweige auf: 1) Wie merke ich mir diese Zahl? 2) Wie komme ich an die Berechnung?
Und ab hier bin ich ziemlich ratlos.
1) Klassenerweiterungen sind wohl nicht möglich, soweit ich das hier mitbekommen habe? Demnach bräuchte ich wohl eine ungenutzte Variable der Klasse OcMobLockable(?) oder könnte ich auch eine Liste erstellen und mir dort den Fortschritt merken? Die Lockables kann ich ja durchlaufen (bzw. die Vobliste) und bräuchte nur noch eine Liste erstellen, die den Fortschritt und evtl. einen Pointer auf das Mob enthält. Diese Liste könnte ich dann beim Schlösserknacken durchlaufen, bis ich auf den richtigen Pointer stoße(?).
2) Wo/wie finde ich diese Berechnung und woher weiß ich, wie sie aussieht? In den offenen Skripten habe ich nur die G_picklock gefunden und diese kommt leider erst nach der gesuchten Funktion. Kommt man an diese Berechnung überhaupt ran?
Als Notlösung hatte ich noch die Idee zu hooken, dabei bin ich in Zerxes Ttabelle auf

 oCMobLockable::PickLock(oCNpc    * char)

gestoßen. Leider kann ich damit auch noch nicht viel anfangen (), aber es wird ein NPC(?) und ein Buchstabe übergeben, also evtl. ist das die Stelle, an der die Eingabe überprüft wird? Wie erhalte ich Gewissheit? Bzw. das kann ich mit PrintScreens prüfen, aber wenn es die falsche Stelle ist, wie finde ich die Richtige? ^^
Jedenfalls könnte ich dann ja extern prüfen, ob ich schon mal an dieser Stelle war und dann "einfach" die Geschicklichkeit temporär runter- bzw. raufsetzen oder ähnliches. Wobei das nicht gerade elegant ist.

Mein Hauptproblem ist halt tatsächlich, an diese Berechnung zu kommen, an den anderen Stellen würde ich auch gerne selbst rumprobieren (sofern ich mich nicht unwissentlich in einer kompletten Sackgasse befinde), da man so ja doch am besten lernt. Aber dafür brauch ich halt erst mal diesen Ausgangspunkt.
Ich habe das jetzt zwar mit einem konkreten Beispiel beschrieben, aber mir geht es vor allem darum, zu wissen, wie ich an den einzelnen Stellen vorgehen muss. Die Lösung für das Schlösserknacken ist Sekundär (oder prim-einhalb-är *g*).

Vielleicht ist das besser im Ikarusthread aufgehoben, ich war mir nicht ganz sicher.

Edit: Der Hook funktioniert übrigens. Wann immer ich nach links oder rechts drehe wird "hmgnah" auf den Bildschirm gedruckt.

[Lehona]

Das ist eine durchaus schwierige Angelegenheit, selbst für den fortgeschrittenen Ottonormalscripter

Im Endeffekt gleicht das ein bisschen einer Schnitzeljagd. Im Normalfall hat man am Anfang eine oder mehrere Enginefunktionen, die vom Namen her da irgendwie in die Nähe des Problems gehören. Diese Funktionen muss man sich jetzt anschauen bzw. analysieren und herausfinden, was genau dort abläuft. Eventuell hat man dann Glück und findet einen Abschnitt, den man vielleicht so umschreiben kann (oder hooken kann), dass das gewünschte Verhalten auftritt. Meistens muss man sich aber durch mehrere Funktionen hangeln, bis man eine passende Stelle findet. Wenn du sowas wirklich irgendwann mal selber können willst, empfehle ich dir das Intel Handbuch (Intel® 64 and IA-32 Architectures Software Developer’s Manual Combined Volumes: 1, 2A, 2B, 2C, 3A, 3B, and 3C, v.a. Volume 1 und 2A+2B sind für dich interessant). Das ist aber eine Menge harte Arbeit


oCMobLockable::PickLock(oCNpc*, char) scheint aber genau die richtige Funktion zu sein und auch nicht sooo kompliziert. Momentan habe ich Besuch, aber vielleicht komme ich in den nächsten Tagen dazu, mir das mal anzuschauen (und genau herauszufinden, was du eigentlich willst, so ein Textwall am Morgen ist irgendwie zu viel für mich).

Edit: Was mir gerade noch einfällt: Ich habe vor einiger Zeit schonmal rausgesucht, wie genau die Abbruchswahrscheinlichkeit berechnet wird (Eigentlich nur (100-Dex)%), das Ändern der Formel ist z.B. ziemlich einfach.

[Nincompoop]

Das ist eine durchaus schwierige Angelegenheit, selbst für den fortgeschrittenen Ottonormalscripter

Im Endeffekt gleicht das ein bisschen einer Schnitzeljagd. Im Normalfall hat man am Anfang eine oder mehrere Enginefunktionen, die vom Namen her da irgendwie in die Nähe des Problems gehören. Diese Funktionen muss man sich jetzt anschauen bzw. analysieren und herausfinden, was genau dort abläuft. Eventuell hat man dann Glück und findet einen Abschnitt, den man vielleicht so umschreiben kann (oder hooken kann), dass das gewünschte Verhalten auftritt. Meistens muss man sich aber durch mehrere Funktionen hangeln, bis man eine passende Stelle findet. Wenn du sowas wirklich irgendwann mal selber können willst, empfehle ich dir das Intel Handbuch (Intel® 64 and IA-32 Architectures Software Developer’s Manual Combined Volumes: 1, 2A, 2B, 2C, 3A, 3B, and 3C, v.a. Volume 1 und 2A+2B sind für dich interessant). Das ist aber eine Menge harte Arbeit

Hm, äh, vielleicht später. ^^

oCMobLockable::PickLock(oCNpc*, char) scheint aber genau die richtige Funktion zu sein und auch nicht sooo kompliziert. Momentan habe ich Besuch, aber vielleicht komme ich in den nächsten Tagen dazu, mir das mal anzuschauen (und genau herauszufinden, was du eigentlich willst, so ein Textwall am Morgen ist irgendwie zu viel für mich).

Edit: Was mir gerade noch einfällt: Ich habe vor einiger Zeit schonmal rausgesucht, wie genau die Abbruchswahrscheinlichkeit berechnet wird (Eigentlich nur (100-Dex)%), das Ändern der Formel ist z.B. ziemlich einfach.

Keine Eile, wie gesagt ich mache das aktuell vor allem um LeGo und Ikarus kennen zu lernen. Die Formel habe ich leider noch nirgends gefunden.

Was den Textwall angeht: Da habe ich viel drumherum geschrieben, im Grunde will ich beim Schlösserknacken abfragen, ob man schon mal an dieser Stelle der Kombination war oder nicht und den Spieler halt bestrafen, wenn er an einer Stelle einen Fehler macht, die ihm eigentlich bekannt sein sollte.

[Lehona]

Die neue LeGo-Version ist soweit fertig, dass die Öffentlichkeit sich an sie herantrauen kann - aber da ich damals noch nicht die Gewichtung von Branching oder Test Driven Development kannte, bin ich mit dem Testen soweit hinter her, dass ich jetzt erstmal gerne eine Alpha releasen würde.
Es wäre sehr nett, wenn ihr diese neue Version kurz installieren (ggf. ein Backup eures alten LeGo-Ordners machen - nur zur Sicherheit!) und dann testen könntet. Auch wenn ich natürlich auch die versteckten Bugs gerne finden würde, wäre mir am wichtigsten zu wissen, ob ich irgendwas Größeres kaputt gemacht habe. Ein kurzes "Alle meine LeGo-Anwendungen funktionieren noch." wäre also das, was ich gerne hören würde Ansonsten halt soweit es geht eine kleine Beschreibung des Fehlers, das erleichtert mir die Arbeit und spart viel Zeit (gerade, da ich mittlerweile alleine arbeite).

LeGo 2.3.0a






@Nincompoop: oCMobLockable hat ziemlich viel Platz in seinem Bitfield (nur 3 Bits sind genutzt), da solltest du dir also locker merken können, wie weit der Held bereits gekommen ist. Viel wichtigere Probleme dabei: Du musst diesen Wert zurücksetzen, wenn neue Kombinationen generiert werden (je nachdem, wann du das machst, eine kleine, aber nicht schwierige, Aufgabe) und du musst die Bestrafung noch scripten.

Edit: Verdammt, PickLockNr besetzt natürlich nicht 1 Bit, sondern 30 Also kein Platz im Bitfield des oCMobLockable, aber eventuell im zCVob? Weiß nicht, ob das gespeichert wird. Sonst musst du irgendwie über den Hashindex des zCObjects arbeiten, mal schauen.

[Nincompoop]

Die neue LeGo-Version ist soweit fertig, dass die Öffentlichkeit sich an sie herantrauen kann - aber da ich damals noch nicht die Gewichtung von Branching oder Test Driven Development kannte, bin ich mit dem Testen soweit hinter her, dass ich jetzt erstmal gerne eine Alpha releasen würde.
Es wäre sehr nett, wenn ihr diese neue Version kurz installieren (ggf. ein Backup eures alten LeGo-Ordners machen - nur zur Sicherheit!) und dann testen könntet. Auch wenn ich natürlich auch die versteckten Bugs gerne finden würde, wäre mir am wichtigsten zu wissen, ob ich irgendwas Größeres kaputt gemacht habe. Ein kurzes "Alle meine LeGo-Anwendungen funktionieren noch." wäre also das, was ich gerne hören würde Ansonsten halt soweit es geht eine kleine Beschreibung des Fehlers, das erleichtert mir die Arbeit und spart viel Zeit (gerade, da ich mittlerweile alleine arbeite).

LeGo 2.3.0a

Hui, ihr seid echt unermüdlich dabei. Klasse.

Aber als Einsteiger habe ich noch keine Skripte, die ich anpassen müsste. ^^
Wobei eines fast fertig ist und (zumindest in 2.2) funktioniert, nur noch aufpolieren. Und dann wäre da noch meine MultiBook Variation, aber die ist aktuell eh mäh.

@Nincompoop: oCMobLockable hat ziemlich viel Platz in seinem Bitfield (nur 3 Bits sind genutzt), da solltest du dir also locker merken können, wie weit der Held bereits gekommen ist. Viel wichtigere Probleme dabei: Du musst diesen Wert zurücksetzen, wenn neue Kombinationen generiert werden (je nachdem, wann du das machst, eine kleine, aber nicht schwierige, Aufgabe) und du musst die Bestrafung noch scripten.

Edit: Verdammt, PickLockNr besetzt natürlich nicht 1 Bit, sondern 30 Also kein Platz im Bitfield des oCMobLockable, aber eventuell im zCVob? Weiß nicht, ob das gespeichert wird. Sonst musst du irgendwie über den Hashindex des zCObjects arbeiten, mal schauen.

Hm, merken wie weit ich bin ist glaube ich recht einfach. Ich brauche ja nur eine neue Instanz, die sich das Mob und den Fortschritt merkt und baue mir ein Array mit einem Objekt dieser Instanz für jedes MobLockable. Nach der Methode gehe ich aktuell fast überall vor. ^^
Obendrein müsste ich das Schlösserknacken wohl noch simulieren, um zu wissen, ob ich beim aktuellen Versuch schon bei "Fortschritt" angelangt bin oder nicht. Daher sollte sich die Instanz wohl noch die Position merken.

Aber dann ist immer noch das Problem, dass ich nicht weiß, wie ich die Berechnung für die Abbruchchance ändern/aushebeln kann.

Ist aber erst mal auch nur ein Nebenprojekt, ich habe etwas anderes gefunden, dass mich gerade gut auf Trab hält.

[Atmus]

Ich hab einen Fehler gefunden. Ich weiss nicht ob das mein Fehler ist oder nicht. Sehe das:

func void ChangeHPTexture(var string tex)
{
    var oCViewStatusBar bar; bar = _^(MEM_Game.hpBar);
    _View_SetTexture(bar.value_bar,tex);
    bar.texValue = tex;
};

1. new game
2. save game (HP Textur ist original)
3. ruft ChangeHPTexture mit neuer Textur
4. load game

und HP Textur ist immer geändert. (Ich kann das selbstverständlich manuell zum Original ändern)