Beiträge von eis_os

Zitat von Tom

@DarkMo, ich sehe wir stimmen im Prinzip überein, drücken uns nur unterschiedlich aus.

Was mich aber immer noch interessiert:
Gibt es einen Zusammenhang zwischen "hoher FPS" und "langem Ruckler". Warum, weshalb und wie auch immer...

Wenn ich keinen Post mit FPS-Angaben übersehen habe, haben wir hier mit 40-50 der eben solchen einen Spitzenreiten...

Zum Thema CPU Belastung und GPU, es gibt einen Grund für Mantel, Vulkan, DirectX12 usw., einfach gesagt, waren alle bisherigen Konzepte zur GPU hin, single-threaded.

Umso höher die FPS, umso flüssiger ist der Haupt-Thread.

Zur veranschaulichen rede ich mal in Ticks, eine feste Zeiteinheit und Haupt und Nebenthread, der für die Wegberechnung.

Ein Spiel Monat braucht 120 Ticks. Eine Nebenthread für den Monat 130 Ticks. Es fehlen 10 Ticks, also ist die Warte Zeit länger.
Im Fast Modus brauch der Monat nur noch 90Ticks, nun fehlen uns schon 40 Ticks.

So wenn jetzt der Monat gebremst wird. Sagen wir die GPU Leistung für den Hauptthread ist der limitierende Faktor:
Der Hauptthread braucht nun 150 Ticks für einen Monat, am Monatsende haben wir kein Problem, der Nebenthread ist fertig. (Kann man mit ProcessExplorer sehen).

Andere Probleme:
CPU Ram Anbindung für die Datenmenge zu schwach.
Beispiel:
Nebenthread hat nur 90 Ticks gebraucht,
120 Ticks Monat ist Fertig.
Nun kommt der Threadjoin, wir brauchen aber um die Daten zusammenzuführen 5Ticks, das Spiel bleibt trotzdem stehen!

Mikroruckler:
Der Hauptthread beschäftigt sich mit Passagieren beim Rendern oder für die Kollisionsabfrage für Passagiere.

Hoffe das Hilft bei verstehen der Komplexität.

Während eines Monatsende werden kommt es zu einem Thread Join, dabei wird nur ein Kern belastet und eine ganze Menge an Daten verschoben, die passen in keinen CPU Cache.
Microruckler sind ein Zeichen für zu viel Passagiere auf dem Screen

Kurz und knapp, alle Berechnungen auf X Threads müssen irgendwann wieder zueinanderfinden, sollte die Zeit reichen, ist es flüssig, sonst macht TF eine Gedenkpause.

Was macht TF Intern und warum es ruckelt

Zitat von Tom

Vermutung: Train Fever dürfte keine "gründliche" Buchführung über die Verwendung von Mods implementiert haben.
Da ein Mod beliebig oft in einem Spielstand gebaut/gekauft und wieder abgerissen/verkauft werden kann, müsste eine Referenzzählung über die Verwendung wachen. Ist der Refernzzähler auf 0, wird der Mod nicht (mehr) benutzt und kann entfernt werden. Das geht dann bei Mods, die wiederum auf anderen Mods basieren, weiter.

So eine Referenzzählung ist ein ständiger Hort von Programmiererfreuden in wie Memoryleaks, "use after free" etc., wenn man nicht aufpasst. Genutzt wird es z.Bsp. in Microsofts Component Object Model.
So etwas nachträglich und fehlerfrei einzubauen geht nicht zwischen Aufstehen und Zähneputzen...

Das kann man aber auch eleganter machen, zum Beispiel nur beim Laden wenn etwas vermisst wird. Wir bzw. Josef hat das für TTDPatch auch hin bekommen.
Das Problem ist das Train Fever leider nur eine einfache Liste macht. Sollte beim laden des Spielstands etwas nicht da sein, kommt die ganze Liste durcheinander -> Crash.
Lösung wäre da zum Beispiel ein Dummy. Für Strassen / Häuser wäre das sicher möglich. Für Stationen und Fahrzeuge eher nicht wenn es noch genutzt wird, für Häuser aber sehr wohl, auch Strassen und Brücken sollten da kein großes Problem darstellen, auch wenn Sie vielleicht komisch aussehen würden.

Mein Angebot steht noch immer, macht TF irgendwann Open Source (Nur Programm, keine Model/Grafik-Daten) und ich Bau das ein!
Zumindest war das bei den Savegame vergleichen der frühen Versionen, und da hat sich später (bis auf Komprimierung) nicht so viel geändert.

Zitat von Tom

