Beiträge von VacuumTube

Technisch wird die Datei natürlich nicht wortwörtlich überschrieben, sondern es wird die alte gelöscht und eine neue erstellt. Daher könnten Dateiwiederherstellungstools wie Recuva helfen.

EDIT: Es gibt natürlich keine Garantie, dass eine Datei wiederhergestellt werden kann. Je mehr Aktivität auf dem Laufwerk, desto mehr sinkt die Chance.

Autobahn_Kreuz_1

Ich habe für mich noch bei den Abfahrten und den Verbindungsstücken die Straßenlänge verkürzt, um mehr Spielraum zum Verbinden zu haben. Das war etwas Fummelei mit den Tangenten. Und ging auch nur begrenzt - bis zum Teil, der als Modell abgebildet ist.

ich hätte jetzt auch vermutet, dass es sich um ein nie umgesetztes Feature handelt. Sonst hätte man das ja promotet.

Es wurden ja einige Sachen von Cities Skylines abgeschaut, und so hatte man wahrscheinlich (parallel zum Ampel Feature) auch überlegt eine Vorfahrtfunktion wie bei CS zu implementieren.

Hier ist der Übeltäter

frage mich trotzdem, wie sowas passieren kann... da muss ja eigentlich mal eine Mod in der Richtung aktiv gewesen sein

Gebäude wurde vor ca 16h gebaut

Tom hat mir den Spielstand zur Analyse geschickt. Ich habe mal ein paar prints eingefügt, um zu schauen was falsch läuft.

Ich kann es kaum glauben, was hier passiert:

Normalerweise sieht ein Update eines Townbuildings so aus:

