Prepar3d

Missionen (Scenarios) für P3D

Tagebuch MemoryFlug Erstellung:

Seit dem TicTacToeFlug hatte ich im Sinn, ein weiteres Spiel zu erstellen.

Welches wusste ich lange Zeit nicht, denn Schach, Dame, oder ähnliches ist unmöglich, ein Schiebepuzzle ist auch viel zu aufwändig.
Neulich kam ich auf das Spiel Memory, welches vermutlich sehr aufwändig, aber machbar ist.

Ich habe lange an einigen Problemen herumstudiert:
- Wie das Spielfeld, die Spielsteine aussehen sollen.
- Wie soll ich die Spielsteine zufällig auf dem Spielfeld verteilen?
- Danach muss ich auch noch auswerten, welcher Spielstein wo liegt und ob der Spieler das richtige Paar findet.

Für Spielfeld und Spielsteine hatte ich rasch eine Lösung, aber alles andere konnte ich einfach nicht im Kopf durchdenken, es war zu komplex.
Darum habe ich nach 3 anderen Missionen beschlossen, es einfach zu versuchen, denn wenn man optisch Spielfeld und Spielsteine sieht, wird der Rest hoffentlich schon kommen.

Anmerkung: Einige der unten gezeigten Bilder können durch Anklicken in einer grösseren Ansicht betrachtet werden.
Dieses grössere Bild wird in einem neuen Tab dargestellt. Schliesse einfach diesen Tab, um zu dieser Seite zurückzukehren.

Also los:

Wie soll das Spielfeld aussehen?

Ein Gitterrahmen, welcher eine Grösse von 2x4 | 3x4 | 4x4 aufweist.

Wenn man von der anderen Seite das Spielfeld anfliegt, sind alle Symbole seitenverkehrt.
Wie weiss der Spieler, von welcher Seite er das Spielfeld betrachtet?
Durch Einfügen von einigen Quadraten unterhalb des Spielfeldes, kann man es nun leicht erkennen.

Welche Symbole Benötige ich?

- Weisse Fläche (welche das Feld markiert, welches gerade aktiviert wurde und zu welchem nun das Duplikat gefunden werden soll.)
- 2 Grüne Flächen (welche bei den 2 Symbolen angezeigt wird, wenn das richtige Duplikat gewählt wurde.)
- 2 Rote Flächen (welche bei den 2 Symbolen angezeigt wird, wenn das falsche Duplikat gewählt wurde.)

Im weiteren Spiel-Aufbau habe ich auf eine weisse, grüne und rote Fläche reduziert.
Das Deaktivieren der weissen Fläche und aktivieren von 2 grünen, oder 2 roten Flächen hätte unverhältnismässig viele zusätzliche Elemente benötigt.
Jetzt wird jeweils eine weisse und grüne Fläche bei "Richtig" angezeigt, oder eine weisse und rote bei "Falsch".

- Ein Galgenmännchen, welches bei jedem Fehler, Schritt für Schritt weiter angezeigt/aufgehängt wird.

Alle diese Symbole habe ich also neben dem Spielfeld aufgereiht, damit ich sie beim Erstellen im Blick habe und sehe, was passiert, wenn ich diese verschiebe.
Zum Schluss werde ich diese Teile im Boden verstecken, weil sie im Spielverlauf nicht sichtbar sein sollen.

Das Spielfeld, die Symbole, farbige Flächen und das Galgenmännchen bestehen übrigens schlicht aus RectangleAreas.
RectangleAreas kann man als unsichtbar, umrandet, oder gefüllt verwenden. Bei farbig gefüllten Areas kann man mit einer Action die Farbe auf transparent (= unsichtbar) umschalten.

Leider muss ich die Symbole verschieben, ich kann nicht einfach von sichtbar (Farbe "schwarz") auf unsichtbar (Farbe "transparent") schalten. Transparent bedeutet zwar unsichtbar (ist bei P3dv4 auch wirklich unsichtbar), ab P3dV5 und in P3dV6 ist bei unsichtbaren Areas immer eine hauchdünne Linie sichtbar.
Erkennst du die dünnen weissen Linien in Form eines Plus?

Also muss ich die Symbole verschieben, was grösseren Aufwand und Probleme mit sich bringt.
Verschieben funktioniert so: Ein Symbol ist irgendwo auf der Welt platziert. Damit das Symbol "weiss", wo es hinverschoben werden muss, ist am Ziel eine Area platziert. Eine "ChangeObjectPlacementAction" sagt dem Symbol, wo es hin soll.

Alle Symbole sollen mittig im richtigen Bereich des Spielfeldes platziert werden, darum habe ich die Ziel-Positionen mit unsichtbaren quadratischen Areas im Spielfeld markiert.
Zur Veranschaulichung sind hier die Positionen mit dünnen schwarzen Linien sichtbar.

Ein Quadrat zu platzieren geht problemlos, weil es die gleiche Grösse hat, wie die Ziel-Position. Eine senkrechte Linie ist schmaler und eine waagerechte Linie weniger hoch, als die Ziel-Position. Also würden die Symbole unten- und links-bündig an der Ziel-Position ausgerichtet.
Das Symbol Plus (+) besteht aus 2 Areas, einer waagerechten und einer senkrechten Area.
Zur Veranschaulichung sind hier die 2 Areas unterschiedlich eingefärbt.

Wenn ich die 2 Areas für ein Plus verschiebe, werden sie so platziert:

Immer wenn ein Plus angezeigt werden soll, muss ich 2 Areas verschieben, was 2 ChangeObjectPlacementActions benötigen würde.

Darum habe ich um das Plus-Symbol eine unsichtbare Area (hier mit rotem Rahmen sichtbar) platziert und die beiden Linien (hier grau und schwarz sichtbar) an diesen roten Rahmen angebunden. Jetzt muss ich nur den roten Rahmen ans Ziel verschieben und beide Linien folgen dem roten Rahmen.

Jedes Objekt kann entweder eine feste Position auf der Welt haben (AttachedWorldPosition), oder an ein anderes Objekt angebunden werden (AttachedWorldObjekt). Wenn ein Objekt an ein anderes Objekt angebunden wird, mach ersteres alle Bewegungen des zweiten Objektes mit.

Auf diese Weise benötige ich pro Symbol nur eine ChangeObjectPlacementActions und die Symbole sind immer perfekt mittig platziert.

Als Spielfeld und die Symbole fertig waren, habe ich mit dem nächst "einfachen" weiter gemacht, denn die grossen Probleme kann ich bestimmt später lösen. Psychologen nennen das wohl Problemverdrängung.

Der MemoryFlug soll, genau wie der TicTacToeFlug, mit jedem beliebigen Flugzeug geflogen werden können. Das Spielfeld ist so gross gebaut, dass selbst die AN225 locker durch die einzelnen Felder fliegen kann.

Auch Segelflugzeuge sollen verwendet werden können, darum habe ich die entsprechende Gruppe aus dem TicTacToeFlug importiert und angepasst.

