Closed SuNzZeR closed 3 years ago
Hi, danke für die nützlichen daten. Aktuell funktioniert die Mod so das sie alle Fahrzeuge mit Fahrplan auf der karte in regelmäßigen Abständen überprüft. Es währe auf jedenfalls eleganter und Retouren schonender nur die Fahrzeuge im Bahnhof zu überprüfen, leider bietet das Spiel keine Möglichkeiten dies Ressourcen sparend abzufragen. Ich fürchte wir müssen da auf den guten willen von Urban Games hoffen das sie etwas derartiges in ihrer Mod API nachliefern
Könnte man sich da nicht selbst behelfen und sich die Zeit der letzten Prüfung abspeichern und zu Beginn der Prüfung abfragen:
[gespeicherte Zeit] + [Intervall] <= [aktuelle Zeit]
Es gibt bereits ein Mechanismus der pro game tick nur eine bestimmte Anzahl Fahrzeuge prüft. Das sollte eigentlich die Auslastung pro game tick konstant halten. Da gilt es eigentlich nur noch ein gutes balancing zu finden zwischen genug abfragen damit kein Zug verpasst wird aber so wenig wie möglich um die Performance nicht unnötig zu belasten. Mögliche Ansätze dafür wurden hier bereits bestrochen: https://github.com/IncredibleHannes/TPF2-Timetables/pull/8
@SuNzZeR Für wie viele Züge hast du einen Fahrplan aktiv?
Es sind 4 Linien mit ca. 9 Zügen aktiv.
Interessant bzw. kurios ist für mich jedoch, umso weiter weg ich von den aktiven Linien bin desto schlimmer wird es.
Ich habe gestern mal bisschen rumgebastelt. Die Timetable coroutine wird bei mir ca. 1250x in 1 Sekunde aufgerufen. Wie oft das guiUpdate pro Sekunde aufgerufen wird, wollte ich heute mal schauen 😅
Bei manche Routinen sollte man in Betracht ziehen, dass diese nicht "so oft wie möglich" laufen müssen.
Gestern erst hatte ich bei einem anderen Mod mal einen print reingeschrieben und war entsetzt, wie viele tausend mal es sich in die Log geschrieben hat - dabei sollte das Mod nur bei Laden des Spielstandes alle verfügbaren Industrien patchen...
Die Timetable coroutine wird bei mir ca. 1250x in 1 Sekunde aufgerufen.
Das würde ja bedeuten das die updateFn vom game 125x pro Sekunde aufgerufen wird? Wenn ich es von meinen Tests gestern Abend richtig in Errinerung habe, war es bei einem leeren (1 Linie, 2 Fahrzeuge) Savegame bei etwa 20x pro Sekunde (coroutine)
Es wäre wohl am sinnvollsten die Anzahl runs von den Anzahl Fahrzeugen mit Timetable abhängig zu machen. Aktuell ist z.B. die Verbesserung von mir bei einer Karte ohne das ein Fahrplan aktiviert ist sogar schlechter als vorher. Da in dem Fall dann 10x pro updateFN alle Fahrzeuge ausgelsen werden.
Ich poste mal später, was ich an der Timetable Coroutine geändert habe und die vorher/ nachher Log. Damit wurde es minimal besser und ich hatte nur noch zwischen 8 bis 27 Aufrufe/Sekunde. Und es wurden auch alle 9 Fahrzeuge geprüft.
Das war/ist nur rumgebastel was ich da treibe. Bin in lua nicht so fit 😅
Ich habe gestern mal bisschen rumgebastelt. Die Timetable coroutine wird bei mir ca. 1250x in 1 Sekunde aufgerufen. Wie oft das guiUpdate pro Sekunde aufgerufen wird, wollte ich heute mal schauen 😅
Ich habe festgestellt, dass es zu den 1250x Aufrufen gekommen ist, weil ich vergessen habe, meinen Counter zurückzusetzen nach dem print.
Ich habe nun auch rausgefunden, woran es bei mir an der Performance scheitert: game.interface.sendScriptEvent("timetableUpdate", "", timetable.getTimetableObject() )
Kommentiere ich das aus, läuft es wieder flüssig und die Process Commands sind auf einem normalem Niveau.
Mir ist klar, dass das benötigt wird, um die Fahrpläne zu aktualisieren.
Das guiUpdate wird bei mir ca. 60x/Sekunde ausgeführt (s. Bild). Dabei wird, soweit ich es richtig gesehen habe für alle Fahrpläne die Fahrzeugposition ermittelt.
Wäre das nicht eine Idee (sofern möglich), nur für den zum Zeitpunkt angezeigten Fahrplan die Fahrzeuge und die Position zu ermitteln? Bzw. wenn das Fenster nicht angezeigt wird, dass es gar nicht aktualisiert wird.
Hi, das event "timetable update" ist nur zur synchronisation zwischen GameTread (welcher den timetable durchsetzt) und dem UI Thread (Auf dem die Änderungen des timetables passieren) Das ist nicht sonderlich rechenaufwändig. Ich habe aber trotzdem probiert das Event nur bei tatsächlichen änderungen auszulösen, leider lässt dies das spiel abstürzen. Du hast aber natürlich recht, das muss nicht 60x die Sekunde passieren. https://github.com/IncredibleHannes/TPF2-Timetables/pull/38 Hier habe ich einen counter eingebaut der das Update alle 30 Frames macht. Das sollte häufig genug sein um auch bei niedrigen frameraten den timetable aktuell zu halten, aber 30x weniger as zuvor ;)
Ein kurzer Test auf meiner großen karte zeigt das der fix die Performance deutlich verbessert! Danke für deine detaillierte nachforschung!
Kein Problem :)
Ich habe eine ähnliche Lösung gebaut:
if clockstate and time then
if clockstate:getText() ~= os.date('%M:%S', time) then
print("Called timetableUpdate " .. os.date('%H:%M:%S', time) .. " OLD: " .. tostring(clockstate:getText()))
game.interface.sendScriptEvent("timetableUpdate", "", timetable.getTimetableObject() )
end
else
print("Called timetableUpdate " .. os.date('%H:%M:%S', time))
game.interface.sendScriptEvent("timetableUpdate", "", timetable.getTimetableObject() )
end
Aktualisiert es bei deiner Lösung die Position der Züge, während man sich die Linie anschaut? Weil bei mir ist das nicht der Fall. Ich weiß aber gar nicht mehr, ob das auch schon davor so war.
Nur so als kleiner Hinweis für den Test.
Ja wird auch mit https://github.com/IncredibleHannes/TPF2-Timetables/pull/38 wieder gefixed. Das muss mir irgendwann beim refactoring verloren gegangen sein
Mir ist heute leider aufgefallen, dass wenn umso mehr Linien einen aktiven Fahrplan haben desto schlechter wird die Game-Performance. Damit meine ich nicht die FPS sondern z. B. die Züge fangen an zu "ruckeln".
Ich habe paar mal die Zeit gemessen zwischen den Ingame Sekunden: ca. 3 Sekunden dauert 1 Sekunde.
Ich habe mal ein Bild angehängt, in dem man die Anzahl der Prozessbefehle vergleichen kann (links: ohne und recht: mit Mod).
Ich habe gesehen, dass im develop Branch paar Performanceoptimierungen dabei sind, jedoch beheben die meine Probleme nicht.
Ich weiß leider nicht wie oft die Linien und Züge auf deren Zustand geprüft werden, aber evtl. liegt es da dran (wenn sofort wieder neu geprüft wird nachdem die Prüfung durch ist). Wenn das das Problem wäre, würde es reichen, wenn die Prüfung ein Intervall (z. B. 1 Sekunde) bekommt.
An meinem Rechner kann es nicht liegen ;-)