Beiträge von VacuumTube

Der FPS Monitor misst auch die Simulationsperformance, ich hätte es nach dieser Ergänzung umbennen können. Die Simulation ist in der Theorie unabhängig von den FPS, richtig. Der Ansatz ist, sich im ausgelasteten Simulationszustand (8x) die vergangenge Zeit für die update Ticks anzuschauen und mit der normalen Zeit für Echtzeitdarstellung (5ticks/sec bei 1x) zu vergleichen. Also 100% wenn die Berechnungen hinterherkommen und sonst weniger, das ist der Wert für die Sim Performance. Mehr Infos bei FPS Monitor oder dem verlinkten Beitrag Simulationsperformance zu den Diagrammen.

VRAM nimmt jetzt auch nicht ständig wieder ab, bleibt konstant, aber ich glaub vor dem Update höher. Von 6,8GB Texturen entfallen 4,9 auf terrain

Was die Ruckler angeht: Bei größenwahnsinnigen Maps mit aktiviertem NEP (oder erhöhter Renderdistanz) wird das besonders deutlich. Das war früher einfach flüssiger.

https://steamcommunity.com/gro…ns/7/3788128618784317059/

kommt ja drauf an auf welcher Platte das user Verzechnis ist, wo die savegames liegen

in die entsprechende .con datei gehen und schauen wo steht result.cost = 10 und das auskommentieren mit --

Die Idee ist nicht neu: "Überwachungskameras / Webcams"

Wenn sich noch nichts geändert hat, sind cameraViews für Assets/Konstruktionen nicht möglich.

Was modbar ist, wäre eine Liste von abspeicherbaren Kamera Positionen, die man per Klick rreicht. Dabei ist man aber auf die normale Spielkamera beschränkt, d.h. man kann nicht so nah ran, nicht in den Untergrund und FOV ist nicht änderbar. Im Prinzip bräuchte es eine bessere Version des Kameratool.

Dass Ladezeiten und Savegamedateigröße verbessert wurden habe ich gelesen, aber das war für mich nicht wichtig. Ladezeiten sind kein Problem mehr seit ich eine NVME SSD hab. Der Fokus des Tests war auf die reine Performance im laufenden Spiel.

Ich wollte ein paar unterschiedliche Szenen testen (Blick über Karte, auf Stadt, auf mit Mods bebauten Bahnhof), da die GPU meist in diesen Ansichten viel zu tun hat. Wenn man nah ranzoomt, wo nur wenige Objekte sind, sind die FPS meist kein Problem.

Offensichtlich wurde die Mindestgröße entfernt und es ist jetzt nur so groß wie nötig. Wenns gar keine Parameter gibt, siehts noch komischer aus. Aber ist wahrscheinlich Gewöhnungssache.

Mit dem Update gibts endlich mehr Fehlerinformationen, hatte ich vorher nicht selbst so bekommen:

urban_games/train_fever/src/Lib/UI/Component.cpp:1819: void __cdecl UI::CComponent::RemoveChild(class UI::CComponent *): Assertion `!m_childMutex' failed.

Bringt mir das jetzt was....

Ich hab nachgeschaut, menu.construction tabWidget.currentChanged ist das einzige Event was passiert, sowohl bei X als auch mit ESC

Destroy toolbutton  guiHandleEvent:  menu.construction    tabWidget.currentChanged    {
  id = "menu.construction.terrain",
  index = 4,
}
Destroy toolbutton  guiHandleEvent:  menu.construction    tabWidget.currentChanged    {
  index = -1,
}
urban_games/train_fever/src/Lib/UI/Component.cpp:1819: void __cdecl UI::CComponent::RemoveChild(class UI::CComponent *): Assertion `!m_childMutex' failed.
Additional info extracted from the previous state:
GC Called
Destroying failback ui done
Uncaught exception while in class UI::CSelector
End of redirect Buffer to StdOutBuffer
Restoring as we are still responsible for stdout
End of redirect Buffer to StdOutBuffer: done
Exception type: Lua exception

This error is usually caused by modding. Some game resources contain incorrect data.

Details:

Error message: 

