Beiträge von BenGreen

Sehr nice, danke Dir! Freue mich und werde geduldig warten.

Schade, aber auch nicht so tragisch.

Könnte es denn was mit den Ablaufrinnen werden?

Der Gedanke kam mir auch. Könnte man das auswählbar machen? Dann würde es für alle Eventualiäten passen.

Zitat von Grimes

Wegen dem fehlenden Bloom, da kann ich nicht mehr genau sagen wieso der verschwunden war, Absicht oder versehen.

Moinsen!

Könntet Ihr Euch dem Thema nochmal annehmen? Mit Ingo's Mod wird ja nur der Vanilla-Zustand wieder hergestellt, das Blooming ist damit extrem hell und unrealistisch übertrieben. Außerdem fallen durch die Wiederherstellung einige Änderungen, wegen der man ja NEP auch einsetzt, weg. Es wäre schön, wenn es - vielleicht wählbar - ein sehr dezentes Blooming gäbe. Damit wären dann auch die Beleuchtungsprobleme bei manchen Mods erledigt.

Und ein "ziehbarer" Modwunsch wären Ablaufrinnen, s. Foto. Die wären dann auch perfekt dazu geeignet, die unsauberen ausgefransten Übergänge zwischen den Texturen zu verdecken. Ich hatte dazu schon Deine Beeteinfassungen ausprobiert, die sind aber dafür leider zu schmal und passen von der Höhe nicht optimal.

jag-999 :
Moinsen,

zunächst mal ganz lieben Dank für Deine tollen Mods! Ich weiß nicht, ob es technisch überhaupt machbar ist, aber ein "nice to have" wäre, wenn Deine ziehbaren Bürgersteige eine Bordsteinkannte, analog zu den Straßen, hätten.

Zitat von eis_os

- Es gibt keine Möglichkeiten solche Straßen per Jokerstraßen oder anderen ScriptMods zu erstellen...

(Sprich diese müssen physisch auf deinem Datenträger liegen und via modifer eingelesen werden können)

Danke für die Hinweise, war mir aber so weit auch schon klar. Freiwilig werde ich auch nicht mehr auf CommonAPI2 verzichten, dafür ist die Mod viel zu gut. Jokerstraßen benutze ich nur für die erste Zusammenstellung, um schnell zu checken ob's mir gefällt. Über'n Jokerstraßen Saver hole ich mir die luas dann zur weiteren Bearbeitung in Notepad++.

Habe ein bisschen getestet und ausprobiert: Lief soweit alles ganz gut, und auch der Fallback im Falle CommonAPI2 fehlt hat funktioniert. laneConfigEndCapCommonAPI funktioniert leider nur für Straßen mit gerader Lane-Anzahl, und man sollte den Straßentyp nur an Kreuzungen und Einmündungen wechseln, sonst gibt's z. B. überflüssige Haltlinien beim Übergang (auch ganz logisch, weil TPF2 die ja auch als Kreuzung wertet). Siehst Du technisch eine Möglichkeit, das noch in den Griff zu kriegen?

Ich dachte ich sehe nicht richtig, als ich mir Deinen Screenshot angeschaut habe: Nicht nur ein realistischer Parkstreifen, sondern da sind auch Haltlinien drin. You made my day! Vielen Dank!

Hintergrund: Ich habe mir auf Basis von WernerK 's Jokerstraßen für den Schönbau (und nur zur eigenen Verwendung) eigene Straßen angelegt, Ohne Straßenmöbel (hier gibt's im ganzen Dorf mit 660 Einwohnen 1 Briefkasten), mit 15 cm Gehweghöhe und ohne unschöne ungünstig platzierte Bäume. Dafür aber mit unterschiedlichen Belägen für Fahrbahn und Gehweg. Händisch ergänzt habe ich dann noch Abläufe und Gullys von EAT1963 und hier und da auch noch Kleinigkeiten angepasst. Besser aussehende Pfeile kommen aus Frankreich (im Workshop), weil ich leider nicht fähig bin, aus manuel_zockt 's schönen Pfeilen entsprechende Texturen zur automatischen Verwendung zu machen. Bei mir sind auch Zebras statt Fußgängerfurten erlaubt, Karte spielt im Raum DACH, danach ist CH-Schmalspur geplant, von daher geht der Kompromiss für mich in Ordnung. Was mir bei meinen 52 Stadtstraßen bisher fehlte, waren die Haltlinien und (realistische) Parkstreifen, sowie Markierungen im Kreuzungsbereich. Auf letzteres werde ich vermutlich verzichten müssen. Beim "Sonderbau" für Trams bin ich noch gar nicht angekommen. Nun fragt man sich vielleicht, warum ich das alles nicht einfach von Hand setze. Für mich ist es - dank diverser Nervenschäden durch MS - zwar machbar, aber halt nicht einfach und auch sehr anstrengend. Zumal es leider auch keine Raster oder sonstige Ausrichthilfen dafür gibt - das ist in CS deutlich besser gelöst. Für CS gibt es auch das "Intersection Marking Tool", damit ist es sehr einfach Markierungen bei Kreuzungen, Einmündungen etc. zu setzen. Eine der Mods die ich für TPF2 am meisten vermisse. Dank CommonAPI2's Node Editor kann man aber wenigstens schon das Routing anpassen, auch eine sehr wichtige Funktion für mich. Lange Rede kurzer Sinn, jetzt kann ich meine Straßen perfekt ergänzen.

