Ankündigung Transport Fever 3
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
-
-
Wenn wirklich Offshore Industries und Helicopters der große Gaga-Hype sind, dann bin ich schon jetzt ziemlich skeptisch.
Dass die Tycoon Features verbesserungswürdig waren, ist klar, aber ich fürchte, dass es zu Lasten des Schönbaus gehen wird. -
Es gibt Neuigkeiten. Ein Entwickler von UG scheint ein Interview gegeben haben, den Artikel gibt es hier.
LG Ben
Die Lok auf dem 2. Bild sieht komisch aus. Weiss man denn, welche Lok das Vorbild ist? Von der Anordnung der unteren Lampen könnte man meinen es sei die Renfe Baureihe 251.
-
Ist eine japanische Kapspurlok
(Und bevor jemand wieder fragt, die Lok ist korrekt schmalspurig modelliert)
Und wir haben zurzeit ein Trailer, ein Interview und acht Screenshot.
Jetzt schon zu sagen obs schlecht oder gut wird, ist viel zu früh
-
die Frage ist halt, ob die begrenzten UG Ressourcen wirklich sinnvoll eingesetzt wurden.
Das Feature mit den Helicoptern hätte ich definitiv nicht gebraucht bzw. hatte ich bisher Hubschrauber als Transportmittel in keinem Teil der TF Reihe wirklich vermisst.
-
Was ich gut finde, dass laut dem Interview es keine einheitliche Höhe gibt, sondern Flüsse von oben nach unten fließen sollen.
-
Da werden gute Neuerungen angesprochen. Hat jeder das Interview gelesen oder soll nur pauschal auf Helikoptern rumgehackt werden?
ZitatThe placement of maintenance facilities then becomes crucial because they’re not inexpensive.
Ergo Betriebswerke. Wie schön man die bzw. das optische Drumherum baut, bleibt einem selbst überlassen. Es ist dann aber eine Mischung aus Notwendigkeit einer guten Planung und eigenem Schönbauanspruch. Bei vielen ist das heute ja strikt getrennt, entweder schön aber alles "fake" oder Wirtschaftssimulation möglichst hübsch zu bekommen, ohne dass der PC abraucht. Naja, oder ganz extrem: Vanilla pur und es löppt sogar einigermaßen.
-
Naja, ich hätte es halt gut gefunden, wenn neben irgendwelchen wahnsinnig aufregenden Helikopter-Features auch vielleicht eine gesteigerte Vorbildtreue beworben würde. Zum Beispiel scheint es immerhin so zu sein, dass Trams künftig tatsächlich in der Straßenmitte verkehren (wobei die Gleise immer noch merkwürdig aussehen). Es gäbe wirklich zig Sachen, die wichtiger wären, als Helikopter, die dann auf einer "Weltkarte" mit der Größe von wenigen Quadratkilometern (!) herumfliegen, was mich dann irgendwie an diverse fragwürdige "von-den-Alpen-bis-zum-Strand"-Modellbahnen erinnert. Vor allem gäbe es viele Altlasten zu beseitigen, schaut euch z.B. die verstümmelten Weichen oder die Fahrdraht-Rohre an, nur ein Besipiel! Eigentlich müsste UG nur einmal diverse Mods erforschen (z.B. die Sachen von eis_os, VacuumTube, Lollus, okeating, enzojz oder meinetwegen auch mir), um festzustellen, wo noch brach liegende Potenziale zu verorten wären.
Aber vielleicht liege ich völlig falsch, und sie haben wirklich ihre Hausaufgaben gemacht. Dann allerdings hieße es: "Tue Gutes und rede darüber".
Oder es ist eben künftig nur noch ein reines Zockerspiel, das fände ich ziemlich traurig. -
Dass die Tycoon Features verbesserungswürdig waren, ist klar, aber ich fürchte, dass es zu Lasten des Schönbaus gehen wird.
Das glaube ich nicht, denn gleich zu beginn des Gespräches wird gesagt:
ZitatThat said, we don’t want existing players to miss out on what they love doing, so all the mod-support, customization, creative build options continue in the game, and they’ve all been given attention as well.
Das klingt doch eher positiv, besonders der letzte Halbsatz.
-
[...] Eigentlich müsste UG nur einmal diverse Mods erforschen [...]
... und mit den Mod-Autoren reden....!?
-
... und mit den Mod-Autoren reden....!?
Das wäre das verbesserungswürdigste Feature überhaupt - abgesehen von einer lückenlosen und verständlichen Dokumentation. Wer schon einmal im größeren Stil ein GUI gemoddet hat (dürfte weltweit eine Handvoll Personen sein), weiß, wovon ich rede.
Aber selbst die Erstellung simpler Splines oder das Update von Konstruktionen gleicht schon einer Doktorarbeit. Ich weiß, es verursacht Kosten - aber Support ist enorm wichtig, besonders, wenn ein Spiel vor allem von der Modder-Community lebt! -
Interessant, dass sich zu diesem frühen Zeitpunkt schon die "Nietenzähler" und Pessimisten melden, welche "Standarts" sie erkannt, bzw. vermissen, oder zu Gunsten anderer darauf verzichten würden.
Die Entwicklung des Spiels befindet sich in einem frühen Alpha Stadium. Also alles was jetzt zu erkennen ist, wird im fertigen Spiel vielleicht nicht so sein.
Und Features, die jetzt genannt werden, werden implentiert und erst im fertigen Game, wird man sehen, obs gelungen ist.
-
Die Entwicklung des Spiels befindet sich in einem frühen Alpha Stadium. Also alles was jetzt zu erkennen ist, wird im fertigen Spiel vielleicht nicht so sein.
Mit Ausnahme der sensationellen und überaus coolen Helis und Bohrplattformen.
Ja, ich weiß, ich bin eine Spaßbremse. 
-
Für das Feature kann ich auch (O)TTD(Patch) spielen... Bzw. das hab ich vor 20 Jahren schon, und da waren Ölplattformen am besten mit Zug anzubinden, Schiffe waren erst mit meinen Kanal und Schiffshebewerken wirklich brauchbar... Und ja, Wasserwege und dann über Höhenstufen in Transport Tycoon sind eine Idee und Umsetzung von mir. *
Und das mit den Trams, nun ja das ist ja keine Raketenwissenschaft. Auch wenn man den c++ Code hat, und nicht ne Assemblersuppe.
Der Renderer für die ganzen Straßenfeatures fehlt halt, Rasengleise? Verschiedene Oberleitungsmodelle?
Wobei UG hier viel mehr Möglichkeiten hätte und nicht wieder alles in einen Gleistyp zwängen müsste, aber mein Feedback geht ja nach /dev/null
Und sagt mir nicht, das geht nicht. CommonAPI2 zeigt doch ganz genau, dass das alles möglich ist.
Wenn man sich den Banner anschaut, sieht man nichts neues, das CommonAPI2 nicht schon für TPF2 anbietet.
https://gamingbolt.com/wp-cont…nsport-fever-3-banner.jpg
Ggf. sehen wir da halt ne Änderungen der Nodeverbindungen und Trams in der Mitte der Straße. Ganz Toll...
Alles was in Trailern angedeutet wird, nehme ich nicht ernst, bevor ich das nicht selber ausprobieren kann.
* Und einen Prototypen für Schiffskanäle in TPF2 hätte ich auch... Da andere Features auch nicht so doll angenommen werden, ist die Zeit nur nicht wirklich gut investiert und daher lasse ich es...
-
Nun ja, gerade CommonAPI2 hat ja die früher oft genutzte Phrase: "Nicht modbar!" ad absurdum geführt... 😏
-
CommonAPI2 hat ja die früher oft genutzte Phrase: "Nicht modbar!" ad absurdum geführt...
Mit Eingriffen in den Hardcode ist alles modbar - bis hin zu einem komplett neuen Spiel