Nachdem die Spielfeldgrösse ausgewählt wurde, kommt die Aufforderung, ein beliebiges Flugzeug zu wählen. Ein Timer von 10 Sekunden wird eingeblendet, innerhalb dieser Zeit muss ein anderes Flugzeug gewählt werden. Die Zeit reicht locker, denn sobald man in die Flugzeugwahl wechselt, stoppen Flug und Timer. Anschliessend fragt ein Trigger ab, wie viele Motoren das Flugzeug hat. Bei null Motoren handelt es sich um ein Segelflugzeug und ein Text wird eingeblendet, welcher sagt, wie man ein Schleppflugzeug rufen kann (Ctrl+Shift+Y). Gleichzeitig werden Thermiken rund um das Spielfeld aktiviert und zur optischen Hilfe ein paar Vögel in den entsprechenden Bereichen.

Damit man nie einen Mangel an Auftrieb hat, ist im Bereich unterhalb des Spielfeldes eine schwache Grundthermik (rot), welche den Segler mit etwa 500ft/min. steigen lässt. Die Thermiken vor und hinter dem Spielfeld (hier blau markiert), haben eine mittelstarke Thermik, welche den Segler mit etwa 1000ft/min. steigen lässt. Links und rechts vom Spielfeld befinden sich starke Thermiken (grün), welche eine Steigrate von etwa 1500ft/min. ermöglichen.

Anschliessend habe ich ein Galgenmännchen gebastelt und dabei kam mir die irre Idee, das Galgenmännchen animiert, um Hilfe rufen zu lassen. Spontan habe ich dieses Sub-Projekt verwirklicht.

So wird das Galgenmännchen bei jedem Fehler weiter aufgebaut:

Galgen.mp4

Sobald der linke Arm eingeblendet wird, ruft das Galgenmännchen alle 20 Sekunden um Hilfe.

Das Einblenden der einzelnen Elemente war schon aufwändig, aber die Armbewegung und der Schriftzug "HELP" übertraf alles.
Alleine das Entfernen des Schriftzuges "HELP" erforderte zusätzliche 22 Objekte, ganz zu schweigen vom schrittweise einblenden.

Hier noch ohne Verknüpfungen mit den einzelnen Schrift-Elementen.

Verknüpft sieht es so aus (43 Objekte sind jetzt miteinander verknüpft):

Total hat das Einblenden des linken Armes, samt Animation und Schriftzug "HELP" 144 Objekte benötigt.

Jetzt wird es knifflig, denn wie soll ich das Spielfeld mit zufällig platzierten Symbolen belegen, bzw. wie speichere ich, an welcher Stelle welches Symbol ist. Ohne Scripting muss ich eine Methode finden, wie ich etwas speichern kann. Ich habe also beim nahegelegenen Flughafen eine ganze Flotte an Flugzeugen platziert, welche unterschiedliches speichern.

- Die 16 Flugzeuge ganz links stehen für die 16 Felder des Spielfeldes.
- Die 8 Flugzeuge in der Mitte "merken" sich, ob das darüber sichtbare Symbol bereits belegt ist, genauer gesagt: frei | 1xbelegt | 2xbelegt.
- Das einzelne Flugzeug rechts merkt sich, wie gross das Spielfeld ist (2x4 | 3x4 | 4x4) und wird mit LMS abgefragt Leicht | mittel | schwer

Wie speichert ein Flugzeug sowas? Ganz einfach:

Für die Spielfeld-Position:

- Ob und wie oft ein Symbol schon auf dem Spielfeld vorhanden ist, könnte ich aus den Spielfeldflugzeugen abfragen, aber das wäre eine irre grosse Abfrage (16x8 Symbole, also 128 abfragen). Darum habe ich das separiert und auf die 8 Flugzeuge (mit darüberliegenden Symbolen) verlegt.
Die Symbole über den Flugzeugen sind übrigens nur als optische Hilfe für mich platziert und haben ansonsten keine Funktion.

Doch nun zum zufälligen Füllen des Spielfeldes mittels Random Action:

Erst wollte ich per Zufall eines der 16 Spielfelder auswählen und der Reihe nach mit den Symbolen "Quadrat", "senkrechte Linie", usw. füllen lassen. Wenn ein Feld schon belegt ist, müsste der Random erneut gestartet werden. Es würde am Ende irre lange dauern, wenn 15 Felder belegt sind, bis endlich per Zufall das letzte freie Feld ausgewählt wird.

Also habe ich es umgedreht und belege der Reihe nach die Spielfelder A1 | A2 | A3 | A4 | B1 | B2 | B3 | B4 | C1 | usw.

Das Prinzip: Per Random wird eines der 4 Symbole ausgewählt, hier die senkrechte Linie, welche mit den 3 Property Triggern (rot) abgefragt wird, ob auf dem Spielfeld schon irgendwo 0 (keine), 1 oder 2 senkrechte Linie vorhanden ist. Die Property Trigger fragen also das entsprechende Flugzeug mit dem passenden Symbol ab, ob "Light Wing" und/oder "Light Cabin" aktiv ist.
- Bei 0 wird beim Flugzeug "Senkr Strobe" (blau links) das "Light Wing" aktiviert und das Symbol "A Senkr" auf dem Spielfeld platziert (dafür sind die orangen Areas zuständig und "OnComplete" wird beim entsprechenden Flugzeug ein Licht aktiviert).
- Bei 1 wird beim Flugzeug "Senkr Strobe" (blau links) das "Light Cabin" aktiviert und das Symbol "B Senkr" auf dem Spielfeld platziert (orange Areas und Lichtaktivierung, wie oben).
- Bei 2 wird der Random erneut ausgeführt, weil ein anderes Symbol platziert werden muss.

Die markierten Objekte sind für die Abfrage verantwortlich. Blaue und orange Objekte werden auch bei allen anderen Abfragen verwendet, sind also nur 1x vorhanden.

Flugzeug A1 (unten links) wird mit dem Symbol senkrechte Linie belegt, das markierte Flugzeug rechts speichert, wie oft die senkrechte Linie schon verwendet wurde.

So sieht die Elementgruppe aus, welche benötigt wird, allein um das Feld A1 zu füllen.
Sobald Feld A1 belegt ist, wird zu Feld A2 gewechselt und dort die nächste Random-Belegung ausgelöst.
Diese 46 Elemente muss ich 7 weitere Male erstellen für das komplette 2x4 Spielfeld.

Das üble ist, dass für das 3x4 Feld weitere 12 solcher Gruppen benötigt würden, welche ausserdem nicht aus 46, sondern aus jeweils 69 Elementen besteht und beim 4x4 Feld kämen weitere 16 Gruppen mit je 92 Elementen hinzu.
Total 2668 Elemente, nur um das Spielfeld zu füllen!
Meine bisher grösste Mission hatte 2238 Elemente. Ab 2000 Elementen wird der SimDirector sehr langsam und Abstürze können vorkommen.

Also umdenken...
Darum habe ich das zusätzliche Flugzeug (LMS) auf dem Rollfeld platziert, welches "speichert", welche Spielfeldgrösse aktiv ist. Nun erstelle ich "nur" die 16x92 Elemente, was Total 1472 ergibt und bei jeder Random-Abfrage wird vorher die Spielfeldgrösse abgefragt und entsprechend nur aus 4, 6, oder 8 unterschiedlichen Symbolen gewählt. So komme ich mit wenigen zusätzlichen Elementen für diese Abfrage, mit deutlich weniger Elementen für das Füllen des Spielfeldes aus.

