Seite 8 von 15 ErsteErste ... 456789101112 ... LetzteLetzte
Ergebnis 141 bis 160 von 296

Thema: Detail-Wissen und Geheimnise des RPG-Makers -vorallem für Erfahrene/Profis lehrreich

  1. #141
    Nein über Wände laufe etc. ist gedrückte STRG-Taste.

  2. #142
    Uuups, hast Recht! Ist mir auch gerade aufgefallen, ich hab die beiden Tasten verwechselt. Aber wenn es eine "Dialog-taste" auf dem Gamepad gibt, dann muss es da bestimmt auch eine "Fliegen-taste" geben. Ich probiere das gleich mal aus!

    EDIT: Also, ich habe jetzt alle 12 meiner Gamepad-tasten ausprobiert und keine davon hat mich duch Wände laufen lassen!

  3. #143
    Es ist leider nicht der Fall, dass die Gamepads einem bestimmten Standard folgen und alle die selben Tasten der Tastatur mappen. Je nach herstellerspezifischem Treiber werden andere Tasten gemappt, oder auch garkeine. Dazu sollte man sich mal die Konfiguration des Gamepads in der Systemsteuerung anschauen.
    Eine unabhängige Möglichkeit zum mappen der Tasten der Tastatur auf das Gamepad wäre das Tool Joy2Key.

  4. #144
    Achso. Ich hab es kappiert! Dann werde ich mir das Tool auch mal irgendwo saugen. Danke für den Hinweis!

    EDIT: Hey, ich habe bemerkt das das Tool ziemlich nützlich ist bei Benutzung des Keypatches für den Rm2k. Die Spiele sind so viel leichter zu spielen!

  5. #145
    Ich glaube dies wurde noch nicht genannt:

    Wenn bei zwei oder mehr Seiten eines Events die Startbedingungen erfüllt sind wird automatisch die Seite mit der höheren Seitenzahl verwendet.
    D.h. Eventseite 28 hat höhere Priorität als Eventseite 27.

    Herausgefunden habe ich das, da ich bei einer typischen Zeitanzeigeeventschar zunächst die letzte Seite so angepasst habe, dass die Null nur angezeigt wird, wenn die Variable nicht höher 10 war. Das resultierte jedoch darin, dass immer 0 angezeigt wurde, selbst wenn eine vorherige Seite die Bedingung Variable größer als 10 hatte und die Variable tatsächlich größer als 10 war.

    Ich denke das ist bei komplexeren Ereignissen der Bugverursacher schlechthin.

  6. #146
    Das hab ich schonmal bemerkt als im mit mehreren TABs und Variablen in einem Event gearbeitet habe.
    Ich finde diese Funktion, aber schon praktisch.

    ...ich glaub das hab ich beim SKS basteln bemerkt.

    Zitat Zitat
    Ich denke das ist bei komplexeren Ereignissen der Bugverursacher schlechthin.
    Ohhhjaaaa

  7. #147
    Zitat Zitat von mitaki Beitrag anzeigen
    Ich glaube dies wurde noch nicht genannt:

    Wenn bei zwei oder mehr Seiten eines Events die Startbedingungen erfüllt sind wird automatisch die Seite mit der höheren Seitenzahl verwendet.
    D.h. Eventseite 28 hat höhere Priorität als Eventseite 27.

    Herausgefunden habe ich das, da ich bei einer typischen Zeitanzeigeeventschar zunächst die letzte Seite so angepasst habe, dass die Null nur angezeigt wird, wenn die Variable nicht höher 10 war. Das resultierte jedoch darin, dass immer 0 angezeigt wurde, selbst wenn eine vorherige Seite die Bedingung Variable größer als 10 hatte und die Variable tatsächlich größer als 10 war.

    Ich denke das ist bei komplexeren Ereignissen der Bugverursacher schlechthin.
    Huch , ich dachte das wäre bekannt?
    Der Maker beachtet übrigens bei einem Event immer zuerst die Eventseite mit der höheren Nummer. Wer das testen möchte -> Baut euch mal ein Truhenevent.
    Nur stellt ihr bei der ersten Seite den Switch/Selfswitch für die Öffnung ein und auf der darauffolgenden zweiten Seite eben die die geschlossene Truhe mit dem Inhalt von eben dieser.

    Schon wird die Truhe unerschöpflich sein. Der Maker liest eben die zweite Seite zuerst und sieht das die Bedingungen von eben dieser erfüllt sind. Also bleibt er auch dort. Das von dir nun neu entdeckte gilt also auch wenn nicht zwei Seiten diesselbe Bedingung erfüllen.


    ~ Makenshi

    Geändert von makenshi (22.11.2006 um 08:26 Uhr)

  8. #148
    \o/ Juhuu! Es gibt neue Posts zu ungelüfteten RPG-Maker Geheimnissen!!! Wie? Was?
    Grundkentnisse zu Eventseiten?
    Geheimnisse die gar keine sind?

    Leute, nehmt den Thread doch bitte etwas ernst! Wenn ihr jede Hürde, über die ihr beim Makern stolpern, hier mitdokumentiert, wird der Thread seinem Namen
    Zitat Zitat
    Detail-Wissen und Geheimnisse des RPG-Makers -vorallem für Erfahrene/Profis lehrreich
    nicht so ganz gerecht.

    Ich fände es schade, wenn gerade hier die Quantität über die Qualität überhand nimmt.
    Nur mal so als Tipp für zukünftige "Geheimnisse".

  9. #149
    Zitat Zitat von RPG Hacker Beitrag anzeigen
    Du bist ja ein ganz kluger, du! Das man mit dem GamePad Textboxen schließen kann WAR mir ein Geheimnis! Und das man mit dem RPG Maker 2003 MP3s abspielen kann, auch. Dann bin ich halt ein Noob, na und?
    Recht hat er dennoch. Der Thread soll ja für Erfahrene/Profis als Austauschplattform dienen. Bzw. auch als Sammelthread. Da sind solche Sachen die selbst im Quartier Kurs erwähnt werden etwas fehl am Platz.

  10. #150
    Gut, dann lösch ich die Beiträge eben wieder... Wenn es überhaupt geht!

    EDIT: Das man auch das Gamepad für Sonderfunktionen nutzen kann hab ich aber nicht in der Anleitung gefunden, deswegen lasse ich es auch stehen!

  11. #151
    Mir sind einige Kleinigkeiten aufgefallen.

    zB war mit noch nicht bewusst, dass man im Testmodus mit F10 ans ende des gerade aktiven Events springt...

    Ich hate neulich ein Problem, von dem ich allerdings nicht sagen kann, ob es generell auftritt oder wieso es auftritt. Ich hatte ein CE, das ich in ein map-event kopiert habe und musste feststellen, dass, sobald ich einen Loop in diesem Event "verlassen" wollte (durch labels oder breaks) das Spiel abstürzte und die Fehlermeldung "??????? RPG_RT xxxxxx Reading xxxxxxx2D ???????" oder so ähnlich brachte. Als das Event wieder unter den CE's ausgeführt wurde, klappte es wieder.

    Wenn man zwei Events auf "Over Hero" stellt, wählt der Maker nicht nach Event ID, sondern scheinbar willkürlich fest welches der beiden Events über dem anderen angezeigt wird.

    Clear Timer funktioniert übrigens nicht in CE-Events, die auf Autostart stehen.

    Tschau, Ich bin raus
    Beril ^^

  12. #152
    Bezüglich eiens anderen Threads ist mir das gerade nochmal eingefallen:

    Bei dem Befehl "MoveEvent" werden zwischen "StartJump" und "EndJump" scheinbar keine anderen Befehle außer Richtungsangaben ausgeführt (MoveUp, MoveDown, MoveLeft, MoveRight).

    Hab das ein paar mal getestet und es scheint sowohl für den RM2k als auch für den RM2k3 zu gelten.

    Das erste mal ist mir das aufgefallen als ich via "ChangeGraphic" im MoveEvent während des Sprunges eine Animation erstellen wollte, diese aber nie ausgeführt wurde.

  13. #153
    Mir ist da noch was aufgefallen!
    Es gibt anscheinend immer noch Einige die dass nicht wissen:
    (obwohl das zum Grundwissen gehört)

    Du hast einen Fork erstellt willst ihn aber wieder löschen,
    den Inhalt des Forks allerdings kopieren...
    Halte Shift gedrückt und geh einfach mit den Pfeiltasten
    nach unten, so markiert man sie. Dann kann man diese kopieren^^

  14. #154
    Zitat Zitat von Cloud der Ex-Solda Beitrag anzeigen
    Du hast einen Fork erstellt willst ihn aber wieder löschen,
    den Inhalt des Forks allerdings kopieren...
    Halte Shift gedrückt und geh einfach mit den Pfeiltasten
    nach unten, so markiert man sie. Dann kann man diese kopieren^^
    Du kannst auch einfach einen Befehl makieren, deine Befehlsliste weiter runter gehen (Den Befehl aber markiert lassen) und mit gedrückter SHIFT Taste auf einen anderen Befehl klicken. Alles was zwischen den beiden Befehlen liegt und die Befehle werden dann markiert.

    Ist im Grunde das selbe, ich wollte nur nochmal drauf aufmerksam machen, dass es mit der Maus auch möglich ist, das spart Zeit.

  15. #155
    Das klappt so ziemlich überall unter Windows.

  16. #156
    Ja natürlich geht das überall^^
    Ich sagte ja auch, dass es eine Grundfunktion ist.

    @BW-Gamer: Ja gut, hast schon recht. Mit Maus gehts natürlich auch^^

  17. #157

    Users Awaiting Email Confirmation

    Ich weiß nicht obs schon irgendwo hier steht ( habs nicht gefunden) aber weiß jemand wie lange die Befehle "Face UP", "Face Down" .... dauern?

  18. #158
    Wenn du die Zeit für einen Wait brauchst: Gib einfach 0.5 Sekunden ein, das müsste genügen.

  19. #159
    Die Verwendung der Show Picture Picture Befehle des RPG Maker 2000 und 2003 kostet sehr viel Systemleistung. Dies hängt zwar auch von der Größe des Bildes ab, aber auch wenn es sich nur um kleine Bilder von 16x16 Pixeln handelt, fängt das Spiel (besonders auf etwas älteren Rechnern) an zu stocken, sobald man mehrere dieser Befehle kurz hintereinander ausführt. Bei größeren Bildern kann es wie gesagt auch schon bei nur einem Show Picture Befehl auf älteren PCs zu einem kurzen, rapiden Einbruch der Framerate kommen.

    Dies war übrigens das größte Problem bei einem meiner Kampfsysteme, bei denen ich Gegner und Held durch Bilder anzeigen ließ.

    Die Lösung hierzu mag zuerst banal erscheinen. Einfach keine Show Picture Befehle verwenden!
    Solange man ein Bild nur bewegen muss, kann man dies ja bequem und ohne Ruckeln, per Move Picture Befehl. Aber was soll man machen, wenn man eine andere Animationsphase anzeigen möchte? Wie kommt man nun um den Show Picture Befehl herum?
    Man könnte einfach alle benötigten Animationsphasen einmal zu Beginn des Spiels per Show Picture anzeigen lassen, dadurch würde es einmal am Anfang (vielleicht beim Betreten der Map) zu einem Einbruch der Framerate kommen.
    Dann könnte man einfach die benötigte Animationsphase per Move Picture Begfehl anzeigen lassen und nicht benötigte per Move Picture Befehl mit 0.0 Wait auf transparent schalten (oder besser noch außerhalb des Bildschirmausschnittes bewegen), so kann man, allein durch Move Picture Befehle, immer zwischen einzelnen Bildern (Animationsphasen) wechseln, ohne Show Picture Befehle verwenden zu müssen. Diese Idee hab ich btw von ZidanneFFIX ^^'.
    Der Schwachpunkt dieser Methode ist aber offensichtlich. Man kann nur maximal 20 (rm2k ohne Patch) bzw. 50 (rm2k3) verschiedene Animationsphasen per Show Picture gleichzeitig zu Beginn anzeigen lassen.
    Dies ist natürlich recht wenig, so dass man meist doch gezwungen ist, hier und da mit Show Picture Befehlen zu arbeiten.

    Aber auch dafür gibt es eine Lösung! Man könnte einfach ALLE Animationsphasen einer Spielfigur, in bestimmten Abständen, in einer Reihe untereinander auf ein einziges Bild packen. Diese Abstände müssen so groß sein, wie der Bildschirm hoch ist, sodass niemals zwei Animationsphasen gleichzeitig auf dem Bildschirm zu sehen sein können. Diese Zwischenräume müssen dann natürlich auch, dank transparenter Farbe, durchsichtig sein.
    Hier ist zB. ein Beispielbild, auf das 4 Animationen (rot gekennzeichnet) mit 16x16Pixel Größe passen würden (Weiß muss hier die transparente Farbe sein):


    Will man nun eine andere Animation anzeigen, muss man das Bild einfach nur, per Move Picture Befehl, in Y-Richtung verschieben. Diese Verschiebung soll natürlich abrupt sein, also sollte man hier den schnellstmöglichen Move Picture Befehl mit 0.0 Wait wählen. Zu beachten ist aber, dass man dann nicht unmittelbar danach im Code einen weiteren Move Picture Befehl verwenden kann, da sich Move Picture Befehle ja überschneiden (was ja sicher den meisten bekannt ist). Man müsste also nach diesem Move Picture 0.0 Wait Befehl auch den Code um 0.0 Wait unterbrechen (zb. durch einen entsprechenden Wait Befehl), bevor man weitere Move Picture Befehle, die sich auf dieses Bild beziehen, ausführt.

    Neben dem "Performanceboost" ist es auch unglaublich praktisch, alle Animationsphasen auf einem einzigen Bild zu haben. So kann man Animationen per Variable über ein und denselben Move Picture Befehl ansprechen, wo dies vorher nur durch unterschiedliche Show Picture Befehle möglich war und wenn man mal was an seinen Animationen ändert, muss man nur ein Bild neu drüberkopieren, und nicht zig Bilder neu importieren.
    Die Idee hab ich übrigens von Zeph (hier afaik unter DR_Zeph registriert, Dank an ihn!).
    Hier noch ein paar Anmerkungen dazu, die ich schon im Quartier gepostet habe:
    Zitat Zitat von Ryo Saeba
    Anzumerken ist aber, dass man die Animationen wirklich nur übereinander auf das Bild packen sollte. Ich habe es mit übereinender und nebeneinander gleichzeitig probiert und hatte dann ein Bild von 1024x768 Pixeln. Dabei kam es dann aber zu heftigen Einbrüchen der Framerate bei mehreren gleichzeitigen Move Picture Befehlen.
    Keinerlei Probleme scheint es aber bei besonders hohen aber schmalen Bildern zu geben (wie das, das Zeph gepostet hat).
    Ich verwende zur Zeit ein 48x8976 Pixel großes Bild (32 Animationen von 48x48 Pixel Größe), habe es aber schon mit bis zu 65000 Pixel hohen Bildern getestet, es lief ruckelfrei bei 20 gleichzeitigen Move Picture 0.0Wait Befehlen (in einem PP Event mit abschließendem gesetzten 0.0 Wait) auf meinem 750MHz Test PC.
    Auf so ein Bild würden dann um die 224 verschiedene 48x48 Pixel große Animationen passen.

    Importieren muss man die mit der guten alten Methode, die in einer der Makersmind Ausgaben erläutert wurde. Erst kleines "Dummie Bild" importieren (selbe Farbpalette!, sonst ist die Transparenz beim großen Bild falsch) und dann einfach das große Bild über das "Dummie Bild" im Picture Ordner drüberkopieren.
    Da man vorher ein kleines Bild importiert hat, dürfte es eigentlich auch keinen Map Tree Data Break Fehler geben.. hoffe ich zumindest xD

    Die Grenze scheint hier also nicht der RPG Maker zu sein.. sondern meine Bildbearbeitungsprogramme ^^'
    IDraw macht bei einer Größe von 10000 Pixeln schlapp, das gute alte Paint bei 65535 Pixeln. An "professionelleren Programmen" hab ich nur Gimp getestet, das kommt zwar auch mit größeren Bilder klar, wenn ich da das Bild allerdings als PDF speichere, ist die entstehende Datei WESENTLICH größer als die mit IDraw oder Paint gespeicherten Bilder.
    Mein 48x8976 Bild ist nicht mal 4KB groß^^ mit Gimp werden die Bilder aber zigmal größer oO
    Gimp scheint also noch irgendwelche anderen Dinge mitzuspeichern.. vielleicht gibt es da noch irgendeine Option im Speicherdialog, die ich übersehen hab kA.
    Aber naja, 65000 Pixel reichen sicher aus, ist nur leider etwas unkomfortabel mit dem alten Paint auf so großen Bildern rumzuscrollen und diese zu bearbeiten ^^'

    Nebenbei habe ich übrigens auch noch herausgefunden, dass angezeigte Bilder an der Systemleistung zehren, auch wenn sie auf transparent geschaltet sind, oder sich nur ein transparenter Teil des Bildes auf dem Bildschirmausschnitt befindet.
    Man sollte also nicht verwendete Bilder nicht auf transparent schalten, sondern per Move Picture Befehl, zu einem Punkt außerhalb des Beildschirmausschnittes bewegen, da kosten sie keine Systemleistung.

    Geändert von Ryo Saeba 1000 (01.03.2007 um 14:50 Uhr)

  20. #160
    Zitat Zitat von Ryo Saeba 1000
    Importieren muss man die mit der guten alten Methode, die in einer der Makersmind Ausgaben erläutert wurde. Erst kleines "Dummie Bild" importieren (selbe Farbpalette!, sonst ist die Transparenz beim großen Bild falsch) und dann einfach das große Bild über das "Dummie Bild" im Picture Ordner drüberkopieren.
    Da man vorher ein kleines Bild importiert hat, dürfte es eigentlich auch keinen Map Tree Data Break Fehler geben.. hoffe ich zumindest xD
    Sehr nützlicher Hinweis.
    Vorallem wenn es sicher keinen Map tree Data Error gibt ^^
    Das ganze wäre in KS und Menüs sicher extrem hilfreich, spart nochdazu
    Systemressis (und Speicherplatz??, werd das mal mit einem Grafikprog ausprobieren)

    Wenn man auf Nummer sicher gehen will muss man halt ein 640x480 Pic
    importieren. Darauf würde man aber nur 4 Animationsstufe bringen.

    Obwohl es auch schon bei 4 Stufen hilfreich wäre, weiß ich jetzt nicht
    ob sich das von der Größe(wahrscheinlich minimaler Unterschied) rentieren würde.
    Aber der Übersichtlichkeit würde wegen wäre es sicher überlegenswert.

    Zitat Zitat von Ryo Saeba 1000
    Nebenbei habe ich übrigens auch noch herausgefunden, dass angezeigte Bilder an der Systemleistung zehren, auch wenn sie auf transparent geschaltet sind, oder sich nur ein transparenter Teil des Bildes auf dem Bildschirmausschnitt befindet.
    Man sollte also nicht verwendete Bilder nicht auf transparent schalten, sondern per Move Picture Befehl, zu einem Punkt außerhalb des Beildschirmausschnittes bewegen, da kosten sie keine Systemleistung.
    Heißt dass, so lange auch nur ein einziger Pixel eines Bildes im Bildschirmausschnitt ist, wird die Systemleistung beansprucht, aber sobald
    es außerhalb des Bildschirmausschnitts ist braucht es keine Systemleistung mehr
    (braucht es keine oder weniger Systemleistung)

    Eine Frage hätte ich da noch:
    Ich gehe da mal von meinem Pic aus.
    Sagen wir der rote Punkt wäre ein Menüpunkt und ich will ihn mit 4 animationsstufen einblenden lassen. Wenn ich das jetzt per Move Pic Befehl mache würde es sicher weniger Systemressis brauchen, da das Pic aber größer ist wieder mehr und somit wäre es egal ob man ein 4x320 oder 1x640 verwendet.

    Deine Methode gefällt mir btw super, aber es ist einfach ein bisschen unsicher
    wegen dem importieren.

    ~Waradience~

Berechtigungen

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