File name: C:/Program Files (x86)/Steam/userdata/382485722/1066780/local/staging_area/Build_with_collision_1/res/config/game_script/build_with_collision.lua

Key: game/res/gameScript/build_with_collision.lua_guiHandleEvent

Minidump: C:/Program Files (x86)/Steam/userdata/382485722/1066780/local/crash_dump/cbf09f22-6bf9-485a-95ad-50ec31542731.dmp

UI Component Hierarchy: 
 type: class UI::ToggleButton, id = "menu.construction.terrain", name = "ConstructionMenuIndicator", styleClasses = {}
 type: class UI::TabWidget, id = "menu.construction", name = "TabWidget", styleClasses = {}
 type: class UI::CComponent, id = "menu", name = "wrap", styleClasses = {}
 type: class UI::CComponent, id = "mainMenuTopBarBG", name = "wrap", styleClasses = {}
 type: class UI::CComponent, id = "", name = "UI_root", styleClasses = {}
 type: class UI::CComponent, id = "", name = "RendererComponent::Layer2", styleClasses = {}
 type: class UI::CRendererComponent, id = "mainView", name = "RendererComponent", styleClasses = {"action-constructionbuilder"}
 type: class UI::CGameUI, id = "", name = "CGameUI", styleClasses = {"top-gamebar-visible"}
 type: class UI::CMenuUI, id = "", name = "MenuUI", styleClasses = {}
 type: class UI::CComponent, id = "", name = "wrap", styleClasses = {"platform-desktop", "ui-classic", "input-mouse", "gamepad-type-xbox"}

I dont quite understand your message...

I had to compress the screenshots to jpg because only files <1MB are allowed here, unfortunately.

The gpu timings are flickering very much and I know the FPS value there is not in line with the (correct) value of the steam overlay FPS. In the screenshots it is also lower than in the table because the debug windows have impact on the FPS.

...also gut, hab erneut gemessen.

Kann jetzt keine wirklich Verbesserung sehen. Kein Witz, aber bei game3 ist es wieder schlechter. Hab zwei mal gemessen. Naja, vielleicht ein Sonderfall.

Lade Further Render Distance nach NEP, da kannste dir es jeweils für Geometrie Niedrig/Mittel/Hoch einstellen

Laut den Release Notes wurde im kommenden Spielupdate sowohl die Performance der Simulation als auch des Renderings verbessert. Ich wollte wissen, wieviel sich die Performance wirklich geändert hat. Dazu habe ich mithilfe von FPS Monitor die FPS und die Simulationsperformance gemessen.

Ich habe 4 verschiedene Savegames getestet:

1. Vanilla Spiel (mittel) mit nicht zu großen Städten, Blick auf Stadt
2. Sehr große Desert Karte, geringe Baudichte, weiter Blick über die Karte
3. Größenwahnsinnige Karte, Blick auf dichte Bebauung mit einigen Mods
4. Savegame von Marcolino26 mit großen Städten (Vanilla Stadtgebäude) und hoher Simulationslast (27k Einwohner)

• Für die ersten beiden Savegames ist eine Performanceveränderung nicht wirklich erkennbar. Bei game2 deutet sich sogar eine minimale Verschlechterung an, was aber sehr nahe an der Messungenauigkeitsschwelle liegt.
• Beim Savegame 3 mit größter Karte und Blick auf Szene mit einigen Mods zeigt sich eine deutliche Verbesserung der FPS und leichte Verbesserung der Simulation
• Beim 4. Savegame sind die FPS minimal besser, während die Simulationsperformance praktisch gleich bleibt
• Neben diesen statischen Messungen der Performance ist aber auch die Flüssigkeit beim Bewegen auf der Karte ("dynamische Grafikperformance") für das Spielerlebnis sehr wichtig. Das lässt sich nicht so einfach messen. Bei game1+2 war alles flüssig. Bei game3 (vmtl. voller Grafikspeicher) war mein subjektives Erlebnis allerdings, dass die auftretenden Ruckler in der neuen Spielversion etwas stärker und häufiger waren, auch nach mehrmaligem Überfliegen der Karte.