Mit den Zusatz-Abfragen bin ich jetzt bei 99 Elementen, also voraussichtlich total 1584 für die fertige Feld-Belegung.

99 Elemente Duplizieren, jedes einzelne umbenennen (den Zusatz „- Copy 1“ entfernen und aus „A1“ A2 machen) ist eine reine Fleissarbeit.

Vorerst habe ich also nur 1x das ganze dupliziert und umbenannt, um zu testen, ob es nachher in der Mission überhaupt funktioniert.
Bei dieser Arbeit habe ich mir nebenbei ein paar Gedanken gemacht.

---Gedanken---
Wie werte ich die Feldauswahl des Spielers aus?

- Mit den vorhandenen 16 Spielfeld-Flugzeugen:
1. Feld aktiviert ein 9. Licht... zu aufwändig, beim 2. Durchflug müssen 16 Lichter gelöscht werden.

- Mit 1 weiterem Flugzeug:
Taxi aus = 1. Durchflug, Taxi ein = 2. Durchflug.

Wie erkenne ich beim 2. Durchflug, dass beide Symbole stimmen/falsch sind?

- Abfrage aller 16 Flugzeuge, welche Lichter an sind... Weil vorher schon welche eingeschaltet wurden, geht es nicht, es sei denn...

Beim durchgeflogenen Feld wird beim entsprechenden Flugzeug ein 9. Licht geschaltet, welches markiert, dass dieses Flugzeug "gemeint" ist.

Nun einfach 16 Abfragen basteln (1 pro Flugzeug), welches das 9. Licht eingeschaltet hat, die Abfrage kann immer wieder verwendet werden. Geht glaube ich doch nicht.

- 2 zusätzliche Flugzeuge basteln, welche sich nur das Symbol merken. Erster Durchflug Quadrat = Taxi, 2. Durchflug = Beacom, passt nicht, rote Symbole einblenden, Flugzeuge resetten, Galgenmännchen erweitern, usw. Geht wohl auch nicht, weil nicht wiederverwendbar…
---/Gedanken---

Weil ich aktuell mit den obigen Problemen nicht weiterkomme, kümmere ich mich um andere Dinge.

Mir ist eingefallen, dass ich das Spielfeld je nach Spielfeld-Grösse ein- und ausblenden muss.

Das Spielfeld ist leider nicht ein einzelnes Objekt, wie ein Haus, Flugzeug oder ähnliches, sondern besteht aus vielen einzelnen Teilen.
Sichtbar sind nur die schwarzen Rahmen-Linien, 6 Linien werden für die Erweiterung auf 3x4 benötigt, unsichtbar kommen noch 12 Areas hinzu, welche die Position des Symbols, die Durchflug-Area (welche beim Durchfliegen das passende Symbol einblendet und auswertet, ob das Feld schon belegt ist, usw.) und anderes hinzu.
Für das 4x4 Spielfeld kommen noch mal so viele Elemente hinzu.

Bedauerlicherweise kann man mit der "ChangeObjectPlacementAction" nicht alle 18 Objekte gleichzeitig an den gewünschten Ort verschieben, die Action kann nur ein einzelnes Objekt verschieben. Also muss die erste Verschiebe-Action Objekt1 verschieben und "OnComplete" die nächste Verschiebe-Action für Objekt2 auslösen, usw.
Es kommen weitere 18 Objekte hinzu, denn die "ChangeObjectPlacementAction" benötigt 2 Positionen: 1. den Startpunkt des zu verschiebenden Objektes und 2. den Zielpunkt. Also muss ich die Spielfeldlinien irgendwo "Parken", damit ich sie bei Bedarf ans Ziel verschieben kann. Die Parkposition sind 18 Objekte, also brauche ich 18 weitere, um die Zielposition zu markieren.
Das bedeutet, es benötigt 18 Actions und weitere 18 Areas, um das 2x4-Spielfeld auf ein 3x4-Spielfeld zu erweitern (und natürlich noch mal so viel für ein 4x4-Feld).

So werden aus ursprünglich 18 Objekten plötzlich 54 Objekte, was verknüpft so aussieht:

Nur die markierten Objekte waren vorhanden.

Sobald das Spiel zu Ende ist, soll man natürlich die Möglichkeit haben, ein neues Spiel zu starten, also müssen alle Objekte an den ursprünglichen Platz zurückverschoben werden, was in diesem Falle (für das Spielfeld) 18 Actions erfordert.
Ich will gar nicht daran denken, was ich noch alles zurücksetzen muss, angefangen mit allen Flugzeuglichtern, welche ich auch nur einzeln ausschalten kann, also im Zweifel alle 128 Lichter, denn ich weiss nicht, welche wirklich aktiv sind), dann alle Symbole, das Galgenmännchen usw.

Einfacher wäre es, wenn der User den Flug neu startet, aber das ist nicht komfortabel…
Angesichts der Grösse dieses Projektes musste ich am Ende leider auf das Zurücksetzen des Spieles verzichten. Ausserdem kann man CounterTrigger nicht Zurücksetzen. Der User muss also resetten, für ein neues Spiel.

Spielfeldgrösse je nach Bedarf einblenden funktioniert, also folgt jetzt die Fleissarbeit.
Die Felder A1 und A2 werden schon per Random belegt, nun muss ich alles für die Felder A3-D4 duplizieren, umbenennen und anpassen.
Zuerst habe ich nur die erste Zeile fertig gemacht, also die Felder A3 und A4.

Die Felder sind übrigens so nummeriert:

Um das ganze zu optimieren, habe ich die Ansicht des SimDirector umgebaut, damit die Wege mit der Maus nicht so weit sind.
Wenn nur eine Handvoll Objekte umbenannt werden müssen, hat meine bisherige Methode gut funktioniert, aber bei mehr als 1500 Objekten übersieht man bestimmt einige.
Bei wenigen Objekten wähle ich im Visualisations-Bereich (rot) ein Objekt und benenne es im Objekt-Property-Bereich (grün) um.

Um kein Objekt zu übersehen, wähle ich also neu im Objekt-Bereich (orange) der Reihe nach die Objekte aus, um sie dann im grünen Bereich umzubenennen. Du siehst, der Weg mit der Maus von 1 nach 2 ist extrem weit.

Also habe ich die Ansicht umgebaut, sprich den Visualistations-Bereich ausgeblendet und den Objekt-Property-Bereich direkt neben den Objekt-Bereich geschoben.

Nach dem Umbenennen müssen die einzelnen Objekte natürlich auch anderen Areas und Flugzeugen zugeordnet werden. Diese neu Zuordnungen mache ich üblicherweise auch in der Normalansicht, mit Visualisations-Bereich in der Mitte des Bildschirmes.