Wenn ich die Doku richtig verstanden habe, schreibe ich in der lua der Straße nur die Parameter, die abweichend vom UG-Standard sein sollen. Wenn ich z. B. für einen Parkstreifen das gleich Material möchte, wie für die Fahrbahn, muss ich also in laneConfigCommonAPI nur transportModes = "emptyLane" für die entsprechende Lane eintragen, richtig?

Vielen Dank für die ausführliche Erleuchtung. Also ist das letztendlich ein ähnlicher Schwachfug, der bei junctionStripe, junctionStripeMedian und junctionLine getrieben wird. Die "funktionieren" zwar, wenn man priority in den Straßen verwendet, aber auch nur dann, wenn es eine Kreuzung - keine Einmündung - ist und die gegenüberliegenden Straßen gleichen Typs bzw. Priorität sind. @UG: Warum?!

Ich markiere das hier dann als gelöst, und schreibe dann gleich dort weiter Rasengleis Strassenpaket mit CommonAPI2, da diese geniale Mod von Dir die Lösung sein könnte, bzw. ist.

In vielen Straßen sind in der lua-Datei mit

    crossingStopline = {
      name = "street/new_medium_stopline.mtl",
      size = { 6, 0.5, },
    },

Haltlinien hinzugefügt, werden aber nicht gerendert. mtl-Datei und zugehörige Texturen sind Vanilla und vorhanden. Dies scheint aber auch der "Normal-Zustand" zu sein. Da Foren- und Google-Suche nix erhellendes gebracht haben, kann mich bitte jemand erleuchten?

Muss mich entschuldigen, was ich hiermit mache. Der Fehler liegt nicht in manuel_zockt Mod, sondern daran, dass ich bei mir die Gehweghöhe von 30 auf 15 cm reduziert habe. D. h. wer mit 30 cm Gehweghöhe arbeitet, hat kein Problem.

Der von mir angegebene Wert in den Dateien hstreets_ablauf.mdl, hstreets_ablauf2.mdl, hstreets_gully.mdl und hstreets_gully2.mdl von -0.02 stimmte auch nicht. Zwar wurde damit alles sichtbar, aber als ich heute ganz genau hingesehen habe, habe ich bemerkt, dass die Abläufe schweben. Der korrekte Wert ist Gehweghöhe - 0.015. Bei 30 cm Geweghöhe passt also -0.285, bei 15 cm ist es dann -0.135.

Sorry für die Verwirrung!

Kaum hatte ich den Beitrag abgeschickt, viel mir ein: Du hast noch nicht die "ablauf- und gully-Dateien" verglichen. Und siehe da, Fehler gefunden. In EAT1963 's Version der /res/models/model/asset/eat1963_hstreets_ablauf2.mdl steht:

            children = {
                {
                    id = "asset/eat1963_hstreets_ablauf.msh",
                    transf = {
                        1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0.02, 1, 
                    },
                    type = "MESH",                    
                }, 
            },

In manuel_zockt 's /res/models/model/asset/hstreets_ablauf2.mdl statt dessen:

                children = {
                    {
                        _meshId = 1,
                        _origMeshId = 1,
                        materials = { "asset/hstreets_ablauf2.mtl", },
                        mesh = "asset/hstreets_ablauf.msh",
                        name = "MSH_eat1963_hstreets_ablauf_1",
                        transf = { 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, -0.285, 1, },
                    },
                },

