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

[Dingsi]

Das ganze geht auch einfacher indem man beim Malen einfach Shift drückt.

[Zer0]

@Fu:
. . .



...und sowas sagt man mir erst jetzt? X_x"
Naja, mit Shift kann man allerdings nicht jede Ecke des Autotiles bekommen..also manchmal doch recht praktisch..^^"

|Edit|..okay, okay...danke für den Tipp..da erspare ich mir einiges an Zeit mit..

[Dingsi]

...und sowas sagt man mir erst jetzt? X_x"
Naja, mit Shift kann man allerdings nicht jede Ecke des Autotiles bekommen..also manchmal doch recht praktisch..^^"

...

Drück mal Shift während du mit Rechtsklick ein beliebiges Autotile auf der Map (Nicht in der TileSet-Auswahl links!) auswählst und male dann mit Shift damit.

[Unit Nero]

Hey nicht schlecht. Daraus kann auch ich noch ein paar Vorteile ziehen. Auch die Sache mit den Waits. Hmhmhm ....

[Noshire]

Sodele.... hab auch was entdeckt...

Viele dachten es sich vllt. schon, aber ich habs ausgetestet!!!

COMMENTS BREMSEN DEN MAKER AUS!!!

Wie habe ich das herausgefunden?

Mit Zephs Methode...
Ich habe einfach einmal eine sekunde lang immer eine variable + eins laufen
lassen.
Diese Variable hatte am Ende den Wert 305000!
Nun habe ich in das Label noch ein Comment eingebaut und siehe da...
Die Variable gibt mit nur noch einen Wert von 203333 aus!!!

Hoffe, ihr könnt damit was anfangen...
Ich auf jedenfall^^


Gruß, Kintaro

...

Die Sache hier wurde einmal kurz angezweifelt und dann irgendwie zur Seite geschoben. Wäre aber imho noch interessant zu erfahren, ob das nun wirklich stimmt.
Also ich hab das getestet. System: 2000er.
Ich habe zwei PPs erstellt, einen mit "Change Var [001]+1" und eines mit "Change Var [002]+1 , 15 x Comment [-------------------------------------------------------]".

Das eine Event also nur als Zähler, das andere als Zähler mit 15 vollen Comments. Nach 10 Minuten hatten beide den gleichen Wert. Diese 20%ige Abweichung ist also nicht eingetreten, wäre aber irgendwie auch seltsam gewesen. Bei mir ist jedenfalls gar keine Abweichung eingetreten. Falls das bei jemandem anderem nicht so ist, wäre es natürlich gut, die Werte mit benutzter Engine hier zu posten

[natix]

Auto Start und Parallel Process Events beschleunigen


Neulich saß ich an einem wirkoich verzwickten Bug in meinem rm2k Pong Spiel. Immer als ich dir Rechtstaste im Spiel drückte, bewegte sich der Ball im Spiel schneller und ich wusste nicht warum. Es war egal ob ich die Maussteuerung anmachte (Und damit ist bei mir die Tastatur völlig abgestellt) oder mit der Tastatur spielte. Also wälzte ich ersteinmal 2 Tage meine Skripte durch auf der Suche nach dem Bug, erfolgslos.

Nebenbei sollte ich jetzt erzählen, dass ich für meine Charsets in denen die Skripte sitzen verschiedene Farben benutze (Rot für Auto Start, Grün für Parallel Process etc) damit man eine bessere Übersicht hat, demnach stehen die Events auf "Same Level as Hero"

Einfach so, genervt vom Skripte wälzen, hab ich diese dann nebenbei auf "Below Hero" gestellt. Und ZACK ! Da haute alles wieder hin. Warum ?

Der Hero wurde auf die Position links neben dem Event in dem das Ballmovementskript liegt teleportiert, demnach läuft man mit dem Hero wenn man nach rechts drückt in das Event rein, und ruft es dann also erneut auf. Es läuft dann also zweimal und somit auch schneller, somit wurde der Ball dann auch schneller und das ganze Skript ebenfalls.


Mein nicht lohnenswertes Ergebniss nach zwei Tage harter Arbeit:
Wenn man Skripte beschleunigen möchte (Wozu auch immer xD) einfach andauernd erneut aufrufen.

Vielleicht hilfts ja, wenn einer einen ähnlichen Bug hat. ^^

[DR_Zeph]

nen Cycel sollte auch seinen Dienst tun. Es ist ja nun mehr oder weniger bekannt, das am Ende eines PP events, ein 0,0 Wait sitzt, was das Event verlangsamt...

[natix]

nen Cycel sollte auch seinen Dienst tun. Es ist ja nun mehr oder weniger bekannt, das am Ende eines PP events, ein 0,0 Wait sitzt, was das Event verlangsamt...

...

Richtig, nur hab ich keinen einzigen Wait Command im Skript und auch Cycel Events werden beschleunigt.