Der SimDirektor zeigt dabei im Visualisations-Fenster immer gleich das neu verknüpfte Objekt an, wechselt dabei auch die Gruppe. Bei kleinen Missionen bis 500 Objekte funktioniert das ganz gut und schnell. Aktuell hat diese Mission schon über 800 Objekte, was bedeutet, dass bei jeder Verknüpfung 1-2 Sekunden vergehen, bis der SimDirektor die Visualisation aktualisiert hat und die nächste Verknüpfung gemacht werden kann. Bei 2000 Objekten dauert es sogar 4-5 Sekunden. Gefühlt eine Ewigkeit, wenn man 25 Trigger schnell hintereinander in einer einzelnen ObjectActivationAction doppelklicken könnte, ohne eine Mausbewegung zu machen, aber dazwischen immer 5 Sekunden warten muss, bis die Visualisation aktualisiert ist.

Dieses Problem kenne ich schon, also deaktiviere ich schlicht die Visualisation und habe in wenigen Sekunden alle 25 Objekte verknüpft.
Das Problem ist aber, dass der SimDirektor mit 90-prozentiger Sicherheit abstürzt, wenn ich anschliessend die Visualisation wieder aktiviere. Selbst wenn der SimDirektor nicht abstürzt, rechnet er mehrere Minuten lang an der Visualisations-Darstellung.

Inzwischen habe ich dafür eine sichere und schnelle Lösung: Vor dem erneuten Aktivieren der Visualisation einfach die Mission speichern und anschliessend neu laden, dadurch wird das Projekt aktualisiert, was nur wenige Sekunden dauert und wenn ich die Visualisation aktiviere, gibt es keine Probleme.

Nachdem ein Test mit den Feldern A1-A4 erfolgreich war, sollte das weitere Duplizieren schneller gehen.

Durch eine Optimierung konnte ich übrigens die Objekte-Anzahl von 99 auf 91 pro Feld verkleinern. Das klingt nicht nach viel, aber bei 16 Feldern sind das immerhin 128 eingesparte Elemente. Ich habe dieses Mal nicht eine einzelne Gruppe (A1) dupliziert, sondern eine ganze Zeile (A1, A2, A3, A4). Das sind gleichzeitig 364 Objekte, welche toller Weise ihre Verbindung zu anderen Gruppen beibehalten. Dadurch hat sich die Anzahl der Objekte von 899 auf 1263 erhöht.

Hier die neuen 4 Gruppen.

Die Übersicht sieht aktuell so aus.

Heute war ich fleissig und habe alle 365 Objekte umbenannt:
Dazu musste ich bei jedem Objektnamen hinten " Copy 1" entfernen und ganz vorne "A" durch "B" ersetzen. Eine eintönige Arbeit, welche aber nur etwa eine Stunde gedauert hat.

Anstrengender waren 224 Objekte, denn jedes muss individuell dem richtigen Objekt zugeordnet werden. Weil diese Objekte nicht im selben Verzeichnis liegen muss man diese Gruppenübergreifend (unter den aktuell 1263) vorhandenen Objekten suchen. Ich habe mir dazu eine recht einfache Suchmethode angeeignet, manchmal reicht als Suchbegriff "A", oder "wa" (für wagr), trotzdem ist das Verknüpfen zeitaufwändig, und anstrengend. Ausserdem fehleranfällig: Wenn "Quadrat" und "Quadrat grau", oder "A Platzieren" mit "B Platzieren" verwechselt wird, gibt es unerwartete Fehler: Ein Objekt verschwindet beim Spielfeld-Aufbau plötzlich, oder der Spielfeld-Aufbau stoppt unerwartet.
Folgende Objekte mussten verknüpft werden:
- 32 Objekte mit dem richtigen Spielfeld-Flugzeug
- 64 Aktions mit dem richtigen Flugzeug-Symbol
- Ausserdem mussten die Verknüpfungen der Symbol-Verschiebung angepasst werden, also weitere 128 Verknüpfungen (Symbol Start- und Zielpunkt müssen definiert werden).

Das Verknüpfen hat natürlich Auswirkungen auf die Visualisation. Aus der oben gezeigten Ansicht, welche noch recht übersichtlich war, ist das geworden:

Irgendwie macht mir diese Ansicht Angst, denn ich habe noch nicht mal die Hälfte erreicht. Egal, hiermit ist das 2x4-Feld soweit fertig, sodass ich die zufällige Symbolzuordnung testen kann.

Der erste Test war erfolgreich und auch angenehm schnell, ca. 6 Sekunden für den Spielfeldaufbau.
Hier kannst du ein Video des Testes sehen:

2x4RandomTest.mp4

Natürlich habe ich einen 2. und 3. Test gemacht, um zu sehen, ob die Symbole auch wirklich zufällig verteilt werden. Unglücklicherweise, oder soll ich besser sagen, Gott sei Dank blieb der Spielfeldaufbau beim 4. Feld stecken. Denn ansonsten hätte ich den Fehler vielleicht nie, oder erst ganz am Ende entdeckt.

Ich habe also 50 weitere Tests und jeweils einen Screenshot vom Ergebnis gemacht, denn auf diese Weise hoffte ich, hinter den Fehler zu kommen. Wenn z.B. immer nach der zweiten waagerechten Linien der Aufbau stoppt, ist dort ein Verknüpfungsfehler, welcher dem Random sagt, dass der Spielfeldaufbau beendet ist, oder so was Ähnliches.

Hier die 50 Versuche:

Bei den Versuchen 14, 35 und 43 blieb der Aufbau stecken. Erkennt jemand ein Muster? Ich jedenfalls nicht. Allerdings ist mir Interessantes aufgefallen.

1) Bei Versuch 35 blieb der Aufbau beim 2. Symbol stehen, bei den Versuchen 11 / 19 / 28 / 30 und 37 lief der Aufbau durch, obwohl die ersten 2 Symbole identisch sind. An einem bestimmten Symbol kann es nicht liegen.
35 11 19

28 30 37

2) An einem bestimmten Spielfeld kann es auch nicht liegen, denn der Aufbau stoppt immer bei einem anderen Feld.
14 35 43

Der Fehler kann also nur noch bei der Random Action liegen.

Eine Random Action kann man auf 3 Arten verwenden:
1) Man setzt bei "Actions" nur eine Action ein (z.B. Motorausfall) und bestimmt bei "ProbabilityPercent", mit welcher Wahrscheinlichkeit diese Action ausgelöst wird (0-100% Chance, dass der Motor ausfällt).
2) Man setzt bei "Actions" mehrere Objekte ein und eines dieser Objekte wird zu 100% ausgewählt und aktiviert, sofern natürlich bei "ProbabilityPercent" 100% eingestellt ist.
3) Man setzt bei "Actions" mehrere Objekte ein und bestimmt bei "ProbabilityPercent", mit welcher Wahrscheinlichkeit eine Action ausgelöst wird.
Wenn 50% eingestellt ist, wird nur jedes 2. Mal ein Objekt ausgewählt und aktiviert, im anderen Fall wird nichts aktiviert.

