Darstellung kommt bei Parallel Process durcheinander

Hallo,

in meinem derzeitigen projekt, das momentan getestet wird, haben meine betatester immer mal wieder das problem, das ihnen bei parallel-events die anzeige durcheinanderkommt. Das sieht z.b. so aus:

http://fs1.directupload.net/images/180223/k4u2nd5p.png
Es ist der charakter asgar zu sehen nicht valnar. und die textbox fehlt.

http://fs1.directupload.net/images/180223/rhvmqajg.png
Auch hier falscher name oder bild. Und textbox.

Zu den events kann ich sagen, dass die parallel process sind und IMMER aktiv sind. aber sie haben conditional branches, erst wenn die erfüllt sind, geht der text los. Auto-start geht nicht, weil man da links in der switch und variablenspalte zu wenig eintragen kann und wenn man es über conditional branch macht kann man sich auf den maps trotzdem nicht bewegen. Hinzu kommt, dass diese story-events meist auf 4-5 maps sind weil nicht festgelegt ist, wo der spieler sie genau auslöst. Ich hatte glaube ich auch schon versucht an den anfang der parallel-events einen wait zu setzen aber das hatte wohl auch nichts gebracht glaube ich.

Gibt es einen weg, diese anzeigefehler zu verhindern?

Es wäre nett, wenn ihr uns mit diesem problem helfen könnt, danke.
Noch einen schönen freitag.

Vermutlich kommen sich da mehrere Parallele Prozesse ins Gehege und überschreiben gegenseitig ihre Befehle - oder du löst einfach falsche aus. Ich würde dir raten, das über eine Variable zu steuern (bspw. "Story-Scene" oder so) und an diese dann einfach Auto-Events zu knüpfen, nicht per Conditional Branch, sondern per Event-Seite.

Ich gebe zu bedenken, dass PP-Events an der Stelle weiter laufen wo sie aufgehört haben, wenn man sie zB mit einem Switch an und ausschaltet. Vielleicht hat es auch damit zu tun.

Hallo,

danke für eure beiträge. Ich war schon drauf und dran einen weiteren post zu schreiben weil ich es nicht wirklich verstanden hatte, aber dann hab ich erstmal rumprobiert. ich glaube ich habe das problem gelöst, das mit autostart und den seiten hat geklappt, auch wenn ich dafür die variable eines optionalen NPCs in einen switch ändern musste, damit es links reinpasst. Sehr blöd und rückständig, dass ein event nur zwei switches und eine variable als überprüfung zulässt.

Danke nochmal, dass ihr geholfen habt.

Noch einen schönen sonntag.

Zitat:

---

Zitat von Pacebook

Sehr blöd und rückständig, dass ein event nur zwei switches und eine variable als überprüfung zulässt.

---

Warum lässt du das nicht weg und überprüfst das Event stattdessen komplett mit if-Abfragen? Die kannst du unendlich verschachteln und hast da kein Limit!

Zitat:

---

Zitat von Ken der Kot

Warum lässt du das nicht weg und überprüfst das Event stattdessen komplett mit if-Abfragen? Die kannst du unendlich verschachteln und hast da kein Limit!

---

Weil es dann permanent laufen muss. Im Falle eines PPs gibt das schnell Performance-Probleme und Bugs (s. independentArts Post), bei Autostarts blockiert ein einzelnes Event dann direkt die komplette Steuerung.

Eher wäre es ne Idee, die Steuerung dieser Switches und Variablen alleine auszulagern (falls das überhaupt nötig ist) und für das Autostartevent dann wirklich nur mit einer einzigen Variable zu arbeiten.

Zitat:

---

Zitat von BDraw

Weil es dann permanent laufen muss. Im Falle eines PPs gibt das schnell Performance-Probleme und Bugs (s. independentArts Post), bei Autostarts blockiert ein einzelnes Event dann direkt die komplette Steuerung.

Eher wäre es ne Idee, die Steuerung dieser Switches und Variablen alleine auszulagern (falls das überhaupt nötig ist) und für das Autostartevent dann wirklich nur mit einer einzigen Variable zu arbeiten.

---

Aha, und ansonsten läuft ein Parallel Prozess mit diesen Switches und Variablen, die man einstellt, nur dann, wenn die Switches an sind und die Variablen einen bestimmten Wert haben, oder?

Genau.

Man kann beim erstellen von Events Startbedingungen einstellen (besagte zwei Switches + Variable, bei Berührung durch den Spieler/einen NPC, ...) die bestimmen, wodurch ein Event getriggert wird. Sind diese Bedingungen erfüllt, wird der Code darin ausgeführt. Abfragen, etc. sind Teil dieses Codes, dafür muss das Event also schon laufen.

Autostart-Events blockieren - egal was drinsteht - andere Events und vor allem die Steuerung, da sie für Cutscenes gedacht sind. Parallele Prozesse dagegen laufen halt parallel zu allem anderen - können aber halt auch zu Performance-Problemen führen, wenn zu viele laufen oder man beim Scripten nicht aufpasst. Da sollten normale Abfragen also nur verwendet werden um zu schauen, was der Prozess tun soll, nicht ob.

Ich frage mich gerade, ob denn jemals mehrere der Events gleichzeitig aktiv sind. Kann mir das grad noch nicht recht vorstellen, weil die Bilder nicht funzen. Wenn nicht: Was spricht dagegen ein PP-Event zu machen mit einer Seite pro Charakter und jede Seite mit einer Variablennummer anzusteuern?

Zitat:

---

Ich gebe zu bedenken, dass PP-Events an der Stelle weiter laufen wo sie aufgehört haben, wenn man sie zB mit einem Switch an und ausschaltet. Vielleicht hat es auch damit zu tun.

---

Betrifft aber nur Parallele Common Events, Parallel Map events machen das nicht.

Zitat:

---

Zitat von BDraw

Genau.
Autostart-Events blockieren - egal was drinsteht - andere Events und vor allem die Steuerung, da sie für Cutscenes gedacht sind. Parallele Prozesse dagegen laufen halt parallel zu allem anderen - können aber halt auch zu Performance-Problemen führen, wenn zu viele laufen oder man beim Scripten nicht aufpasst. Da sollten normale Abfragen also nur verwendet werden um zu schauen, was der Prozess tun soll, nicht ob.

---

Man muss beachten, dass parallele Events untereinander im Prinzip kooperatives Multitasking machen (das Event signalisiert via Scriptende, "Wait" oder anderer Befehle die zu eienm "yield" führen, dass es für diesen Frame fertig ist). Wenn man das "yield" vergisst sind insbesondere Endlosschleifen teuer, da das PP 10000 Befehle pro Frame ausführen darf bevor es pausiert wird.
Okay und designbedingt sind alle Switch- und Variablenoperationen langsam, weil nach jeder Operation die komplette Map refreshed wird um parallele Events zu entfernen, die nicht mehr der Startbedingung entsprechen.