[DR_Zeph]

Wird es das, oder laufen einfach mehrere Events parallel, was eine Zählung oder whatever schneller zählen lässt und es nun so aussieht, als ob das besagte Event schneller arbeitet?

[natix]

Die Events werden dann wohl Parallel laufen, wodurch das Skript dann letztenendes schneller läuft. Aber es geht ja einfach darum, dass Parallel Process/Auto-Start Events auch noch so aufgerufen werden können. Ich wusste das nicht, habs vorher auch nie ausprobiert und vielleicht hat ja einer von euch auch so einen dämlichen Bug. ^^

[catcone]

ich habe einen PP, der etwas feststellen soll (z.b. welche waffe der held hat)und dann in abhängegkeit dazu eine variable ändert. wofür braucht der maker mehr resourcen, wenn ich...
-die forks, die die heldenwaffe bestimmen nacheinander abfolgend mache:
<> if hero =>waffe1 is equipped
<> change var [001]- (set) 1
<>end case
<> if hero =>waffe2 is equipped
<> change var [001]- (set) 2
<>end case
<> if hero =>waffe3 is equipped
<> change var [001]- (set) 3
<>end case
-die forks die die heldenwaffe bestimmen per else case verbinde:
<>if hero =>waffe1 is equipped
<> change var [001]- (set) 1
<>else case
<> if hero =>waffe2 is equipped
<> change var [001]- (set) 2
<> else case
<> if hero =>waffe3 is equipped
<> change var [001]- (set) 3
<> end case
<> end case
<>end case

[Dhan]

Das ist Text, da geht der Unterschied gegen Null, ich denk aber, das mit Else belastet weniger (ist aber unübersichtlich, da man den Unterschied net merkt empfehl ich Nacheinander)

[catcone]

hab ich mir fast schon gedacht, wollte aber noch gewissheit haben ^^

[Kyuu]

Weil mir dermaßen langweilig ist:

Damit man auch versteht, warum...

Nacheinander folgende Forks:

<> if hero =>waffe1 is equipped
<> change var [001]- (set) 1
<>end case
<> if hero =>waffe2 is equipped
<> change var [001]- (set) 2
<>end case
<> if hero =>waffe3 is equipped
<> change var [001]- (set) 3
<>end case

...

Hier wird jede einzelne Fork, unabhängig von den anderen durchgenommen.

Verschachtelte Forks:

<>if hero =>waffe1 is equipped
<> change var [001]- (set) 1
<>else case
<> if hero =>waffe2 is equipped
<> change var [001]- (set) 2
<> else case
<> if hero =>waffe3 is equipped
<> change var [001]- (set) 3
<> end case
<> end case
<>end case

...

Sollte die Bedingung aller Forks nicht zutreffen, werden zwar auch hier alle Forks durchgenommen, aber...
Bei Erfüllen der Bedingung einer der ersten Forks, würden alle darauffolgenden (alle "Else"-Fälle dieser Fork-Verschachtelung) übersprungen werden.

Das ist bei diesem Beispiel zwar egal, da der Unterschied nicht bemerkbar wäre, bei langen, komplexen Forksystemen aber, die z.B. (ressourcenfressende) "Show Picture"s drin haben, wäre eine Verschachtelung sehr ratsam.

[melior]

wenns nur ums change variable geht würde ich das eh eher so machen:

Change Variable:[0001] ->Set ->Hero ->held auswählen ->Arms No.

so wird die variable einfach auf die ID der waffe aus der database gesetzt, ganz ohne forks. also würds auch keine belastung geben (und vorallem kann man sich das pp sparen)

[Heaven]

Was natürlich in eigenen Kampfsystemen eher selten funktionieren wird,weil die meisten Leute in diesem Fall ein eigenes Menü dem Standart vorziehen.

[melior]

Original geschrieben von [_Heaven_]
Was natürlich in eigenen Kampfsystemen eher selten funktionieren wird,weil die meisten Leute in diesem Fall ein eigenes Menü dem Standart vorziehen.

...

der beitrag war schon auf mich bezogen, oder?

warum sollte man das nicht in eigenen menüs nutzen können? ich finde das sogar recht praktisch, mit den IDs der database zu arbeiten. das erspart viele forks.
ich weiß zwar nich, was catcone mit der variable macht, aber man kann mit den IDs leicht ein komplettes ausrüstungsmenü ohne große umstände scripten. man macht einfach nen ordner, der die items anzeigt (mit pictures z.B.) und setzt in diesem gleich die variable auf die nummer aus der database. wenn du dann später die rüstung anziehen willst, machst du einfach change equipment und wählst unten die variable aus. so wird dann gleich das item angezogen, komplett ohne zustäzlichen forks.

also imho kann man die IDs der database sehr gut in eigene menüs einbaun, das da oben war nur ein beispiel.

