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
Zitieren
