Beiträge von Von Blankenburg

Nicht, dass ich wüsste.

Hallo zusammen,

ich habe das Problem, dass bei mir grundsätzlich alle Züge wenden – auch die mit Triebwagen. Was kann man da tun? Muss man das neue Feature eventuell irgendwo aktivieren?

Beste Grüße

Zitat von TT junkie

Was ich ziemlich lahm finde ist die Umsetzung der Metroliner Triebwagen:

Das habe ich mir auch schon gedacht. Das hätte man schöner lösen können.

Hallo zusammen,

ein Klassiker der Eisenbahn sind steinerne Viadukte (Bild). Leider vermisse ich diese in TpF völlig. Wäre es möglich, solche nachzumodden bzw. arbeitet vielleicht sogar schon jemand daran?

LG
von Blankenburg

Wenn zwei Linien denselben Weg haben, so wird immer der schnellste benutzt. Ich habe gestern versucht, eine Alttrasse für den Regionalverkehr zu nutzen, aber keiner wollte damit fahren, da die Schnellzüge flotter waren. Wäre vielleicht eine Erweiterung für die Zukunft, dass die Leute eben nicht nur das Verkehrsmittel sondern auch die Linie nach persönlichem Gusto wählen (Schnellzug, Regionalzug).

My system also tends to crash when building tunnels. The problem is reproducable, if it happens: I can load the autosave, build a tunnel at the same position again, and it will crash in all cases. The only way to fix this is to load an older autosave (a year before).

@Streichholz [GER] Ich habe zumindest gesehen, dass man Weichen auch im Bahnsteigbereich setzen kann. Womöglich kann man da auch Haltesignale setzen.

Ich habe gestern bei Steam einen Mod runtergeladen, wo oben Bus- und unten Tramstation ist. Die Busse müssen dabei über eine Rampe auf die zweite Ebene fahren.

Zitat von darkman61980

Kann man bitte bei den Zügen nicht gleich die Werte einfügen was sie im Normalfall befördern können? Das mit den ganzen Zugkraftrechnern ist ja schön und gut, aber dafür jedesmal nen Programm anwenden geht mir auf den Nerv. Einfach beim Zugkauf unter den Zugdetails reinschreiben das dieser Zug 25 Waggons Schüttgut, oder 30 Waggons Waren usw. bei voller Beladung transportieren kann.

Ich finde die Art, wie es in Transport Gigant umgesetzt war eigentlich ganz schön: Man plant zunächst den Zug, indem man Loks und Wagen auswählt. Ein einfacher Prozentwert zeigt dann an, wie ausgelastet die Zugmaschine(n) ist/sind.

Nun ist mir klar, dass die Welt im Transport Gigant flach war. Daher müsste man bei TpF die Anzeige erweitern. Das könnte man entweder über eine Tabelle machen mit Steigung und Beschleunigung sowie Höchstgeschwindigkeit, oder man wählt direkt in der Planungsphase die Linie aus und bekommt ein Diagramm angezeigt, wie schnell der Zug an welchem Streckenabschnitt unterwegs sein wird.

Hier ein Beispielbild.

Ja.

Ein Kreuzungsbahnhof wäre eine total tolle Sache!

Das mit den mehreren Gütern hat man wohl der Einfachheit halber weg gelassen.

Zitat von Nordwestexpress

Ich frage mich wirklich langsam, wie es zu so grossen Unterschieden auf den Rechnern verschiedener User hier kommen kann, obwohl es mit der Leistung selbiger nicht zu erklären ist

Ich denke, dass es an der Kombination aus CPU und Betriebssystem liegt. Es könnte durchaus sein, dass das Spiel für aktuelle Prozessoren optimiert wurde, die natürlich einen optimierten Befehlssatz haben. Kommt man nun mit einem 5 Jahre alten Rechenwerk daher, und sei es auch noch so schnell, müssen die modernen Befehle umständlich emuliert werden und das Spiel läuft plötzlich um den Faktor 20 langsamer. Ich habe vom Lesen auch das Gefühl, dass überwiegend Leute mit Windows 10 Probleme haben.

Zitat von AJaey

Prinzipiell braucht der Entwickler lediglich die Direkt X Schnittstelle anzusprechen, den Rest übernimmt dann Direkt X für die Grafik in Kombination mit Grafiktreiber und der CPU, Windows, die CPU für grundlegende Berechnungen der Spielemechanik... etc etc...