Dabei geht es um die Zeile mit dem Wert von "transf", und zwar der Eintrag "-0.285", das ist der Fehler. An dieser Stelle muss statt dessen "-0.02" stehen, dann werden die Abläufe sichtbar. Dort gehört wohl immer der letzte Wert aus der Variable bbMax mit negativem Vorzeichen rein. In diesem Fall steht in bbMax als letzter Wert 0.02, also ändert man in transf auf -0.02. Analog funktioniert das dann auch für die Dateien hstreets_ablauf.mdl, hstreets_gully.mdl und hstreets_gully2.mdl.

Mir ist aufgefallen, dass in manuel_zockt 's - ansonsten genialer - Mod MZ Markierungen die Abläufe und Gullys nicht dargestellt werden. Ich vermutete Positionierungsfehler, bin aber mit der Problemlösung nicht wirklich weiter gekommen. Das einzige was ich heraus gefunden habe ist, dass die Abläufe und Gullys aus EAT1963 's TPF1-Mod Historische Straßen entnommen wurden. Hat jemand eine Idee, wie das zu fixen ist?

eis_os: So ähnlich wie Du Dein Vorhaben für 2024 beschreibst, hatte ich mir das vorgestellt.

WernerK: Vielen Dank für Deine ausführliche Erklärung. Da war mir einiges noch nicht klar. Ich hatte mich mit meiner Frage aber wohl auch etwas missverständlich ausgedrückt. Ich meinte eigentlich, ob man bei den Straßen nicht auch "einfach" die Masten etc. unsichtbar machen kann, so wie bei den Gleis-Mods. Jeremy_mux hat quasi meinen Gedanken aufgegriffen.

eis_os: Nach 3-maligem Lesen hab ich Deine Erklärung zum Straßenbau verstanden (wohl der MS-Matschigkeit in meiner Birne geschuldet). Ließe sich das Problem mit den Extradaten nicht durch entsprechende Anpassungen bzw. Austausch der mdl-Dateien umgehen? Den Straßenbau mit CommonAPI2 habe ich mir bisher noch nicht angeschaut, werde ich gleich nachholen.
Ich sehe TPF2 als Spiel und virtuelle Modellbahn, habe aber auch nicht wirklich Lust alles händisch zu setzen. Daher ja auch meine Bitte an UG. Aber wenn's anders nicht möglich ist, würde ich das auch in Kauf nehmen.

WernerK

Wegen der Gehweg-Höhe gebe ich Dir recht, hab's jetzt auf 15 cm angepasst, dieser 3 cm-Unterschied zu meinem ursprünglichen Ansatz fällt so gut wie nicht auf. Das Schweben lässt sich IMHO schnell beheben, es sei denn man hat eine komplett zu gebaute Map.

