Seite 115 von 117 ErsteErste ... 1565105111112113114115116117 LetzteLetzte
Ergebnis 2.281 bis 2.300 von 2331

Thema: Programmwunsch und -erstellungsthread #2

  1. #2281
    Also ich mache das "manuell": Es gibt in jedem Event am Anfang das Common Event BLOCKER und am Ende den ENT_BLOCKER, welche jeweils den PP fürs Menü on und off schalten. Habe damit eigentlich wenig Beschwerden. Ich will aber auch nicht behaupten, dass es totsicher ist. Wenn jemand das ganze Spiel hindurch auf der Esc Taste rumhämmert will ich nicht ausschließen, dass noch irgendwas komisches passiert. Der Maker ist da manchmal unberechenbar.

  2. #2282
    Mit den super-manuellen Blockern in jedem Interaktions-Event geht das relativ sicher und ich werde in dem Spiel,
    für das das Menü ist, diese Arbeit auch nicht tun müssen, sondern andere, da ich mich nur um das Menü selbst
    und ein bisschen was anderes kümmere. Aber ich muss denen ja nicht mehr antun (in Sachen von Extra-Arbeit
    aufbrummen, die ich irgendwie rechtfertigen muss) mit Technikschwächen als unbedingt nötig ist.

  3. #2283
    Hey hey, ich wollte mal nachhacken, wo den das super Programm für den RM2k3 von Cherry hingekommen ist, welches ermöglicht hat größere Charsets zu verwenden, wie zum Beispiel beim RMxp. Bedanke mich schon mal für die Hilfe.

    Greez Artwork

  4. #2284
    Das gibt es mittlerweile für DynRPG ^^
    http://www.multimediaxis.de/threads/...9Fere-Charsets!

  5. #2285
    Da 2k nicht so meine Domäne ist:
    Ist es möglich, eine variable Startposition hinzubekommen? Wie genau das passiert ist mir dabei egal, also ob ich jetzt rpg_rt.exe --position=X,Y,MAPID mache oder die tatsächliche Startposition verändere, bevor ich das Spiel starte (durch Manipulation der Maps? Kein Plan was da machbar ist).

  6. #2286
    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.

  7. #2287
    Oh, smart. Da hatte ich jetzt gar nicht dran gedacht

  8. #2288
    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.

  9. #2289
    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.

  10. #2290
    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.

    Falls da jemand was machen möchte:
    [GamePicture] ⇒ [] ⇒ [+08] (Liste) ⇒ [+04] (Array) ⇒ [+(PictureID-1)*4] ⇒ [+B4] (2000) bzw [+C0] (2003)
    (GamePicture = 2000 1.07: 49AE40, 2000 1.61: 4A0E10 (glaub ich...), 2003 ab 1.08: 4CDF3C)

    Zitat Zitat
    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.

    Geändert von MagicMaker (27.06.2016 um 22:22 Uhr)

  11. #2291
    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

  12. #2292
    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.

  13. #2293
    SwitchOnMenuCall
    Ersetzt den Aufruf vom Standardmenü per Abbruchtaste durch einen Switch, standardmäßig #1017.

    RPG_RT.exe-Version: RPG2000 1.07 + 1.61, RPG2003 1.08 + 1.11

    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:
    Code:
    <>Change Switch: [1017:MenuCall] = OFF
    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:
    Code:
    CE0001: "Menü"   Trigger: [AutoStart]   Switch: [1017:MenuCalling]
    
    <>Game Menu: Disallow   Caller vorerst sperren
    <>Change Switch: [1017:MenuCalling] = OFF   Switch ausschalten hat keinen Einfluss darauf, ob das Menü weiterläuft
    <>Play Sound: Decision1 (Vol 100, Pitch 100, Pan 50)   Ein xbeliebiges Signal zum Öffnen vom Menü
    <>Loop Start
     <>Show Choice: "Status", "Optionen", "Speichern", "Beenden", ExtraCancel   Provisorische Auswahl zur Demonstration
     : Choice ["Status"]
      <>Show Message: "Hier gibt's nix!"
      <>
     : Choice ["Optionen"]
      <>Show Message: "Hier gibt's ne doppelte Portion Nix!"
      <>
     : Choice ["Speichern"]
      <>Go To Label: 99
      <>
     : Choice ["Beenden"]
      <>Set Face: Delete
      <>Show Message: "Willst du wirklich zurück zum Titelbildschirm?"
      <>Show Choice: "Nein", "Ja"
      <>
      : Choice ["Nein"]
       <>
      : Choice ["Ja"]
       <>Go To Titlescreen
       <>
      : Choice End
      <>
     : Cancel
      <>Play Sound: Cansel1 (Vol 100, Pitch 100, Pan 50)
      <>Break Loop
      <>
     : Choice End
     <>
    : Loop End
    <>Go To Label: 100
    <>Label Set: 99
    <>Call Save Menu
    <>Label Set: 100   Ende vom Menüprozess
    <>Game Menu: Allow   Dafür sorgen, dass das Menü nachher wieder geöffnet werden kann
    <>
    Um einen anderen Switch zu verwenden, tragt an der jeweiligen Hex-Adresse eure gewünschte Nummer ein.
    • 2000-1.07: 0x0008CA4A
    • 2000-1.61: 0x00086BDA
    • 2003-1.08: 0x000A8EAE
    • 2003-1.11: 0x000BD796



    SwitchOnMenuCall rv100 (2015|06|29)

  14. #2294
    Bei v1.09a+ (inkl. der offiziellen englischen Version!) den "End Game"-Menüeintrag entfernen:

    https://cherryshare.at/f/3Giamb/RPG_...mandInMenu.ips


  15. #2295
    Wäre es möglich, Die Position des Schattens der normalen Schriften im Spiel zu ändern? Also der normale Schatten ist immer um X1Y1 versetzt, ich hätte aber zum Beispiel gerne X0Y1.

  16. #2296
    Klar, welche Makerversion genau?

  17. #2297
    RM2k3 1.08.

  18. #2298
    Ah, du verwendest ja DynRPG - Hier als QuickPatch:

    Code:
    ShadowX0=489611,00

  19. #2299
    Das war schnell! Vielen Dank!

  20. #2300
    Hab einen kleinen Patch für den offiziellen RM2k3 gemacht, um 125 Sprites in BAs nutzen zu können so wie es RM2k9U erlaubt hat (mit derselben Einschränkung dass höhere Sprites nicht korrekt gespiegelt werden wenn die BA gespiegelt wird):

    https://cherryshare.at/f/U7Zxc1/rpg2...25baframes.ips

    Auf die RPG2003.exe (nicht RPG_RT.exe) vom offiziellen Maker anwenden. (Backup nicht vergessen.)

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •