Übersicht über die Änderungsvorschläge

Der Thread Verbesserungsvorschläge zu Transportfever ist mittlerweile 37 Seiten lang und damit besonders für neulinge schon lange nicht mehr übersichtlich.
Um allen einen Üerblick darüber zu geben, was bereits vorgeschlagen wurde, habe ich diese Liste erstellt.
Manche Vorschläge, die nicht identisch sind, aber das Selbe Problem lösen, habe ich zusammengefasst.
Andere Vorschläge, die sehr schwammig formuliert oder bereits umgesetzt sind (einschließlich Beta build 12663) oder zu denen ein Tipp gegeben wurde bei dem ich den Eindruck hatte, dass dieser das Problem für den Nutzer auf andere Weise zufriedenstellend gelöst hat, habe ich nicht in die Liste übernommen.

So bald ich die Liste fertiggestellt habe, könnt ihr mir in diesem Thread gerne mitteilen, falls ich einen Vorschlag übersehen habe und könnt hier auch neue Vorschläge posten. Ich werde diese dann in die Liste übernehmen und entsprechend verlinken.
Bitte beachtet, dass es ein wenig dauern kann, bis ich alle 37 Seiten des Threads durchgelesen und entsprechend übernommen habe (bis Seite 2.5 bzw. Post50 bin ich bereits gekommen...).

Erklärung:
Beschreibung ist eine kurze Beschreibung des Wunsches. Diese sind mit dem ersten post der diese Verbesserung vorschlägt verlinkt.
Community Rating gibt an wie wichtig der community eine bestimmte Verbesserung ist. Ich werde dazu eine Umfrage starten so bald die Liste vollständig ist und die Ergebnisse in die Liste übertragen.
Status wird auf "Umgesetzt" gesetzt, wenn ein Verbesserungsvorschlag in das Spiel eingebaut oder durch eine Mod umgesetzt wurde. Ggf. folgen weitere Stati wie "Angekündigt", "WIP" etc.

Karten/Missionen

UI/Interaktion

Verkehrswegebau

Modelle

Gameplay

Modbarkeit

Sonstiges

@GrumPa da hast du vollkommen Recht.
@pdca_cycle Die Zusammenfassung ist nicht schlecht aber da ich den Vorschlag jeweils verlinke, da ich die Beschreibung in der Liste zur Übersicht möglichst kurz halten möchte und einige Vorschläge schon ziemlich ins Detail gehen, werde ich zum verlinken wohl doch alle Seiten nochmal durchwühlen müssen.
Fürs erste werde ich die Zusammenfassung aber übernehmen und ab dort weiter machen.
Auch deine Unterteilung werde ich teilweise übernehmen. u.a. weil UI/Interaktion ansonsten eine ziemlich lange Liste würde

Zitat von Merk

Einstellungsfenster für Mods