Also habe ich alle Random-Actions überprüft, bei allen sind die 4 möglichen Objekte bei "Actions" eingetragen und bei "ProbabilityPercent" ist überall 100% eingestellt.
Was nun? Scheinbar funktioniert die Random-Action nicht zu 100% zuverlässig.
Ich vermute, das ist ein generelles Problem bei P3d, denn 100% scheint es nicht zu geben. Leistungshebel 100% wird zum Beispiel so ausgewertet: 99.999999%. Wenn das bei der Random-Action ähnlich ist, kann es nicht zu 100% funktionieren.
Allerdings sind 3 Fehler bei 50 Versuchen 6%, bei 99.999999% dürfte der Fehler nur sehr selten auftreten.
Wer weiss schon, wie die Random-Action im Hintergrund ausgewertet wird, vielleicht wird 100% mit 95.555555 ausgewertet?

---Nebenbei---
Dasselbe Problem hatte ich schon beim Tic Tac Toe Flug, bin aber nicht dahintergekommen, warum es manchmal nicht funktioniert hat.

Zitat aus der Tic Tac Toe Flug-Erklärung:
"Aus unerfindlichen Gründen hat das nur in 95% der Fälle funktioniert, darum habe ich mit 0.5s Verzögerung die RandomAction erneut auslösen lassen. Sollte das Feld frei sein, wird diese verzögerte Action sofort deaktiviert."

Damals habe ich mit einer aufwändigen Methode den Fehler abgefangen, was als Nebenwirkung hatte, dass sich der nächste Zug der KI um mindestens 0.5 Sekunden (im Extremfall bis 5s) verzögert. Ausserdem waren dafür rund 90 zusätzliche Elemente nötig.

Der MemoryFlug ist etwas anders aufgebaut und grösser, darum würde die obige Lösung etwa 450 zusätzliche Elemente benötigen und der Spielfeldaufbau beim 2x4-Feld dauert nicht mehr 6, sondern bis zu 40 Sekunden. Beim 4x4-Feld entsprechend 120 Sekunden, also 2 Minuten, was untragbar ist.
---/Nebenbei---

Ich habe jedenfalls noch ein paar Spielfeldaufbau-Tests gemacht, um meinen Verdacht zu bestätigen. Dabei habe ich den "ProgressLog" aktiviert, um zu sehen, an welcher Stelle der Aufbau hängen bleibt.
Den Log habe ich normalerweise ausgeblendet, weil diese zusätzliche Echtzeitanzeige den P3d extrem verlangsamt. Hier ist es aber nützlich, weil ich genau sehe, welches die letzte Action ist, die aktiviert wurde, bevor es stehen blieb.
In diesem Falle, beim 4. Feld:

Der Log sieh so aus:

Zu klein? Hier ein Detail:

A4Random2x4 wird ausgelöst, aber keines der 4 Zeichen wird aktiviert, es geht einfach nicht weiter.

So müsste es aussehen:
B4Random2x4 (macht das gleiche wie oben A4Random2x4) wählt zufällig eine der 4 Actions, in diesem Falle "B4 + ein", welche mit den 3 darunter stehenden Triggern auswertet, ob das Symbol "+" frei, oder belegt ist.
B4 + 2 Erkennt, dass schon 2 "Symbole +" vergeben sind und löst darum "B4 + Random erneut" aus.

Meine Idee, für eine Lösung dieses Problems ist ein Timer, welcher bei Ablauf die Random-Action neu startet.
Die Random-Action soll ja zufällig eines der 4 Objekte auswählen, sobald das geschehen ist, kann die Random-Action eine "OnCompleteAction" auslösen.

Also habe ich eine Dummy-Action eingefügt, welche die Random-Action, sobald fertig (OnCompleteAction) auslösen soll.
Es benötigte sehr viele Tests, bis endlich diese eine Random-Action versagte, kein Symbol ausgelöst hat und stehen blieb. Der Log zeigte aber, dass die "OnCompleteAction" ausgelöst wurde.
Theoretisch müsste es also funktionieren, jetzt muss ich nur entwickeln, wann und wo ich den Timer einfügen kann.

Ich habe eine Lösung gefunden, welche nur 4 zusätzliche Elemente pro Spielfeld (also insgesamt 64 Elemente) benötigt. Um dies Einzubinden, muss ich 8 Verknüpfungen erstellen, oder anpassen, bei 16 Spielfeldern sind das 128 Verknüpfungen, danach werde ich sehen, ob es wirklich zu 100% funktioniert.
So sieht die Lösung aus:
Diese Grafik habe ich für mich erstellt, damit ich beim Anpassen aller Spielfeld-Gruppen keine Verknüpfung vergesse.

- Die 3 Random-Actions aktivieren bei "OnComplete" die "Random Timer ein" Action, welche wiederum den Timer aktiviert, besser gesagt startet.
- Random LMS (welcher zu Beginn und bei jedem Neustart der Random-Action prüft, welche Spielfeldgrösse aktiv ist) resettet gleichzeitig den Timer.
- Random aus (welcher immer dann aktiviert wird, wenn ein Symbol erfolgreich einem Spielfeld zugeordnet wurde) deaktiviert den Random Timer.
- Anmerkung: Der Timer startet bei Beginn einer Spielsteinwahl und stoppt erst, wenn ein Spielstein gefunden wurde. Selbst wenn es im Extremfall 10 Sekunden dauern würde, erreicht der Timer nie die Endzeit von 2 Sekunden. Wenn alles korrekt läuft, ist die Auswertung in 0.01s beendet und bei belegtem Symbol wird der Timer resettet (startet also wieder bei 0) und die Random-Action erneut gestartet. Nur wenn die Random-Action versagt, löst der Timer einen erneuten Random aus.

Die Lösung sieht gut aus, also habe ich die neuen Objekte eingebaut und verknüpft. Nach vielen Tests bin ich nun sicher, dass es zu 100% funktioniert, denn der Timer ist mehrere Male angesprungen und hat den Random neu ausgelöst.

Jetzt kommt wieder eine Fleissarbeit, denn es müssen 2 weitere Spielfeldzeilen für die Modi mittel und schwer eingebaut werden. Das sind 8x95 Objekte, Total 760 Objekte, welche anschliessend umbenannt und richtig verknüpft werden müssen.
Alleine am Duplizieren der Objekte hat der SimDirector rund 5 Minuten gerechnet. Insgesamt hat diese Mission übrigens schon 2064 Objekte, entsprechend träge reagiert der SimDirektor inzwischen.

Neu duplizierte Gruppen

Gesamtübersicht ohne neue Verknüpfungen:

Gesamtübersicht, nachdem Flugzeuge, Symbole und Areas verknüpft sind:

Jetzt wird es extrem unübersichtlich. Wohlgemerkt, hier werden nur die Gruppen angezeigt, wenn man bedenkt, dass in vielen Gruppen 95 und mehr Objekte stecken.
Hier der rot markierte Ausschnitt von obiger Anzeige:

Ein erster Test im SimDirektor mit der Preview-Funktion war enttäuschend, der Spielfeldaufbau dauert lange 30-60 Sekunden. Also habe ich es direkt im P3d getestet und erstaunlicherweise dauert dort der Spielfeldaufbau nur ca. 10 Sekunden.