Fakt ist, dass die Hardware im Durchschnitt unterfordert ist und das Spiel trotzdem besonders im Lategame extrem an Performance verliert. Das liegt hauptsächlich an der Berechnung der eigentlichen Simulation, welche nicht verschönert wurde (wie z. B. beim letzten SimCity oder bei Cities Skyline) , sondern mit tatsächlichen Werten arbeitet. Jeder Bewohner hat ein echtes Haus, echte Arbeit... Die Simulation ist extrem umfangreich. Und bei mehr als 20000 Einwohnern mit seinen zig tausend Parametern... Da muss ganz viel zu einer bestimmten Zeit und in einer festgelegten Reihenfolge berechnet werden.

[...]

Diese selbst entwickelte Engine liegt dem Spiel aber nunmal zu Grunde. Das Budget baut darauf auf.
Was würde die Entwicklung über eine andere, leistungsfähigere aber dafür kostenpflichtige Engine kosten? Kann man das dann noch mit einem 5 Mann starken Team stemmen und können die zu erwartenden Verkaufzahlen die Ausgaben decken?

Alles anzeigen

Ich will Dir nicht zu nahe treten, aber das klingt alles sehr nach Hörensagen. Nein: Man muss nicht einfach irgendwie so "lediglich die DirectX-Schnittstelle ansprechen", und schon läuft das Spiel von selbst. Hinter TpF werden aus meinem Erfahrungshorizont mit Sicherheit mindestens 1 Mio. Zeilen Code stehen, die erst einmal geschrieben und erdacht werden müssen. Ein Computerspiel entwickelt man nicht mal eben so nebenher.

Zitat von Blowfly

Also wenn es an diesen Kosten scheitern würde braucht man gar nicht erst anfangen zu programmieren. Ich möchte nicht wissen wie viel Mannstunden (sprich Geld) die Eigen-(Weiter- ?) Entwicklung der eigene Engine gekostet hat.

Kann mir ehrlich gesagt nicht vorstellen, dass Eigenentwicklung günstiger als die o.g. Engines ist.

Eine Engine alleine ist nicht alles. Außerdem, und das vergessen viele, schnürt eine fertige Engine immer ein Korsett, aus dem man sich nur schwer befreien kann. Sowohl Unity wie auch Unreal sind beide Engines, die ursprünglich für Spiele aus der Ego-Perspektive entwickelt wurden. Für eine komplexe Aufbausimulation wie TpF können sie sich als völlig ungeeignet erweisen, da hier die Anforderungen ganz anders gesteckt sind. Hier geht es nicht darum, den einzelnen Baum mit einem möglichst hohen LOD (Detailgrad) darzustellen oder eine perfektionistische Tierfellsimulation zu bieten. Was bei TpF (und anderen Aufbauspielen) notwendig ist sind verformbares, hochauflösendes Terrain, die Darstellung von zahlreichen Objekten gleichzeitig und und und. Noch dazu kommt, dass diese Engines oft viel Fachwissen benötigen, um sie richtig zu bedienen. Klassische Programmier-Expertise reicht hier oft nicht aus.

Kurzum: Aus fachlicher Sicht gibt es überhaupt keinen Anhaltspunkt anzunehmen, dass das Spiel auf Basis der Unity-Engine (o.Ä.) in irgend einer Form besser geworden wäre. Dazu kommt, dass bereits vom Vorgänger eine Basis vorhanden war, die man als Basis nehmen konnte. Dazu auch:

Zitat von Nordwestexpress

Da stellt sich mir dann die Frage:
Wie problemlos lässt sich eine solche Engine einbetten? Ich bin kein Profi-Programmierer und weiss daher nicht, wie schwer es ist, von der eigenen Engine auf eine andere umzusteigen...

Das Haus und den Hof nehme ich gerne. Die Wette verlierst Du nämlich (mit hoher Wahrscheinlichkeit). Das Problem hier ist die Simulation, und die hat mit der Engine nichts am Hut. Die Simulation von 20.000 virtuellen Bürgern ist nicht ohne. Hier kann nur durch Parallelisierung und starke Optimierung durch einige Kunstgriffe ein sinnvolles System erschaffen werden. So macht es beispielsweise einen Unterschied, ob ich in jedem Frame die Position aller Bürger anhand ihrer Wege neu berechne, was relativ leicht umzusetzen aber schrecklich unperformant ist, oder ob ich mir nur diejenigen, die gerade sichtbar sind "intelligent" herausfiltere und deren Bewegung simuliere. Ich kann quasi für jeden Bürger eine exakte Wegstrecke berechnen und dann in jedem Frame die x- und y-Koordinaten anpassen, oder ich speichere zum Zeitpunkt des Spawns den Soll-Weg und die Ankunft am Ziel. Letztlich brauche ich dann in jedem Frame nur noch meine Liste jedes Frame abfragen und wenn die Timer abgelaufen sind die Bürger/Waren dem nächsten Lager/Ort zubuchen. Solch eine Optimierung erfordert jedoch erhebliche Gedankenarbeit. Da ist es einfacher, jeden Bürger quasi in einer For-Each-Schleife nach Schema F abzukanzeln. Und ich denke, dass TpF genau letzteres macht.

