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

Zitat:

---

Zitat von JamahlOmega
Wusste das zwar schon, hab aber genau dieses wissen bei bestimmten chipsets vermisst.
Gut, dass dus gepostet hast.

Was ich eigentlich fragen wollte:
Gibts vielleicht auch einen patch, damit man auch andere teile eines chipsets so zeichnen kann?
Danke

---

Also ich kapier deinen ersten Satz einfach nicht .. endweder du hast es schon gewusst, oder du hast es nicht gewusst ...

Was deine Frage angeht .. nein dafuer gabs nie einen Patch, gibt es keinen Patch und wird es auch nie einen Patch geben. Das ist einfach nicht realisierbar .. an der Verarbeitung der Graphik und somit auch der Chipsets kann man nichts veraendern .. wie oft soll ich mir denn noch den Mund fusslig reden -___-

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

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)

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

Weil mir dermaßen langweilig ist:

Damit man auch versteht, warum...

Nacheinander folgende Forks:

Zitat:

---

<> 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:

Zitat:

---

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

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)

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

Zitat:

---

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.

Zitat:

---

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.

Zitat:

---

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.

Ö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 ^^)

Zitat:

---

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... :D
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...

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 ^^

Zitat:

---

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.

Zitat:

---

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

setzt man die position eines "vehicle" fest, beginnt das spiel und speichert es ab, sollte man eines bedenken:
wenn man im maker die position des vehicles nun verändert, aber das spiel nicht von neuem beginnt, sondern das alte lädt, dann ich das vehicle verschwunden. weder auf der alten noch auf der neuen position zu orten.

Division by the zero / Division durch 0

Lange war es für mich ein Mysterium, doch nun ist mir endlich ein einfach gestricktes Projekt in die Finger gekommen, welches diesen Fehler verursachte. In einem eigens erstellten Projekt konnte ich diesen Fehler erstmals absichtlich und unendlich oft reproduzieren.
Die Ursache des Problems liegt, wie ich schon einige Zeit vermutet habe, an einem internen Fehler des Makers bei der Pictureverarbeitung.

Folgende Bedingungen rufen diesen hervor:

• Die erste generelle Screenbewegung (sprich normales Movement oder Pan Screen) nach links oder nach oben, wenn zuvor ein Show Picture oder Move Picture stattgefunden hat, bei dem die Magnification (Bildgröße) auf 0% gestellt wurde.
  .
• Die erste generelle Screenbewegung nach links, wenn zuvor ein Show Picture oder Move Picture stattgefunden hat, bei dem die Magnification auf 1% gestellt wurde.

Screenbewegungen in eine andere, den beiden genannten Punkten entgegengesetzte Richtung, heben dieses Phänomen auf, und zwar solange, bis man die selbe Anzahl an Feldern, die man in die entgegengesetzte Richtung gelaufen ist, wieder zurück läuft und ein zusätzliches Feld weiter geht, dann kommt es erneut zu dem Fehler.
Teleports auf eine andere Map heben es ebenfalls auf.
Vorsicht, das Phänomen wird auch beim speichern übernommen!


Es könnte natürlich noch andere Situationen geben, die diesen Fehler hervorrufen, doch zumindest ein erster Anhaltspunkt wurde gesetzt.

:confused: :confused: :confused: :confused: :confused:

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

:confused: :confused: :confused: :confused: :confused:

Vielleicht wurde es schon gepostet,aber jene Paralell Process,die als erstes erstellt werden,laufen auch von allen als erstes ab.
Zum ausprobieren: 10Events erstellen,alle Paralell Process definieren und jeweils die Zahlen 1-10 in einer Message durchnummerieren.Es wird zuerst
Message: 1,dann 2,dann 3,... erscheinen.Die Namen der Events spielen an dieser stelle keine Rolle.

Ich glaube nicht dass dies in einem Q&A Thread enden sollte..

@ Janos_Audr0n
Falls du die Formeln meinst, die stehn doch auf der ersten Seite hier, ausserdem kannste hier noch ein paar finden.

@ Sirius
Jop, auch auf der ersten Seite.
Eigentlich ja logisch, wär ja auch strange wenn der Maker sie per Zufallsgenerator in den RAM laden würde. :D