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

[Helli]

Original geschrieben von Dhan
Öhm... eine Zeitzählung würd ich jetzt einfach mit Wait 10 machen, wozu genauer als Sekunden?

...

ähm... da bin ich auch erst jetzt draufgekommen...
Aber die PPs werden auf jedem Prozessor gleich oft pro Sekunde (nämlich genau 60 Mal) wiederholt.

Wieder mal typisch, ich mach's aber auch IMMER kompliziert, wo's auch einfacher geht.

Aber trotzdem, manchmal kann eine genaue Zeitzählung von Vorteil sein, z.B. für Minigames, in denen es um Geschwindigkeit oder Geschicklichkeit geht...

Mit dieser Funktion lässt sich auch eine eigene 'Wait'-Funktion bauen, durch die auch variable Wait-Zeiten mögich sind (auch im 0.0-Wait-Bereich).
Über deren Nutzen muss man aber erst nachdenken...

[Dhan]

Soa, hab was durch Zufall rausgefunden:

ich war gerade dabei, jemandem zu helfen, der ein Sichtlinien Script braucht (Sichtlinie: wenn man in vertikaler oder horizontaler Linie zu einem Event steht, passiert was) und hab, weil dat bei ihm net geklappt hatte, det mal selbst mit meinem Script versucht (da hats natürlich geklappt ^^) und als passierende Sache hab ich gemacht, dass das Event 0.1s lang einen Flash abbekommt (in einem PP sich wiederholend, mit 0,0s wait Verzögerung)

steht man jetzt neben dem PP, so flasht er regelmäßig, ganz klar
wenn man nun aber gegen das Event läuft und die Lauftaste gedrückt hält... verdoppelt er die Flashrate! Die anderen Events laufen in der Zeit genauso schnell wie zuvor, nur dieser eine Event scheint beeinflusst
morgen probier ich dasselbe mal mit einem Timer aus...
weiß net, obs nützlich ist, aber kurios isses auf alle Fälle ^^

[Kyuu]

Original geschrieben von Manuel
Dem muss ich zumindest teilweise widersprechen, aus eigener Erfahrung. Ich verdeutliche mal das in einem Beispiel:
Der eine oder andere kennt mein 4Gewinnt-Spiel. Als Feature habe ich eine Kontrolle eingebaut, die überprüft, ob ein Spieler gewonnen hat. Die Event-Seite sah ursprünglich so aus:

Code:

<> If Switch(0001:Rot 1x1) is ON
 <> If Switch(0002:Rot 2x1) is ON
  <> If Switch(0003:Rot 3x1) is ON
   <> If Switch(0004:Rot 3x1) is ON
    <> Switch (gewonnen) = ON
    <>
   :End Case
   <>
  :End Case
  <>
 :End Case
 <>
:Else Case
<> If Switch(0005:Rot 1x2) is ON
[...]

Ich habe jede einzelne Switch überprüft, falls die erste IF-Klausel nicht zutrifft, wird automatisch das Nächste untersucht (Der Eventcode ist in Wirklichkeit mehrere hundert Zeilen lang, ich habe es nur ein wenig übersichtlicher gestaltet). Obwohl theoretisch alle Forks übersrpungen werden, wenn auch nur ein einziges Mal vier genannte Switches auf ON sind, brauchte der Maker doch zwischen 5 und 6 Sekunden, um die Eventseite zeigen zu können. Selbst beim Editieren brauchte der Maker abermals ein paar Sekunden, um die komplette Seite neu laden zu können.

Da mich das ziemlich genervt hat, habe ich dann die andere Möglichkeit benutzt, in dem nicht alles in einer Fork mit ELSE zusammenhängt:

Code:

<> If Switch(0001:Rot 1x1) is ON
 <> If Switch(0002:Rot 2x1) is ON
  <> If Switch(0003:Rot 3x1) is ON
   <> If Switch(0004:Rot 3x1) is ON
    <> Switch (gewonnen) = ON
    <>
   :End Case
   <>
  :End Case
  <>
 :End Case
 <>
:End Case
<> If Switch(0005:Rot 1x2) is ON
[...]

Und so weiter. Ich habe also nicht alle Überprüfungen knallhart in einer einzigen Fork gebracht und diese dann mit ELSE fortgesetzt, sondern erst nach und nach. Wären jetzt vier genannte Switches alle auf ON gesetzt, werden immer noch die restlichen Switches geprüft, obwohl das gar nicht mehr nötig wäre. Aber - und das ist ja das Seltsame dabei - kurioserweise braucht der Maker nun nimmer 5 bis 6 Sekunden, um die Eventseite anzeigen zu können.