Eingebettet wird da letztlich gar nichts. Man kann sich das Ganze eher so vorstellen, dass man das Spiel an die Engine "heranprogrammiert". Eine Engine stellt einen gewissen Katalog an Schnittstellen bereit, welche vom eigentlichen Spiel angesprochen werden. Da könnte es beispielsweise einen Befehl geben, um ein Objekt an eine bestimmte Stelle im virtuellen Raum zu platzieren. Das eigentliche Spiel gibt nur Objekt und Koordinaten an die Engine weiter, der Rest läuft in einer "Blackbox" ab.

Da diese API-Befehle in keiner Weise genormt sondern stets propritär sind kommt der Tausch der Engine quasi einer Neuentwicklung gleich. Klar kann man die meisten Codefragmente wiederverwenden, jedoch muss vielen angepasst und einiges komplett neu geschrieben werden, da auch nicht jede Engine gleich funktioniert. Es ist völlig unrealistisch, ein fertiges Programm an eine komplett andere Engine anzuflanschen.

Ich vermute ja fast, dass das Problem dasselbe ist wie mit meinen Schiffen. Ich habe das Gefühl, dass ein Teil der Passagiere/Waren bereits für das nächste Fzg. vorgemerkt wird und deshalb an der Station verbleibt.

Ich hatte aber gestern auch eine Situation, wo ein Zug zwischen drei Städten gependelt ist. Dabei ist es vorgekommen, dass Passagiere von Station B nach A mitgefahren sind, im Zug blieben, wieder zurück zu B, wieder sitzen geblieben und dann zu C. Irgend etwas scheint da auch noch nicht zu stimmen.

Bei der Europa-Mission mit den Inseln ist mir aufgefallen, dass Schiffe teilweise gar nichts laden und leer losfahren, obwohl von mehreren Gütern zahlreiche Waren (50+) für die Linie vorrätig sind. Hat das sonst noch wer beobachtet?

Diese Ruckler alle paar Sekunden habe ich auch. Und auf meinem System gibt es definitiv keine Onboard-Grafikkarte.

Zufällig auch Windows 10?

Da möchte ich mich anschließen. Die Performance ist (bei den meisten Rechnerkonstellationen) miserabel. Punkt. Da lässt sich nichts wegdiskutieren und nichts schönreden. Und das ist ein Punkt, der nun hoffentlich mit Hochdruck angegangen wird, sobald die Blocker-Bugs behoben sind.

Andererseits kenne ich - als erfahrener Softwareentwickler - auch die Probleme, mit denen sich die Entwickler herumschlagen müssen. Was hier so alles geschrieben wird von Leuten, die vermutlich noch nie eine Zeile echten Code geschrieben haben, ist bemerkenswert. Das klingt oft so, als seien die Jungs bei UG zu blöd oder würden gar böswillig auf die Optimierung verzichten.

Man muss in der Softwareentwicklung Kompromisse eingehen. Hier gilt, wie so oft, die 80-20-Regel: Um eine Funktion X irgendwie solala ans Laufen zu bekommen benötigt man 20 % der Zeit. Die restlichen 80 % der Zeit braucht man zum optimieren bis zur Perfektion.

Rechnet also nicht damit, dass die Ruckler sich binnen der nächsten paar Tage beheben lassen! Das kann mitunter viele Monate dauern, bis die Optimierung richtige Früchte trägt. Das ist mit Arbeit in erheblichstem Umfang verbunden.

Ich habe das Gefühl, dass Schiffsrouten ab einer gewissen Entfernung nicht mehr funktionieren, wenn nicht zahllose Schiffe eingesetzt werden. Das Problem ist, dass das Eingangslager an der Gütersenke regelmäßig leer läuft und die Quelle dann die Produktion zurückfährt. Man benötigt also Trotz der enormen Lademengen eines Schiffes einen zügigen Takt. Und dann fressen meistens die Betriebskosten alles auf.

Hallo zusammen,

ist das eigentlich Absicht, dass der Fluss zu den drei Ölfeldern um den kleinen See nicht schiffbar ist? Leider kann man scheinbar den Fluss auch nicht mit den Terraformingtools verbreitern. Sehr schade!

Mir ist noch etwas aufgefallen, was vielleicht nicht jeder von Euch genutzt hat. In TF konnte man grundsätzlich ein Signal vor eine Weiche setzen. Man konnte das beispielsweise an Kreuzungen unmittelbar nach dem Bahnsteig nutzen. Schließt man hingegen in TpF eine Weiche direkt an den Bahnsteig an, so kann dazwischen kein Signal mehr gesetzt werden. Man muss hier also immer Platz einplanen.