Wow... this is awesome =DZitat:
Zitat von dragonheartman
I waited for this =)
Druckbare Version
Wow... this is awesome =DZitat:
Zitat von dragonheartman
I waited for this =)
@dragonheartman:
Hey, cool :D
Its very good and this is a of the "Tools" or "Plugin" that i need :)
Thx :)
Hallo Kirsche,
eine Sache müsste echt nochmal gefixt werden: Die Eventpageverarbeitung im Kampfsystem geht so ganz und gar nicht, weil einfach nicht mehr sicher ist, dass Code ausgeführt wird wenn man es erwartet. Das ist irgendwie bitter, denn mit DynRPG könnte man echt tolles Gameplay basteln. Ohne ist das 2k3 System ätzendst langsam, mit dem Eventpageproblem allerdings ist man zurück in der Ära des blinden Enterdrücken weil einfach keine eigenen Systeme mehr verlässlich funktionieren.
Am nachvollziehbarsten passiert das Verschlucken immer wenn gerade auch Monster am Zug sind und angreifen ausserdem kommen Monsterangriffe sehr verzögert wenn parallel ein Spielercharakter dran ist.
Normal:
- Monster turn elapsed (+aufblinken)
- Monsterangriff
- Spieler Does X Command
- Spielerangriff
- Spielernachbearbeitung (wichtiger Code)
DynRPG:
- Monster turn elapsed (+aufblinken)
- Spieler Does X Command
- Spielerangriff
- Monsterangriff
Je nach genauen ATB Werten ab und an etwas zufällig anders, diese Reihenfolge entspricht dem was ich gerade eben nochmal getestet hab.
Hast du den IPS-Patch draufgetan der das längere Skillwindow entfernt? Damit sollte das nämlich für den Moment eigentlich behoben sein...
(Übrigens, so als Tipp: In RPG::updateBattleEvents steckt immense Power ;) )
Wo tue ich diese .ips-Datei eigentlich rein? Ich habe zwar noch keine Probleme gehabt, aber man kann ja nie sicher genug gehen.
Sauber! Das tuts!Zitat:
Zitat von Cherry
@Auge des Sterns:
Benutz den mal, machts nur besser.
Leider hilft das nicht. Der Moment des Aufrufens muss nach der Handlung des Akteurs passieren. Diese beiden...Zitat:
Zitat von Cherry
bool onDoBattlerAction (RPG::Battler *battler)
bool onBattlerActionDone (RPG::Battler *battler, bool success)
...werden beide vor der eigentlichen Action ausgeführt. Um den Kniff des gezielten "Switch on" um im nächsten Zyklus Code aufzurufen kommt man also nicht herum.
Hey! Netter Patch. Habe gerade auf die Schnelle für einen Freund ein Plug-In zusammengeschrieben.
Aber mal eine Frage (wurde vielleicht schon gefragt, aber keine Lust, mir alle Seiten durchzulesen):
Gibt es einen besonderen Grund, wieso RPG::Key kein KEY_SHIFT enthält? Fom RM2K3 wird die Taste ja immerhin unterstützt. Kam mir ein bisschen komisch vor. Ist zwar kein Ding, die Taste mit C++ nachträglich auszulesen, aber wäre natürilch schön, wenn ich mein Plug-In komplett über RM-Funktionen bedienen könnte.
In der Doku steht:
"The Shift key is handled differently by the RPG Maker, thus it can't be used the way other keys can be used by DynRPG."
( Quelle )
Der 2k3 ist, wenn man den Disassemblern unserer Community glauben schenkt, zuweilen etwas schräg zusammengehackt. Da die Shi8fttaste ein neues Features des 2k3 ist kanns gut sein, dass es in diese Kategorie fällt.
Mann, wie konnte ich das nur übersehen? Genau die Beschreibung habe ich mir doch durchgelesen und mich gewundert, wieso kein KEY_SHIFT dabei ist. Ich stehe echt neben der Spur! 0_o
Naja, hier mal mein erstes Plug-In:
http://rpg-hacker.de/RPGMaker/Downlo...ningScript.rar
Es ist nichts weltbewegendes. Nur ein Lauf-Skript (Laufen, durch Drücken der Shift-Taste). Als ich mal versucht habe, sowas im Maker direkt einzubauen, hat es seltsamerweise zu unerklärlichen Bugs geführt.
Nutzung (per Comment in einem Parallel Process Common Event):
WobeiCode:@DynRun X, Y, Z
X: Laufgeschwindigkeit (1 bis 6)
Y: Gehgeschwindigkeit (1 bis 6)
Z: Aktivierungs-Switch
Der für Z verwendete Switch muss im Maker auf ON gestellt werden, damit der Held per Shift laufen kann. Entsprechend kann er nicht mehr laufen, wenn man den Switch wieder auf OFF stellt.
Und hier noch der Source Code:
http://pastebin.com/pgsxzPnQ
Ich garantiere nicht für Fehlerlosigkeit.
Wie kann ich mir das mit den Neben-Modulen eigentlich vorstellen? Wenn ich
in einem Modul definiere, kann ich dann mein Plug-In in mehrere DLLs aufsplitten? Und kann ich einem Neben-Modul dann immer noch alle Callbacks verwenden? Und wann werden die aufgerufen? Günstig wäre es, wenn sie erst nach dem Haupt-Module aufgerufen werden.Code:#define NOT_MAIN_MODULE
Ich plane nämlich, ein paar Plug-Ins auf Basis der Spiele-Library Allegro 5 zu schreiben. Logischerweise benötigen alle Plug-Ins dann auch Allegro 5 (was somit mein Haupt-Modul wäre), aber ansonsten soll man - wenn man bestimmte Funktionen haben will - auch nur Teil-Module verwenden können, solange nur das Haupt-Modul vorhanden ist und die Library initialisiert hat. Geplant sind unter anderem eine Library für Musik (und somit alle Musik-Dateien, die von Allegro unterstützt werden) und eine Library für Tastenabfrage (Tastatur und Gamepad).
Das würde dann so aussehen:
-DynA5Main (Mindesvoraussetzung)
--DynA5Keys (Optional)
--DynA5Music (Optional)
--Weitere optionale, auf Allegro 5 aufbauende Plug-Ins
EDIT:
Nope, scheint wohl nicht so zu funktionieren. Schade!
Hi,
Ich habe versucht das Plugin zu testen und wurde sofort von folgenden Fehlermeldungen begrüßt:
Anhang 13748
Ach Mist... Das ist der GNU GCC Compiler. Scheinbar habe ich es wiedermal nicht hinbekommen, das Ding ordentlich statisch zu verlinken. :/
Ich gucke mir das ganze nochmal an.
EDIT:
So, neue Version ist oben (selber Link). Kannst du es nochmal ausprobieren? Hoffe das statische Verlinken hat diesmal funktioniert.
Ich hab zwar keine Ahnung von C++, aber das ganze scheint interessant zu sein :P
Bin am Überlegen ob ich vllt ein Mode7 Plugin schreibe? Kp xD
Das würde sicherlich schwer und performancelastig werden, denn letztendlich müsste das ja trotzdem alles über die Grafik-Engine des Makers laufen.
Wenn du Ahnung hast, wie M7 aufgebaut ist, nur zu.Zitat:
Bin am Überlegen ob ich vllt ein Mode7 Plugin schreibe? Kp xD
Mein Versuch, allein nur die perspektivische Anzeige ohne irgendwelche Rotationen zu machen (ohne Dyn),
laggt leider extrem und braucht etwa 180MB extra im RAM.
http://garden.magicmaker.cherrytree....-alpha009B.png
Okay, dann lass ichs lieber xD
Es würd mich aber wirklich interessieren, wie sowas mit Dyn läuft.Zitat:
Okay, dann lass ichs lieber xD
Naja, da man in Dyn ja Threads verwenden kann, sollte es zumindest theoretisch sein. Wobei ich jetzt nicht weiß, inwiefern man da mit der Grafik-Engine des Makers arbeiten muss. Die dürfte ja die größte Begrenzung bei dem ganzen sein, da man weiterhin alle Bilder darüber anzeigen muss.
wie gesagt ich kenn mich nicht mit C++ aus. war nur so ne Idee von mir.Zitat:
Zitat von MagicMaker
WIe hast du denn das ganze ohne Dyn geregelt?
Mit Referenzbildern die aussehen wie die Map und der Kopierfunktion von Destiny.
Wenn die jetzt noch selbst 2 Streckungsparameter hätte, könnte ich eine ganze Menge Rechenarbeit und RAM-Verbrauch sparen.
Bitte mal um Gegenchecken seitens der Community: onDrawBattleStatusWindow funktioniert bei mir nicht. Checkt das mal bzw. gibt es da Dinge, die ich nicht weiss?
Dann gibt es da eine Irreführung in der Dokumentation der Funktion onBattlerDrawn
Zitat:
id Zero-based party member Id of the battler
- im Falle eines Monsters ist es die 0-basierte ID des Monsters in der Monstergroup, Monster 4: id=3
- im Falle eines Helden ist es die Id des Heldens in der Datenbank, Held 0001: id = 1
Ich hoffe das wurde hier noch nicht gefragt... Aber ich habe bis jetzt nur kenntnisse was C# angeht. Und soweit ich weiß ist da der große Unterschied die komplette Objektorientierung... Aber was muss ich beachten wenn ich eben C++ für dieses Plugin benutzen will?
Syntaktisch gibt es zwischen C# und C++ zwar keine so großen Unterschiede, allerdings wirst du dennnoch stark umdenken müssen beim Umstieg. Insbesondere im Hinblick auf Klassen ist C++ so viel unflexibler und fehleranfälliger als C#. So ohne weiteres wirst du jedenfalls nicht umsteigen können. Ich empfehle dir, zumindest ein kompaktes Tutorial zu überfliegen. Durch die C#-Kenntnisse dürftest du zwar schneller reinfinden, als jemand komplett ohne C-Kenntnisse, aber ohne irgendein Nachschlagewerk dürfte das recht schwer bis unmöglich werden. Wenn auch nur, weil C++ immer schon bei den dümmsten Kleinigkeiten rummeckert und man als User oftmals die Fehler weder sehen noch nachvollziehen kann. Zumindest ist hier ein Vorteil für dich, dass für ein Plug-In eine Source-Dateie völlig ausreicht, also musst du dir nicht erst angucken, wie Header-Dateien funktionieren. Die gibt es ja in C# gar nicht erst.
Thanks for the positive feedback. Cherry provided me some tips and I have updated the plugin to fix a memory leak. Links are still the same:
https://www.dropbox.com/s/a4bsrvp5kq...d_monsters.dll - plugin
https://www.dropbox.com/s/si7cfu0ims...d_monsters.cpp - source code
Moreover, here is a sneak peek of a diablo3-style minimap I am working on:
http://sphotos.xx.fbcdn.net/hphotos-...35881844_n.jpg
The map is dynamically created using terrain data and to make things even cooler you can resize/reposition it real-time. The player is always at the origin of the map so it looks great even at small sizes. Lastly, the minimap is revealed as you explore more of the map (with fancy alpha effects), so large maze-like dungeons are rewarding to explore.
AWESOME! Thank you very much! I really appreciate your hard work!Zitat:
Zitat von dragonheartman
And I'm looking forward to your new plugin too! ^^
Minimap? If you create such a plugin, hours of work will be spared. That is something I'm looking forward to.
I can't really say how cool this actually is.
Awesome work! Can't wait to see the sourcecode for that one.
Edit:
There's one question i have. Your'e changing the monsters image using that (as you call it) "ugly cast" and setting it back to the original every time it is drawn~
Here's what i would have done:
- Return "false" in "onDrawBattler" prevents monster from being drawn
- Draw it manually
My disadvantage is that other plugins won't receive the callback after returning false...
What reasons made you chose your current approach? Did you try others before? This is not meant to be critical, i'd just like to read your thoughts as a developer.
Jetzt mal ne vermutlich saublöde Frage:
Ist es, zumindest theoretisch, möglich, einen "Patch" zu schreiben bzw. ein eigenständiges Programm, das es ermöglicht, RPG-Maker Games für Konsolen zugänglich zu machen?
Dabei denke ich beispielsweise an Download-Contents für aktuelle Konsolen (z.B. Wii); aber auch an Apps für Smartphones und andere neuartige High-Tech Wunder.
Ein solches Programm könnte der Makerszene völlig neue Möglichkeiten bieten, auch wenn die Projekte wohl primär als Freeware angeboten werden würden.
Was denkt ihr?
Solange die RPG Maker Engine auf Windows-Schnittstellen zugreift, nicht möglich, weil diese nicht portabel sind. Soweit ich es verstanden habe, injiziert Cherrys DynRPG lediglich Sprungpunkte in die RPG Maker Engine, d.h. daran, auf welche Schnittstellen die RPG Maker Engine zugreift, wird nichts geändert.
Naja, soweit ich weiß sind ja sämtliche Daten des eigentlichen Spiels in den Unterordnern und den Datenbank-Files gespeichert. Deswegen wäre es theoretisch möglich, vorausgesetzt man könnte diese Datenbank-Files entschlüsseln und mit einer selbst geschriebenen Engine auf der Ziel-Konsole verwerten. Wobei ich da aber schwarz sehe bei deinem Beispiel mit Download-Content, inbesondere mit der Wii. Erstens wäre das ja dann eine illegale Entschlüsselung und zweitens würden die Hersteller dieser Konsolen diese Spiele wohl kaum in ihr Online-Angebot aufnehmen. Es bleibt als nur die Möglichkeit, das ganze über Wii-Homebrew laufen zu lassen (und wie gesagt nur, wenn man die Engine erst eigens dafür programmiert).
Projekte diese Art gibts schon mehrere. Das größte ist easyRPG, davon gibts Runtimes für DS, A320, PSP (I think), Anrdoid (?) und andere.
Kann man mit nem Plugin die Pfeiltasten ausmachen?
Bräuchte das nähhmlich, will mit den WASD Tasten spielen und nicht mit den Pfeiltasten, außerdem ist das auch bequemer wenn man die Maus noch benutzen muss^^
Ich finds ja schön, wie Linkshänder bei der Bedienbarkeit ignoriert werden. Und überhaupt, WASD ist einZitat:
außerdem ist das auch bequemer wenn man die Maus noch benutzen muss^^
unglaublich dummer Tastenblock umgeben von anderen Tasten, die Pfeiltasten sind als Pfeiltasten perfekt
weil man sich bei ihnen nicht verdrücken kann.
Ich will ja eine Einstellung einbauen, mit der man zwischen den WASD- und Pfeiltasten wechseln kann.
Ich spiel nähmlich persönlich lieber mit WASD, da verdrück ich mich auch nicht xD
Wobei du zugeben musst, dass du keinen wirklichen Nutzen davon hast, die Pfeiltasten gezielt zu deaktivieren. Die bessere Frage wäre also gewesen "Kann man durch ein Plugin WASD als Pfeiltasten-Ersatz verwenden?"Zitat:
Zitat von Soul96
Ich glaube, dass das sogar möglich ist. WASD auszulesen ist mit C++ ohnehin kein Problem. Ich meine aber, dass man in DynRPG auch irgendwie auf die Tasten des Makers zugreifen kann. Deshalb muss man nur WASD von der Tastatur abfragen und dann die Tasten des Makers updaten.
Kann man das nicht einfach mit Inelukis Tastenpatch regeln O.o? Oder gibt es da irgendwelche Konflikte mit den Move Events?
Ich hab das jetzt so das man beides WASD und die Pfeiltasten benutzen kann.
Ich will aber das nur eins möglich ist.
Ich benutze für die Maus, sowie für Tasten das Plugin von Cherry.
Leider kann man damit die Standard-Maker-Tasten nicht abschalten :/
Zumindestens weiß ich ncihts davon...
Naja, ein Plugin das die Tasetn abschaltet wäre nciht schlecht.
Die ESC bzw. Menü-Taste lässt sich ja durch das abschalten des Menü ausschalten.
Bitte konkret erläutern, ich sehe keinen Sinn.Zitat:
Ich will aber das nur eins möglich ist.
Wer 2012 immernoch damit Tasten abfängt obwohl es zuverlässigere Möglichkeiten gibt, wird verhauen.Zitat:
Kann man das nicht einfach mit Inelukis Tastenpatch regeln O.o?
[zB ist das wahrscheinlich besser was Soul schon nutzt ↓]
Damit ist es doch sowieso getan oder? Wenn nicht, antworte mal auf meine erste Zeile. ^-^Zitat:
Ich benutze für die Maus, sowie für Tasten das Plugin von Cherry.
Ich würds noch für verständlicher halten, wenn man die von ASCII damals seltsam gewählten Alternativen
H J K L für die Richtungstasten ausknipsen will (wenn man die Adressen mit den Tastencodes kennt
könnte man da sogar ohne Dyn WASD oder alles andere Mögliche einstellen ohne ↑←↓→ zu löschen).
Derzeit kann man mit WASD und den Pfeiltasten sich bewegen.
Ich will aber nur das eins aktiv ist.
Beim beginn des Spiel soll man das wechseln können.
Außerdem will ich die Pfeiltasten auch über das Plugin von Cherry abfragen, damit kommt das Menü dann nciht durcheinander^^
Btw. hier mal das Plugin:
http://forum.rpg2000.4players.de/php...&hilit=+plugin
Alte Argumente wiederholen bringt keine Erleuchtung dem Gegenüber, next try.Zitat:
Derzeit kann man mit WASD und den Pfeiltasten sich bewegen.
Ich will aber nur das eins aktiv ist.
Beim beginn des Spiel soll man das wechseln können.
Wie ich es noch genauer sagen soll, hab ich keine Ahnung :/
Die Möglichkeit der Wahl zwischen WASD und Pfeilen bringt gegenüber der gleichzeitigen Verfügbarkeit von beidem keinerlei, absolut null spielerischen Mehrwert.
Leute, ich habe mal eine Frage. Ich persönlich habe von der Programmiererei ÜBERHAUPT keine Ahnung, also bin ich auf euch angewiesen :)
Ich glaube es war mal davon die Rede, dass ein Mode7 Plugin erstellt werden soll, oder? (Das ist doch diese "gekippte" Map, nicht wahr?)
Und sowas könnte ich an sich gut gebrauchen, die Frage ist nun nur, ist sowas in der Mache? Oder wird sowas gemacht werden?
LG
MajinSonic
Pedia gibt Aufschluss:Zitat:
(Das ist doch diese "gekippte" Map, nicht wahr?)
Die Frage hier ist ob Dyn und das Drumherum genug Möglichkeiten dafür bereithält und ob ein PluginCode:Im Mode 7 ist es unter anderem möglich, eine Hintergrund-Ebene zu rotieren und skalieren. Durch eine zeilenweise Veränderung der Position und Skalierung lässt sich ein einfacher Effekt räumlicher Tiefe erzeugen, der zum Beispiel in Rennspielen oder Flugsequenzen verwendet wird.
auch schnell genug mit der RPG_RT arbeiten kann, um sowas flüssig darzustellen.
Hm, naja gut, man ist bisher auch ganz gut ohne das zurecht gekommen, doch es würde mich wirklich interessieren, ob das gehen würde, oder ob das jemand vor hat. :D Ich finde diesen Effekt immer ganz tollig :D
Da DynRPG nichts an der Grafik-API des Makers ändert, halte ich es für unwahrscheinlich, dass man damit ein effektives Mode 7-Plugin machen kann. Zwar sind Matrix-Transformationen auch auf Software-Basis möglich, allerdings doch recht langsam und ineffektiv, was bei der Langsamkeit, die der Maker eh schon hat, unpraktisch ist. Heutzutage unterstützen alle Grafikkarten solche Transformationen. Man müsste also irgendwie dafür sorgen, dass man über den Maker (per Open GL oder so) direkt die Grafikkarte ansprechen kann. Ich kann mir aber kaum vorstellen, dass das gut mit der normalen Grafik-API zusammenspielt.
Wie wärs mit: Unter DynRPG einen eigenen Thread anknipsen, DirectX hernehmen und das Ergebnis auf 320*240 Rendern. Im "onFrameDrawn" jeweils aktuellstes Bild drüberzeichnen...
Dann wäre die Katastrophenmischung aber wirklich komplett, RPG_RT hybridiert sowieso schon zwischen GDI und...Zitat:
(per Open GL oder so)
wie wild herum.Zitat:
DirectX
Warum nicht OpenCL, schön die nVidia Chips nutzen und "Benötigt Shader Model 2.0" in den Hardware-Anforderungen des Spiels =p
Naja, wenn der Maker eh schon DirectX verwendet ist das was anderes. Open GL ist ja im Prinzip nichts anderes als eine Cross-Plattform-Alternative zu DirectX. Wenn man es schafft über den Maker auf DirectX zuzugreifen dürfte es durchaus möglich sein damit etwas Mode 7-artiges auf die Beine zu stellen.
Tastenbelegung ändern (z.B. WASD statt Pfeiltasten): http://rpg-maker.cherrytree.at/dynrp...be5e8f4918dccc
z.B.:
Bewegungssteuerung deaktivieren: http://rpg-maker.cherrytree.at/dynrp...01e56aa969660bCode:RPG::input->key(RPG::KEY_UP)[0] = 'W';
RPG::input->key(RPG::KEY_LEFT)[0] = 'A';
RPG::input->key(RPG::KEY_DOWN)[0] = 'S';
RPG::input->key(RPG::KEY_RIGHT)[0] = 'D';
z.B.:
Code:RPG::hero->setControlMode(RPG::CONTROL_EVERYTHING_EXCEPT_MOVEMENT);
Ich nehme an, wenn man stattdessen einen Index von 0 oder höher benutzt, wird stattdessen eine der Alternativsteuerungen überschrieben?Zitat:
Zitat von Cherry
Und mit welchen Chars setzt man Zurück auf Pfeilsteuerung? (Denn genau das wollte Soul ja: Dass man dazwischen umschalten kann)
Soweit ich weiß haben die Pfeiltasten ja keine normalen ASCII-Codes.
http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx
Index 1 müsste Num2/4/6/8 sein normalerweise, Index 2 müsste HJKL sein. Index 3 bis 7 sind vom Maker normal nicht fürs Steuerkreuz benutzt. (Man kann natürlich eigene Alternativsteuerungen da reintun.)Code:RPG::input->key(RPG::KEY_UP)[0] = VK_UP;
RPG::input->key(RPG::KEY_LEFT)[0] = VK_LEFT;
RPG::input->key(RPG::KEY_DOWN)[0] = VK_DOWN;
RPG::input->key(RPG::KEY_RIGHT)[0] = VK_RIGHT;
Optimal wäre dann sicherlich, HJKL zu überschreiben. Da hätte man einerseits beide Steuervarianten implementiert und könnte andererseits die Tasten HJKL für anderen Kram nutzen.
Kopie aus dem englischen Forum:
Zitat:
Zitat von Cherry
Hallo!
Ich wollte jetzt den DynRPG Patch installieren, habe aber den neuen KS Bugfix drauf der in der 14a Version vom Patch noch nicht enthalten ist(?).
Muss ich, nachdem ich den DynRPG Patch installiert habe den KS Bugfix nochmal nachreichen oder wird er beibehalten?
Und gibt es irgendwelche Kompatibilitätsprobleme oder kann man den Single Fix und den Patch beide ohne Probleme drauf haben?
Harmonisiert alles miteinander.
Okay!Zitat:
Zitat von Cherry
Die dynrpg_patcher.exe sagt Version 0.13b. Ich dachte die neuste sei 0.14a? Oder wie ist das?^^
Edit: Hat sich erledigt, habe eben den Changelog gelesen ;D
Edit2: Ich habe gerade entdeckt, dass wenn man beim Battlelayout "Small Window" ausgewählt hat und dann Choices im Kampf anzeigt,
der Cursor bei den Choices 2-4 nicht an der richtigen Stelle ist, sondern sich immer ein kleinwenig nach oben verschiebt je weiter man runter geht.
Könnte man das noch fixen?
@Edit2: Der Bug ist mir neu, wird notiert. Gibt jetzt aber noch keinen Fix, im Zweifelsfall Large Window verwenden...
Kein Problem. Drängt nicht. :)Zitat:
Zitat von Cherry
Mir ist noch etwas aufgefallen, weiß nicht ob das beabsichtigt ist oder nicht:
Der DynRPG Patch verlängert ja die Zeit, in der Ein Skill am oberen Bildschirmrand angezeigt wird.
Wenn der Spieler einen Skill einsetzt wird der Skillname früher gelöscht als die Box.
Vom Timing her würde ich die Box dann mitlöschen.
In den Patchlogs habe ich zwar nichts davon gelesen aber, beim Benutzen von Items würde ich die Verlängerung weglassen, da nach dem Ende der Itemuse Animation,
eine unnatürliche Pause entsteht, wo nichts geschieht und erst nach dieser Pause tritt der Itemeffekt in Kraft.
Joa, das ist leider sowieso buggy, wird in Zukunft wohl entfernt oder zumindest verbessert. Irgendwo hier im Thread fliegt ein Patch-Patch rum der das wieder wegpatcht. :)
Hatte einen Fehler in dem getMenuScreen-Code den ich hier gepostet hatte, der richtige Code ist:
Code:int getMenuScreen() {
return (**reinterpret_cast<char ***>(0x4CDC60))[12];
}
Mhh, schade. Finde es eigentlich ganz hilfreich.Zitat:
Zitat von Cherry
Drauf gemacht. Danke!Zitat:
Zitat von Cherry
Und noch ein Beitrag :P
Ich hab festgestellt, dass Pictures mit der ID 1001 und höher (sie sollen ja nach dem Mapwechsel angezeigt bleiben) auch angezeigt werden nachdem man zum Titlescreen per Spiel verlassen oder F12 geht und dann auf neues Spiel geht. Lässt sich das nicht anders vereinbaren falls sie beim Mapwechsel erhalten bleiben sollen?
Known Bug... Man könnte natürlich ein Plugin als Bugfix machen was einfach bei onInitTitleScreen sowas wie for(int i = 1001; i <= 2000; i++) RPG::pictures[i].erase(); macht.
Wenn ich das könnte, würde ich es natürlich selbst machen ^^´
Wird der Bug in der nächsten Version von DynRPG behoben?
Wenn die mal kommt: Ja.
Ich meine irgendjemand hat bereits von den Transparenzbug mit Charsets berichtet. Als ich es ausprobierte waren die Transparenzen recht unmerkbar und auf Transparent eingestellte Events waren völlig sichtbar. Daher wollte ich mal wissen, ob bereits Lösungsansätze hierzu bestehen.
Achja, und natürlich pushe ich diesen Thread mal etwas.
Das möchte ich an dieser Stelle auch einfach nochmal fragen. Sorry falls das Problem mittlerweile behoben sein sollte, aber das werde ich dann wohl nicht mitbekommen haben.Zitat:
Zitat von Auge des Sterns
Und eine weitere Frage noch:
Kann ich irgendwie das battle command window (oder wie das heißen mag), wo ich eine Auswahl treffe zwischen Angriff, Abwehr usw., versetzen, z.B. in die untere rechte Ecke des Bildschirms? Es verdeckt scheußlicherweise dauernd die Gegner und den an ihnen angerichteten Schaden, was für den Spieler ein wenig unkomfortabel ist.
Wäre dankbar über Hilfe :)
Nicht nur das, anscheinend hab ich noch einen Fehler gemacht, deswegen funktionert das ganze RPG::monsters nicht wirklich... Bäh.Zitat:
Zitat von Kyuu
DList.h: Zeile 10 und 11 (Definition von "int count" und "T *items") gehört getauscht, sodass "items" vor "count" kommt.
http://www.multimediaxis.de/threads/...=1#post3030978Zitat:
Zitat von JasonWeal
Funktioniert wunderbar =)
Hab ein Problem mit "RPG::map->events".
Ich kriegs nicht gebacken auf ein Event zuzugreifen.
Kurioserweise bekomme ich nach z.B.Code:
RPG::Event *ev = RPG::map->events[0];
RPG::Event *ev2 = RPG::map->events.get(0);
if(ev->doesEventPageExist(0)) // Speicherzugriffsfehler hier
{
CortiHelper::ShowInfoBox("Event Page Exists","hahaha");
}
RPG::Event *ev3 = new RPG::Event();
für ev3-> allemöglichen Member und Methoden im Intellisense. Die oben genannten machen zwar keinen Compilerfehler, aber Intellisense tut nichts.
Das hier:
Gibt Zahlen wie 12343242343254 um den Dreh. Erinnert mich an RPG::monsters, da gab es das Problem ja auch.Code:int i = RPG::map->events.count();
CortiHelper::ShowInfoBox(i,"hahaha");
In diesem Falle gibts für das was ich vorhabe leider kein einfaches Workaround ohne die Liste.
Zwei Posts über dir steht die Lösung (ich Depp hab zwei Member in RPG::DList vertauscht, nämlich "items" und "count" - erklärt alles, ne?).
Übrigens wird events[0] immer fehlschlagen, weil du als Index die Event ID nehmen musst und Event 0 gibts nicht. Willst du über alle Events iterieren, kannst du über events.ptr->list die zugrundeliegende RPG::DList (eigentlich DListPtr) erreichen, deren Indizes normal 0, 1, 2, 3... sind und nicht die Event IDs.
Erklärung: events ist vom Typ NamedCatalogPtr. Das ist eigentlich nur eine Hilfsklasse die NamedCatalog* ersetzt um die Zugriffe zu vereinfachen, also damit events[1] geht und nicht (*events)[1] notwendig ist. event.ptr erreicht den eigentlichen NamedCatalog*, und da NamedCatalog von Catalog erbt, ist der Member "list" dort verfügbar, welcher vom Typ DListPtr ist (was wiederum eine Hilfsklasse ist die DList* ersetzt). Der Maker kennt da leider so viel verschiedene Klassen (DList, Catalog, NamedCatalog) dass der Zugriff ohne die Hilfsklassen wie DListPtr, CatalogPtr und NamedCatalogPtr sehr beschwerlich wäre.
doesEventPageExist(0) ist auch nicht sinnvoll, weil die Event Page IDs ja im Maker bei 1 anfangen.
Okey. Hab gemerkt, dass ich zwei Versionen der DynRPG Dateien rumliegen hab und hab immer in den falschen rumeditiert.
Nach dem ich nun die richtigen erwischt habe funktioniert die Countmethode, hurray ^.^
Was die Events angeht, da bekomme ich weiterhin Speicherzugriffsfehler. Hab die DList Änderung wie beschrieben durchgeführt.
Hm, wie greifst du jetzt drauf zu? Wie gesagt, Index 0 wird nie gehen.
Mit 'ner eins ;-)
Code:RPG::Event *ev = RPG::map->events[1];
if(ev->doesEventPageExist(1))
{
CortiHelper::ShowInfoBox(1,"Event Page Exists");
}
Zitat:
Access violation in module "CortiSysRTP2k13,dll" in with address 68702079 and offset 00000004 of type Read occurred.
Schick mir doch einfach mal die DLL, dann kann ich sehen was an Adresse 68702079 ist.
Ich hab ein kleines Problem, arbeite seit ein paar Tagen mit dem DynRPG und nun wollte ich ein kleines Plugin schreiben!
Der Held soll bei jedem "normalen" Angriff und Abwehr-Befehl eine kleine Menge seiner MP wiederherstellen (Ich weiß das würde wahrscheinlich auch ohne DynRPG gehen, aber egal...^^)!
Der Abwehr-Befehl regeneriert auch die MP, aber leider der "normale" Angriff nicht... :>!
Hab erst gedacht es läge vll an der onDoBattlerAction-Methode, aber auch mit der onBattlerActionDone-Methode funktioniert es nicht >,>.
Hier ist mal der Code:
Code:bool onDoBattlerAction ( RPG::Battler * battler) {
// MP Aufladen bei einem Angriff
if (battler->action->basicActionId == RPG::BA_ATTACK ) {
battler->mp += 10;
}
// MP Aufladen bei Abwehr
if (battler->action->basicActionId == RPG::BA_DEFEND) {
battler->mp += 10;
}
return true;
}
Erstmal:
Sowohl onBattlerAction als auch onBattlerActionDone werden pro Charakter mehrfach in Folge ausgelöst. Wenn du eine Handlung genau ein mal abfragen willst, dann solltest du dies in onBattlerActionDone mit success == true machen.
Ob BA_ATTACK bei mir funktioniert kann ich derzeit nicht testen, da musste dich gedulden ;-)Code:bool onBattlerActionDone (RPG::Battler *battler, bool success)
{
if(success && !battler->isMonster() ) // Bei Helden, nur das eine mal nach dem die Handlung wirklich ausgeführt wurde
{
if(battler->action->kind == RPG::AK_BASIC &&
(battler->action->basicActionId == RPG::BA_ATTACK ||
battler->action->basicActionId == RPG::BA_DEFEND))
{
battler->mp = battler->mp + 10;
}
}
return true;
}
@Corti: onDoBattlerAction sollte eigentlich nicht mehrfach ausgeführt werden... Bist du sicher? Das hat nämlich auch keinen success-Parameter.