@Xanos, im Prinzip hast Du ja recht und so würde ich es auch implementieren.
Aber man muss z.Bsp. bei Waggons im Depot und der automatischen Ersetzung jede einzelne Instanz des Mods hoch und wieder runter zählen.
Sicher ist das keine Raketentechnik, aber es nachträglich einzubauen an allen Stellen, wo Mods den Spielstand betreten und wieder verlassen können, bedarf etwas Zeit.

Das kann man beim Spielstand laden machen bzw. bei Veränderungen. Ich würde das während des Spiels nicht machen, das geht nur auf die Performance und ist Quark.
Und bevor hier wieder jemand meckert, ich kann auf eigene Referenzen verweisen: http://www.tt-wiki.net/wiki/GRFStatusWindow und das ist in Assembler geschrieben, also erzählt mir keiner was von schwierig

Zitat von Licaon

Jep, Gewichte wären generell was tolles. Erfordert dann aber auch einen neuen Lokparameter (Grenzlast) - wieviel man an die Lok anhängen darf. Damit müsste man sich auch beim Lokkauf viel mehr Gedanken machen.

Frage ist, was passiert, wenn man sich nicht daran hält. Zughakenrisse kann man ja schwer simulieren.

TTDPatch + DBSetXL hat einfach den Zug elend langsam gemacht, dann dauert es eben 5min um den Zug in das nächste Depot zu bewegen

Ob IBM Produkte wie OS/2 die bessere alternative wäre

Ich kann mich dunkel an Config Dateien editieren für die Installation mit CD Rom Treiber erinnern, wenn es nicht funktioniert hat, hat das OS/2 Setup sich selber nicht mehr gefunden.
Die Dumps (Bluescreens) waren auch nicht der Hit. PPP und TCP IP ist mir auch in schlechter Erinnerung geblieben. GEM war leider keine Zukunft gegönnt.

Zitat von eis_os

Das scheint ne OEM Version von DoNotSpy (aber ohne OpenCandy Drive By Download Kram ) zu sein. Man meckert über undurchsichtige Lizenzen von MS, aber bietet den Nutzer eine Englische Lizenz des Entwicklers an bei einem Tool einer deutschen Zeitung?

Zitat von mediziner

Wie kann man ein Programm zum Schutz der Privatsphäre empfehlen, daß standardmäßig Malware mit installiert?

Dann kann man mit der nächsten News vor OpenCandy schützen

Vielleicht geht es ja bald wieder los mit jedem Heft, die tausend besten Windows Tips&Tricks, und bei Tip 1001 läuft Windows garantiert nicht mehr.

PS: Wer Win7/8.1 nutzt sollte die "neuen" Telemetrie Updates auch nicht installieren...