4x4RandomTest.mp4

Der Simdirektor zeigt mir bei der Preview in Echtzeit den ProgressLog an, was irre viel Leistung frisst. Log deaktiviert und auch im SimDirector ist es wieder fast so schnell wie im P3d. Klar es ist immer noch langsamer, weil der Simdirektor neben der P3d-Anzeige auch die 2064 Objects, die ObjectProperties des ausgewählten Objektes und die ConditionalLogic (welche in Echtzeit den aktuellen Wert anzeigt) darstellen muss.

Seit der Erweiterung von 2x4 auf 4x4 habe ich das Problem, dass nach Aufbau des 2x4-Feldes die Random-Action endlos weiterläuft und verzweifelt versucht, das nächste Feld zu belegen, welches nicht existiert. Ich muss also einen geeigneten "Ausstiegspunkt" finden, welcher der Random-Action sagt, dass der Spielfeldaufbau beendet ist und das Spiel beginnen kann.

Die letzte Action, wenn das 2x4 Feld fertig ist, lautet "B4 Random Timer aus" aus. Diese startet anschliessend den nächsten Random "C1 Random LMS", also muss ich spätestens dort eingreifen. LMS entscheidet zwischen leicht, mittel und schwer. Bei "L" (leicht) gibt es keine 3. Zeile, also klinkt sich der Random genau da aus. Ich kann also ein paar wenige Elemente entfernen, weil unnötig. Ab der 4. Zeile gibt es auch kein "M" (mittel), also könnte ab da die LMS-Abfrage komplett entfallen.

Soweit die Theorie, in der Praxis ist entfernen von unnötigen Objekten gefährlich, weil man vielleicht nicht alle Situationen durchdacht hat und ein funktionierendes System plötzlich Fehler macht. Egal, ich habe entfernt, was ging. Der Erfolg der Löschaktion ist bescheiden, von 2064 Objekten konnte ich nur auf 2036 Objekte reduzieren, also nur 28 weniger.

---Nebenbei---
Langsam verstehe ich, warum Programmierer ihre Programme nicht immer komplett optimieren, sondern auf alten Routinen aufbauen, anstatt diese Routine zu optimieren. Bei so einem Umbau müssen viele Ein- und Ausstiegspunkte angepasst werden. Geht dabei etwas schief, funktioniert das Programm nicht mehr. Weil Rechner immer schneller werden, verarbeiten sie auch die alte (langsame) Routine schnell genug.
---/Nebenbei---

Jetzt wird es knifflig, wie werte ich die Felder aus.

---Gedanken---
1) Ich durchfliege ein beliebiges Feld, z.B. A1 welches als Erstes abfragt, ob beim entsprechenden Flugzeug ein 9. Licht an ist.
- Wenn ja, wird Text eingeblendet "Spielfeld wurde bereits aufgedeckt". (Weiter muss nichts passieren)
- Wenn nein, Abfrage: Hat Flugzeug A schon ein Licht (es wird ein Flugzeug A und B geben zum Vergleich).

1a) Hat Flugzeug A schon ein Licht: Wenn nein, folgt Abfrage, welches Symbol (sollte mit 8 Abfragen funktionieren), je nach Licht das entsprechende Symbol (z.B. Panel = Quadrat) temporär im Spielfeld anzeigen und auch die weisse Fläche. Ausserdem Texteinblendung "Wähle nun das passende Gegenstück". Zusätzlich bei "Flugzeug A" das Licht Panel aktivieren.

1b) Hat Flugzeug A schon ein Licht: Wenn Ja, folgt Abfrage, welches Symbol, je nach Licht das entsprechende Symbol (z.B. Panel = Quadrat) temporär aktivieren. Bei "Flugzeug B" das entsprechende Licht aktivieren.

1c) Jetzt Abfragen, ob Flugzeug A/B die gleichen Lichter aktiviert haben (sollte mit 2 Abfragen gehen, die Logik wird allerdings gross).

2) Sobald klar ist, dass die Symbole ein Paar sind (oder eben nicht), muss ich die Flächen (weiss | grün | rot) entfernen und bei "falsch" auch das entsprechende Symbol.
- Wenn richtig, weisse Fläche weg und 2 grüne Flächen aktivieren. (Aber wie weiss ich wo?)
-Wenn falsch, weisse Fläche weg und 2 rote Flächen aktivieren. (Aber wie weiss ich wo?)

Ist wohl wie beim Schach, 1-2 Züge kann ich im Voraus planen, sobald das Spiel weiter fortgeschritten ist, kann ich den nächsten Zug angehen. Da hilft wohl nur ausprobieren.
---/Gedanken---

Mir wurde bewusst, dass bei den Spielfeld-Flugzeugen nebst den 8 Lichtern für den entsprechenden Spielstein und dem 9. Licht (für aufgedeckt), einen weiteren Zustand gespeichert werden muss (für temporär aufgedeckt).
So sind die Lichter jetzt verwendet:
- Die Lichter 1-8 speichern, welcher der 8 unterschiedlichen Spielsteine zufällig dem Feld zugeordnet wurde.
- Licht 9 "Wing" speichert, ob das Feld bereits aufgedeckt wurde.
- Licht 10 "Recognition" (kurz "Reco") speichert temporär, ob ein Feld aufgedeckt wurde.

Meine Theorie:
Gleich nach Spielstart ist das 9. Licht noch nirgendwo aktiv. Sobald ein Paar erfolgreich aufgedeckt ist, haben nur 2 Spielfeld-Flugzeuge dieses Licht aktiviert, im weiteren Verlauf werden es mehr.
Beim nächsten Feld-Durchflug kann ich abfragen, ob belegt, oder frei. Bei "frei" aktiviere ich Licht 9 (Cabin) und temporär Licht 10 (Reco).
Bei jedem weiteren Feld-Durchflug wird nun Cabin abgefragt, bei "belegt" kommt ein Text BELEGT, bei "frei" werden wieder Cabin und Reco aktiviert.
Nach jedem 2. Durchflug werden die 2 Flugzeuge A + B verglichen, wenn richtig nur Reco, wenn falsch Reco und Cabin löschen.
Dadurch sollten nur korrekt aufgedeckte Felder das 9. Licht "Cabin" aktiv haben.

Ausserdem habe ich 2 weitere Flugzeuge eingebaut (A + B), für den Vergleich des Paares.

Ob es damit wirklich funktioniert, wird sich zeigen.
Ich habe einfach begonnen, obige Gedanken umzusetzen:

1) Als erstes habe ich eine Abfrage für Feld A1 erstellt "A1 Belegt", in dem ich Abfrage, ob das 9. Licht aktiv ist.
Die Logik dazu ist simpel, ist Light Cabin ein (also=1) Text einblenden "Das Feld wurde schon aufgedeckt, wähle ein anderes Feld."
Natürlich benötigt es eine weitere Abfrage, ob das 9. Licht inaktiv ist. Also habe ich eine 2. Abfrage (rotes Element rechts) eingebaut und "A1 Frei" benannt.

