Hallöchen ich hab ein kleines Problemchen ^^;
Offensichtlich vertragen sich DynRPG und BetterAep nicht bei allen Funktionen...
(Der Dateipfad in der Fehlermeldung hat so auf meinem Rechner nie existiert)
Der Fehler tritt auf, seit ich eine BetterAep rpg_rt.exe mit Dynrpg verwende und wird genau dann ausgelöst, wenn ich die Funktion nutze, Bilder mit einer ID höher als 50 anzuzeigen. In meinem Fall genau bei Show Picture 143 usw.
Könnte jemand mit DynRPG + BetterAep testen, ob Bilder mit einer ID über 50 im 2k3 v1.08 funktionieren oder ob der gleiche Fehler auftritt? Ansonsten würde ich wohl wieder auf BetterAep verzichten müssen ^^;
@Davy: Danke ^^;
...
Ich würde mich ausnahmsweise mal selbst zitieren, da das Problem noch immer besteht ;_; (sorry wenn ich nicht lange genug auf eine antwort gewartet habe.. ^^° will nur sicher gehen, dass es nicht übersehen wurde...)
Danach könnte der Fehler auftreten, wenn:
-die RPG2003.exe nicht an allen Stellen gleich verändert wurde --> bei mir nicht so, hab alles richtig gemacht und im Ultimate auch noch mal getestet
-man Pictures anzeigt/bewegt/löscht, welche es nicht gibt (etwa Picture 0, oder ein Picture mit größerer ID als 50) --> bei mir nicht so, der Fehler kommt bereits beim Show Picture von nur einem gewöhnlichen, importierten Bild mit ID 142
-wenn man andere Transparenzen als 0 oder 100 wählt? --> bei mir nicht so
Ich habe es auch noch einmal mit meiner gewöhnlichen RPG_RT.exe versucht, die nur mit DynRPG gepacht ist und da klappt es...
--> Bestätigt mich darin, dass DynRPG und BetterAep sich nicht vollständig vertragen ;_;
Hey Cherry, wann wird es eine aktuellere Version des DynRPG SDKs geben, mit allen bisherigen Korrekturen und Erweiterungen, die hier herumschwirren? Ich pflege zwar meine eigene Kopie von DynRPG, aber eine aktuelle Version auf deiner Webseite (die Anlaufstelle für DynRPG) wäre nicht schlecht.
Und, wie stehen die Chancen für ein onMapChanged()-Callback?
Ich hab, wie man sicher merkt, einfach keine Zeit für den Maker. Ich hab eine Datei BUG2.txt, die sieht so aus:
...ich hätte also genug zu tun.
Ich hab dir jetzt hier aber mal mein MinGW mit DynRPG hochgeladen, d.h. da ist auch der Compiler dabei der garantiert funktioniert (ein relativ alter). Außerdem ist da eine DynLoader.dll die neuer ist als die die vom Patcher erzeugt wird (die hat den Bug gefixt dass wenn der letzte Parameter bei einem Comment ein String oder Token ist dass da zusätzliche Müll-Zeichen angehängt werden können). http://share.cherrytree.at/showfile-9356/mingw_dynrp.7z
--
Mir war nichtmal bewusst dass ich nominiert wurde, aber: Cool! Hälfte des Lobes muss aber unbedingt an Archeia!
Ja leider, wobei das meiste davon das SDK selber betrifft, nicht die Spielmechanik - bis auf das Problem mit der Eventseitenverarbeitung im Kampf (da gibts einen IPS-Patch dagegen), die Tatsache dass Bilder >1000 (die "permanenten") bei New Game nicht gelöscht werden und den Transparenzbug (der ist wohl das Ärgerlichste im Moment, und ich hab auch mal versucht den Fehler zu suchen aber noch nicht gefunden).
Der Rest sind z.T. schon gefixte Sachen bzw. Vermutungen, die vielleicht gar kein wirklicher Fehler sind.
--
Mir war nichtmal bewusst dass ich nominiert wurde, aber: Cool! Hälfte des Lobes muss aber unbedingt an Archeia!
@Davias:
So wie du es schreibst klingt es schlimm. Ist es aber nicht. Mit dem erwähnten Patch, der die Skill Window Duration wieder auf Standard setzt ist wieder alles in Butter. Da du momentan bei Elektra Kingdom den Atb-Entfernungspatch einsetzt hast du was das angeht allerdings sowieso schon wesentlich schlimmere Phänomene in deiner Maker.exe ;-)
Ich hab, wie man sicher merkt, einfach keine Zeit für den Maker. Ich hab eine Datei BUG2.txt, die sieht so aus:
Zensiert.
...ich hätte also genug zu tun.
...
Kein Problem. Deine Liste ist übrigens zu chaotisch und kann einen schlechten Eindruck von DynRPG vermitteln, wenn man wenig mit dem Inhalt anfangen kann (siehe Davy Jones). Und was machen getLowerLayerTileId, getUpperLayerTileId und getTerrainId in deiner BUG2.txt?
Zitat von Cherry
Ich hab dir jetzt hier aber mal mein MinGW mit DynRPG hochgeladen, d.h. da ist auch der Compiler dabei der garantiert funktioniert (ein relativ alter).
...
GCC 4.4.1 (die mit CodeBlocks 10.05 mitgeliefert wird) funktioniert eigentlich recht gut mit DynRPG, zumindest soweit ich getestet habe. Die GCC in deinem Paket ist auf Version 3.4.5, aus dem Jahr 2004. Ehrlich gesagt, so ein alter Compiler schreckt mich etwas ab, da die Compiler sich seit 2004 stark verbessert haben sollten. Ich bin schon mit GCC 4.4.1 (2009) nicht wirklich zufrieden.
Zitat von Cherry
Außerdem ist da eine DynLoader.dll die neuer ist als die die vom Patcher erzeugt wird (die hat den Bug gefixt dass wenn der letzte Parameter bei einem Comment ein String oder Token ist dass da zusätzliche Müll-Zeichen angehängt werden können). http://share.cherrytree.at/showfile-9356/mingw_dynrp.7z
@Kyuu: Ich dachte bisher, 4.6.1 ist okay, aber da gabs anscheinend ein Problem mit RPG:attler::getMaxHp, was mit 3.4.5 nicht vorhanden war. Keine Ahnung ob 4.4.1 da geht oder nicht. Ich weiß übrigens selber nicht warum mein Compiler so alt ist, weil 2004 hatte ich mit C++ noch null am Hut.
Ja, die Liste ist chaotisch, ist auch keine öffentiche. Und es sollte eher TODO.txt heißen, das stimmt. Einige Sachen sind nämlich auch einfach neue Ideen bzw. Details die ich erst nachher rausgefunden habe und integrieren müsste (wie RPG:BActor::_unknown_128).
--
Mir war nichtmal bewusst dass ich nominiert wurde, aber: Cool! Hälfte des Lobes muss aber unbedingt an Archeia!
@Kyuu: Ich dachte bisher, 4.6.1 ist okay, aber da gabs anscheinend ein Problem mit RPG:attler::getMaxHp, was mit 3.4.5 nicht vorhanden war. Keine Ahnung ob 4.4.1 da geht oder nicht.
...
Habe es gerade mit 4.4.1 getestet und es funktioniert einwandfrei. Eine Test Suite wäre natürlich optimal, mit der man automatisiert die Kompatibilität mit einem Compiler prüfen könnte.
Eine andere Frage: Sind die 2000 Pictures, die mit DynRPG zwangsläufig kommen wirklich so eine gute Idee? Zum einen bin ich mir ziemlich sicher, dass niemand (bei klarem Verstand) so viele Pictures brauchen wird und zum anderen, (das ist nur eine Vermutung, da ich die Interna nicht kenne) so eine große Menge an Pictureobjekten, die jeden Frame abgearbeitet werden müssen, könnte wertvolle Zeit verschwenden, die einem Plugin gerade fehlen könnte. Ich vermute, dass DynRPG noch weitere Änderungen im Programmablauf vornimmt, die Zeiteinbußen einbringen. Wäre vielleicht eine abgespecktere Version von DynRPG möglich, ohne die 2000 Pictures und eventuellen anderen Kram, den man nicht wirklich braucht, der aber wertvolle Zeit verschlingt?