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
aber im Codeblock wird nur auf j und k Bezug genommen.
ja aber auf compartment
Das Modell hat einen customCargoModels anstatt einer (normalen) cargoBay. D.h. die Gütermodelle für Schienen/Gleise können hier nicht (korrekt) dargestellt werden. Daher wird es nicht hinzugefügt.
Ja genau das ist es. Mehr Infos hier RE: Build with Collision
Bahnhöfe auf Turmspitzen
Ich habe niemals gesagt man soll jetzt sinnlose Dinge zu bauen 
Die Mod bietet einfach nur die Möglichkeit. Was der Spieler macht, liegt in seiner Verantwortung. Ich denke es gibt genug Fälle, wo es Sinn macht, da das Spiel unnötig oft nach Kollision schreit. Bei Assets haben nur die wenigsten Mods diese Option, da man dafür 2 Einträge im Menü braucht (leider wurde nie ein result.skipCollision eingebaut). Die Haupt Motivation waren allerdings die Straßen und Gleise. Siehe auch Einleitung der Modbeschreibung.
Was Fehlerquellen angeht, so habe ich bisher noch nicht gehört, dass Objekte ohne offizielle Baugenehmigung im Spiel zu Crashes führen. Das hat nur optische Auswirkungen.
Doch wenn ich auf das "X" des Baumenüs klicke, dann ist Feierabend. Das Spiel stürzt ab.
Das ist auch schon längst bekannt, da hast du leider den Hinweis übersehen und dass v1.3 Beta heißt.
Bei mir läuft Deine Mod "Build with Collision 1.2" mit Build 35246 bis dato einwandfrei.
Assets können aktuell nicht gebaut werden
weil so können mehrere kerne ja das spiel berechnen, wodurch (nach meiner Logik meines wissens nach) das spiel performanter läuft, da nicht der Eine Kern alles berechen muss und ggf. überlastet ist, sondern schön alle 12 kerne mitrechnen können. wäre vielleicht auch ne Idee die man mal in einem update rausbringen könnte
Du bist nicht der erste mit der Idee. Aber Multithreading ist einfach gesagt aber alles andere als trivial und harte Programmierarbeit und manchmal auch von der Logik nicht möglich. Man muss sagen, dass hier seit TPF1 auch einiges gemacht wurde (früher lief das Spiel auf nur einem Kern). Seit TPF2 sind zB GUI und Simulation in verschiedenen Threads unabhängig. Das macht aber auch viele Sachen komplizierter (eis_os kann ein Lied davon singen). Es scheint dass UG hier schon viel versucht hat, aber es gibt allgemein kaum Games, die mehr als 4 Kerne ausnutzen.
MrOnic Mag für andere Spiele gelten, aber nicht für TPF2. Die Simulation kommt ja schnell an die Grenzen.
Version 1.3 crash nicht nur beim X
sondern?
ist eigentlich auch egal, UG hat zu dem Fehler bei dieser Lösung nichts gesagt. Sie versuchen eine andere Lösung bereitzustellen. Daher werden die Probleme der 1.3 wegen dem Button sich erledigen.
nicht einfach auf ne taste legen
Tasten sind nicht modbar
--
ne hab noch keine Antwort von UG
Man muss aber wohl auch fairerweise sagen, die meisten Probleme entstehen durch Mods, die sich entweder gegenseitig stören, nicht angepasst wurden oder grundsätzlich buggy sind.
Naja... nach der Logik könnte sich UG jetzt zurücklehnen und die Modder wären dran. Das Gegenteil ist der Fall: Die Bugliste ist nachwievor ellenlang. Und ich kann zB Build with Collision aktuell nicht fixen, da ist einfach UG jetzt am Zug. Ich habe rechtzeitig in der Beta versucht, eine Lösung zu finden und UG informiert.
Das war einfach keine richtige Beta... es war noch mitten in der Entwicklung. In einer idealen Welt haben die Entwickler einen ausgiebig getesteten Zustand, in dem das Vanillaspiel und die wichtigsten Mods stabil laufen, DANN wird eine Open Beta freigegeben und die Entwickler sind bereit, weitere Fehler zu fixen. Und in dieser Zeit können die Modder (wenn sie wollen) ihre Mods an das neue Spiel anpassen. Zum Release steht dann eine stabile Version und idealerweise kriegen die Spieler nicht mal was mit. Aber es kann nicht sein, dass dann während der Beta auch noch laufend grundlegende Dinge geändert werden.
Was man mitbekommen hat, sind die Konsolenversionen ja auch noch nicht gerade stabil, d.h. es liegt hier nicht an Mods. Das war in anderen Updates eher so.
Es liegt einfach daran, dass dies nicht nur ein Release für neue Plattformen ist (der noch parallel zur Betaphase lief), sondern gleichzeitig auch das (technisch betrachtet) größte Update für die PC-Version! Die Aussage "Die halbe GUI wurde geändert" ist nicht übertrieben. Und dass die Änderungen deutlich mehr Auswirkungen auf Mods haben, als die anderen Updates, hätte man sich auch denken können.... Natürlich kann man sagen sind halt Mods.. aber ganz ehrlich man kann nicht 3 Jahre nach einem Release anfangen die Struktur in der base_config aufzuräumen. Da muss man irgendwie an Kompatibilität denken, vor allem da es mit der Zeit immer nur mehr Mods gibt und immer mehr Spieler mit mehr Mods spielen. Natürlich wird es bei Mods immer Wechselwirkungen geben, aber mittlerweile kennen wir die. Dass da jetzt der Frust bei manchen groß ist, die einfach nur mit dem letzten stabilen Zustand weiterspielen wollen kann ich nur zu gut verstehen.
Siehe auch mein Beitrag im anderen Thread
ESC hilft in dem Fall. Lua Fehler sind ja noch angenehm. Nervig wirds wenn die Anwendung nicht mehr reagiert. Manchmal kommt aber auch im Hintergrund ein Error occured und man kann einfach mit Alt+Tab das Fehlerfenster schließen und muss nicht in den Taskmanager.
Das Problem war einfach, dass die Betaphase im Verhältnis zu den Änderungen viel zu kurz war. Ich weiß nicht ob man sagen, dass es das größte Update ist, aber die Auswirkungen auf Mods sind zumindest enorm. Ich habe in vergangenen Updates 1 oder keine Mods anpassen müssen. Diesmal sind es... jetzt muss ich erstmal zählen.... 6
Dabei ist auch aufgefallen, dass viele Fehler erst zum Release auftauchten, wenn die Mehrheit der Spieler das Spiel startet. Das liegt einfach daran, dass die Modder/Betatester in der Betaphase mit genug anderen Problemen zu tun hatten und die wenigsten hiermit "normal" gespielt haben. Das Bug Forum in Steam ist immer noch ewig lang und UG kommt nicht hinterher. Selbst wenn man als Modder in die Beta gegangen ist und versucht seine Mods vor Release zu updaten, bei Build with Collision gibts bis jetzt noch keine funktionierende Lösung seitens UG.
Zumal die Betaphase neben den Fixes auch noch mitten in der Entwicklung war, es kamen viele Neuerungen zwischendrin. Der Zeitplan war einfach völlig unrealistisch.
Wir könnten natürlich alle den Controller Mode aus Protest ignorieren, aber ich glaube, so ganz zielführend wäre das nicht.
Warum nicht? Ich habe den Controller Modus noch nicht einmal ausprobiert. Ist ja fürn PC nicht wirklich sinnvoll. Und auf den Konsolen gibts eh keine Mods.
Jedenfalls werde ich für meine Mods keinen Consolen Support bieten können. Gibt so schon genug zu fixen.
BTW Werden eigentlich noch die alten Menü-Icons in einfacher Größe/Auflösung, sprich ohne @2x, für irgendwas gebraucht?
Hab die noch nie ingame gesehen, auch nicht bei niedrigen Einstellungen.
Das sind einfach Überreste von Transport Fever. Man findet in den Spieldateien sogar Train Fever Überreste.
Gibt es irgendwo eine Möglichkeit einzustellen ob das im Spiel im Pausenmodus startet oder nicht? Im Moment ist es bei mir random.
Es ist genauso wie du es speicherst.
Wenn man sicher mit Pause starten will --> https://www.transportfever.net…?entry/5266-start-paused/
Ich würde mal machen was da steht: Contact the mod author. In dem Fall also UG
Sieht aus wie ein Fehler in den modifiers.
Relozu hatte doch da mal was gebastelt um das zu erkennen. Findet man das irgendwo im Lexikon?
Was passiert mit meinen Mods/Savegames, wenn ich in Steam auf die frühere Version von TPF2 downgrade?
Gibts da einen Trick, sodass es mir nix zerschießt ?
Damit Savegames noch in der alten Version funktionieren, dürfen sie mit der neuen Version nicht gespeichert werden!
Bei manuellen Mods braucht man halt beide Versionen. Ich bin jetzt auch ein paar mal gewechselt und dann entsprechend
eis_os_commonapi2_1 in eis_os_commonapi2_1new bzw old umbennant.
Dasselbe mit dem shaders Ordner von NEP.
Bei Steammods wird es schwierig, wenn der Modder die Änderung inkompatibel zur alten Version gemacht hat. Bei Better Terrain Layer konnte ich zB einen switch einbauen, sodass verschiedene Spielversionen unterstützt sind.
Das geht aber nicht bei allen Mods.
Maybe you can ask Enzojz to provide an older version of Shader Enhancement.
Was die Performance angeht verweise ich auf meinen Performance Vergleich Spielupdate (35210)
Grundsätzlich decken sich die Erfahrungen hier ja:
Auf dem Papier sind die FPS gerade mit vielen Mods besser, aber nur in der statischen Ansicht.
Während Spieler mit schwächerer Hardware eher profitieren, zeigt sich bei neuerer Hardware mehr Ruckeln auf großen Karten im Vergleich zu vorher.
Wer viel VRAM hat, kann versuchen die beiden neuen Einstellungen (settings.lua)
auf false zu setzen.
CComponent::setMouseListener
Ich hänge mal das Beispiel an was mir geschickt wurde.
Also irgendwie glaube ich das funktioniert noch nicht ganz richtig.
Man kann nichts mehr bauen. Also die Durchleitung der Events mit return false scheint nicht zu gehen.
D.h. ich kann jetzt zwar Mouse Events abfangen und mit Kollision bauen aber nicht mehr normal
"Assertion Failure: Assertion `m_data->keyInputCacheBeforeWithoutRepeatPress.IsPressed(key->scancode)' failed."
Also ich kriege das in der CommonApi Console, einfach ein paar mal auf Strg+C hauen oder gedrückt halten....
Mit rendermode = 2 erscheint commonapi nicht mehr im Menü
I.A. ist es gar nicht so schlau, haufenweise Mods wieder zu deaktivieren, v.a. wenn man nicht genau weiß ob die schon verbaut sind oder es Abhängigkeiten gibt.
In deinem 2.letzten Beitrag gibt es zumindest eine halbwegs brauchbare Fehlermeldung
urban_games/train_fever/src/Game/collision_shape_lib.cpp:827: struct Box3 __cdecl collision_util::CalcBoundingBox(const struct ModelData *,const struct ecs::component::ModelInstanceList &): Assertion `result.bounds[0].x <= result.bounds[1].x' failed.wäre interessant, was genau du hier gerade bauen wolltest.
nutzt die KI diese Häuser/Fahrzeuge/Personen auch selbst ohne mein zu tun?
kommt drauf an wie es vom Modder definiert wurde.
Im Prinzip wird jedes Modell vom Spiel als Auto gesehen wenn in der mdl steht car = {}
Und für personen gilt person = {}
Falls nicht, ist es einfach nur ein Modell, was erstmal nur genutzt wird, wenn irgendjemand diesen Dateinamen verwendet (ggf. versehentlich bei zu allgemeinen Namen)
Damit Häuser als KI Stadtgebäude gebaut werden, ist eine Definition als TOWN_BUILDING notwendig. Da muss man sich noch ein paar Gedanken über Parcels Größe machen und welche Seite eigentlich die Straßenseite ist. Das machen leider die wenigsten Modder. Eine Art Addon, das für bestehende Modhäuser zu machen ist möglich, aber sehr aufwändig, gerade weil man zum Testen dauernd Städte erstellen und auf diese Häuser warten muss. Das Thema hatten wir irgendwo schonmal.
Bei Straßen wirds spannend. Beim KI Stadtausbau oder Stadtgeneration werden nicht nur Vanilla Straßen genommen, sondern z.B. welche von SMP. Es hat mir noch keiner sagen können, worauf es da genau ankommt.
Interessant dazu wäre eigentlich noch das.
Das könnte tatsächlich interessant sein für WernerK 
Ich hänge mal das Beispiel an was mir geschickt wurde.
Im Beitrag wurde geantwortet, dass es folgende Einstellungen gibt (settings.lua)
-enableDeferredTextures
-terrainTesselationEnabled
Die sind mit dem Update hinzugekommen. Ich habe beide auf false gesetzt und es ist wieder ein gutes Stück besser.
Falls ihr diesen Mod habt, mal ohne diesen versuchen:
Auch darf man niemals ein Layout in ein Layout packen.
Genau das habe ich aber gesehen beim mainButtonsLayout
UG hat mir ein Beispiel geschickt mit setMouseListener. Sieht so aus, als wäre build with collision sogar ohne umwege möglich. Muss ich mir morgen genauer anschauen.