Dieses 2. Element aktiviert die Abfrage, ob bei Flugzeug A schon ein Licht aktiviert ist.
Die benötigte Logik-Abfrage ist etwas umfangreicher, denn sie fragt ab, ob eines von 8 Lichtern aktiv ist. Natürlich benötigt es eine zweite Abfrage, welche zündet, wenn keines der 8 Lichter aktiv ist.

1a) Flugzeug A ist frei, folglich deckt der Spieler ein erstes Feld auf. Also wird bei dem durchgeflogenen Feld abgefragt, welches Symbol dort hinterlegt ist. Es gibt zwar 16 Symbole, aber nur 8 unterschiedliche, weil jedes 2x vorhanden ist. Darum genügen 8 PropertyTrigger, welche jeweils ein Licht (Panel, Strobe, usw.) abfragen. Nur einer der 8 Trigger wird zünden und aktiviert eine SetPropertyAction, welche beim Flugzeug A das entsprechende Licht aktiviert und anschliessend eine ChangeObjectPlacementAction aktiviert. Die Action verschiebt den passenden Spielstein in das Feld und aktiviert danach eine ObjektActivationAction, welche die 8 Trigger deaktiviert und eine weitere ChangeObjectPlacementAction aktiviert. Diese Action aktiviert wiederum die weisse Fläche und einen Text (Wähle nun das passende Gegenstück.).

1b) Flugzeug A ist belegt, also deckt der Spieler ein zweites Feld auf. Ich habe darum die komplette Abfrage für Flugzeug A kopiert und alles so angepasst, dass bei Flugzeug B das entsprechende Licht gesetzt wird.

1c) Am Ende der "1b) -Abfrage" wird verglichen, ob die 2 Symbole übereinstimmen. Dazu werden nur 2 PropertyTrigger benötigt.
Die Logik für die Abfrage "Gleich" ist mit 57 Elementen sehr gross.

Die Logik der Abfrage "Ungleich" ist mit 113 Elementen noch grösser.

Schritt 1a-c meiner Gedanken habe ich testweise für ein Feld (A1) erstellt und es werden dafür 73 Objekte benötigt. Die 73 Objekte muss ich für alle anderen Felder (A2-D4) duplizieren und alle Verknüpfungen anpassen (15x73=1095 zusätzliche Objekte).

Auf diesem Bild sieht man 103 Objekte, in der Gruppe sind aber effektiv nur 73 Objekte. Die übrigen sichtbaren Objekte (alle orangen, einige violette und 3 blaue) befinden sich in anderen Gruppen, sind aber mit dieser verknüpft.

---Nebenbei---
In vielen Gruppen sind mehr Objekte sichtbar, als tatsächlich vorhanden sind.
In dieser Gruppe z.B. befinden sich nur 49 Objekte, sichtbar sind aber 342, welche (aus anderen Gruppen) die orangen Areas aktivieren.

So sah diese Gruppe aus, bevor die externen Verknüpfungen hinzukamen.

Ich schweife ab, zurück zum Thema.
---/Nebenbei---

Bevor ich 73 Objekte 15x kopiere, umbenenne, Verknüpfungen und bei Triggern die Referenzen anpasse, möchte ich wissen, ob ich auch die Auswertung irgendwie hinbekomme.

Bei Schritt "2)" müssen die aktuellen Objekte, je nach "richtig/falsch" entsprechend ausgeblendet und bei falsch zusätzlich das Galgenmännchen schrittweise eingeblendet werden.

Wenn die 2 aufgedeckten Symbole übereinstimmen wird zuerst geprüft, ob das Spielfeld komplett aufgedeckt ist.
Dazu wird zuerst die Spielfeldgrösse LMS (Leicht | mittel | schwer) abgefragt und entsprechend zwei PropertyTrigger aktiviert, welche prüfen, ob alle Lichter eingeschaltet sind, oder nicht.
Falls alle Lichter aktiv sind, ist das Spielfeld erfolgreich gelöst worden und somit beendet.
Die Logik für das grosse Spielfeld benötigt 49 Elemente.

- Bei Spielfeld ungelöst wird ein Text aktiviert (Gut gemacht. Wähle das nächste freie Feld.), die weisse und grüne Fläche werden entfernt und bei allen Flugzeugen das Reco-Licht ausgeschaltet.
- Bei Spielfeld komplett gelöst, wird ein Text aktiviert (Herzlichen Glückwunsch, du hast das Spiel gelöst.), die weisse und grüne Fläche werden deaktiviert und das Goal als erfüllt geschaltet.
Diese Auswertung kann immer wieder verwendet werden und benötigt nur 46 Elemente.

Wenn die aufgedeckten Spielsteine nicht übereinstimmen, wird es komplizierter:

Als Erstes wird ein Text eingeblendet (Die Symbole stimmen leider nicht überein.) und beim Galgenmännchen ein Teil gezeichnet. Dafür wird mit LMS die Spielfeldgrösse abgefragt und je nach Grösse werden bestimmte Counter aktiviert.
Beim 2x4 Feld sind 3 Fehler erlaubt, beim 4. Fehler hängt das Männchen vollständig und das Spiel ist verloren. Beim 3x4 Feld sind es 5 und beim 4x4 Feld 7 Fehler. Es werden also 4, 5 oder 7 Counter benötigt.

Die 4 Counter beim 2x4 Feld haben unterschiedliche Startwerte (4,3,2,1) und zählen zurück nach null (0). Eine CountAction gibt allen 4 Countern einen Impuls, worauf diese den Wert um 1 verringern. Der Counter mit Startwert 1 wird als Erstes zünden und das Zeichnen des Galgenmastes aktivieren, ab da ist der Counter inaktiv. Beim nächsten Impuls der CountAction wird der Counter mit Startwert 2 zünden und das Galgenmännchen weiter zeichnen, usw.
Für diese Fehlerauswertung sind 33 Objekte notwendig.

Der nächste Schritt ist das Entfernen der weissen und roten Fläche und der falsch aufgedeckten Symbole. Dazu werden alle 16 Spielfeld-Flugzeuge abgefragt, ob sie ein Reco Licht eingeschaltet haben. Wenn ja werden bei diesem Flugzeug die Lichter Reco und Cabin ausgeschaltet und anschliessend die 8 Lichter abgefragt, welche für die unterschiedlichen Symbole stehen. Der PropertyTrigger mit dem entsprechenden Licht aktiviert zwei ChangeObjectPlacementActions, welche beide Spielsteine (z.B. Quadrat A und Quadrat B) entfernt. Ich entferne beide, weil ich nicht weiss, ob das Symbol A, oder B platziert war.

Ich habe diese Abfrage der übersichtshalber in 4 Gruppen aufgeteilt, jeweils eine Zeile des Spielfeldes, hier die Gruppe für die Felder A1/A2/A3/A4, welche 48 Objekte beinhaltet (Total benötigt die Abfrage 192 Objekte).

