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
Dann stauen sich nicht mehr 12 Eisenerzzüge, weil erstmal 5 Baumaterialzüge Vorfahrt haben, die wiederrum an anderer Stelle 6 Rohölzügen Vorfahrt gewähren etc. pp.
Wenn Züge dauerhaft an einer Zufahrt warten müssen, ist das Überlastung.
Für einen flüssigen Betrieb braucht man wesentlich mehr Blöcke als Züge. Mindestens Faktor 3 würde ich mal sagen. Im RL noch mehr.
In der .sav.lua sind nur gamescript Daten, was du gefunden hast war nur irgendwas, was vom guidesystem benutzt wird.
Die Spielzeit ist fest im Savegame .sav drin.
Aber man kann mit dem Sandboxmode das Datum beliebig ändern.
Für sowas gibts glaub ich diese Mod: https://steamcommunity.com/sha…iledetails/?id=2075070872
The cubes are the placeholders for missing models. The can usually just be deleted. If they belong to wagons, replace them.
The bridges: wtf?
Die sogenannte "Größe" einer Stadt in der Statistik ist Kapazitäten von RES, COM und IND addiert und geteilt durch 3. Wenn die drei Bereiche etwa gleich groß sind (wie es normalerweise ist), entspricht die Größe also den Zahlen der einzelnen Kapazitäten.
Anonsten sieht man die Gesamtwerte auch in den Gesamstatistiken (Auf Geld klicken).
Mit Einwohner meint man in der Regel die Gesamtkapazitäten aller Wohngebäude. (Genau genommen ist das aber nicht die tatsächliche Anzahl an simulierten Personen, die ist meist geringer, aber nicht so einfach rauszufinden.)
Also auch nicht viel Unterschied.
Ich hab Nvidia aber anscheinend auch gelb.
Die Bedeutung der Farben ist mir noch unklar.
Weiß nicht wie du auf 25k kommst, ist eher so 17.
Mit diesem neuen "feature request" wollte ich die Angelegenheit vereinfachen.
Je einfacher, desto wahrscheinlicher, dass es umgesetzt wird.
Das stimmt.
Eigentlich sollte die Fahrtfreigabe doch auch so funktionieren, da es sinnvoll ist, wenn sich die wartenden Züge in eine "Liste" eintragen und der am längsten wartende fahren darf. Wie das im Spiel aber entschieden wird, weiß ich nicht.
Ohne eine einigermaßen intelligente Signalsteuerung ist Tpf2 nicht beherrschbar.
Wer hat Lust, ständig auf der Karte nach stehenden Zügen zu schauen und manuell bereits am Signal stehende Züge anzuhalten, damit auch mal das andere Gleis freie Fahrt bekommt?
Das würde ich aber so nicht behaupten. Auch wenn das Signalsystem etwas simpel ist - es funktioniert.
Das klingt dann eher nach Streckenüberlastung. Da sollte man dann evtl auf weniger aber längere Züge umstellen oder neue Gleise verlegen.
Das Thema wird ja gerade viel diskutiert, auch mit der Frage, inwiefern der Patch Besserung gebracht hat (Fazit: überschaubar).
Transport Fever 2 Version / Updates / Patches
Die Sache mit den Bildern pro Sekunde
Welcher Teil meines PCs bremst das Spiel?
Diskussion Mindestanforderungen Transport Fever 2
Das Spiel "ruckelt" wenn ich Vorspule
Im Update wurde allerdings auch ein neuer Parameter hinzugefügt.
Zitat[Modding] Added user-definable probability of recomputation of person destinations (experimental)
Konkret geht es um game.config.simPersonDestinationRecomputationProbability siehe base_config Zeile 179.
Also anscheinend eine Wahrscheinlichkeit, die man angeben kann, sodass die Zielberechnungen der Sims nicht bei jedem Simulationsschritt (0.2s) ausgeführt werden müssen. Denn diese scheinen ja die Hauptlast zu sein, insbesondere Autofahrer und bei dichten und nahen Städten.
Die Frage ist also, was dieser Faktor bringt. Werden dadurch Ruckler verringert?
Ich würde eine entsprechende Mod machen mit Einstellung, aber natürlich nur, wenn das ganze eine nützliche Wirkung hat.
Bei meinen Tests habe ich nur einen kleinen Unterschied festgestellt.
Wie erfasst man die Simulationsperformance/berechnungen?
Debug Modus, 2x AlrGr+i, dann sieht man zwei Diagramme. Das obere ist für die Gui, das untere für die Simulation (siehe Bild).
Wenn man zB ESC drückt, wird die Simulation angehalten, während die Gui weiterläuft.
Die Scriptberechnungen sind stark von der Geschwindigkeit abhängig. Bei 4x geht es schnell mal über die rote Linie. Das bedeutet, die Berechnung dauert zu lange, die Folge ist ein Simulationslag ("SimLag"), also alles bleibt stehen, aber man kann noch die Karte bewegen und mit der Gui interagieren. SimLags treten auch so gelegentlich auf, was man durch einen großen blauen Balken bemerkt, und dadurch von Rucklern anderer Art unterscheiden kann.
Die Berechnungen sind aber unabhängig von der aktuellen Ansicht und den FPS.
Daher ist der Vergleich: Einmal mit Standard (Faktor=1) und einmal den Wert auf 0.1 gesetzt (0 habe ich mal vermieden, falls das nicht erlaubt ist).
Spielgeschwindigkeit: 1x
Das Spiel etwas laufen lassen und das Diagramm eine Weile beobachten, denn der Verlauf ist etwas unregelmäßig.
Der Effekt hängt natürlich auch von eurem Spielstand ab (Lage der Städte, Anteil Autofahrer, ...)
Wenn bei euch ein deutlicher Unterschied ist, schreibt bitte mal die Einwohner dazu und wie weit das Diagramm ausschlägt.
Schau dir mal die vehicle entity an. Da müsste es vehicle.vehicles geben, was eben die einzelnen Modelle angibt. Vielleicht muss man die Config in genau diesem Format angeben.
Wäre es mit der neuen Modding-API möglich, so etwas per Mod zur Verfügung zu stellen, kompatibel mit allen installierten Signalpaketen?
nein
Um das nochmal klarzustellen... Das Update wird an den FPS nichts ändern.
Siehe mein Beitrag, im Update wurde nur an der Simulation geschraubt.
Mein erster Eindruck: Die Simulationsperformance ist nicht signifikant besser geworden. Auch gibt es gelegentlich SimLags. Ob das schlimmer ist als vor dem Update, kann ich nicht sagen.
Wenn die FPS sich stark geändert haben, kann es nur am Vergleich liegen, oder es gibt ein Hardware oder Mod-Problem.
Ihr könnt ja nicht einfach die base_mod überschreiben. Ich weiß nicht mal ob es gehen würde, aber wenn, wäre es keine gute Idee (sonst sind wir ja wieder genau bei dem Problem, dass jede Mod ihr eigenes Ding macht).
Man muss eine eigene postRunFn erstellen
Die Module werden in der base_mod erzeugt (und ist nebenbei ein anschauliches Beispiel für postRunFn):
postRunFn = function(settings, params)
local tracks = api.res.trackTypeRep.getAll()
for __, trackName in pairs(tracks) do
local mod = api.type.ModuleDesc.new()
local track = api.res.trackTypeRep.get(api.res.trackTypeRep.find(trackName))
if trackName ~= "standard.lua" and trackName ~= "high_speed.lua" then
for __, catenary in pairs({false, true}) do
mod.fileName = "trainstation_" .. tostring(trackName) .. (catenary and "catenary" or "")
mod.availability.yearFrom = track.yearFrom
mod.availability.yearTo = track.yearTo
mod.cost.price = math.round(track.cost / 75 * 18000)
mod.description.name = track.name .. (catenary and _(" with catenary") or "")
mod.description.description = track.desc .. (catenary and _(" (with catenary)") or "")
mod.description.icon = track.icon
if mod.description.icon ~= "" then
mod.description.icon = string.gsub(mod.description.icon, ".tga", "")
mod.description.icon = mod.description.icon .. "_module" .. (catenary and "_catenary" or "") .. ".tga"
end
mod.type = "track"
mod.order.value = 0 + 10 * (catenary and 1 or 0)
mod.metadata = {
track = true,
}
mod.category.categories = { "tracks", }
mod.updateScript.fileName = "construction/station/rail/modular_station/trackmodule.updateFn"
mod.updateScript.params = {
trackType = trackName,
catenary = catenary
}
mod.getModelsScript.fileName = "construction/station/rail/modular_station/trackmodule.getModelsFn"
mod.getModelsScript.params = {
trackType = trackName,
catenary = catenary
}
api.res.moduleRep.add(mod.fileName, mod, true)
end
end
end
endSehr hässlich, wenn ihr mich fragt.
Sieht halt irgendwie nach Flickenteppich aus. Soll zwar die Kompatibilität für Modgleise einfach hinzufügen, ist so aber sehr unflexibel.
Wie von eis_os schon angemerkt, wäre es besser, die Icon names in der track datei anzugeben. Bzw auch, ob diese überhaupt angezeigt werden.
Daher 1. Möglichkeit:
UG fragen wie mans am besten machen soll. Oder anmerken, ob man das ganze nicht nochmal sauber überarbeiten möchte.
2. Möglichkeit, man arbeitet mit dem was jetzt da ist, und schreibt noch einen Workaround um den Workaround (was die Sache nicht schöner macht)
Das hier könnte hilfreich sein: https://transportfever2.com/wiki/api/modules/api.res.html
In der postRunFn sind die Ressourcen writeable.
Man könnte also alle Module durchgehen, sich die eigenen über den filename raussuchen, und dann versuchen visibility zu ändern.
The modular station and non modular ones works essentially over the same fundemental.
Would you say, it's in general possible, to upgrade train stations or airports afterwards with other params?
Wenn man alle Gleise auf Standard oder Highspeed ändert, sollte man Gleismods entfernen können
Gleismods sind ja so eine Sache... nicht wenige überschreiben die Vanillagleise. Sobald man mehr als einen davon aktiviert, gibts Kompatibilitätsprobleme.
Weitere Nachteil von Gleisen als Lua-Datei (egal ob überschreiben oder nicht): Sobald was in den Spieldateien an den Gleisen geändert wird (das war in den letzten 2 Patches der Fall), sind die Modgleise nicht mehr auf dem aktuellsten Stand.
Wenn jemand in Zukunft eine Gleise Mod machen will, ist evtl die neue dynamische Erstellung nützlich. So könnte man auch das Menü übersichtlicher machen, sodass man nur die Gleise hat, die man will.
Abgesehen davon wäre es eigentlich auch angebracht, wenn UG endlich den Gleistyp von der Geschwindigkeit entkoppelt. Dann wären solche Probleme wie hier hoffentlich Vergangenheit.
Die Fehlermeldungen nehmen ganz neue Ausmaße an. Muss man wohl zuerst entschlüsseln.
Kam original so raus:
cc:\:b\ubiulidl\dt\ptfp2:f_2sbtsueilma\mtpfs2r_stggeaaamme\\sprrc\game\proceedduurraall\cbbeudiulrdail\butiyylpdeirnegpt.ycppperep.c::pp:3773373:: coccnosntsstts tssttrruucctt uBBuuiillddiinnggTTyyppee &&__ildingT_yc_pec &__cdecl Beucell lBiuBnugilTldyipnegRTeypppeeRRGpe:t::yepteGT(ecyopnTs(ycpn(tconsst sbtl:a:sbsa std_:s:ibca_sg<icnhga<rc,hsatsuic ssttrdi:n:sgc<dc:hra_rh,rsa_tttr<ucctta<rs,tcrld>:,:chasr:_:ttrlda:li:tast<ocoh<acrh>arcclhaass> >s &d : :>a lsl)o cc otstr<ctAasor>rtiiotn !`= i> &)i l_douniTlydpiensg:e ne(.Aes'nsdfe)ir'e diain `
it
!= m_buildingTypes.end()' failed.
c:\build\tpf2_steam\src\game\procedural\buildingtyperep.cpp:373: const struct BuildingType &__cdecl BuildingTypeRep::GetType(const class std::basic_string<char,struct std::char_traits<char>,cla\suil \spt2_ste:ama\slrcl\oame\ptroor<cehuraalr\b>uildingtyper ep>c p&) :const: Assertion `it != m_373il:din gTcynpset sst.ruectn Building'ypef &__cled.ecl Buildin
TypeRep::GetType(const class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > &) cnst: Assertion `it != m_buildingTypes.end()' failed.Soweit ich weiß, ist boundingInfo für Modelle und collider für Konstruktionen. Da skipCollision vermutlich für alles gilt, würde ich versuchen die boundingInfos anzupassen.
Na dass man nicht mehr für jede Geschwindigkeit, jeden Typ oder jedes Zusatzzeichen ein eigenen Eintrag braucht und man sich ewig durch die Listen scrollen muss (früher gab es ja nichtmal Kategorien, geschweige denn eine sinnvolle Reihenfolge). Bei einer gewissen Zahl von Kombinationen explodiert das sehr schnell und wird unübersichtlich. Und am Ende ist genau das Signal, was man haben will, nicht dabei.
Aber das hat nichts mit Vorsignalen zu tun (außer dass man über die Konstruktionsparameter einfach die Vorsignalvariante auswählen kann).
Damit die auch funktional sind, müssten die Entwickler das Signalsystem ändern.
Verrückt...
Relevant ist noch, welche Gleismods du installiert hast (oder vor kurzem (de)aktiviert hast) und ob du die Beta hast.
Wer sagt, dass UG nichts an den fps ändern will? Woher hast du diese Info?
Hab ich das gesagt?
Ich habe behauptet, das Update enthält keine Änderungen, die wesentlichen Einfluss auf die FPS haben.
Außerdem unterstützt TPF 2 bereits multithreading.
"Unterstützen" ist eine sehr pauschale Aussage. Fakt ist, im Gegensatz zu TPF1 sind Gui und Simulation wesentlich getrennter. Das heißt nicht, dass damit alle Probleme gelöst sind.
Es gibt einen Script Thread und ich nehme an, dass die Simulation dort komplett läuft und eben in den 200ms fertig sein muss. Möglich wäre es aber, z.B. Pfadberechnungen und Fahrzeuge parallel zu berechnen und verschiedene Zyklen zu benutzen.