[Manuel]

Weil mir dermaßen langweilig ist:

Damit man auch versteht, warum...

Nacheinander folgende Forks:

Code:

<> if hero =>waffe1 is equipped 
<> change var [001]- (set) 1 
<>end case 
<> if hero =>waffe2 is equipped 
<> change var [001]- (set) 2 
<>end case 
<> if hero =>waffe3 is equipped 
<> change var [001]- (set) 3 
<>end case

Hier wird jede einzelne Fork, unabhängig von den anderen durchgenommen.

Verschachtelte Forks:

Code:

<>if hero =>waffe1 is equipped 
<> change var [001]- (set) 1 
<>else case 
<> if hero =>waffe2 is equipped 
<> change var [001]- (set) 2 
<> else case 
<> if hero =>waffe3 is equipped 
<> change var [001]- (set) 3 
<> end case 
<> end case 
<>end case

Sollte die Bedingung aller Forks nicht zutreffen, werden zwar auch hier alle Forks durchgenommen, aber...
Bei Erfüllen der Bedingung einer der ersten Forks, würden alle darauffolgenden (alle "Else"-Fälle dieser Fork-Verschachtelung) übersprungen werden.

Das ist bei diesem Beispiel zwar egal, da der Unterschied nicht bemerkbar wäre, bei langen, komplexen Forksystemen aber, die z.B. (ressourcenfressende) "Show Picture"s drin haben, wäre eine Verschachtelung sehr ratsam.

...

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.

[Helli]

Original geschrieben von Jinjukei
...wusstet ihr schon, dass sich ein "Parallel Prozess" jede Millisekunde wiederhohlt, also 60 mal in einer Sekunde....

...

Das ist zum Beispiel sehr nützlich, um die Spielzeit zu speichern, ohne einen Timer zu benutzen.

Und zwar so:
(Common Event - Parallel Process)

Code:

<>If Switch(0065:Spielzeit annhalten) is OFF
 <>Change Var: Var[0058:SZTick] (+)- 1
 <>If Var(0058:SZTick) 60
  <>Change Var: Var[0059:SZSekunden] (+)- 1
  <>Change Var: Var[0058:SZTick] (Set)- 0
   <>If Var(0059:SZSekunden) 60
    <>Change Var: Var[0060:SZMinuten] (+)- 1
    <>Change Var: Var[0059:SZSekunden] (Set)- 0
     <>If Var(0060:SZMinuten) 60
      <>Change Var: Var[0061:SZStunden] (+)- 1
      <>Change Var: Var[0060:SZMinuten] (Set)- 0
      <>
     :End Case
     <>
    :End Case
    <>
   :End Case
   <>
  :End Case
  <>

Wenn Schalter 0065 (Spielzeit anhalten) AN ist, wird die Spielzeit nicht gestoppt. Ist er hingegen AUS, wird dieser Parallel Process 60 Mal in der Sekunde wiederholt - Jedesmal wird der Wert der Variable 0058 (SZTick) um 1 erhöht. Ist der Wert 60, wird er auf 0 zurückgesetzt, die Variable 0059(SZSekunden) wird aber um 1 erhöht. Das geschieht so oft, bis der Wert von SZSekunden 60 ist. Dann wird der Wert wieder auf 0 gesetzt und es wird 1 zur Variable 0060(SZMinuten) hinzugefügt. Nach einer Stunde ist dann der Wert von SZMinuten auf 60 gestiegen - Es wird der Variable 0061 (SZStunden) 1 hinzugefügt, SZMinuten wird wieder auf Null gesetzt. Zur Abfrage der Spielzeit eignet sich am besten eine normale Message mit \V[xxxx]. Wenn die Spielzeit im Format hh:mm:ss dargestellt wird, sollte man aber mit Fork Conditions verhindern, dass Zeiten wie '2:0:34' ausgegeben werden (z.B.: Wenn SZMinuten < 10, führende 0 im Text der Message anzeigen).
Es ist unmöglich, so lange zu spielen, wie dieses Skript stoppen kann, also ist es in jeder Situation zuverlässig (immerhin, dieses Skript müsste 114 Jahre, 56 Tage und 15 Stunden laufen, bevor die Variablen überfüllt sind)

PS: Ich hab' keine Probleme mit diesem Skript, aber es könnte sein, dass es auf langsamen PC's nicht läuft (bei so etwas kann man ja keinen Wait einfügen, wenn man genau messen will und das Skript so einfach wie möglich halten möchte.

[Dhan]

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

Außerdem, eine solche Anzeige wäre alles andere als genau, wenn ich mich recht entsinne, müsste die Wiederhohlrate der PPs von der Framerate abhängig sein, d.h., wenn man einen langsamen Prozessor hat, verginge die Spielzeit langsamer (habs aber net getestet ^^)