Anschliessend werden alle PropertyTrigger deaktiviert, welche bei den obigen Abfragen aktiviert wurden. Das ist notwendig, damit die aktivierten Trigger, welche noch nicht gezündet haben, nicht im weiteren Spielverlauf plötzlich zünden, wenn ein nächstes Spielfeld durchflogen wird. Dazu habe ich zu Beginn der Fehlerauswertung einen Timer gestartet, welcher nach einer Sekunde alle PropertyTrigger deaktiviert. Die ganze Fehlerauswertung sollte eigentlich nur etwa 0.2 Sekunden dauern, das muss ich später noch testen, notfalls kann ich den Timer auf 2-3 Sekunden stellen. Der Timer löst also eine ObjectActivationsAction aus, welche 145 Objekte deaktiviert.

Zum Schluss müssen noch die entsprechenden Lichter der Flugzeuge A und B gelöscht werden, damit sie für den nächsten Felddurchflug bereit sind.

Für Schritt 2 werden insgesamt 298 Objekte benötigt.

Damit ich nun Testen kann, ob alles funktioniert, habe ich die Abfrage für Feld A1 dupliziert (73 Objekte) und alle Verknüpfungen für A2 angepasst.
Weil das viele Anpassungen sind, habe ich mir einen Spickzettel gebastelt, damit ich nichts vergesse.

---Spickzettel---
1) PropertyTrigger A1 Durchflug = Area A1 Durchflug Position
2) A1 Belegt aus = Text Belegt ein
3) A1 Weiss Platzieren = Text Gegenstück ein
4) A1 Grün Platzieren = SpielfeldGelöstAbfrage LMS ein
5) A1 Rot Platzieren = 10sTimerSymboleWeg ein
6) PropertyAcions
A1 A Cabin 1 (A1 B Cabin 1, A1 A Reco 1, A1 B Reco 1) = A1
7) A1 Grün Platzieren = Feld Grün (oben), A1 Feld Position (unten)
(Ebenso mit A1 Rot Platzieren und A1 Weiss Platzieren)
8) A1 A Quadrat Platzieren = A Quadrat (oben), A1 Position (unten)
(A1 B Quadrat Platzieren + alle anderen Symbole auch) (16x)
9) A1 A Quadrat 1 = A (A1 B Quadrat 1 = B)
(Alle anderen Symbole auch) (16x)
10) A1 A Quadrat (A1 B Quadrat und alle anderen Symbole): Logic auf A2 - D4 anpassen (16x)
(A1 Frei und A1 Belegt auch)
(Das rote A1 durch das jeweilige Feld A2 - D4 ersetzen)
---/Spickzettel---

Nach dieser Aktion habe ich einige Tests gemacht und diverse Anpassungen vornehmen müssen, bis es letztendlich fehlerfrei funktionierte.

Aktuell bin ich jetzt bei 2493 Objekten und der SimDirektor ist jetzt schon unerträglich langsam. Ich hoffe nur, dass der SimDirektor das packt, denn die Abstürze häufen sich. Selbst bei so einfachen Aktionen wie "Klick auf den Speichern Button", kann der SimDirektor abstürzen (zum Glück erst nach dem Speichern der Änderungen).

Wenn ich bedenke, dass noch mindestens 1022 Objekte hinzukommen, wird mir angst und bange. Voraussichtlich werden mindestens 3515 Objekte benötigt. Die erste Abfrage (Schritt 1a-c meiner Gedanken) habe ich bisher nur für die Felder A1 und A2 erstellt, diese muss ich nun für die restlichen 14 Felder duplizieren.

---Test---
Irgendwie habe ich Angst, dass der SimDirector bei 3000 Objekten plötzlich meldet, dass die maximale Anzahl an Objekten erreicht ist.
Darum habe Testweise die Gruppen A1-D4 (insgesamt 1504 Objekte) dupliziert, der SimDirektor rechnete rund 4 Minuten und am Ende waren 3997 Objekte vorhanden.
Die Objekt-Anzahl ist kein Problem, also gleich nochmal 1504 Objekte duplizieren, bin gespannt… Nach rund 8 Minuten 5501 Objekte, müsste also geklappt haben, der Bildschirm hat zwischenzeitlich beängstigend geflackert, so, als ob es gleich einen Absturz gibt.
Auf ein Neues, 1504 Objekte kopieren. 8 Minuten später waren 7005 Objekte vorhanden, also gibt es wenigstens bis dahin keine Obergrenze. Einzig mein 10 Jahre alter Computer, der für so grosse Missionen wohl zu langsam ist.
Schafft der SimDirector die 10000 Objekte? Also weitere 3008 Objekte kopiert. Nach knapp 17 Minuten waren 10013 Objekte vorhanden.
---/Test---

Nach diesem Test habe ich 2 weitere Felder (A3 und A4) erstellt und erneut getestet. Erst jetzt konnte ich testen, was nach einem korrekt aufgedeckten Paar passiert, bzw. ob es danach richtig weiter geht.

Leider kam ein merkwürdiger Fehler: Das nächste aufgedeckte Feld, welches ja eigentlich wieder ein erstes für die Paar-Suche ist, wurde behandelt, wie ein zweites aufgedecktes Feld und laut Auswertung ist es falsch. Womit wurde verglichen und warum?

Nach einiger Suche fand ich die Ursache: Die beiden Trigger, welche auswerten, ob die 2 Felder übereinstimmen, werden zwar beide aktiviert, aber nur der Trigger „richtig“ zündet. Der andere Trigger „Falsch“ bleibt aktiv und zündet, sobald ein weiteres Feld durchflogen wird.
Also habe ich 2 weitere Elemente eingebaut, welche die beiden Trigger nach einer Sekunde deaktivieren. Weitere Tests bestätigen, dass es jetzt klappt.

Als nächstes duplizierte ich die Auswertung der Felder A1 – A4, benannte alle nach B1 – B4 um und passte nach Spickzettel alles andere an.
Danach konnte ich das komplette Spiel im Modus leicht testen. Nach umfangreichen Tests und einigen Fehlerkorrekturen läuft das Spiel im Modus leicht.

Als letzten Schritt duplizierte ich die Felder A1 - B4 und passte alles für C1 - D4 an. Nach letzten Ergänzungen und Korrekturen ist das Spiel fertig und funktioniert. Insgesamt sind es 3565 Objekte. Vermutlich bin ich der einzige Irre, welcher je so eine grosse Mission erstellt hat.

Damit ihr euch ein Bild von der Grösse dieser Mission machen könnt, hier ein paar Bilder.

So sieht die Gruppenübersicht aus:

Hier ein Detail von obiger Ansicht:

Eine nähere Ansicht von obigem Bild:

Hier der Inhalt der oben markierten Gruppe B4Random:

Zum Schluss wollte ich noch wissen, wie die Mission aussieht, wenn ich die Gruppenansicht aufhebe.

Gruppenansicht

Ansicht, ohne Gruppierung

An dieser Ansicht hat der SimDirektor übrigens mehr als 2 Stunden gerechnet. Ich dachte schon, der SimDirektor wäre abgestürzt.
Näher heranzoomen ging leider nicht, beim Versuch ist der SimDirektor abgestürzt. Mit dieser Ansicht kann man sowieso nicht arbeiten, man würde niemals das richtige Objekt finden, oder nachvollziehen können, mit welchen anderen Objekten dieses verknüpft ist.