Deshalb sage ich als Fazit: Die erstere Methode KANN(!) im Spiel schneller verarbeitet werden als die zweite, allerdings ist die zweite Methode IM MAKER(!) schneller als die erste.

Wer mir nicht glaubt und einen etwas älteren Rechner hat, kann das gerne nachprüfen, wenn er will: Download in meiner Signatur, nach jeder ersten Fork ein "ELSE" reintun und alles ins "ELSE"-Teil stopfen usw. Dann wird der Maker wieder langsamer.

...

Öh? O_o

Imo hat die Dauer für das Anzeigen der Eventseite nichts mit der eigentlichen Verarbeitung des Eventcodes im Spiel zu tun...

Man kann die unerwünscht lange Ladezeit aber durchaus umgehen, indem man ganz am Anfang der Eventseite z.B. einen kurzen Comment eingibt.

[Manuel]

Original geschrieben von Chingachgook
Öh? O_o

Imo hat die Dauer für das Anzeigen der Eventseite nichts mit der eigentlichen Verarbeitung des Eventcodes im Spiel zu tun...

Man kann die unerwünscht lange Ladezeit aber durchaus umgehen, indem man ganz am Anfang der Eventseite z.B. einen kurzen Comment eingibt.

...

Ich sagte ja, dass die Methode im Maker langsamer ist, ob sie das im Spiel ist, weiß ich selber nicht, das müsste ich mal ausprobieren...

Wegen Comments: Huh O_O! Muss ich mal ausprobieren, das wär' mir neu...

[Janos_Audr0n]

kann mir einer vobn euch sagen wie das KS des Makers 2000 berechnet wird? ich werd aus den Infos der Hilfe-Datei nich schlau...

[Don_Alexandro]

Sorry, falls es die Frage schon gab, aber es ist wichtig und passt hier hin:

Wie lange dauern Battle anminatins? Die längste dauert 9.9, aber was ist das in sec ???

Bitte um Antwort!
Don

[Geiu]

Wie lange dauern Battle anminatins? Die längste dauert 9.9, aber was ist das in sec ???

...

Steht doch gleich auf der ersten Seite:

Was ich eigentlich schon seit längerer Zeit weiß, was ich aber hier noch mal passend erwähnen will ist das Verhältnis von Battle-Animation-Frames zur Wait-Zeit

Es ist (so ziemlich GENAU):
3 Frames pro 0,1 Sekunde "Wait"-Zeit
(eine Battle-Animation kann so maximal 3,3 Sekunden lang sein...)

...

[Cherry]

Cheating-Schutz und mehr
Wie jeder weiß, kann man im RPG Maker eine Anzahl an Variablen einstellen, die man nutzen möchte. Im Maker kann man dann nur diese Variablen auswählen, im F9-Menü sind auch nur diese Variablen sichtbar (z.B. 0001-5000).

Diese Begrenzung ist aber nur kosmetisch. Sie existiert hauptsächlich deshalb, weil das Array, was die Variablen-Namen fasst, eine fixe Länge haben muss. Tatsächlich können aber jegliche Variablen-IDs im Spiel verwendet werden.

Der RPG Maker reserviert immer nur Speicher für die Variablen bis zu jener, die die höchste in diesem Spiel verwendete ist. Soll heißen: Wenn noch keine Variablen verwendet wurden, ist auch kein Speicher reserviert. Wird der Variable 10 nun ein Wert zugewiesen, wird Speicher für 1-10 reserviert, etc.

Es gibt dabei aber keine Überprüfung auf einen Maximalwert! Man kann also beliebig hohe Variablen verwenden, auch jene weit über dem Maximum, das in der Database eingestellt ist. Diese kann man natürlich nicht im Maker auswählen.

Nun aber der Trick: Der Option "Variable No."/"Variable Refernce" (je nach Übersetzung) bei "Change Variable". Damit kann man ja Variablen anpointern, also sagen "Greif auf jene Variable zu, dessen Nummer in der Variable soundso steckt".

Um nun auf die Variable 123456 zuzugreifen (egal, welches Limit im Maker eingestellt ist), verwendet man folgendes:

Code:

<> Change Variable: [0001] = 123456
<> Change Variable: [V[0001]] = 999
<> Message: Wert von Variable 123456: \v[123456] (hier sollte 999 stehen)

Man braucht also immer eine Hilfsvariable, in die man die ID der gewünschten "unsichtbaren" Variable schreibt.