Fazit:

• Die Veränderungen der Performance hängen stark vom Savegame ab (Ausbau, Mods, Einwohneranzahl)
• Im Allgemeinen profitieren besonders Savegames mit vielen Mods von einer FPS Zunahme bei konstanter Ansicht ("statische Grafikperformance")
• Die Simulationsperformance hat sich leider nur marginal verbessert
• Interessanterweise hat sich gerade für Vanilla die Performance weniger bis nicht verbessert, wo das doch der Fokus für die Konsolenvarianten sein sollte. Anhand der Draw Calls sieht man, dass sich die Vertices/Tris nicht erkennbar verringert haben. Viele Vanilla Modelle hätten eigentlich mal eine Optimierung der Lods gebraucht - anscheinend wurden wirklich nur die Fahrzeuge optimiert. Die Hecke (hedge_m) hat bei game1 sagenhafte 14%, bei game2 verbraucht eine einzelner Steintyp 177k vertices, obwohl höchstens Punkte sichtbar sind. Wie man am 4. savegame sieht, sind die Stadtgebäude immer noch ein FPS Killer.
• Der Grafikspeicher hat sich laut Diagrammen zahlenmäßig verringert (was für die Konsolen wahrscheinlich nötig war). Als PC Spieler ist mir die Auslastung allerdings ziemlich egal, denn am Ende zählt nur wie flüssig das Spiel läuft. Daher befürchte ich dass die Speicheroptimierung leicht zu Lasten der dynamischen Grafikperformance (also Ruckler beim Bewegen der Karte) geht.

Zitat von Feluno

dass die Screenshots auch nicht von einer Steamseite gehostet werden, stattdessen versucht die Seite offiziell zu klingen.

Hoffe ich hab jetzt keinen Buchstabendreher übersehen, aber das ist die ganz normale Hosting Seite für Steam bilder

https://steamuserimages-a.akam…6FFBD4FA34813CFA5964903B/

Völlig egal was da steht -0 macht keinen Syntax Fehler. Kannst auch schreiben sum = iljhashdfiuhasjhdbas

Ja Lua ist etwas eigen.

Also eigentlich ist es ja ein Problem im serializer

Danke für den Tipp, das kann sein, dass es zu schnell doppelt gelöscht wird.

Wobei ich eigentlich vor dem löschen natürlich folgendes checke:

local elem = api.gui.util.getById(tb.id)
if elem then
...

Die Events auf die zum Ausblenden gehört wird sind:

elseif (id=="menu.construction.railmenu" and name=="visibilityChange" and param==false) or
            (id=="menu.construction.roadmenu" and name=="visibilityChange" and param==false) or
            (id=="menu.construction.rail.tabs" and name=="tabWidget.currentChanged") or
            (id=="menu.construction.road.tabs" and name=="tabWidget.currentChanged") or
            (id=="menu.construction.terrain.tabs" and name=="tabWidget.currentChanged") or
            (id=="menu.construction" and name=="tabWidget.currentChanged") or
            (id=="menu.bulldozer" and name=="toggleButton.toggle")

sonst würde der Button noch dauerhaft angezeigt werden.

Es wird auch destroy aufgerufen wenn die collision im proposal wieder verschwindet. Aber auch hier wird direkt elem:destroy() aufgerufen, und nicht api.gui.util.destroyLater(elem) was nur beim onClick auf den Button benutzt werden muss. Ein Fehler wegen der gleichzeitigen Nutzung dieser 2 destroy Methoden kann es also auch nicht sein.

Zitat von Carbonunit

Advanced Statistics habe ich jetzt auch, da kann ich dann den Kreis über die Karte bewegen und es zeigt mir an, ob in dem Kreis ein Wohnhaus ist. Oder wie geht das sonst damit nach bewohnten Häusern zu suchen?

Townbuildings sind nur die vom Spiel gebauten Stadtgebäude. Auf constructions sieht man die Personenkapazitäten von allen Objekten.

Ne das Bauen kann ja nur durch den Klick auf den Button ausgelöst werden. Wenn man bei Collision aufs Terrain klickt, kann man soviel klicken wie man will, es passiert nichts.