Mit der hauseigenen API ist aber trotzdem vieles nicht oder nur mit heftigen Tricksereien modbar. Das ist sehr schade, wäre schön, wenn sich da in TpF3 was ändern würde. -
Ja mal sehen ob es dann Workers and Resources:Soviet Republic, das Wasser reichen kann,bin gespannt.
-
WernerK : Ich kann das nur von der Warte des Beobachters beurteilen. Was tief in der Programmierung drin steckt und welche Möglichkeiten da offen stehen, lässt mir nicht erblicken.
Von daher sind viele Funktionen von CommonAPI2 virtuell von mir mit Fragezeichen beflaggt.
Aber manchmal kommen Modder, wie euereins mit Dingen um die Ecke, wo ich mir sage: " Guck an..., dabei hieß es doch, das sei nicht möglich!"
Über das WIE bin ich mir meist nicht im klaren, aber freuen kann ich mich darüber 😄
Hoffe mal, dass sich das in Zukunft auch nicht ändert...
-
Das schlimme ist halt, wenn man sich bestimmte Sachen in CommonAPI2 anschaut,
die Entwicklungszeit zum Ziel absurd hoch ist (weil UG Sachen nicht Umsetzen möchte).
Die Umsetzung dann gerade lächerlich klein ist.
Und der Support Code an das Ziel zu kommen dann 99% der Arbeit ausmacht.
Beispiel, ich hab ewig versucht mit Bordmitteln die Daten der Lane Configuration für geschlossene Lanes (Rotphase) in eine Konstruktion zu speichern,Im Endeffekt hab ich nun Code um Konstuktionsskripte .script auszuführen, das musste ich mir erst mühsam in 2 Monaten mit Vorwissen erarbeiten, wie das funktioniert...
https://commonapi2.bytetransfe…?id=constructionextradesc
ConstructionAddon hat dann gerade mal 1000 Zeilen, so ca. 200 Zeilen beschäftigten sich wirklich um ein Node auf gesperrt zuschalten, damit zum Beispiel die Klappbrücke funktioniert.
Hätte ich Platz in einer eigenen Entity Komponente und Scripte aufrufen, oder ein bisl Platz im ConstructionBuilder, oweia wäre das Produktiv ...
Da wären wir schon bei TPF4 oder einem Tram DLC...
Bestimme Sachen liefen noch in TPF1, Animationen starten via API, das wurde aber fallen gelassen. (Es gibt triftige Gründe, aber CommonAPI2 baut was vergleichbares wieder ein)
Ggf. hat man sogar weniger Optionen in nachfolgenden Versionen von TPF also...
Um das mal mit dem Code zu veranschaulichen, sobald der Script Code mir die edges herauswirft, die den Verkehr der Brücke anhalten soll, wird der Code hier aufgerufen:
Code
Alles anzeigenvoid LockConstructionEdges(ecs::Engine* engine, ecs::TransportNetworkSystem *transportnetworksystem, const ecs::Entity *entity, ecs::component::TransportNetwork* transportNetwork, std::vector<std::pair<int, int>> &edgeBarrier) { transport::EdgeUseManager* edgeUseManager = transportnetworksystem->edgeUseManager; auto tpinternal = transportnetworksystem->m_tpNetData->tpinternal; auto key = tpinternal.m_key2index.at(entity->id); if (key < 0) { msglog(MSGLOG_ALWAYS, "LockConstructionEdges id = %i, no tpinternal.m_key2index", entity->id); return; }; auto dataForEdges = &tpinternal.m_index2data.at(key).edges; auto edgesSize = transportNetwork->edges.size(); for (auto it = edgeBarrier.begin(); it != edgeBarrier.end(); it++) { auto edgeid_index = it->first; if (edgeid_index < 0 || edgeid_index >= edgesSize) { continue; } auto edge = &transportNetwork->edges.at(edgeid_index); transport::PortId portId; if ( it->second != 1) { portId.nodeid.id = edge->conns0.id; portId.nodeid.index = edge->conns0.index; portId.port = dataForEdges->at(edgeid_index).ports[0]; } else { portId.nodeid.id = edge->conns1.id; portId.nodeid.index = edge->conns1.index; portId.port = dataForEdges->at(edgeid_index).ports[1]; } //msglog(MSGLOG_ALWAYS, "SetPortLocked portid.nodeid.id = %i portId.nodeid.index = %i portId.port = %i", portId.nodeid.id, portId.nodeid.index, portId.port); if (!edgeUseManager->GetPortLocked(&portId)) { edgeUseManager->SetPortLocked(&portId, true); }; }; }; Und das ist der Teil der die laneConfigFn aufruft und die Daten holt: try { std::lock_guard<std::mutex> lock(LockUnlockConstructionEdges_mutex); auto result = conDescExtra->runLaneConfigFn(gameState, &con->params); if (result.isNil()) { return; } auto ctx = luaTPF::access_context::create(); luaTPF::Table* tableEdgeBarrier; if (result.get("tnBarrier", &tableEdgeBarrier, false)) { auto ctxEdgeBarrier= luaTPF::access_context::addKey("tnBarrier"); for (auto it = tableEdgeBarrier->daten.begin(); it != tableEdgeBarrier->daten.end(); it++) { std::string keyStr; if (it->first.isString()) { keyStr = it->first.getString(); } else { keyStr = std::to_string(it->first.getInteger()); } auto ctxentrykey = luaTPF::access_context::addKey(keyStr); int32_t edgeId = -1; int32_t port = 0; bool portA = false; bool portB = false; if (it->second.get("edgeId", edgeId, true)) { if (it->second.get("portA", portA, false)) { } else { // not set, use default true portA = true; } it->second.get("portB", portB, false); if (portA) { edgeBarriers.emplace_back(edgeId, 0); } if (portB) { edgeBarriers.emplace_back(edgeId, 1); } }; }; }; } catch(std::exception &e) { msglog(MSGLOG_ERROR, "Exception in LockUnlockConstructionEdges runLaneConfigFn (%s) %s", con->fileName.c_str(), e.what()); } if (!edgeBarriers.empty()) { try { LockConstructionEdges(engine, transportnetworksystem, entity, transportNetwork, edgeBarriers); } catch(std::exception &e) { msglog(MSGLOG_ERROR, "Exception in LockConstructionEdges %s", e.what()); } };Feature komplett, mit Modding Support...
Der luaTPF::access_context::addKey Circus mache ich um brauchbare Fehlermeldungen zu erstellen,
wenn ich das weglasse, könnte ich noch Code streichen...
PS: Der Code ist auf meinem eigenen Mist in der Freizeit entstanden, Namen für APIs oder Klassen sind an TPF2 angelehnt, aber sind mein eigener Code der ggf. TPF2 Code aufruft.
Ich habe meine eigenen C++ Header für den ganzen Kram, daher ist die Umsetzung quasi C++ Code ohne Klassen Support.
Zurück zum Thema:
Bessere API wünsche ich mir, brauchbare API Bindungen auch. Städte und Hausbau? Mindestens 20% des Proposal für Konstruktionen in TPF2 könnt Ihr gar nicht sehen...
-
Für das Feature kann ich auch (O)TTD(Patch) spielen... Bzw. das hab ich vor 20 Jahren schon, und da waren Ölplattformen am besten mit Zug anzubinden, Schiffe waren erst mit meinen Kanal und Schiffshebewerken wirklich brauchbar... Und ja, Wasserwege und dann über Höhenstufen in Transport Tycoon sind eine Idee und Umsetzung von mir.
Als ich im Interview "you’ll want to carry workers out to those [offshore] industries – fishing farms, sand excavators, and oil platforms" gelesen hatte, dachte ich auch, "Das kann ich (mit dem passenden Industrie-Set) auch in OpenTTD." 🤷♂️
Dennoch halte ich das für eine interessante Erweiterung.
Tschö, Auge