Was genau hat denn Corti bei seinem ATB Plugin gemacht? Das ganze einfach nur beschleunigt und komplett angehalten sobald einer am Zug ist? Oder noch irgendwas an der Formel an sich geändert?
Das Problem ist ja wirklich eher, dass das ganze System mit mehr Party Mitgliedern elendig langsam wird. Bei 1v1 Kämpfen hat das System kaum Macken, aber wenn man ne 4er Party und mehrere Gegner hat dauerts zur Zeit wirklich ne ganze Ecke.
Glückwunsch, Cherry!Du hast dir verdientermaßen einen Namen gemacht und wenn du mit dem Produkt verbunden bist, ist das für mich ein Blindkauf.
Ich hoffe, ein möglichst großer Teil der Arbeit in den diversen Fan-Erweiterungen ist nun nicht obsolet, sondern kann noch in den Maker einfließen.
Es gibt einen MaxWert an ATB-Speed basierend auf der Anzahl der Teilnehmer. Nach einem Zug wird der Wert angenähert, das wäre eine Beschleunigung. Wenn sich ein ATB-Balken seinem Ende nähert, wird proportional auf 20% des Wertes runtergebremst.Zitat von Sölf
Während der Züge ist der Wert auf 1, ich tracke zu dem "onAction"-Events und setze mit denen eine Slotdown-Zeit auf einige Frames, wobei die Eventverarbeitung buggt wenn man den AtbSpeed ganz auf 0 setzt. Um Events ordnungsgemäß ablaufen zu lassen, also um überhaupt irgend etwas Erstrebenswertes mit dem 2k3 zu bauen, müssen die Eventseiten sauber durchlaufen ohne, dass ein neuer Held oder ein Monster dazwischenhaut.
Beobachtungen:
Der Maker füllt die ATB-Leisten abwechselnd. Zumindest erhöhen sich die Werte bei den Helden gefühlt nie im selben Frame. Daher wohl auch der Effekt, dass mit jedem Kampfteilnehmer das ganze System langsamer wird. So machen sie aber auch, dass quasi in einem Tick nur ein Teilnehmer die volle Leiste erreicht.
Ich würde in einem eigenen Atb-System alle im selben Tick bearbeiten und dann die Teilnehmer mit vollem Atb anhand einer Prioritätsliste sortiert nach Agi und dann Helden vor Monstern nach aufsteigender ID drankommen lassen. Das Atb-Füllen wird dabei so lange komplett pausiert bis ein Teilnehmer seinen ganzen Zug mit Eventverarbeitung durchgezogen hat.
Hinweis noch:
In der Entverarbeitung gibt es zwei Zeitpunkte, die wichtig sind. Zwischen Kommando und Aktion, das wären dann die "Hero does X Command"-Seiten UND noch wichtiger, nach der Handlung. Diese Seiten schaltet man durch ein Switch, dass in "Hero does X Command" gesetzt und nach Bearbeitung zurückgesetzt wird.
--CortiWins GitHub DynRPG < Charguide < [2k3] Zahlen und Werte < [2k3] Kurven als Wertetemplates < [2k3] DynRPG Werkstatt
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
Hello from the otter side
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
Das scheint ja ganz gut zu funktionieren; mit deiner Genehmigung würde ich das im Code nachzubauen versuchen. Könnte ich da den Quellcode bekommen als Hilfe?
--
Mir war nichtmal bewusst dass ich nominiert wurde, aber: Cool! Hälfte des Lobes muss aber unbedingt an Archeia!Now all new and shiny:CherryShare | Patches und Tools | Programmwunschthread | www.cherrytree.at | Cherry = CherryDT
Ich seh da aber ein Problem (generell, nicht für mich, ich find Cortis Plugin auch super): Cortis Plugin stoppt bei einer Aktion, aber der Maker hat standardmäßig die Möglichkeit bei einer Aktion alle Zeitleisten zu stoppen oder weiterzulaufen. Und wenn man letzteres mit Cortis Plugin macht wird das ein gigantischer Clusterfuck, da die Gegner einen total zerreißen werden.
Oder wäre es vielleicht möglich, den Code nur beim "Warten" anzupassen? Sprich, wenn das KS wartet gibts Cortis sehr viel schnellere Folge (wodurch man quasi ein rundenbasierendes KS hat) und ansonsten läuft es langsamer (quasi wie jetzt), hält aber bei einer Auswahl nicht an.
Der Active-Mode ist eine beschissene Idee, die nur einigermaßen mittelscheisse funktioniert hat, weil das System von Grund auf ätzend lahm ist. Der Maker ist nicht dafür gemacht Handlungen parallel laufen zu lassen, nicht nur, dass die Gegner einen kaputtschlagen würden, man wird ja auch ständig in der Bedienung blockiert wenn Gegner handeln. Wenn man ATB schneller macht und somit das KS weniger scheisse, dann wird der Active-Mode das auf jeden Fall alles schlimmer machen, es wird sich frustrierend spielen und es versaut jegliche Customtechnik weil die Eventverarbeitung gar nicht mehr klar geht.
Ich sehe keine Chance den 2k3 so umzubauen, dass der Active-Mode ähnlich flüssig parallele Handlungen ermöglicht wie zB in FF13 wo das ganze by Design mit drin ist. Tötet den Active-Mode. Er war sowieso nie etwas anderes als nervig, scheisse und Fehlerquelle.
--CortiWins GitHub DynRPG < Charguide < [2k3] Zahlen und Werte < [2k3] Kurven als Wertetemplates < [2k3] DynRPG Werkstatt
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
Hello from the otter side
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
Bin ich persönlich auch für, aber das ist eben schon ein sehr tiefer Eingriff und ob das von Seiten Enterbrains/Degica gestattet wird ist wieder etwas ganz anderes.
Evtl. könnte das zu Battles: Fast/Slow umgebaut werden.
--
Mir war nichtmal bewusst dass ich nominiert wurde, aber: Cool! Hälfte des Lobes muss aber unbedingt an Archeia!Now all new and shiny:
Ich mags i.A. nicht das, während man eine Handlung auswählt, das ATB weiterläuft.
Dadurch wird nur sinnlos stress generiert, da man während der Auswahl der Handlung Zeit verliert (der Gegner schlägt auf einen ein). Dies führt dazu das die kämpfe viel schwerer werden da man keine Zeit hat sich die beste Strategie zu überlegen.
Das fand ich auch bei FF13 total ätzend. Mal abgesehen davon das man nur einen Charakter steuern konnte und der Rest KI-gesteuert war (so ein Müll). Während man nachlas was welche Fähigkeit macht wurde man halt verprügelt, ganz toll.
--
@Cherry
Erstmal gratz, dass enterbrain mit Dir eine Kooperation eingeht, damit der RPG Maker 2003 auch endlich im Westen erscheint. Mit den Nachfolgern kann ich mich nicht so ganz anfreunden, aus vielerlei Gründen. Der schwerwiegendste Grund ist allerdings der, dass man aus den Nachfolgern die Funktion: "Store Event ID" gestrichen hat, die ich sau gerne zur Unit Collision Detection benutze. Dabei kann ich mir nicht vorstellen, warum. RGSS beherrsche ich leider nicht, habe auch kaum Zeit, das zu lernen, weswegen ich lieber bei dem RM2k3 bleibe, um damit meine Spiele zu machen. Da ich mir jetzt die offizielle Version auf Steam gekauft habe, steht dem ja eigentlich nichts mehr im Weg, etwas auf Steam zu veröffentlichen, das ich im RM2k3 gemacht habe. Ich wäre nach meinen Konzepten auf den VX Ace oder den XP umgestiegen, damit ich Spiele veröffentlichen kann, aber das brauche ich nicht unbedingt. Ich weiß aber, dass die Nachfolger vorteilhafter sind.
Jedenfalls spreche ich Dir meinen größten Dank aus, dass Du das möglich gemacht hast, auch wenn die ganzen VX Ace Kiddies auf Steam den RPG Maker 2003 nicht zu schätzen wissen
Jetzt komme ich zu meinem eigentlichen Anliegen: Ist es möglich, zu implementieren, dass man die Picture IDs über Variablen steuert, sprich, dass man in den Picture-Steuer-Befehlen die IDs aus einer Variable auslesen kann? Denn das würde einiges an Skriptarbeit ersparen, wenn sich mal irgendwo ein Bug, z.B. zwei verwendete IDs gleichzeitig, einschleicht. Naja, eigentlich sogar prinzipiell.
Du meinst, den PicPointerPatch einzubauen? Sowas ist geplant, ja.
=======
So, das erste RM2k3 Update ist draußen, v1.10a!
Es ist nur ein "Quick Fix" der die schlimmsten Probleme beheben soll. Manche Fixes werden später noch verbessert (z.B. Fullscreen und Installer).fullscreen and the installer).
Details: http://steamcommunity.com/games/3628...22901753211419
Und ich habe mit Degica mal über das Patchproblem geredet. Es wird deshalb jetzt die EULA geändert werden, und eine spezielle "Patch EULA" wird erstellt. Ich kann jetzt nicht in Details gehen, aber ich glaube ihr werdet das Ergebnis mögen.
--
Mir war nichtmal bewusst dass ich nominiert wurde, aber: Cool! Hälfte des Lobes muss aber unbedingt an Archeia!Now all new and shiny:
Spitze! Weißt du auch, wann das implementiert wird?
Achso: Das habe ich ganz vergessen^^ Wird es bald auch möglich sein, .OGG-Files abzuspielen?
Was natürlich richtig great wäre, wenn man ein Breitbild-Support implementiert, also die Auflösung von 320x240 (4:3) auf 426x240 (16:9) oder auf 384x240 (16:10) im Maker änderbar macht. Aber das ist bei der Engine, denke ich mal, eine fast schon utopische Vorstellung ^^ Das Problem dabei ist nämlich, dass 4:3 auf allen Geräten gespielt werden kann, es wird halt dementsprechend skaliert. Jetzt sollte man sich aber 16:9 auf nem 4:3 Monitor vorstellen :/ Das würde entweder gestrechted, was richtig ekelig aussähe oder es würde mit dicken Filmbalken oben und unten skaliert. Also müsste man theoretisch im Titel-Screen, Game-Over-Screen und Picture-Ordner drei Unterordner haben, wo halt jeder, der sein Spiel erstellt jeweils gleichnamige Bitmaps reintut. Zumindest für Bitmaps, die an die Auflösung angepasst werden müssen. Dann müsste man das im Spiel umstellen können, ob man 4:3 will, 16:10 oder 16:9. Dann weiß die Engine "Aha, ich muss, (z.B.) auf den 16:9-Ordner zugreifen, damit ich das Bitmap mit dem Namen 'Titelbild' in dem richtigen Seitenverhältnis anzeigen kann." Das hieße, dass 'Titelbild' mit dem selben Namen jeweils im 4:3 Ordner, im 16:10 Ordner und im 16:9 Ordner läge. Bitmaps, die sich nicht an die Auflösung anpassen mussen, lägen dann nicht in den Unterordnern, sondern im Hauptordner der jeweiligen Kategorie von Grafiken (Pictue, Title, Game Over, ...)
Aber wie gesagt, ich kann mir vorstellen, dass man die Engine dafür grundlegend verändern müsste. ^^
Geändert von Drakee (30.04.2015 um 10:14 Uhr)
Uhw, klingt vielversprechend
- Das Inno -
--News: Dark Sword - Betatest gestartet!
Gamedev-Homepage | Gamedev-Bluesky | Dark Sword Discord
Shut up, I have DONE THE SCIENCE! >;|
Wenn ich das richtig gesehen habe, benutzt die RPG_RT wieder eine Harmony.dll, womit die Frage
sich ziemlich erübrigt, theoretisch geht es dann auch jetzt schon. Ich würde es ohnehin begrüßen,
wenn MP3 gar gleich durch OGG ersetzt werden würde, MP3 eignet sich einfach nicht für Spiele.
So wie du es beschreibst, wäre mir das beim Basteln eines Spiels viel zu viel Anpasserei an alle
Seitenverhältnisse, was die Vorteile von Breitbild wieder ziemlich nutzlos macht. Wenn ich ein
Spielchen im Breitbild haben will, dann auch wirklich nur im Breitbild und gestreckt wird im neuen
Vollbildmodus sowieso nichts mehr.
Mal so nebenbei:
432. Ist zwar nicht ganz 16:9, aber es gibt sowieso keine richtige 16:9-Auflösung unter 1280x720
und bei 480 Zeilen wird ja auch nicht 853 genommen, sondern für gewöhnlich 848 (oder 854).
--
Solange es hier falschzitierende Ärsche gibt, dulde ich keinerlei Zitatboxen, die von mir sein sollen.
Harmony.dll? Nein. Wie kommst du da drauf...?
--
Mir war nichtmal bewusst dass ich nominiert wurde, aber: Cool! Hälfte des Lobes muss aber unbedingt an Archeia!Now all new and shiny:
@MagicMaker Naja, ich dachte halt, dass man im Maker einstellen kann, in welchem Verhältnis das Spiel hinterher ist. Das wäre dann fix. Aber was ist mit den Usern, die nur einen 4:3 Monitor haben? Ich meine, wenn 16:9 auf einem 16:10 Monitor dargestellt wird, dann sind links und rechts noch kleine Streifen. Das ist jetzt nicht unbedingt das Drama. Okay, ich hab gerade in Photoshop geschaut, wie eine 16:9-Auflösung bei beigehaltenem Verhältnis auf 4:3 skaliert wird. So breit sind die Streifen auch nicht. Jedenfalls wäre das eine Idee, im RPG Maker bei der Erstellung des Projekts auszusuchen, welches Seitenverhältnis man will. Dann passt sich der Editor automatisch daran an, was das Projekt für Seitenverhältnisse hat. Wenn man ein anderes Verhältnis will, müsste man dann mit dem Maker das Spiel konvertieren können von 16:9 auf 4:3 ^^
Die Idee, das Spielerabhängig zu machen, also in das Spiel alle Möglichkeiten zu implementieren, wäre tatsächlich viel Aufwand. Jedoch ein fixes Seitenverhältnis sollte keinen Mehraufwand für denjenigen, der es erstellt, bedeuten. Allerdings dann, wenn er das Spiel wieder konvertiert, sodass es ein anderes Verhältnis hat. Aber das wäre ein Kompromiss. Viele würden 16:9 nehmen und dabei bleiben
In wiefern sich der Editor anpasst: Ein Beispiel. Bei 4:3 ist die minimale Mapgröße z.B. 20x15 Felder. Diese müsste der Editor dann an das ausgewählte Seitenverhältnis anpassen.
Also ich meine, ein RPG Maker 2003 Spiel in 16:9. Wie geil sähe das denn aus?
Geändert von Drakee (30.04.2015 um 11:01 Uhr)
Du meinst das?
--
@Zakkie Okay, der VX Ace hat das wohl wieder. Hab ich übersehen. Sorry für die Aussage dann. ABER der XP hat die Funktion trotzdem nicht^^ Und mit dem VX Ace kann ich mich im Sinne eines ABS oder eines Horrorspiels irgendwie nicht anfreunden. Dafür würde ich lieber den XP nehmen. Aber allein wegen den 1000 Picture IDs zieh ich erstmal wieder den 2003er vor. Klar, mit RGSS braucht man 1000 Pictures dann nu auch wieder nicht und kann sich seine custom Menus und BSs selber skripten, aber RGSS kann ich wie gesagt (noch) nicht und aktuell zieh ich lieber Java/C++ im Rahmen meines Studiums vor, wobei RGSS eine ähnliche Syntax hat... etwas ähnlich. ^^
@Cherry mir ist übrigens noch was eingefallen. Kann man das implementieren, dass man bei Pictures einstellen kann, dass sie von Tile- und CharSets überdeckt werden können (Upper Tileset mit Stern markiert)? Das selbe wäre bei Battle Animations genial. Das wäre perfekt für ABSysteme. Ein Schwertschwung oder ein Feuerball liegt ja in der Regel nicht über einem Baum drüber
Geändert von Drakee (30.04.2015 um 14:10 Uhr)
Das sind aber nur eine persönliche Präferenzen, wie man was makern könnte. Das hat nichst mit den Makern selbst zu tun.
--
@Drakee
Auf dem XP braucht man für ein AKS eigentlich gar keine Pictures mehr, weil die Events beliebig groß sein können und eine Methode, die die Event-ID für eine bestimmte X/Y-Koordinate zurückliefert, ist eine Sache von ein paar Minuten.
Berechtigungen
Zitieren
"Wolfenhain" fertig. "Endzeit": fertig. Neues Projekt: "Nachbarlicht" 