Da die Option "Variable No."/"Variable Reference" bei Forks nicht verfügbar ist, braucht man hier 2 Hilfsvariablen: in die zweite lässt man den Wert der angepointerten "unsichtbaren" Variablen schreiben und fragt sie dann in der Fork ab.

Das schöne daran: Nachdem sich die Anzeige im F9-Menü ja nach dem im Maker eingestellten Limit richtet, sind höhere Variablen dort nicht sichtbar! Cheater sind von diesen Variablen also ausgesperrt (außer sie durchschauen das System und ändern was in den Events).

Die Namen der "unsichtbaren" Variablen kann man dann natürlich nicht mehr im Maker einstellen, sondern muss sie sich wo anders aufschreiben.

Viel Spaß damit

mfG Cherry

[Pincky]

... dass, wenn ein Paralleles Common-Event unterbrochen wird, es beim wieder aktivieren genau DORT anfängt, wo es unterbrochen wurde?

...

Das hab ich heute am eigenen Leib zu spüren bekommen, hätte einer von euch ne Idee wie man das umgehen kann? Hab n common event auf parallel process und mit einem switch als Bedingung.
Wenn der Switch deaktiviert wird, stoppt das Event, doch sobald ich ihn wieder aktiviere, soll das Event wieder von vorne starten, was es jedoch leider nicht tut, es läuft genau da weiter wo es angefangen hat.
Ideen?
Mit Cycle und Break cycle lässt es sich leider nicht lösen, da es möglich sein muss das Event in jedem Moment zu stoppen und wieder neuzustarten.
Auch Forks die alle 0,1 Sekunden den Switch abfragen gehen nicht da das Event extrem lang ist (24 minuten)

Bin hier grade regelrecht am verzweifeln.

edit: Bin das ganze völlig falsch angegangen, hat sich erledigt

[Cherry]

eine Möglichkeit ist, den Switch nicht als Startbedingung zu setzen, sondern das Event mit einer Fork einzurahmen. Dann wird es immer zuende ausgeführt.

[Cherry]

Setzt man hinter Befehle, die irgendwas Grafisches ändern, einen Show Screen-Befehl, wird die Änderung überblendet!

z.B.:

<> Change Chipset
<> Show Screen

...

<> Change Panorama
<> Show Screen

...

<> Set Event Place
<> Show Screen

...

<> Move Event: Change Graphic
<> Show Screen

...

<> Change Switch (bei Events, wo sich dann die Grafik ändert)
<> Show Screen

...

<> Change Hero Charset
<> Show Screen

...

<> Show Picture
<> Show Screen

...

Der Fantasie sind keine Grenzen gesetzt!

Damit lassen sich sicher tolle Effekte machen.

mfG Cherry

[Rosa Canina]

Ich glaub ich hab da was für euch - eine Kleinigkeit, die mir letztens großes Kopfzerbrechen bereitete.


Wusstet ihr, dass mit "Clear Timer" gelöschte Events nicht richtig gelöscht werden und immer noch Werte ausgeben können?
Sie werden lediglich quasi auf "Nicht sichtbar" gestellt.

Der Beweis:
Ich hatte eine paralelle Abfrage nach einer Event ID - wenn dieses Event nun
gelöscht wird, dann wird euch die Abfrage auch weiterhin die Event ID des
eigentlich gelöschten Events ausgeben!
Kann sehr lästig werden, z.B. bei JnRs, in dem man auf Dingen laufen kann,
die auch weg sein können. In dem Fall sollte man die Events woanders
hin teleportieren.

Callen kann man die Events natürlich nicht mehr - sie geben lediglich ihre
Terrain ID für ihre alte Position aus.


Getestet auf 2k3

[Engel der Furcht]

Ich wusste nicht wohin damit und nen neuen Thread aufmachen wollte ich auch nicht.

Wenn man beim 2k3 bei den Transitions das Fade Out auf "No Transition" und den Fade in auf "Fade In" macht,ist der Übergang bei Maps mit einem einzelnen Teleport (ohne "Erase Screen" und "Show Screen") der Übergang transparent. D.h. dass der Übergang direkt stattfindet,und kein schwarzer Bildschirm kommt.
Setzt man nun den Fade-Out auf was anderes,so ist der Übergang wieder mit Schwarz,genauso wenn man Erase+Show Screen wieder reinmacht.
Ich würde gerne wissen,wie das zu stande kommt.

[R.D.]

Naja, das Fade Out findet einfach nicht statt und dann wird halt die alte Map ausgefadet oder die Neue ein.