Es wird auf eine Reihe von Events gehört, die andeuten, dass das Menü gewechselt oder ausgeblendet wird. Darauf hin soll der Button wieder entfernt werden. Das klappt in allen anderen Fällen wunderbar, nur bei dem X crasht es ohne Fehlermeldung.

Ja genau. Ich habe bisher weder eine Erklärung noch eine Lösung dafür.

UG ist informiert. Keine Rückmeldung bisher. Ich weiß nicht ob das bis nächste Woche noch was wird.

Solange die v1.2 nutzen.

---> Build with Collision

Zitat von eis_os

Ich würde sagen TPF2 kann kein min = inf, laden

"inf" ist kein Problem. Das wäre schon viel früher aufgefallen, so oft wie das vorkommt. Abgesehen davon dass es math.inf sein müsste und inf=nil ist.

Das Problem ist "-nan(ind)" (der Lua Wert für NaN) , ebenso "-inf"

Es geht ja hier um Advanced Statistics

data = {...
    town = {...
        TrafficRatings = {
                    av = -nan(ind),
                    max = 0.98568439483643,
                    min = 0.94183653593063,
                    num = 5,
                    sum = -nan(ind),
                },

ich hab mich natürlich bei der Entwicklung schon damit rumgeschlagen, als es das erste mal auftrat und ich natürlich erstmal keine Ahnung hatte wo das Problem ist. Ja ich habe 0/0 geteilt, passiert halt bei einem Durchschnitt, wenn n=0... Ich habe dann natürlich Vorkehrungen getroffen, dass das vermieden wird.

Sooo warum passiert das jetzt hier trotzdem.....

Bei einer Stadt ist das TrafficRating unerwarteterweise -nan(ind). Davon kann man nun wirklich nicht ausgehen. Vor allem, da das vorher nie aufgetreten ist.

Vorübergehender Fix: Die sav.lua löschen, wenn du keine Mod hast die da was wichtiges reinschreibt (wie zB Timetables; bei Adv.stats sind es nur die Einstellungen). Oder besser: die -nan(ind) einfach mit 0 ersetzen. Die Daten werden nicht gebraucht, sondern nächstes mal neu berechnet. Oder noch besser, mir fällt grad ein, ich hatte mal ein Button "Free data" gebaut, um eben die ganzen daten vom state zu löschen.

BITTE AN UG

Das Spiel muss endlich robuster werden. Es muss doch in euerm Interesse sein, dass gerade Fehler, die nicht sofort einer Mod zugewiesen werden können, besonders kritisch sind?

Nicht jeder Modder kann jetzt anfangen nochmal seinen state Inhalt zu überprüfen, ob da zufällig doch -nan(ind) drin steht, weil die api unerwartet diesen Wert ausgibt.

Vorschlag: Entweder kann -nan(ind) und -inf vom state file problemlos eingelesen werden oder es wird ein Fehler geworfen wenn state in save() diese problematischen Werte enthält (für userdata klappt das ja auch)

Zitat von Carbonunit

Das könnte der volle Grafikspeicher sein

Hat nichts mit der hohen SImulationslast zu tun

Zitat von Carbonunit

selbstgesetzten Asset-Häuser sitzen immer noch Sims, schade, dass man die nur selbst durch Draufklicken suchen kann.

kann man auch mithilfe Advanced Statistics

Zitat von Carbonunit

zwei Remote Airfields mit tausenden Bewohnern

soviele sollte man vermeiden. Vor allem Residential. Ich überlege grad, ich glaub es müsste für die Berechnungen besser sein, wenn hohe Kapazitäten eher zentral liegen als abgeschieden. Weil die Wegsuche beginnt bei Residential. Versuch mal die remote Kapazitäten auf Com/Ind zu setzen.

Zitat von VECtron2017

Freestyle Industries

Genau die haben letztens bei einem andern auch zu Problemen geführt. Auch die Anzahl der Güter"Sims" ist wichtig. Gibt leider einige Industriemods mit übertriebenen Produktionswerten - das schadet der Performance!