... gibt es doch noch. Und zwar da, wo auch die Spielschwierigkeit eingestellt wird - zumindest beim "neuen Spiel".
Nein, die geringste Option in TpF3 ist "spärlich". Für mehr brauch ich einen Mod.
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
... gibt es doch noch. Und zwar da, wo auch die Spielschwierigkeit eingestellt wird - zumindest beim "neuen Spiel".
Nein, die geringste Option in TpF3 ist "spärlich". Für mehr brauch ich einen Mod.
Ich dachte, der ist im Sandkastenmodus dabei gewesen und kein Mod?
Ja, aber die Option, dass keine neue Industrien erstellt werden hat UG aus den Spielstandseinstellungen entfernt ohne das in den Sandbox Mod mitreinzupacken.
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:
ZitatSteam's use of
steamloopback.hostin its Chromium backend to refer to itself. Due to the way systemd-resolvd attempts to resolve this host (viamdnsby 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.confto changemdnstomdns_minimaland 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.
ZitatJetzt 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
terminals — the
list[/h1]
[h2]1. The two station files[/h2]
| Ground level | |||
| Elevated |
All six of these carry an identical
terminal, so all six need the same fix. (
,
,
,
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
, 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:
Those 8 edges are only the four door‑pair strips (
), each 2.5 m:
| 1, 2 | −15 → −10 | 5.0 m |
| 4, 5 | −7 → −2 | 5.0 m |
| 8, 9 | 2 → 7 | 5.0 m |
| 11, 12 | 10 → 15 | 5.0 m |
| Total | 20 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
— 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
cover the whole platform lane (all 14 edges
), not just the door strips.
[h3]
,
,
,
[/h3]
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]
and
[/h3]
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]
files are not involved.
files only define materials (shaders/textures); they carry no geometry or lengths, so they cannot produce a 20 m/40 m error.
are fine — they are the door‑alignment points and should stay as they are.
). If the intended platform is the full 40 m module, additionally move the two outer platform‑lane nodes (
and
; the
ones in the
/module files) to
, which brings the full‑lane
sum to exactly 40 m.
Bottom line: the fault is the terminal's
in the station
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
to the whole platform lane and the malus disappears.
Äh, hieß es nicht mal irgendwann irgendwo, dass Wasser (schiffbares) Gefälle haben kann?
Ich hatte das auch in Erinnerung vom Teaser-Trailer und dem 1. Blogpost. Leute die auf der Gamescom TpF3 angezockt haben, haben aber auf Reddit geschrieben, dass Wasser wieder auf einer Höhe ist.
Habe die Änderung jetzt hinbekommen. Im geladenen Spiel habe ich jetzt nur noch 65KiB/s ! Vielen Danke für die Hilfe.
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 0BDas 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.
Also so dass die letzgeladene .mtl genommen wird so hatte ich das bisher auch immer verstanden. Die Karomuster kommen kommen afaik daher, dass die Albedo map und/oder die metal_gloss map die in der .mtl referenziert werden, nicht gefunden werden.
Deswegen wundert mich ja, dass es mit der anderen Reihenfolge keine Probleme beim E4 gibt.
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.
Danke für deine Nachforschungen! Macht es Sinn, UG darüber nen Bugreport zu schreiben ? Der Bug könnte ja eventuell auch noch in Tpf3 drinnen sein.
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.
Danke für deine beiden Tests.
Hat mod.io irgendeinen extra Prozess mit dem Tpf2 IPC machen könnte? Ist ja kein Netzwerktraffic nach "draußen" über eth*, sondern nur lokal auf lo.
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.
Thread 67 - tid: 17140
0 ntdll.dll + 0x1656e4
rax = 0x00000000000001e3 rdx = 0x0000000000000000
rcx = 0x0000029c9418d230 rbx = 0x0000000000000000
rsi = 0x0000000000000000 rdi = 0x0000000000000000
rbp = 0x000000a3122ff4a0 rsp = 0x000000a3122ff428
r8 = 0x0000029c9418d230 r9 = 0x7ffffffffffffffc
r10 = 0x0000029c9418d230 r11 = 0x0000029c9418d230
r12 = 0x0000000109c667c9 r13 = 0x0000029c9418d278
r14 = 0x0000029c9418d230 r15 = 0x0000000000000000
rip = 0x00007ffd829856e4
Found by: given as instruction pointer in context
1 ntdll.dll + 0x94c9d
rsp = 0x000000a3122ff430 rip = 0x00007ffd828b4c9e
Found by: stack scanning
2 KERNELBASE.dll + 0x41d77
rsp = 0x000000a3122ff4d0 rip = 0x00007ffd7fc11d78
Found by: stack scanning
3 msvcp140.dll + 0x5764f
rsp = 0x000000a3122ff510 rip = 0x00007ffd31d77650
Found by: stack scanning
4 msvcp140.dll + 0x1a3e7
rsp = 0x000000a3122ff550 rip = 0x00007ffd31d3a3e8
Found by: stack scanning
5 msvcp140.dll + 0x1a607
rsp = 0x000000a3122ff580 rip = 0x00007ffd31d3a608
Found by: stack scanning
6 msvcp140.dll + 0x1ab66
rsp = 0x000000a3122ff590 rip = 0x00007ffd31d3ab67
Found by: stack scanning
7 TransportFever2.exe + 0x28128f
rsp = 0x000000a3122ff5a0 rip = 0x00007ff62fde1290
Found by: stack scanning
8 TransportFever2.exe + 0x11869f
rsp = 0x000000a3122ff600 rip = 0x00007ff62fc786a0
Found by: stack scanning
9 TransportFever2.exe + 0x2ad858
rsp = 0x000000a3122ff690 rip = 0x00007ff62fe0d859
Found by: stack scanning
10 TransportFever2.exe + 0x1124d7
rsp = 0x000000a3122ff6f0 rip = 0x00007ff62fc724d8
Found by: stack scanning
11 TransportFever2.exe + 0x11a159
rsp = 0x000000a3122ff750 rip = 0x00007ff62fc7a15a
Found by: stack scanning
12 ucrtbase.dll + 0x174ef
rsp = 0x000000a3122ff780 rip = 0x00007ffd802574f0
Found by: stack scanning
13 TransportFever2.exe + 0x119758
rsp = 0x000000a3122ff790 rip = 0x00007ff62fc79759
Found by: stack scanning
14 ucrtbase.dll + 0x37af
rsp = 0x000000a3122ff7c0 rip = 0x00007ffd802437b0
Found by: stack scanning
15 kernel32.dll + 0x2e8d6
rsp = 0x000000a3122ff7f0 rip = 0x00007ffd81dbe8d7
Found by: stack scanning
16 ntdll.dll + 0x8c48b
rsp = 0x000000a3122ff820 rip = 0x00007ffd828ac48c
Found by: stack scanning
Alles anzeigen