Kannste auch manuell machen mit dem Screenshot tool

[Engel der Furcht]

ja,aber es funktioniert nur,wenn du nur den Teleport,aber kein erase+Show Screen hast und wenn die Fade-Out und Fade-In Einstellungen die obigen sind.
Sonst nicht.
Was mMn ein bisschen merkwürdig ist,weil Show-Screen und Erase-Screen diese EInstellungen machen.

[Cherry]

Klar. Fade In wendet einen Effekt vom aktuellen Bild zu einem neuen an. Fade Out wendet einen Effekt vom aktuellen Bild zu schwarz an. Wenn man also Fade Out weglässt, wird ein Bild direkt ins andere überblendet.

Warum das mit Show und Erase Screen so ist, liegt darin begründet, dass es intern noch eine "globale Helligkeit" gibt, wenn die auf 0 ist, siehst du nichts von der Überblendung (und Sie wird auch nicht wirklich ausgeführt, WENN es bereits 0 ist). Wenn du also das die Fadeout-Transistion auf No Transition setzt, wird der Wert nie 0. Wenn aber da z.B. "Fade Out" steht, wird sie bei "<> Teleport" auf jeden Fall 0. (Das ganze ist noch etwas komplizierter, aber so ungefähr ist es^^)

[DMII]

Ich weiß nicht ob das schon bekannt ist, aber über das hier bin ich gerade selber gestolpert:

Wenn ein Event einen Move Befehl erhält und ihn nicht ausführen kann (weil z.B. etwas im Weg ist) führt es ihn aus, sobald es die nächste Gelegenheit dazu erhält. (Dies wurde nur für Move-Befehle mit einem Befehl getestet.)

Eine solche Gelegenheit kann es zum Beispiel durch Setup Event's Place erhalten.

Das kann unter Umständen blöd sein, wenn man wie ich mit dem Helden etwas schießen will und das fliegt zuerst einmal nach oben und dann erst nach rechts xD

[Cherry]

Ich weiß nicht ob das schon bekannt ist, aber über das hier bin ich gerade selber gestolpert:

Wenn ein Event einen Move Befehl erhält und ihn nicht ausführen kann (weil z.B. etwas im Weg ist) führt es ihn aus, sobald es die nächste Gelegenheit dazu erhält. (Dies wurde nur für Move-Befehle mit einem Befehl getestet.)

...

Der Sinn von "Ignore Impossible Movements" ist ja auch, dass es dann solche Befehle einfach ignoriert und zum nächsten übergeht. Kommt auf die Situation an ob das gut ist.

[Corti]

Edit: alles Käse:

Wenn die Tot-Condition auf "Persist after Battle" gestellt ist springt der Defeat-Handler eines "Enemy Encounter"-Befehls ganz normal an, nach dem nächsten Aktualisierungstick ist man aber tot -> GameOver Screen

Storykämpfe sollten in Autostart-Events aktiviert werden, "Enemy Encounter" mit Defeat-Handler in nem ParallelProcess führte bei mir zum Einfrieren des Makers, nach einem Teleport im selben PP zu einem Speicherzugriffsfehler 0x0000vieleNullen000.

[Irresolute Warrior]

Puh, staubig hier... bin gerade auch über was gestolpert:
Common Events (also Events mit Animation Type "Common") gucken bei Auslösung bekanntlich den Helden an und drehen ihren Kopf in die Richtung zurück, in die sie zuletzt geschaut haben, nachdem ihr Event-Code ausgeführt wurde.
Wurde das Event vorher aber mit einem fix-face bewegt (sprich erst FixFace, dann Bewegung, dann CancelFixFace), und wird dann ausgelöst, schaut es nach Ausführung in die letzte Bewegungsrichtung... oder genauer: in die Guckrichtung, die es eigentlich haben sollte, wenn das Face in der letzten Bewegung nicht gefixt gewesen wär.

Wie sehr das nun interessant ist, bleibt jedem selbst überlassen, mir hat´s ziemlich Ärger gemacht, beim AKS, wo sowohl Gegner wegschleudern (Bewegung mit Fix Face) als auch die richtige Common-Animation-Guckrichtung (für Angriffe von hinten) wichtig ist. Gelöst hab ichs btw, dass die Fix-Face Bewegung nicht nur mit CancelFixFace, sondern auch einem weiteren FaceHero abgeschlossen wird, dann ist die Guckrichtung für die Common-Animation wieder klar. (Alternativ: 2x Turn Face 180°, wenn er nach der Bewegung nicht den Helden angucken soll, wie das bei mir der Fall ist.