[2k3] Parallel Process

[Daos-Mandrak]

Hi Leute, stehe vor einem äußerst ärgerlichem Technikproblem. In meinem Kampfsystem benutze ich für Helden und Monster Pictures, die je 3 Sprites besitzen und über Parallele Prozesse nach folgendem Schema animiert werden:

• Zeige Sprite 1
• Zeige Sprite 2
• Zeige Sprite 3
• Zeige Sprite 2

Über einen Switch "Held_01_Animation" wird der Parallel Process gestartet und beendet. Wird dieser nun beendet und neu gestartet, beginnt der Parallel Process immer an der Stelle an der er zuvor beendet wurde. Wurde er z.B. an der Stelle "Zeige Sprite 3" beendet, folgt "Zeige Sprite 2".

Dadurch entstehen Fehler in der Animation, da man immer vom ersten Befehl (also "Zeige Sprite 1") starten müsste. Gibt es irgendeine Möglichkeit einen Parallel Process beim aktivieren komplett neu zu starten anstatt ihn am letzten Punkt weiterlaufen zu lassen? Verwende übrigens Version 1.08 ohne Patches.

[Ligiiihh]

Warum nicht einfach:

Show Picture: 1 (SpriteA)
Wait 0.1
Show Picture: 1 (SpriteB)
Wait 0.1
Show Picture: 1 (SpriteC)
Wait 0.1
Show Picture: 1 (SpriteD)
Wait 0.1

Also sozusagen das Ersetzen der Picture-Nummern durch andere Pictures? Muss aber ehrlich sagen, dass ich das nicht richtig verstanden habe.
Oder Erase Events mit Loops, aber das wäre etwas umständlicher. Und bei sowas könnte man doch Variablen benutzen?

[Daos-Mandrak]

Das Problem liegt leider woanders. Ein Parallel Process startet an der Stelle an der er beendet wurde, der Code ist dabei egal.

[Cherry]

Verwende keine StartBedingung sondern eine Conditional Branch mit dem Switch!

[netwarrior]

Stand mal vor einem ähnlichen Problem.
Mit diesem Code sollte es gehen.
Dafür braucht für den Loop einen zusätzlichen Switch, damit man beim Rausspringen aus der Schleife gleich am Ende des Skriptes kommt, damit es bei erneuten Aufrufen bzw. Switch setzten wieder von vorne beginnt.

Nachteilig sind die vielen IF-Bedingungen, aber die gehen ja schnell mit copy&paste.

Code:

SWITCH "Loop"=ON;

LOOP
 Aktion;
  IF SWITCH "Loop"=OFF
     break;
  END IF

 Aktion;
  IF SWITCH "Loop"=OFF
     break;
  END IF

 Aktion;
  IF ... END IF
 usw.

END LOOP

//Nach Loop
SWITCH "Held_01_Animation"=OFF;
WAIT(1ms); //um zu verhindern, dass es wieder gleich von vorne anfängt.

[Daos-Mandrak]

@netwarrior
Hab den Fehler wie gesagt ebenfalls durch ständige If-Abfragen nach jeder Aktion gelöst und scheinbar ist es dadurch möglich. Aber es interessiert mich natürlich ob sich das in Zukunft nicht einfacher realisieren lässt.

@Cherry
Vielen Dank für den Tipp, mit einer Conditional Branch lässt sich dieser Fehler sehr schön vermeiden. Es müsste nur den Nachteil haben, dass das Event dann verzögert beendet wird wenn der Switch deaktiviert wird, weil der Code komplett bis zum Ende durchläuft. Bei meinem Problem ist es auf jeden Fall ein guter Einsatz falls es irgendwann doch nochmal zu Problemen kommt und ich einen Teil umcoden muss.

[Dhan]

Wie wäre es mit einem PP mit einem Inhalt wie:
fork (Phase = 1) {
__show pic 1
__Phase++
__wait x,y
}
fork (Phase = 2) {
__show pic 2
__Phase++
__wait x,y
}
fork (Phase = 3) {
__show pic 3
__Phase++
__wait x,y
}
fork (Phase = 4) {
__show pic 2
__Phase++
__wait x,y
}
fork (Phase = 5) {Phase = 1}

Und jedesmal, wenn du den PP neu startest, setzt du Phase auf 1

[netwarrior]

Wie wäre es mit einem PP mit einem Inhalt wie:
fork (Phase = 1) {
__show pic 1
__Phase++
__wait x,y
}
fork (Phase = 2) {
__show pic 2
__Phase++
__wait x,y
}
fork (Phase = 3) {
__show pic 3
__Phase++
__wait x,y
}
fork (Phase = 4) {
__show pic 4<--
__Phase++
__wait x,y
}
fork (Phase = 5) {Phase = 1}

Und jedesmal, wenn du den PP neu startest, setzt du Phase auf 1

...

Interessanter Ansatz. Das Problem ist aber, dass das Event da weiterläuft, wo es zuletzt stehen geblieben ist.
Wenn aber die Phase auf 1 gesetzt ist, aber der letzte Moment im ParallelEvent (sieht roten Zeiger) z.B. an einer Stelle auf Phase 4 ist. Würde nachdem inkrementieren der Wert auf 2 sein und anstatt bei Phase 1 auf Phase 2 beginnen.

netwarrior

[Cherry]

dann machst du das Phase++ über das Show Pic.

Es werden nämlich solche Befehle wie Fork oder Change Variable, die nichts grafisch ändern oder auf irgendetwas warten, nie zwischeneinander unterbrochen (außer wenn mehr als 150.000 hintereinander sind oder so, wenn ich mich nicht irre).

[Dhan]

Wenn aber die Phase auf 1 gesetzt ist, aber der letzte Moment im ParallelEvent (sieht roten Zeiger) z.B. an einer Stelle auf Phase 4 ist. Würde nachdem inkrementieren der Wert auf 2 sein und anstatt bei Phase 1 auf Phase 2 beginnen.

...

Recht hast du, aber dafür gibts ne Lösung: Bau in das PP eine weitere fork ein, nämlich:
fork (Phase < -5) {Phase = 1}
und hau ein Phase = -10 vor jede PP-Aktivierung, das kann von keinem Phase++ zerstört werden

Es werden nämlich solche Befehle wie Fork oder Change Variable, die nichts grafisch ändern oder auf irgendetwas warten, nie zwischeneinander unterbrochen (außer wenn mehr als 150.000 hintereinander sind oder so, wenn ich mich nicht irre).

...

Das hast du getestet? Von echten Hochsprachen kenne ich, dass man der Machine nicht trauen darf und außer synchronized-Krams keine Atomarität besteht, andererseits könnte der Maker natürlich auch anders yielden - kann es sein, dass die Wahrscheinlichkeit auf einen schlechten Thread-Wechsel zwischen einer Bedingung und einem Befehl einfach verdammt klein ist?

[Cherry]

Da gibts irgendsoeine beknackte Logik drin, die hab ich irgendwann getestet, ja.

Das ist ja auch der Grund, warum Power Mode 2003 funktioniert; oder der Itempointerpatch - wo ja in beiden Fällen eine Variable befüllt wird und dann nix zwischen dem Change Variable und dem folgenden Befehl kommen darf, weil es sonst nicht klappt.