Das Problem in Dyn 0.20 mit RPG::Image::drawText, von dem immer wieder berichtet wird (z.B. hier) scheint mit der libDynRPG.a zusammenzuhängen, die mit Dyn 0.20 ausgeliefert wird (siehe hier). Ich kann nur vermuten, dass da was beim Übersetzen/Linken schiefgelaufen ist (vorausgesetzt, der Quellcode, den ich von dir habe, ist der selbe, den du auch für die ausgelieferte libDynRPG.a verwendet hast), denn bei meiner libDynRPG.a funktioniert RPG::Image::drawText wie es soll.
Das Problem in Dyn 0.20 mit RPG::Image::drawText, von dem immer wieder berichtet wird (z.B. hier) scheint mit der libDynRPG.a zusammenzuhängen, die mit Dyn 0.20 ausgeliefert wird (siehe hier). Ich kann nur vermuten, dass da was beim Übersetzen/Linken schiefgelaufen ist (vorausgesetzt, der Quellcode, den ich von dir habe, ist der selbe, den du auch für die ausgelieferte libDynRPG.a verwendet hast), denn bei meiner libDynRPG.a funktioniert RPG::Image::drawText wie es soll.
...
Kompiliert man RPG::Image::drawText() mit DynRPG 0.14a, dann funktioniert es. Sowohl mit dem alten, als auch mit dem neuen (0.20) Loader. Kompiliert man mit 0.20, dann funktioniert es nicht.
Dadurch musste ich alle PlugIns, die bei mir RPG::Image::drawText() benutzen, mit nem alten Compiler (GCC 4.6.1) und DynRPG 0.14a kompilieren. Eine Möglichkeit, alle PlugIns unter einer Compiler-Version zu haben, hätte schon was X'D
PeAcE
MorDen
--
»Ein Traum kann auch die Wehmut nach der verlorenen Vergangenheit sein…«
»Manchmal ist eine Enttäuschung auch einfach nur das Ergebnis zu hoher Erwartungen.«
__________________________________________________________________________
Hätte mich auch gewundert, wenn es in 0.14a nicht funktionieren würde. Wie gesagt, Image::drawText funktioniert mit meiner libDynRPG.a (0.20) einwandfrei!
Obwohl ich diesen Thread erst so spät wahrnehme und somit auch das DynRPG aber... jetzt nachdem ich die ersten Plugins gesehen und einige davon ausprobiert habe muss ich dich endlich fragen: Cherry, willst du mich heiraten?
Ich bräuchte mal Hilfe mit dem Maus und Keyboard Plugin.
So sieht meine Ini-Datei gerade aus:
Die Maus und ihre Tasten reagieren wunderbar.
Nur die Tasten (hier von oben nach unten: W, A, S, D) wollen nicht funktionieren. Das einzige was ich rausfinden konnte ist, dass der Switch wieder auf off gesetzt wird, wenn er von etwas anderem eingeschaltet wird (habe ich testhalber mit F9 ausprobiert).
Ich habe die Tastenzuweisungen auch als Kommentare in einem dauernd ablaufenden Parallelen Prozess eingefügt:
Ist es eigentlich egal, ob man die Tasten in der Initialisierungsdatei oder als Kommentare abspeichert?
Wie G-Brothers bereits gesagt hat passiert das mit den Sounds auch bei mir. Aber auch nur sehr sehr selten.
Und! Ich kann nur wiederholen, dass DynRPG neue, revolutionäre Standards setzt. Ich freu mich zur Zeit darüber wie ein kleines Kind am Weihnachtsbaum.
Müssen die vier Einträge nicht unter das [keyboard_mouse_input]?
...
Nein, auch dann funktioniert es bei mir nicht. Ich finde das seltsam, bei Euch allen funktionieren die Tasten doch reibungslos, oder? Sonst wäre das Problem ja bekannt.
Sollte bezwecken, dass Event 1 immer gezeichnet wird, auch wenn es nicht im Sichtbereich ist. Das funtioniert nur in der X-Achse. Sobald das Event in Y aus dem Bild wandert, wird onDrawEvent nicht mehr gerufen.
Was mögliche Fixes angeht, ich benutze noch 0.17 weil 0.20 bei mir damals irgendwas kaputt gemacht hat.
Edit: Die DrawEvent-Callbacks werden jeweils mehrfach aufgerufen. Wtf?
Hi,
ich arbeite mich grad an dem DynRPG ein (bin eher ein mittelmäßiger Programmierer).
Einfach mal Frage: kann man mit den DynRPG ein eigenes Battle System bauen?
Es ist eine vollewertige Programmiersprache dahinter, du kannst Eingaben abfragen, Grafiken anzeigen und Sound abspielen. In Theorie und Praxis kannst du mit DynRPG auch ein Echtzeitstrategiespiel einbauen. DynRPG ist noch nicht sooo gut darin umfassend auf die Datenbanken des Makers zuzugreifen, so praktisch wie in Ruby mit den neuen Makern ist es also nicht.
Was meinst du denn genau mit "eigenes Battle System"?
... es fehlen halt eine ganze Menge callbacks um Herumgefummel mit verschiedenen Sequenzen zu ersparen (für das Verarbeiten von Code zum passenden Zeitpunkt).
Wie viel bei "Herumfummeln mit der richtigen Sequenzierung" verbleiben soll kann ich nicht sagen. Ich kann neue Sachen testen, will aber nicht zu viel zumüllen.
Bugmenot, ist dir der SkillWindowDuration-Fix bekannt?
Im ersten DynRPG hatte die Cherry die Anzeigedauer dieses "Monster nutzt X skill" -Fensters erhöht. Das hat nahezu jede Form eines intelligenten Kampfsystems ruiniert, weil die Eventverarbeitung dadurch korrumpiert wurde. Es gab dafür einen Fix. also für 0.17. In 0.20 funktioniert der nicht mehr, weil es dort eine "bessere" Version gab, wenn ich mich recht entsinne. Besser war aber immer noch Mist, weshalb ich meine Plugins allesamt für 0.17 mache und 0.20 ignoriere.
In Dyn0.14 wurden die Delays nach dem Einsatz von Items und den Monsteraktionen DoubleAttack / Defend / Observe / Charge / SelfDestruct / Escape von 40 Frames auf 90 Frames erhöt.
Der normal_skill_window_duration fix überschreibt das wieder mit 40.
Dyn0.20 nutzt wieder 40 Frames, nimmt diese Zahl aber aus einem call to function her << hier macht der normal_skill_window_duration fix alles kaputt, weil er in die Sprungweite der call-Anweisung schreibt >> dann wird eine falsche Adresse aufgerufen und die Applikation stürzt ab.
In Dyn0.14 wurde der Delay nach Skills von 30 auf 90 Frames erhöt. SkillWindowDuration macht 30 Frames daraus, Dyn0.20 macht 50 Frames daraus.
Dies hier sollte in Dyn0.20 wieder 30 Frames (nach einer Skillaktion) daraus machen:
Dass das Abziehen der MP-Kosten und die Verarbeitung des Skills durch das bisschen mehr Wartezeit an anderer Stelle etwas kaputt macht, ist bedauerlich.
Alternativ kannst du ja das Schließen des Fensters mit dem SkillNamen über
Wo ich das gerade mit den MP lese, im 2k3 KS wird ja keine MP Heilung/Schaden angezeigt. Könnte man das auch anzeigen lassen? Vielleicht in einer andersfarbigen Zahl als Grün (HP Heilung) bzw. dem standard Blau (Hp Schaden) - oder was auch immer für eine Farbe aus der Textbox genommen wird.