Das die Tramgleise Straßen sind ist schon klar, sieht man ja alleine schon am eckigen Kurvenverlauf (Grüße an UG, auch ein Kritikpunkt.). Ich frage aus Unwissenheit: Macht das so einen Unterschied, ob man Straßen mit Tramgleisen oder Bahngleise mit unsichtbaren Masten und unsichtbarer Oberleitung (analog zu jag-999 's NEP-Gleise ohne Mast) ausstattet?

Dank Deiner tollen Mods sehen die Tramstrecken auf jeden Fall schon deutlich besser aus. Vielen Dank dafür!

Also ich habe mir eine Mod selbst gebastelt, die bei allen Straßen die Höhe auf 12 cm setzt. Da ich noch kaum Erfahrung mit der Mod-Erstellung habe, habe ich eine bereits vorhandene Mod, die nur eine "Kleinigkeit" an den Straßen ändert, durch ersetzen an entsprechender Stelle mit "street.sidewalkHeight = .12" angepasst. Da ich keine Vanilla-Straßen verwende, hatte ich dafür zuvor die lua-Datein der einzelnen Straßen direkt geändert, was auf Dauer natürlich keine Lösung ist.

Das Terminal-Problem war mir bisher nicht bewusst, habe aber auch kaum welche installiert. Geplant ist/war ZOBs etc. à la Mättu mit unsichtbaren Straßen zu erstellen.

Das Tram/Strab-Problem beschäftigt mich gerade. Eigentlich kann es doch nicht so schwer sein, das zu modden, denn die Gleise gibt's ja bereits ohne Oberleitung. Da es ja z. B. ansnappbare Telegrafen-Masten und ziehbare Leitungen gibt, müsste man dann "nur" noch das ganze entsprechend für den Tram-/Trolley-Bus-Betrieb anpassen.

Und hier die Antwort von UG:

Zitat

Hallo Bernd,

vielen Dank für deine Nachricht und deine Kritik. Die Fahrdrähte und Tragseile sind durch das Spiel prozedural generiert und die Dicke ist zurzeit fix im Code hinterlegt. Wir haben bereits mit geringeren Werten experimentiert was zur Folge hatte, dass bereits auf relativ kurzer Distanz ein Pixelgewimmel herrschte. Insbesondere für Spieler welche nicht auf der höchsten Grafikeinstellung Spielen können würde das Flimmern auf Dauer anstrengend werden.

Wir können dein Anliegen sicherlich intern weiterleiten und auf unsere Spieler-Feedback-Liste aufnehmen um zukünftig eine Einstellung dafür anzubieten. Ob und wann sowas Umgesetzt wird oder werden kann, kann ich dir leider nicht sagen.

Grund für die hohen Bordsteine ist auch wieder die Ansicht von weit weg. Bereits jetzt zeigt sich das Terrain ab gewisser Distanz gerne mal über der Strasse. Wir versuchen eine möglichst hübsche, etwas realistische, stylisierte Grafik mit Transport Fever 2 zu erreichen. Wir nehmen auch diesen Punkt gerne in auf unserer Feedback-Liste auf.

Vielen Dank für deine Kritik.

Viele Grüsse

Martin Hodler

Alles anzeigen

Ich habe UG heute die folgende Nachricht gesendet:

Zitat

Liebes UG-Team!

Zunächst möchte ich mal ein fettes Mega-Dankeschön für TF2 sagen. Für mich ist es die beste Modellbahn-Simulation, zum einen durch die nahezu fotorealistische Darstellung und vor allem auch die Arbeit der großartigen Modder-Comunity. Zum anderen aber auch durch die Wirtschafts-Simulation, die so auf einer Modellbahn gar nicht, bzw. nur eingeschränkt möglich wäre.

Es gibt leider auch ein großes „ABER“, dass mir die Freude am Spiel - vor allem am Anfang, als ich die Kampagnen durchgespielt habe – wirklich vermiest: Die Bein-dicken Oberleitungen! Diese zerstören das ganze fotorealistische Bild. Natürlich kann man sich mit entsprechenden Mods Abhilfe schaffen, was ich inzwischen auch mache. Es ist für mich – ich bin an Multipler Sklerose erkrankt - aber schon sehr anstrengend, dies auf einer kompletten Map zu bewerkstelligen. Wenn man dies nur noch in den aufwendigen Bereichen, wie z. B. Bahnhöfe, Bahnhofsvorfeld, BW etc., machen müsste, und die Streckenabschnitte außerhalb bereits „ab Werk“ ansehnliche Fahrdrähte nebst Tragseilen hätten, wäre das mehr als nur das „fehlende Tüpfelchen auf dem I“.

Daher meine Bitte, und ich denke ich spreche jetzt auch im Namen aller TF2-Gamer:

Bitte reduziert Fahrdrähte und Tragseile auf eine realistische Dicke! Die vorhandenen Mods wie z. B. „ziehbare Oberleitung“ oder „Stromtrassen“ sind eine gute Vorlage dafür.

Ein weiterer Kritikpunkt waren noch die zu hohen Bordsteinkanten: 30 cm sind – auch im Game deutlich sicht- und erkennbar – viel zu hoch. Dies konnte ich mir selbst mit einer Mod auf realistischere 12 cm reduzieren.

Ich wünsche Euch allzeit happy coding und alles Gute für 2024!

Herzliche Grüße

Bernd

Alles anzeigen

Zunächst ein Mega-Dankeschön an alle Beteiligten für diese großartige Mod, die TF2 erst "genießbar" macht! Ihr seid die Größten!

Ich habe aber einen Fehler gefunden: Bei der gedrehten Version der Gleise mit LZB werden die normalen Beton-Masten verwendet und nicht die gedrehte Version. Dies lässt sich einfach und schnell beheben, in dem man in den entsprechenden lua-Dateien den Eintrag

t.catenaryPoleModel = "railroad/nep_power_pole_2_beton.mdl"

in

t.catenaryPoleModel = "railroad/nep_power_pole_2_gedreht_beton.mdl"
ändert.

LG