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