Eine Sache würde mit einem Patch (von denen ich keine Ahnung hab) bestimmt gehen: Das Spiel auf einer schwarzen Map starten, aus einer Datei die Koordinaten und Map-ID einlesen und dann den Spieler auf die Position teleportieren.
Wenn irgendjemand rausbekommen könnte, wie RPG2000 oder 2003 Inhalte gestreckt auf andere Bilder kopiert,
wie es bei Fensterhintergründen aus der Systemgrafik der Fall ist, wo die Funktion liegt und welche Parameter
sich wo befinden müssen, wär das ziemlich nett, ich zerbrech mir hier schon ne ganze Weile über Tage hinweg
darüber den Kopf und bin am Verzweifeln. RPG_RT-Version ist absolut egal, ich mach gerade sowieso was für
mehrere Versionen und leite mir dann alles von einer auf die restlichen ab.
--
Solange es hier falschzitierende Ärsche gibt, dulde ich keinerlei Zitatboxen, die von mir sein sollen.
Gibt es vielleicht eine Möglichkeit das Spielgeschehen "einzufrieren", um ein eigenes Menü zu basteln?
Ich benutze nämlich viele Move-Picture-Befehle und die gehen dann einfach weiter, auch wenn das Menü aktiv ist.
Wäre cool wenn das irgendwie ginge, genau so wie im Standard-Menü, da wird das Spielgeschehen ja auch irgendwie eingefriert.
Da du wahrscheinlich auch Pictures im Menü verwendest, klingt das nach ner sehr selektiven Sache.
Solange die Bewegungen nicht jeden Frame ne neue Anweisung kriegen, statt sich über irgendeinen
Zeitraum von A nach B zu verändern, seh ich erstmal schwarz. Man könnte... auf den Restwartewert
von jedem erwünschten Pic zugreifen und diesen jeden Frame pseudo-frosten. Das bringt aber nicht
wirklich was, sobald man das Menü verlässt und möglicherweise die Prozesse währenddessen
durcheinandergeraten. Müsste man mal testen.
genau so wie im Standard-Menü, da wird das Spielgeschehen ja auch irgendwie eingefriert.
...
Ja, da das Spiel SceneField verlässt und damit vieles von der Verarbeitung ausschaltet. Solange du
nicht vor hast, mit DynRPG ein Menü in ner eigenen Scene mit C++ zusammenzuklöppeln, hilft diese
Methode nicht wirklich. Denn das Spiel friert dann einfach ein und das war's. Es steht still, weil es ja
nicht weiß, was in Szene drölf zu tun ist.
--
Solange es hier falschzitierende Ärsche gibt, dulde ich keinerlei Zitatboxen, die von mir sein sollen.
Hmm... Ist also doch komplizierter als gedacht. Ich dachte, dass man dann vielleicht ein Event weiterlaufen lassen kann, aber das geht wohl leider nicht.
Kann man denn auf den Restwartewert von einem Picture zugreifen? Wüsste leider nicht wie.
Danke übrigens für die schnelle Antwort
Selbst mit DynRPG sehe ich keine Möglichkeit ein einziges Event weiter laufen zu lassen. Die Bewegung des Helden wird unterdrückt, wenn du ein Autostart laufen hast. Es kann auch nur ein Autostart zur Zeit laufen. Dein eigenes Menü wird sicherlich per Tastenabfrage in einem PP aufgerufen. Mach das Menüevent selbst trotzdem als Autostart. Die anderen PPs aus dem Kampfgeschehen kann man nicht so einfach pausieren, du könntest sie aber am Zyklusende manuell pausieren, davon ausgehend, dass deine PPs alle elegant und kurz gehalten sind. Eventbewegungen auf der Map kann man so aber nicht einfrieren. Die üblichen Kniffe wie ein Mapwechsel sind allesamt unelegant und mit anderen Nebenproblemen verbunden.
Aber nicht verzweifeln, eine Lösung gibt es immer irgendwie. Nur ist sie manchmal mit etwas mehr Aufwand verbunden.
Der Switch, der benutzt wird (oder eine höhere ID, z.B. 5000), muss vor dem allerersten möglichen Menüaufruf
einmal im Spiel verwendet worden sein, damit die Werte von Switch 1 bis X im Speicher initialisiert sind.
Beispiel, was beim Spielstart gemacht werden könnte:
Das Standardmenü kann weiterhin per Event geöffnet werden (<>Call Game Menu), soweit ich beim Testen,
festgestellt hab, gibt's keinen negativen Einfluss auf Dinge wie DirectMenuPatch, soll heißen: Kompatibel.
Auch das Sperren von eurem Menü geht nun so einfach wie beim Standard, das macht nun der altbekannte
normale Eventbefehl (<>Game Menu: Disallow).
Was der Patch bei einem CustomMenu behebt:
Interaktion mit Events zum gleichen Zeitpunkt wie das Menü aufgerufen wird, was zwangsweise eins der beiden
Dinge je nach Fall hinten anstellt (oder bei sowas dummem wie einem Mapmenü die Interaktion ganz frisst).
Das Verhalten hat die Aufruffunktion vom Standardmenü nicht, da die Engine es rechtzeitig blockiert.
Was der Patch bei einem CustomMenu NICHT behebt:
Generelle Probleme mit Events, die bereits parallel im Gange sind. Bislang hab ich dafür leider keine einfache
Lösung, sah aber eh die andere Sache erstmal als kritischer an.
"Noch nicht ganz verstanden. Muss ich mein Menü noch irgendwie manuell aufrufen lassen?"
Nö, das macht das Spiel von allein, solange ein Event, vorzugsweise CommonEvent, auf den Switch reagiert.
Beispielaufbau von einem sehr primitiven Menü-CommonEvent:
Um einen anderen Switch zu verwenden, tragt an der jeweiligen Hex-Adresse eure gewünschte Nummer ein.
Zitat
Berechtigungen
Zitieren
