Neue Transportsimulation von Urban Games

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


  • Denn diese Flugobjekte haben keinen Wirtschaftlichen Nutzen im Transport und Fracht-Bereich.

    In sehr unwegsamem Gelände werden Helis zum Teil für Holztransporte eingesetzt. Wie wirtschaftlich diese sind, weiss ich nicht.


    Für den Bau von Bergstationen (die wünsche ich mir ohnehin), werden ebenfalls oft Helis eingesetzt.

  • In sehr unwegsamem Gelände werden Helis zum Teil für Holztransporte eingesetzt. Wie wirtschaftlich diese sind, weiss ich nicht.


    Für den Bau von Bergstationen (die wünsche ich mir ohnehin), werden ebenfalls oft Helis eingesetzt.

    Dennoch sind auch der Aufgabenbereich ehr eine Ausnahme als die Regel. (Global betrachtet)
    Schaut Euch einfach mal den Betrieb eines "gewöhnlichen" Flughafens an, und schaut wie stark diese von Hubschraubern frequentiert werden. (Im Vergleich zu Flugzeugen) ;)


    Die stärken von Hubschraubern liegen ehr in der Luftraumüberwachung, Rettung, Militär und individual/VIP Transport.
    Kaum etwas, was in einem Spiel wie TPF Gewicht hätte.


    Ps: Im Bereich Bohrinseln dienen Hubschrauber in der Tat Hauptsächlich dem Transport von Personen (Arbeitern).
    Wobei diese meist auch auf den Bohrinseln "leben".
    Alles andere wird meist über Schiffe/Pipelines abgewickelt.

    Ich bin nur dafür verantwortlich was ich schreibe, nicht was andere verstehen "wollen"!


    System: Windows 7 Ultimate 64bit ; AMD Phenom II X4 965 @ 3,4 GHz ; 8 GB DDR3 Ram ; GeForce GTX 660 @ 3 GB GDDR5 Ram (Treiber: 431.36)

  • Man könnte also vermuten, dass die Kapazitäten nun nicht mehr fix auf bestimmte Güter ausgelegt sind, sondern auf Güterarten: Stückgut, Schüttgut, Flüssigkeiten, etc.


    Man könnte auch vermuten, dass Tanker einfach kein Stück- oder Schüttgut laden können...


    Zitat von Urban Games

    Die Zoroaster gilt als der erste erfolgreiche Öltanker und befuhr im späten 19ten Jahrhundert unter anderem das Baltische Meer und die Wolga.

  • Ja natürlich können Tanker kein Stückgut und kein Schüttgut laden. Ist ja logisch! Aber um das geht es mir nicht.


    Es geht mir darum, dass da nicht steht "240t Öl" sondern eben "240t Flüssigkeiten". Wenn jetzt die Capacities so definiert werden, statt das jede einzelne Frachtsorte eingetragen werden muss, dann würde das einiges vereinfachen. Damit dus auch verstehst, ein Beispiel:


    Nehmen wir den AIM. Dort gibts Kies als neue Frachtsorte. Will ich die jetzt in einem Fahrzeug transportieren, dass von Haus aus nicht darauf ausgelegt ist, so muss ich Kies händisch in (je)der *.mdl nachtragen. Da wäre es doch viel einfacher, ich könnte Kies als Schüttgut definieren und alle Fahrzeuge, die Schüttgut transportieren können, könnten dann auch Kies laden.


    Also beim den offenen Wagen würde einfach stehen: Kapazität = xy Schüttgut. Nehmen wir an, Vanilla gäbs Kohle und Eisen, die als Schüttgut definiert sind. Wenn ich eine neue Gütersorte reinbringen will (bleiben wir beim Kies), dann definier ich Kies als Schüttgut et voilà, schon kann ich in jedem offenen Wagen Kies transportieren.


    Analoge Beispiele für Flüssigkeiten gibts wohl genug: Öl, Benzin, Milch, etc.

    TT herrscht!

  • Naja, das ist denk ich leichter implementiert als alles andere, da das ja "nur" ein zusätzlicher Text ist im GUI. Außerdem denk ich, dass die Frachtart eh beim Kauf erstmal bestimmt werden muss (ihr kennt die Diskussion von der Einführung dieses Systems bei TF). Erst lädt der Tanker Benzin und danach Milch... mhhh ;)


    Und ja, ein System das auf die Ladungsart geht find ich gut :thumbup:

  • Was ich zur Zeit noch als realtiv suboptimal empfinde bei den Fahrzeugen, vorallem jenen des Nahverkehrs, dass nur Sitzplätze gerechnet werden...


    z.B. hat das Cobra Tram gemäss UG 96 Plätze - dies ist auch "korrekt", denn es hat 96 Sitzplätze, jedoch auch bis zu 142 Stehplätze, sprich eine totale Kapazität von 238 Passagieren...



    Ich finde dies insbesondere bei Nahverkehrsfahrzeugen doch recht problematisch, denn so hat z.B. en Doppeldecker Fernverkehrsbus wie der Setra S 431 DT mit 87 Sitzplätzen beinahe dieselbe Beförderungskapazität wie ein 36 Meter langes Tram...? (welches logischerweise Stehplatzoptimiert ist).


    Diese Problematik geht dann genau so weiter bei den Nahverkehrszügen, wo z.B. auch die Mirage Rabde 12/12 mit 200 Plätzen angegeben wird, auch dies ist bereits ein - immerhin für schweizerische Verhältnisse) - Stehplatzoptimiertes Fahrzeug mit grossen Stehplatzzonen bei den Eingängen, ebenso die 4 teiligen Flirts mit 8 Türen etc...



    Ich denke hier würde es sinn machen, bei ÖPNV als auch Regionalverkehrszügen Stehplätze mit einzuberechnen...

  • Ich würde dann sogar so weit gehen, und Steh- und Sitzplätze einzeln in der mdl auflisten. Ansonsten sind wiederum Fernverkehrszüge benachteiligt - aber auf Fernreisen mag man halt nicht so gerne stehen ;)


    Irgendwie müsste das Spiel dann noch den Unterschied zwischen Steh & Sitzplatz sowie Reise-dauer auswerten. Nur wie? keine Ahnung ;) (Vor allem da auf den doch eher kleinen Karten die Reisedauer im Fernverkehr oft nicht wirklich lang ist)

  • Also beim den offenen Wagen würde einfach stehen: Kapazität = xy Schüttgut. Nehmen wir an, Vanilla gäbs Kohle und Eisen, die als Schüttgut definiert sind. Wenn ich eine neue Gütersorte reinbringen will (bleiben wir beim Kies), dann definier ich Kies als Schüttgut et voilà, schon kann ich in jedem offenen Wagen Kies transportieren.

    Haben wir dann nicht wieder das Problem das in einem Wagen Kohle, Erz und Kies geladen werden? Dann hat ein Wagen wieder 30t Kohle, 30t Kies und 30t Erz geladen obwohl er nur für 30 Tonnen ausgelegt ist.

  • @Xanos: Näherungsweise? Es sollte ja bekannt sein, wo der PED ( :P ) aussteigt, der Takt ist ebenfalls bekannt -> Takt * zu passierende Halte = Zugverweildauer. Wäre zumindest ein Ansatz *denk* Gibt natürlich genau dann Probleme, wenn man stark ungleichverteilte Teilstückgrößen hat.


    @galippo: Lade nur wenn keine Fracht oder geladene Fracht == zu ladende Fracht ;) Problem gelöst.

  • @DarkMo Die Anzahl von Plätzen sowie die Dauer der Fahrt ist nicht das Problem, sondern die Auswertung ;) Was für einen Effekt soll es haben, wie genau wirkt es sich auf die Passagiere aus, wie bekommt der Spieler Rückmeldung, was er anders machen soll, etc...


    P.S.: Deine Rechnung für die Zugverweildauer ist definitiv falsch ;)

  • Haben wir dann nicht wieder das Problem das in einem Wagen Kohle, Erz und Kies geladen werden? Dann hat ein Wagen wieder 30t Kohle, 30t Kies und 30t Erz geladen obwohl er nur für 30 Tonnen ausgelegt ist.


    Nein, die Kapazität wäre 1x30t Schüttgut. Also 1x30t Kohle oder 1x30t Kies oder 1x30t Erz. Das Problem mit der Mehrfachbeladung war ja eben gerade, dass jede einzelne Frachtsorte in der mdl eingetragen war und sie sich so addiert haben. Nach dem Modell, dass man hier möglicherweise haben wird, steht in der mdl des Fahreugs lediglich die Frachtart, sprich Schüttgut. Einziges Problem, dass man irgendwie umgehen müsste, sind Teilladungen. Sprich 1x12t Erz + 1x8t Kies + 1x10t Kohle... oder 1x148t Milch + 1x90t Benzin + 1x12t Öl :D Das müsste man irgendwie verhindern.

    TT herrscht!

  • @DarkMo Die Anzahl von Plätzen sowie die Dauer der Fahrt ist nicht das Problem, sondern die Auswertung ;) Was für einen Effekt soll es haben, wie genau wirkt es sich auf die Passagiere aus, wie bekommt der Spieler Rückmeldung, was er anders machen soll, etc...

    Das könnte man auf ein ähnlich vereinfachtes Modell wie die 20-Minuten-Regel runterbrechen. Ich nenne es mal "3-Minuten-Regel":
    Immer dann, wenn ein Reisender ein Fahrzeug betreten will, in dem er voraussichtlich mehr als 3 Minuten bleiben wird, akzeptiert er nur einen Sitzplatz.
    Findet er keinen, wartet er auf das nächste Fahrzeug. So lange, bis seine 20 Minuten Gesamtdauer um sind.
    So kann dann auch der Spieler sehen, dass Leute warten, aber nicht einsteigen und daraus schließen, dass sie Sitzplätze brauchen.


    Ob jetzt 3, 5 oder 10 Minuten sei mal dahin gestellt...

  • Irgendwie müsste das Spiel dann noch den Unterschied zwischen Steh & Sitzplatz sowie Reise-dauer auswerten. Nur wie? keine Ahnung ;) (Vor allem da auf den doch eher kleinen Karten die Reisedauer im Fernverkehr oft nicht wirklich lang ist)

    Gemäss der Webseite gibt es ja ohnehin eine Neuberechnung für die Reisezeit mit der Abschaffung der 20' Regel. Da könnten sie ja aufnehmen, wie lange eine Person bereit ist stehend zu reisen. Also vom Wohnort zum Bahnhof "Ja", vom Wohnort zum Nachbarort "Nein". Gäbe vor allem für die Modder viel zu tun, wenn sie von gewissen Bussen dann eine sitzplatzoptimierte und eine stehplatzoptimierte machen müssen.


    Ein anderer Punkt ist für mich noch der Unterschied 1. und 2. Klasse. Züge mit viel (oder nur) 1. Klasse haben auch eine viel geringere Kapazität als solche mit viel (oder nur) 2. Klasse.

  • Nur meine Zufriedenheit geht halt runter.

    Da bleibt die Frage: Wie wirkt sich zufriedenheit aus? Die Leute können schlecht nach Zufriedenheit zahlen, also wäre es mMn am logischten, wenn die "Akzeptanz" der Linien/Fahrzeuge dadurch gesteuert wird. Sagen wir, es wird errechnet, ob jemand meine Linie(n) nimmt oder nicht. Am Ende kommt ein Wert X dabei heraus. Je nach Zufriedenheit wird dieser nochmal gehoben oder gesenkt - die Zufriedenheit faktorisiert also in irgendeiner Weise X -> X*Zufriedenheit. Ist X unterhalb eines Schwellwertes Y, nimmt unser lieber Heinzelmann also lieber das Auto bsp.


    Auf so einer Basis könnte man bspw auch nen Multiplayer mit Konkurrenz gut umsetzen. Dann gibts nicht nur meine Linien und das eigene Auto, sondern meine und Fremdlinien. Allerdings wird hier ein weiteres Problem deutlich: Man müsste die Berechnung nicht für den gesammten Weg vornehmen, sondern für jede genutzte Linie. Wenn man nun aber schon 2 Linien weiter ist, und ab da aber lieber das Auto nehmen wöllte... ^^ Also müsste man entweder sagen "nur wenn alle Teilstücke Liniennutzung ergeben, dann fährt er kein Auto" - oder eventuell noch besser: Nur wenn der Durchschnittswert aller X'e kleiner Y ist, nimmt er das Auto.


    Hmm, kompliziert ><

  • Was ich lustig finde, dass ihr hier Lösungen für Probleme diskutiert, ohne zu wissen, ob UG die Idee überhaupt aufgreifen wird und davon abgesehen, bei vielen Diskussionsteilnehmern scheinbar die Fachkompetenz für die diskutierten Probleme nicht vorhanden ist. Hinzu kommt, dass einige hier immer wieder Texte verfassen, die auf Logik-, Technik- und/oder Physikprobleme kombiniert mit unzureichendem Basiswissen schließen lassen.


    Wie ich schon mal schrieb, bin ich ja gegen Denkverbote und Ideen sollen hier ja auch genannt werden. Aber ich denke, dass die Diskussionen über vermeintliche bzw. gar nicht vorhandene Probleme hier nur den Thread unnötig aufblähen und die ganze Sache unübersichtlicher machen.


    Ich bin mir sicher, dass UG die Nennung der Ideen hier reicht und dann bei den Themen, die UG für TPF interessant findet, schon selbst in der Lage ist, für die programmiertechnische Umsetzung zu sorgen. Just my 2 Cents... ;)

BlueBrixx