TVTower
TVTower copied to clipboard
TVTower
Initial ProgrammePlan cleanup/overhaul commit
Ich hatte urspruenglich angefangen Mutexe in den Programmplan zu integrieren -- und natuerlich kommt es trotzdem zu Deadlocks.
Entsprechend habe ich angefangen, den Programmplan etwas aufzuraeumen, nach Verbindungen zu suchen etc.). Ich entschlacke einiges in der API - und fuege aber an anderer Stelle auch neue Funktionen hinzu.
Damit gehen leider auch notwendige Aenderungen in der AI-API bzw den Skripten einher.
Ich vermute, das wird auch die Abwärtskompatibilität der Speicherstände betreffen, oder?
Nein ... wenn nur die Funktionsaufrufe usw abgeaendert werden, sollte es da keine Unterschiede geben.
Ich habe jetzt angefangen, die "events" in verschiedene Typen zu unterteilen (die von TEventBase abstammen):
TNotificationEvent und TIntentionEvent.
TNotificationEvent ist fuer "informationen/Nachrichten" gedacht, die keiner Bestaetigung beduerfen. Geplant ist, dass diese Informationen auch verzoegert uebermittelt werden koennen - sprich sie landen in der "event"-Qeue des EventManagers.
Die Events koennen nicht mit "Veto" oder Aehnlichem versehen werden - dafuer aber ist weiterhin eine "StartTime" setzbar (also kuenstliche Verzoegerung der Auslieferung)
Diese Events werden natuerlich im naechsten "Update()" der Gameloop (bzw des EventManagers) abgearbeitet (wenn sie denn dran sind). Sprich sie finden koennen "asynchron" genutzt werden.
Ist allerdings die Reaktion von Elementen wichtig - also Vorbereitung fuers Abspeichern/Serialisieren usw., muss TIntentionEvent genutzt werden.
Hier wird "sofort" ausgeloest (immediate reaction) und man kann die Startzeit nicht verschieben. Dafuer gibt es hier den Eventstatus und IsVeto() bzw. IsAccepted(). Diese Events landen nicht in der "event"-Queue sondern werden immer sofort ausgefuehrt.
Man koennte nun ueberlegen, bestimmte Events (wie die, die den System-Channel nutzen) von der Ausfuehrung in "nicht Main-thread"-Threads auszuschliessen und sie doch der Queue zuzufuehren ... wird aber derzeit nirgends genutzt.
Durch den Umbau muss ich eh jeden Event "anschauen" und ueberpruefen, wo der genutzt wird - und ob die Nutzung dort rein informativ ist oder bspweise das direkte Abarbeiten noetig waere - oder gar eine Reaktion ("stoppen des Events" bzw "nein sagen" -> onTryDrag ...) erforderlich ist.
Deswegen habe ich temporaer noch den Plan, "TriggerNotificationEvent()" zu ermoeglichen - also das direkte Ausloesen einer Informationsaussendung. Stellen die dies erforderlich machen, wuerde man dann speziell nochmal anschauen muessen (wenn man die Funktion des direkten Triggerns dieser Events wieder entfernt). Eventuell koennen diese dann einen weiteren Eventtyp gebrauchen, oder eine andere Loesung (callbacks) ... Auf alle Faelle soll damit ein wenig die "direkte Kopplung" entfernt werden - und somit am Ende das Risiko fuer Deadlocks minimiert sein.
Frage zur Planung: dass etwas in Richtung Segmentation Fault und Deadlock gemacht werden muss, will ich nicht bestreiten. Ich frage mich nur, ob wir zunächst kleinere inhaltliche Tickets abarbeiten sollten... Das Grundsatzthema ist ja vorrangig durch die Schnellvorlauftests für die KI hochgekommen. Schnellvorlauf über mehrere Tage wird es im normalen Spielbetrieb ja aber selten geben. Und Absturzmeldungen gab es auch eher vereinzelt.
Nicht jeder meldet Fehler. Manche Fehler sind auch nur ersichtlich, wenn man drauf achtet, wie sich die Zuschauerzahlen verhalten usw. Sprich es wird haeufiger "geschehen" als wir denken.
Der "Schnellvorlauf" erzeugt einfach nur Kollisionen mit hoeherer Wahrscheinlichkeit - mit langsamen CPUs steigt die Wahrscheinlichkeit auch ohne Schnellvorlauf schon an.
Unabhaengig davon, hast Du natuerlich Recht, dass inhaltliche Tickets ebenso mit angegangen werden muessen - das Ueberarbeiten der Events hat schon hier und da kleine Unstimmigkeiten (long vs int) aufgezeigt - heisst groessere Baumassnahmen koennen auch kleinere Bugfixes hervorbringen.