Warum? Also wir installieren gerne Debian/Suse/*buntu auf einen neuen PC.
Ein KUbuntu ist vorinstalliert auf dem PC. Für Server gibt es auch Gentoo und *Bsd Minimalsysteme - ja die Installation kostet Zeit, also ist es nicht umsonst und schlägt sich im PC Preis nieder.

Eine saubere Windows Installation kostet aber auch Zeit sowie die Lizenz.

Randbemerkung: Die meisten Linux Nutzer sind unzufrieden wenn Sie nach X Jahren neue Software installieren wollen und nie ein Distributionsupdate gemacht haben, die Installationen laufen aber meisten immer noch anstandslos. Dieses einen Kunden verständlich zu machen ist etwas schwer. Da ist ein kaputtes Windows echt einfacher

Man spart sich einfach die Supportkosten für mehrere Entwicklungszweige. Das hatten wir ja schon mit Win8 zu Win8.1.

Ich sag mal so, ich verbinde diese Zeitung nicht mit Qualitätsjournalismus.*
Tools gibt es zu Hauf um den Telemetrie Dienst abzuschalten/entfernen, das Suchfeld und die Live Kacheln telefonieren aber trotzdem gerne nach Hause.

-edit-
Das scheint ne OEM Version von DoNotSpy (aber ohne OpenCandy Drive By Download Kram ) zu sein. Man meckert über undurchsichtige Lizenzen von MS, aber bietet den Nutzer eine Englische Lizenz des Entwicklers an bei einem Tool einer deutschen Zeitung?

Unsere Windows 10 Maschinen stehen im Testnetzwerk und bleiben auch dort erst mal. Und Windows 10 gibt es nur bei ausdrücklichen Kundenwunsch.

Und es gibt genügend Updates, die nicht richtig funktionieren.*
Aber meinetwegen installiert alle das Update, man soll ja über zusätzliche Arbeit nicht meckern.

*Viele Windows 8.1/7 Maschinen haben aber schon (Betriebssystem) Fehler, da hat man dann mit einer Kette von Fehlern zu tun und mit Win10 fällt dann alles zusammen.

Zu Thema Pfade:
Ich hab das Plugin im März das letzte mal geladen. (Noch ohne Änderungen durch Merk am Property System)

Sollte es daher Probleme geben, bitte ich erst mal einen TF Bahnhof, zum Beispiel den kleine Busbahnhof bzw. Trambahnhof in Blender zu importieren.
Im Endeffekt ist alles eine 1 zu 1 Ansicht zu den Daten in der Lua Datei.

Describing the contents and paths of the Small Cargo Station

Die GOG Version beinhaltet bei mir gar keine Mods.
Aber wie gesagt, der Fehler tritt erst viel später auf, ein Savegame hier brauchte so 10 Minuten im Hintergrund bis der Fehler auftrat.

Wenn ich viele Strassen im Pausenmodus bei einem neuen Spiel abreiße kann ich den crash nach ca. 2 Minuten forcieren.
Wir reden hier auch immer von der letzten TF Version, ältere hatten dieses Problem nie. Eine andere Lösung wäre irgendwie dem Spiel beizubringen das ein Savegame vor den Hauptstrassen-Feature erstellt wurde. Diesen Schalter hab ich aber nicht gefunden

Nein, es wurde wohl die Berechnung der Städte in einen Thread verlagert. Somit kommt es zum Crash wenn eine Hauptstrasse abhanden kommt.

Die GOG Version ist nicht anders als die Steam Version, sie liegt nur wo anders auf der Platte. Bei der GOG Version, dahin wo Du Train Fever installiert hast.
(Sonst Rechte Maustaste auf die Verknüpfung -> Eigenschaften -> Dateipfad öffnen) Die Spielstände sind in AppData

Faustregel, erst mal ein Backup des Spielverzeichnis. (dort sind die Ordner res, dlcs, mods und die Train Fever.exe drin)

Auf die schnelle:
"Neue" Mods kommen in mods. Dort wird im Zip ein Verzeichnis liegen, in diesem ist eine info.lua. Da kommt das komplette Verzeichnis (namen_irgendetwas_zahl) in das mods Verzeichnis.
"Alte" Mods: Im res Ordner, meistens ist einfach ein res Ordner im Zip, da muss der Inhalt des res Ordners dann einfach in den Spielordner res kopiert werden.

Theoretisch sollten auch die Mod Manager laufen und den Pfad zu Train Fever einfach anpassen.

Der Kontakt mit Stepke ist irgendwie abgerissen... Ich hab, hatte? da zwei mögliche Szenarien auf dem "Papier" um dies zu ermöglichen.

Aber er sucht ja jemanden hier:
Programmierer gesucht mit WBB Kenntnisse

Wenn Du dich schon mal bei citiesinmotion.net registriert hast, kannst Du diese Daten nutzen...

Auch die GOG Version hat das selbe Problem und beinhaltet leider auch keine Debugdaten um den Grund herauszufinden...

Irgendwo berechnet TF nun Straßenerweiterungen, daraus resultiert das Problem und eine einfache Lösung sehe ich da nicht. Ich hoffe die GOG Version beinhaltet ein paar Debugdaten oder lässt es zu einen Debugger zu nutzen. Bis dahin könnte theoretisch ein Speichern-Ladezyklus helfen, aber das ist von mir nicht getestet.

Ich hab ein neues US Spiel gestartet, keine Probleme. Weder im Pausen Modus noch beim weiteren Monatswechsel, sowohl in leicht auch in schwer.

-edit-
Nach ca. 30 Minuten im Hintergrund hat er den Crash auch gezeigt, hmm

-edit2-
Ich hab jetzt keine weiteren Ideen, dafür müsste ich TF total auseinander nehmen, mal schauen ob ich mir nächste Woche eine GOG Version zulege.

Hat die Stadt gar keine Außenverbindungen mehr?

d:\urban\steam_build_x64\release\src\game\urbansim\simulation_util.cpp:86: simulation_util::UpgradeTownCountryStreets::<lambda_4c59cbfb7e759ce0d7fadc4bfe0e4c9e>::operator (): Assertion `time > .0f' failed.

Das sieht sehr danach aus das die Zeit scheinbar rechnerisch nahe 0 liegt (bzw. als float =< 0 bedeutet) und TF daher abbrechen will. Dieses Problem hatten wir definitiv früher nicht, da wird wohl UG uns weg optimiert haben?

Und mit Steam kann ich keinen Debugger ansetzen und schauen ob man das einfach übergehen kann.

Wenn es wieder passiert bitte ich um weitere Testproben der std*.txt, hilfreich, war es die letzte Strassenanbindung, ist es knapp am Monatsende?

Das klingt sehr interessant, vielleicht kann man dort einen Debugger ohne Probleme anklemmen