Beiträge von bionade24

Willkommen in der Transport Fever Community

Wir begrüßen euch in der Fan-Community zu den Spielen Transport Fever und Train Fever, den Wirtschaftssimulatoren von Urban Games. Die Community steht euch kostenlos zur Verfügung damit ihr euch über das Spiel austauschen und informieren könnt. Wir pflegen hier einen freundlichen und sachlichen Umgang untereinander und unser Team steht euch in allen Fragen gerne beiseite.

 

Die Registrierung und Nutzung ist selbstverständlich kostenlos.

 

Wir wünschen euch viel Spaß und hoffen auf rege Beteiligung.

Das Team der Transport-Fever Community


    Verstärkerlinien ist im Kontext des Spiels gemeint. Zwei gleichwertige Linien teilen sich den Laufweg von Bahnhof A nach Bahnhof B. Eine Linie fährt Luft durch die Gegend, während die andere Linie völlig überlaufen ist und hunderte Fahrgäste wütend warten. Das ist im Spielkontext total frustierend und war bereits in den vorherigen Teilen ein Problem. Besser wäre die Logik: Pax wollen von A nach B und steigen in den ersten Zug, der dieses Ziel bedient anstatt auf Linien ausgerichtet zu sein.

    Ich hab das tatsächlich in TpF2 hinbekommen. Damit das mit Rumprobieren ausbalancierbar ist, muss das Verkehrsaufkommen allerdings sehr groß sein, was bisher nur mit "Natural Town Growth" möglich war. An das Shinkansennetz auf der einen Map sind ~24.000 Pops gut angeschlossen. Mit den größeren Städten in TpF3 kann es vielleicht auch für dich klappen.

    Das dauert zwar relativ lange, weil immer auf eine Netzwerkverbindung gewartet wird,

    Mr_Unwichtig Chromium Embedded Framework macht CEF Dinge:


    Zitat

    Steam's use of steamloopback.host in its Chromium backend to refer to itself. Due to the way systemd-resolvd attempts to resolve this host (via mdns by default for some users) this issue can hang the interface. This causes very long startups (if it ever starts) and a slow-responding (or not at all) user interface. This issue can temporary be addressed by editing /etc/nsswitch.conf to change mdns to mdns_minimal and restarting systemd-resolvd.

    Quelle: Archwiki

    Wenn man Daten kopieren, verschieben oder einfach nur lesen will. Ist es ja gewollt, dass das so schnell wie möglich passiert. Oder nicht? Und das heißt natürlich, das man die volle 100% Auslastung haben will.

    So quatsch, zumindest für CPU & GPU. Deren maximale Effizienz ist nicht bei 100% Auslastung. Eventuell will ich auch weniger Strom verbrauchen oder Abwärme erzeugen und habe ganz bewusst den Takt reduziert oder gar undervoltet.


    Zitat

    Jetzt mal meine Frage an euch Expert*innen, kann ich genauso, wie ich "Gigantisch" erst freischalten musste, auch evtl. mehr Arbeitsspeicher zuordnen?


    Ne, der wird ja gar nicht gebraucht. 100% RAM & VRAM - Auslastung, hieße dass es ständig Page Faults geben würden, weil sich Daten gegenseitig aus dem Arbeitsspeicher "verdrängen". Deswegen reservieren Spieleengines meistens erst selbst mal eine Menge RAM beim Betriebssystem, den sie noch nicht benötigen & betreiben dann selbst Speicherverwaltung. Bei Tpf2 zumindest hatte das noch nicht gut funktioniert und ich konnte da selbst etwas nachhelfen, siehe vorletzter Absatz in Performance Tips. Das geht auch 1 zu 1 in TpF3, hab noch nicht geschaut, ob es was bringt.

    Kann man das Spiel irgendwie dazu bringen das man der EULA und der Datenschutzerklärung nicht JEDESMAL zustimmen muss, wenn man das Spiel ohne Internetverbindung startet.

    Welche Version hast du denn, Steam, GOG oder Epic ? Theoretisch könntest du den online check entweder aus der Ausfürbahren Datei rauslöschen, wenn du den offset & größe findest. Mit LLMs ist das jetzt deutlich einfacher zu bewerkstelligen. Oder du fängst erstmal die Netzwerkkommunikation von TpF3 ab und schaust was für eine Anfrage da versucht wird rauszusenden. Das kannst du dir mit Wireshark anschauen. Theoretisch kann man die auch umleiten, solange kein certificate pinning gemacht wurde & dann von nem klitzekleinen Webserver-stub, der die gewollte Antwort schickt beantworten lassen. Ja, beides hat Aufwand, aber über die nächsten Jahre wird sich das wohl amortisieren.


    Reverse engineering & Veränderung der Software als Kunde ist nach einem EUGH-Urteil zulässig, solange man das nur für sich selbst macht.

    Bin damals gescheitert & habe es heute mit einem LLM gelöst. Die personEdges beinflussen die Längenkalkulation für das Einstiegstempo & das wurde mit einem Update dahin geändert:


    [h1]The bug is in the station

    Code
    .mdl

    terminals — the

    Code
    personEdges

    list[/h1]


    [h2]1. The two station files[/h2]


    Ground level
    Code
    monorail_station_02.mdl
    Code
    monorail_station_02b.mdl
    Code
    monorail_station_static_lanes_modul00.mdl
    Elevated
    Code
    monorail_station_03.mdl
    Code
    monorail_station_03b.mdl
    Code
    monorail_station_static_lanes_modul.mdl


    All six of these carry an identical

    Code
    transportNetworkProvider

    terminal, so all six need the same fix. (

    Code
    …_wo_lanes

    ,

    Code
    …_static_modul

    ,

    Code
    …_entry_modul

    ,

    Code
    …_footbridge_modul

    have no terminal / empty terminals — no change needed.)


    [h2]2. How the length is computed[/h2]


    Since the update, TF2 derives a terminal's platform length as the sum of the lengths of the edges named in

    Code
    personEdges

    , and compares that against the train length for the loading‑speed bonus/malus. It does not use the whole lane — which is exactly why this mod regressed.


    [h2]3. Why your stations come out at 20 m[/h2]


    Each terminal is:


    Code
    { personNodes = { 3 , 10 , 18 , 24 }, personEdges = { 1 , 2 , 4 , 5 , 8 , 9 , 11 , 12 } }


    Those 8 edges are only the four door‑pair strips (

    Code
    --doors_1+2 … --doors_7+8

    ), each 2.5 m:


    1, 2−15 → −105.0 m
    4, 5−7 → −25.0 m
    8, 92 → 75.0 m
    11, 1210 → 155.0 m
    Total20 m


    Meanwhile the platform lane itself runs from y = −18 to y = +18 = 36 m. The game reports 20 m because it only ever sums the listed

    Code
    personEdges

    — the rest of the platform is invisible to it. That is precisely the "20 m instead of ~40 m" you're seeing.


    [h2]4. The fix[/h2]


    Make

    Code
    personEdges

    cover the whole platform lane (all 14 edges

    Code
    0…13

    ), not just the door strips.


    [h3]

    Code
    monorail_station_02.mdl

    ,

    Code
    monorail_station_02b.mdl

    ,

    Code
    monorail_station_03.mdl

    ,

    Code
    monorail_station_03b.mdl

    [/h3]


    Code
    terminals = {
    -				{  personNodes = { 3 , 10 , 18 , 24 }, personEdges = { 1 , 2 , 4 , 5 , 8 , 9 , 11 , 12 } },
    +				{  personNodes = { 3 , 10 , 18 , 24 }, personEdges = { 0 , 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 10 , 11 , 12 , 13 } },
    },


    [h3]

    Code
    monorail_station_static_lanes_modul.mdl

    and

    Code
    monorail_station_static_lanes_modul00.mdl

    [/h3]


    Code
    terminals = {
    -				{  personNodes = { 3 , 10 , 18 , 24 }, personEdges = { 1 , 2 , 4 , 5 , 8 , 9 , 11 , 12 } },
    -				{  personNodes = { 31 , 38 , 46 , 52 }, personEdges = { 15 , 16 , 18 , 19 , 22 , 23 , 25 , 26 } },
    +				{  personNodes = { 3 , 10 , 18 , 24 }, personEdges = { 0 , 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 10 , 11 , 12 , 13 } },
    +				{  personNodes = { 31 , 38 , 46 , 52 }, personEdges = { 14 , 15 , 16 , 17 , 18 , 19 , 20 , 21 , 22 , 23 , 24 , 25 , 26 , 27 } },
    },


    [h2]5. Notes / verification[/h2]


    • The
      Code
      .mtl

      files are not involved.

      Code
      .mtl

      files only define materials (shaders/textures); they carry no geometry or lengths, so they cannot produce a 20 m/40 m error.

    • The
      Code
      personNodes

      are fine — they are the door‑alignment points and should stay as they are.

    • Reaching a true 40 m: the platform lane currently spans 36 m (
      Code
      y = −18…+18

      ). If the intended platform is the full 40 m module, additionally move the two outer platform‑lane nodes (

      Code
      { 6.2, -18, … }

      and

      Code
      { 6.2, 18, … }

      ; the

      Code
      −6.2

      ones in the

      Code
      _b

      /module files) to

      Code
      ±20

      , which brings the full‑lane

      Code
      personEdges

      sum to exactly 40 m.

    • After the edit: open the station in the build menu — the length shown should now be the full platform, and the double‑traction monorail should no longer show the loading‑speed malus.


    Bottom line: the fault is the terminal's

    Code
    personEdges

    in the station

    Code
    .mdl

    files — they enumerate only the 20 m of door‑adjacent edges, so the game now computes a 20 m platform and flags the double‑traction unit as "longer than the station." Extend

    Code
    personEdges

    to the whole platform lane and the malus disappears.

    Alternativ Versuchsweise, dieses im Speicher / TransportFever

    48 C7 45 D0 00 00 00 00 48 C7 45 D8 00 C2 EB 0B

    durch dieses hier ersetzen:


    48 C7 45 D0 14 00 00 00 48 C7 45 D8 00 C2 EB 0B

    Das würde dann nanosleep 20ms warten lassen..

    Ich kann den hexstring weder im Tpf2 binary, den mitgelieferten libs noch dem gedumpten Prozess finden.

    Habs mit hexer & mit grep -obUaP '\x48\xC7\x45\xD0\x00\x00\x00\x00\x48\xC7\x45\xD8\x00\xC2\xEB\x0B' * versucht.

    Moin,


    ich habe folgendes Problem der Monorail Mod von majuen und der Shinkansen E4 von Gombe enhalten beide eine Datei unter vehicle/train/glass.mtl. Dass man Dateien anderer Mods in einem Mod referenzieren kann, ist mir bereits bekannt. Wenn die Monorail vor dem E4 geladen wird, dann sind sind in der Monorail die bekannten Karomuster statt der Scheiben - aber sobald der E4 vor der Monorail geladen wird, kann ich keinen Fehler mehr finden. Kann es sein, dass das Problem nur bei der Monorail auftritt und falls ja, wie ? Oder sind solche generischen Namen generell problematisch?


    Viele Grüße


    Oskar

    Das Problem mit der Genauigkeit bei Fließkommaberechnung wird nur gravierend wenn du Fließkommawerte auf verschiedenen Skalenwerten miteinander verrechnest


    Nur in der Theorie. Numerische Rechnungsverfahren die in 3D-Koordinatensystemen genutzt werden wie z.B. numerische Orthonomalisierungsverfahren sind mit FP64 schon grenzwertig, wenn du einen Wert mit 3 vorm Punkt zwischen mehreren 1. in derselben Matrix hast.

    In die ntdll wird Quasi alles geschrieben was Windows so macht, das als Fehlerquelle 🤔 zu 99,97 % Nein 😉

    Das habe ich auch nicht behauptet, sondern dass der Fehler während der Ausführung von Programmteilen in ntdll.dll wahrscheinlich einen externen Grund hat. Dass es in ntdll.dll passiert ist, haben wir aufgrund des Stack Trace im Dump schwarz auf weiß.

    Vor dem Deabbonieren aller bereits deaktivierten (2. Gerät) Workshop-Mods ist mir aufgefallen, dass ich auf dem 2. System mir nur den Traffic während das Hauptmenü läuft angeguckt habe. Sobald das eigentliche Spiel läuft habe ich die gleichen Werte wie eis_os. Ich kann es also nicht reproduzieren. Das ist mir leider durchgerutscht. Entschuldigung für die Verwirrung.


    Wird ein Spielstand ohne irgendwelche Mods geladen, dann sind im Spiel nur noch konstant 50 Mib/s, während es ja wohl eher <1Mib/s sein sollte. Als ich dann in Steam alle Workshop-Mods deaktiviert hatte, hatte ich mit dem Modlosen Spielstand nur noch 200-700 Kib/s traffic. Debug Modus an/aus hat nix gebracht.

    Wenn ich mehr Zeit & Geduld habe, werde ich mal tcpdumps mit Inhalt der TCP-Pakete von Hauptmenü, dem 200 Kib/s & dem 50 Mib/s szenario mit nem fuzz diff Skript, dass ich mir mal geschrieben hatte, vergleichen. Eventuell sind da aufschlussreiche Muster drin.

    Steam overlay habe ich auch abgeschaltet, ich hab auch mal veruscht LD_PRELOAD zu überschreiben, sodass gameoverlayrender.so überhaupt nicht reingeladen wird. Hilft beides nix. Hatte vergessen bei tcpdump mir den Inhalt der Pakete anzuschauen, bei einigen kommt im kodierten Binärmatch immer wieder Pfade zu workshopmods vor. Werde gleich mal probieren statt die Workshop mods nur zu deaktivieren, wirklich alle zu deabbonieren.

    Habe gestern Abend noch CPU und GPU nen Belastungsbenchmark machen lassen, war ok. Ich werde noch einen RAM Test machen um das auch auszuschliessen. Hmmmm

    Die Festplatte kann es ja auch sein, aber dann sollte es nach der Neuinstallation ziemlich sicher einen anderen Mod treffen. Da mal die SMART-Werte auslesen. Das Dateisystem mit chkdsk C: /scan  überprüfen.

    Also der im Log genannte Thread 17140 steckt in ntdll.dll fest. Wenn der Thread wirklich Mods lädt, dann würde ich vermuten, dass eine Datei, das Dateisystem oder was an der Hardware kaputt sind.