UG hat da scheinbar auch bereits drüber nachgedacht und damit angefangen das einzubauen. Scheinbar haben die die Funktion aber nicht fertiggestellt
Z.B. in einigen campaign mods (urbangames_campaign_usa_mission_04_1 Tauchen folgende Zeilen auf:

Zitat von Merk

neue Events für Fahrzeuge: coupled_front und coupled_back

Wie wäre es mit properties und dazu passenden property handlern für Fahrzeuge und Verkehrswege (sowohl für das den Verkehrsweg an sich als auch für alles was daran angebaut wird) ggf. sogar erweiterbar auf Gebäude etc.

Jedes Fahrzeug und jeder Verkehrsweg hätte dann ein properties Objekt, das einfache erstmal bedeutungslose key/value Paare speichert. Ein Wert (value) kann entweder lokal oder mit allen die den gleichen key nutzen geteilt werden. (in Lua auch umsetzbar ohne, dass UG hier explizit einen Unterschied macht)

Fahrzeuge haben zusätzlich mehrere property handler.
Mir fallen so spontan 2 sinnvolle handler für Fahrzeuge und einer für die Verkehrswege ein:
kannGekuppeltWerden, kannFahren und kannBefahrenWerden.

Alle handler funktionieren prinzipiell sehr ähnlich: Es wird das gesamte "eigene " Objekt (mdl) übergeben, welches dort auch verändert werden kann und die properties der mit dem aktuellen Objekt interagierenden Objekte übergeben und es wird true oder false zurückgegeben.

//wird Im Depot für alle existierenden Fahrzeuge aufgerufen, wenn das Depot geöffnet wird und jedes Mal wenn ein Wagen hinzugefügt wird.
//Wird als Filter für die Depotansicht verwendet. War das feedback negativ, wird das Objekt nicht im Depot angezeigt, ansonsten schon.
function kannGekuppeltWerden(ichSelbstFahrzeug, prevProperties)->Feedback;


//Wird für alle Wagen der Zusammenstellung im Depot aufgerufen, nachdem ein Wagen hinzugefügt wurde. Ein Fahrzeugverband kann nur dann das Depot verlassen, wenn für alle Fahrzeuge der Zusammenstellung der Aufruf kannFahren positiv war.
function kannFahren(ichSelbstFahrzeug, prevProperties, nextProperties)->Feedback


//Wird aufgerufen, wenn die Wegfindung eine Linie über einen Gleisabschnitt schicken möchte.
//Eine Linie kann nur dann über einen Verkehrsweg verlaufen, wenn alle Fahrzeuge die aktuell der Linie zugewiesen sind diese auch befahren können.
function kannBefahrenWerden(ichSelbstVerkehrsweg, fahrzeugProperties)->Feedback


class Fedback{
  boolean darfGemachtWerden;
  String userInformation
}

Kurze Erläuterung zum vorgesehenen Zweck der Funktionen:
kannGekuppeltWerden soll verhindern, dass gänzlich inkompatible Systeme zusammengekuppelt werden. z.B. Schmalspur Wagen an normalspur Loks oder aber auch ICE Wagen an normale Loks (ja ich weiß in Sonderfällen ist das möglich aber dann kann die Lok ja einfach eine passende property für die Spezialkuppelung angeben)
Außerdem dürfte das Depot dadurch etwas aufgeräumter werden.

kannFahren ist vermutlich selbsterklärend. In erster Linie wird z.B. geprüft, ob an der Spitze des Zuges ein Führerstand existiert. (ja ich weiß in Spezielfällen darf auch ohne Führerstand an der Vorderseite mit verringerter Geschwindigkeit gefahren werden. Das kann man aber auch scripten, indem man den Wagen sagt, dass sie, wenn sie ganz vorne stehen ein Steuerwagen sind, die Höchstgeschwindigkeit aber verringert ist.)
Außerdem könnte man hier die Kuppelung von Treibköpfen ausfahren, wenn ein Wagen angehängt wurde. Das war vermutlich auch die Idee hinter dem Vorschlag von @Merk.

kannBefahrenWerden dürfte ebenfalls selbsterklärend sein. Ein zug der keine Schmalspur property hat, hat auch Schmalspurgliesen nichts zu suchen. Ein Zug der eine Stromschiene anstatt einer Oberleitung nutzt, hat auch Strecken ohne Stromschiene ebenfalls nichts zu suchen.
Ferner wäre das zumindest schonmal ein Schritt in Richtung "Verkehrsweg ist Verkehrsweg" und nicht "Eine Straßenbahn ist zwar im Endeffekt auch nur ein Zug, ist aber unter allen Umständen inkompatibel zu Zügen, da es ein Straßenfahrzeug ist.

Richtig edel wäre das ganze, wenn man für Fahrzeuge gewisse manuell aktivierbare, optionale properties setzen könnte. Die Idee dahinter ist eine upgrade Funktion von Fahrzeugen, um dem Spieler etwas mehr möglichkeiten zu geben das richtige Fahrzeug für eine Strecke zusammen zu basteln und auch, um das Depot wieder etwas übersichtlicher zu gestalten.
Kleines Beispiel anhand der BR

Ein solches feature wäre für mich in vielerlei Hinsicht eine Bereicherung:
Modbarkeit: Sehr mächtige Funktion um Fahrzeuge anpassbarer zu gestalten. z.B. geöffnete Nase des ICE, wenn dieser gekuppelt wird.
UI/Usability: Deutlich übersichtlichere Depots, da Repaints und Varianten von Fahrzeugen in einem Eintrag mit wechselbaren Texturen (repaint) zusammengefasst werden können. Außerdem würden (ggf. nur auf Wunsch) nur Fahrzeuge angezeigt werden, die gekuppelt werden können.
Gameplay: Mehr möglichkeiten "die richtigen" Fahrzeuge für eine Linie auszuwählen. Möchte man eine Lok die über ein Zugbeeinflussungssystem verfügt auf einer STrecke nutzen wo dies nicht erforderlich ist, kann man diese optinale property einfach abwählen und zahlt weniger.
Außerdem kann man Schmalspurbahnen zwingen nur auf Schmalspurstrecken zu fahren.

Damit könnte man dann ziemlich komplexe Verhaltensregeln für Fahrzeuge scripten.

Eine Vorbesserungsvorschlag von mir selbst ist es noch die Art wie Verkehrswege (aktuell Straßen/Gleise) definiert werden zu vereinheitlichen.
Ein Verkehrsweg definiert beliebig viele Lanes und hat weitere Eigenschaften wie Kosten etc.
Eine Lane sollte eine Breite, eine Höhe über dem Boden, eine Richtung, wobei bidirektional auch eine gültige Richtung wäre (z.B. für Gleise und Gehwege) und beliebig viele Transporttypen haben.
Zu jedem Transporttypen werden bestimmte Texturen definiert.
Ein Transporttyp hat dann die technischen Eigenschaften, die man aktuell für Straßen und Gleise definiert also z.B. die Höchstgeschwindigkeit. Außerdem hätte er noch einen einstellbaren minimalen Kurvenradius und eine maximale Steigung.

Leider ganz bestimmt nicht gerade einfach

Die Idee kann man glaube ich recht gut als dynamische LaneNetworks zusammenfassen. Das würde dann auch sowas wie bewegliche Drehscheiben, Klappbrücken und ähnliches einbeziehen.
z.B. im Falle einer Fähre würden für die Wegfindung automatisch entlang der Linie der Fähre zusätzlich eine Kante für Fahrzeuge und Passagiere entstehen.
Damit weiß dann zumindest schon mal die Wegfindung "ah da kann ich die Autos/Busse/Fußgänger/whatever auch her schicken"
Die Spiellogik die die Fahrzeuge dann tatsächlich bewegt, lässt die Fahrzeuge bis zur Fähre wie gewohnt fahren. Sobald eine Fähre angelegt hat, wird die Straße auf dieser mit dem statischen Transportnetzwerk verbunden,wodurch die Fahrzeuge und Passagiere auf die Fähre fahren. können.
Bevor die Fähre ablegt wir die Verbindung wieder getrennt, die Fahrzeuge auf einem festen Punkt und mit fester Ausrichtung im Verhältnis zur Fähre verankert und zum nächsten Hafen gefahren, wo das ganze wieder erneut gemacht wird.
Ich sehe jetzt schon so eigenartiges Zeugs wie PKW auf Autotransportern(LKW) auf Flachwagen(Bahn) Auf einer Eisenbahnfähre.