TownBuilding Update:  "res/construction/building/era_b/res_1_1x2_02.con"
{
  capacity = 1,
  cargoTypes = { },
  depth = 20,
  parcelFace = {
    { -4.263671875, 0, 0, },
    { 4.263671875, 0, 0, },
    { 4.643798828125, 15.9951171875, 0, },
    { -4.642333984375, 15.99609375, 0, },
  },
  seed = -4332,
  state = {...

Wenn dann der Fehler auftritt, weil das "capacity" feld der params fehlt, sieht es so aus:

TownBuilding Update:  "res/construction/building/era_b/res_1_1x2_02.con"
{
  capacidy = 1,
  cargoTypes = { },
  depth = 20,
  parcelFace = {

Ja richtig, da steht "capacidy"

Aber das komische ist die Frage, wann das auftritt und ob Tom offenbar der erste ist bei dem das auffällt. Eventuell kam der Bug durch das letzte Update rein. Keine Ahnung ob UG das bekannt ist.

van Dusen hast du mal die Renderdistanz auf Vanilla Niveau zurückgestellt? Geht auch präziser mit NEP Addon (for Natural Environment Professional)

Das capacity field in den params wird vom Spiel der updateFn Funktion bei dem Update eines Gebäudes übergeben. D.h. die Infos sind in dem Spielstand enthalten. Die capacity ist nämlich variabel und nicht für ein Gebäude konstant. Es ist sehr komisch, dass das nil ist.

Ich habe nichts auffälliges in der Modliste gefunden? War vorher eine Mod in diesem Bereich aktiv, die kürzlich entfernt wurde?

Population Faktor ist eine der Mods, die die updateFn von Stadtgebäuden modifizieren. Darüber könnte man das/die problematischen Gebäude finden und abreißen oder den Fehler anders umgehen.

Hm das ist schade, v.a. weil ich schon manche Straßen dieser Mod nutze und auch der Splitter praktisch ist...

Aber sollte es dann nicht reichen, in seiner mod.lua

postRunFnUtils.hideAllTramTracksStreets()

auszukommentieren?

Hab ich jetzt noch nicht so beobachtet.

Bei welchen Werten tritt das denn auf?

Bei 1 wie hier nicht, zumindest mit der damaligen version.

Theoretisch sollte AccelerationFactor keinen Einfluss auf Bremsvorgänge haben.

BTW: Wenn du AccelerationFactor verringerst, fehlt deinen Zügen bei hohen Geschwindigkeiten die Leistung. Eine Alternative sind unsichtbare Waggons, die Gewicht mitbringen, um die Beschleunigung beim Anfahren zu begrenzen.

Normale Mods ja, CommonAPI nicht

RAM mind. 32 GB

Maps sind i.A. übertragbar, die Mods müssen aber alle gefunden werden und in derselben Reihenfolge bleiben.

Spielereigentum verhindert nicht Häuser, sondern KI Straßenbau.

No Town Development funktioniert bei zahlreichen Spielern.

Bei gerade neu generierten Städten einmal speichern und neu laden.

Ja halt eben nicht. Das kann auf jedem PC genauso auftreten.

Solange wir seine Map nicht kennen, können wir nichts genaueres sagen. Am besten wäre es halt, wenn man dieselbe Map auf andere Hardware laufen lässt und einen Performance Vergleich macht.

Mal wieder eine typische Hardware Diskussion, die an den TPF2 Problemen vorbei geht.

Allein dass solche Ruckler bei jedem vorkommen können, egal ob PC oder Laptop zeigt, dass es kein spezifisches Hardwareproblem ist.

Wenn die Last unregelmäßig ist (was bei der TPF2 Engine leider der Fall ist), ist auch die Performance unregelmäßig und es kommt zu Rucklern.

"Drop detected(script)" heißt dabei, dass der Simulationschritt im Script/Engine Thread länger dauert als erwartet (normal 0.2s) und in der Folge die Simulation kurz einfriert. Das kann man auch mit den Debug Tools analysieren (hier das untere Diagram)

Da du in deinem Savegame mit deinem System offenbar an diese Grenze kommst, sollte man sich Gegenmaßnahmen überlegen, die Script Performance in den Griff zu bekommen. Einige Tipps und Vermutungen sind hier im Forum verstreut, eine gute Anleitung gibt es leider nicht. Einwohner reduzieren ist eine Sache, aber es kommt auch auf die Verteilung der Kapazitäten (mit Straßenanschluss), Komplexität des Straßennetz, Geschwindigkeit Straßen und verfügbarer Autos an und auch Güterproduktion spielt eine Rolle für die Simulation. Kannst ja mal dein Savegame verlinken.

https://www.transportfever2.co…p?id=gamemanual:updates&s[]=build

Die Güternachfrage geht immer nur von Industrie zu Industrie/Endverbraucher und hängt von der Produktion der nachfolgenden Industrie ab. Es könnte also helfen, mit dem Sandbox nachzuhelfen und manuell die Produktion der Raffinerie zu erhöhen.

Das stimmt nicht ganz, denn Straßen werden sogar grundsätzlich vorzugsweise mit einer Querneigung geplant, sodass Regenwasser abließen kann

https://de.wikipedia.org/wiki/Querneigung

Die erzwungene Ebene macht schöne Kreuzungen im Spiel leider oft nicht gerade einfach.

Hier halte ich mal einen seltsames Verhalten der UG ingame Konsole fest, das andere Modder vielleicht Nerven erspart. Ich habe das Problem bereits im Mai 2024 erkannt und an UG gemeldet. Leider wurde versäumt, dieses im letzten Update zu fixen.

Folgendes Verhalten:

Ruft man eine Lua Funktion in der Konsole auf und tritt dort irgendwo ein Fehler auf, so versucht die Konsolenausführung die Funktion ein zweites Mal aufzurufen.

Beispiel:

>> x = 0
>> function f() x=x+1; print(x); assert(not twice, "Dont call me twice!"); twice=true; y=0+nil; end
>> f()
error: [...]:1: Dont call me twice!
stack traceback:
=[C](-1): ?
=[C](-1): assert
...
f()(1): ?
1
2

Das mag in den meisten Fällen nicht weiter auffallen. Aber in manchen Fällen, ist es ein Problem, wenn eine Funktion öfter aufgerufen wird, als erwartet. Ganz im Ernst, wer würde sowas erwarten? Da muss man beim Debugging erstmal daruf kommen.

Hintergrund:

Bei OSM Importer wird ein Schritt in der Konsole gestartet und das soll nicht mehr als einmal ausgeführt werden. Ruft man die Funktion ein zweites Mal auf, wird ein bewusster Error (assert) erzeugt, um undurchsichtige Folgefehler zu vermeiden. Durch dieses Verhalten wird jedoch der eigentliche Fehler verschleiert und es wird nur ein Error angezeigt, der durch das 2fache Aufrufen entsteht. Das macht die Fehlersuche natürlich deutlich schwieriger.

Und wenn man denkt, alle Fehler sind jetzt raus, kommt natürlich doch immer noch was, vor kurzem hier: https://github.com/Vacuum-Tube/OSM-TPF2-Importer/issues/7

Urban Games (Martin Hodler) schrieb dazu:

Zitat

Es handelt sich bei diesem komischen Verhalten um die Implementation welche Informationen für die Autocompletion sammelt. Damit die Konsole z.B. f().foo vorschlagen kann wird Funktion ausgewertet. Bei einem Fehler verhält sich diese Implementation jedoch nicht sauber.
Wir nehmen das Problem bei uns auf die Liste. Leider kann ich dir aufgrund von Prioritäten und anderen Tasks nicht garantieren ob und wann dies angegangen wird.

Was ich etwas komisch finde, da mir nicht bekannt ist, dass Autocompletion hinter Funktionen stattfindet.

Workaround:

Allerdings habe ich gerade auch einen Workaround herausgefunden. Der Bug tritt nicht auf, wenn man mehr als eine Lua Anweisung gleichzeitig ausführt. Also zB

asdf=1; foo()

oder mehrere Linien Code in die Konsole kopiert.

Celmi ist schon seit Mitte 2021 nicht mehr für TPF2 aktiv. Bei dem Steam Eintrag "Fahrpläne 1.3" ist Gregory365 der Hauptautor, auch wenn Celmi in der Autorenliste oben steht. Nur der Hauptautor kann bei Steam Updates hochladen.

Gregory365 scheint also aktiv zu sein und sein Github Repo ist der einzige aktive Fork. Daher wäre es sinnvoll, Diskussionen und Fixes dort zu platzieren.

MarkMcWire Schön, dass du die Mod verbessert hast. Wenn du das Interesse hast, dich mit Github zu beschäftigen, damit deine Änderungen nachhaltig für alle zur Verfügung stehen, wäre es schön wenn du die Änderungen dort einbringst. Dazu musst du einen Fork von dem Repo erstellen, dann deine Änderungen auf Basis der aktuellsten Version comitten, und einen Pull Request zum originalen Repo erstellen. Bei Fragen zu Git, schreib mir gerne.

Zitat von WernerK

Vielleicht ist das der Nachteil des gitHub-Konzeptes: Du bist gezwungen, fremden Code, in den du dich mühsam einarbeiten musst, zu übernehmen, weiterzuentwickeln und vor allem zu pflegen.

Nur weil man etwas auf Github stellt, "muss" man es nicht maintainen - siehe Celmi.

Einarbeitung in fremden Code ist immer anstrengend, aber am Ende ist es doch besser wenn alle an einer Sache gemeinschaftlich arbeiten, als wenn es 20 verschiedene zip files irgendwo gibt und man nicht sehen kann, wo die Unterschiede sind. Wenn man alleine arbeitet, kann man Versionskontrolle vielleicht noch gerade so selbst managen, aber bei kollaborativem Arbeiten liegen die Vorteile von Github auf der Hand. Man kann alle Änderungen auf einen Blick nachverfolgen und kontrollieren. Und solange der Owner mitspielt, fließen Erweiterungen von anderen direkt ins Hauptprojekt ein, wovon alle profitieren, die Änderungen auch beim nächsten Update noch drin sind, und sich nicht die Frage stellt, wo kann/darf ich das als separate Version hochladen.

Zitat von MarkMcWire

Ich habe eine Lösung gefunden. Ich habe das Script res/config/game_script/timetable_gui.lua in zwei Dateien aufgeteilt. Die original-Datei verwaltet nur noch das Interface und dessen Eingaben.
Das neue Script res/config/game_script/timetable_engine.lua verwaltet die Ausführung des Fahrplans und die Steuerung der Züge.

Das finde ich interessant, weil ich das bei mir auch so gemacht habe

Trennung von Logik/Berechnungen und Gui ist halt irgendwie Standard... Die game_scripts sind da irgendwie unflexibel und auch nicht intuitiv: Dieselbe Lua Datei wird in 2 Threads parallel geladen mit denselben Variablen, die dann 2x existieren, aber in Engine und Gui Thread werden jeweils andere Funktionen aufgerufen. Nur die "load" function wird in beiden aufgerufen. Das kann zu Problemen führen, siehe Game Script => Save function, Unerklärliches verhalten

Zitat von Kirsche

Ich behaupte einfach mal, das die Fahrplanmod programmiertechnisch absoluter Müll ist. Ein lächerlicher Scriptmod welcher mit -im Prinzip- nichts weiter als ein paar Zahlentabellen, 20GB RAM zumüllt, würde ich mir nie antun.

Wie "sauber" eine Mod lua-seitig aussieht und welche Probleme im Spiel dadurch entstehen können, hat absolut nichts miteinander zu tun! Ich kann dir Mods schreiben, die mit 2 Zeilen random Crashes produzieren und gleichzeitig gibt es hier Mods, die programmiertechnisch eine Katastrophe sind (zB 1000 Zeilen was auch in 10 Zeilen geht), aber fehlerfrei laufen. Es geht hier nicht um Konzeptfehler in Mods, sondern um nicht-offensichtliche Probleme in der TPF2 Engine. Wenn es offensichtlicher Design Fehler der Timetable Mod wäre, dass Datenmengen unkontrolliert im Lua Code angehäuft würden, wäre der Fehler schon längst gefunden.

Hier ein ähnliches Beispiel, wie eis_os genannt hat: https://github.com/IncredibleH…TPF2-Timetables/issues/50

Woher soll ein Modder wissen, dass ein simpler API Aufruf nur in bestimmten Situationen einen random Crash erzeugt?

Eine pbf Datei (komprimiert) ist was anderes als eine .osm Datei (hier wird ein raw xml Format erwartet)

Die pbf von Geofabrik muss man erst mit Osmosis zuschneiden, siehe: https://github.com/Vacuum-Tube…/tree/main/python/osmosis und crop_osm.py

Einfacher ist es, den direkten Export mit Overpass zu nutzen. Das mit Geofabrik hat eigentlich nur den Vorteil, wenn man einen historischen Kartenzustand haben will.