Beiträge von MaikC

„Leider“ ist mir auf den Ingame-Screenshots noch etwas aufgefallen, das mir überhaupt nicht gefallen hat: Die Glasscheiben vor den roten Schlussleuchten waren viel zu durchsichtig.

Wenn man sich Fotos der echten Lok anschaut, erkennt man, dass das Innenleben der roten Leuchten durch das dunkelrote Glas kaum zu sehen ist.

Das konnte ich natürlich nicht so lassen!

Also es wäre schon hilfreich zu wissen welcher Mod das ist. Da ich das heute auch mit der ersten hochgeladenen Version meines Zaunbaukasten - Basismod hinbekommen habe, versuch es mal mit der aktuellen Version.

Ich bin mir nicht sicher wo die überhaupt herkommt. Ich glaube das Spiel legt die beim upload an... oder hat die "damals" beim upload nach mod.io angelegt. So oder so, die braucht man nicht.

Das mit dem ansnappen ist ne andere Sache, das geht als Edge_addon. Ich weiss nicht ob ich das direkt einbinden kann, ich schau da mal.
Das wäre aber eh besser als extra Menüeintrag um das GUI nicht zu überfrachten. Die slider die man da für Abstand und ggf Höhe braucht sind für das freie bauen ja nicht nötig.

Welchen anderen Mod meinst du denn?

Never play on patch day! Oder war es doch „Release Day“?

Irgendjemand findet eben immer etwas, das man selbst entweder nie angeklickt oder bisher einfach nicht vermisst hat.

Deshalb gibt es jetzt ein kleines Update für den Zaunbaukasten.

Auf mod.io ist der Mod nun auch verfügbar.

Neu:

• Fünf zusätzliche Mauern aus dem Basisspiel

Bugfixes:

• description.html: Einen Formatierungsfehler behoben, durch den die Modbeschreibung im Modfenster nicht angezeigt werden konnte und dabei einen Absturz verursacht hat.
• Baumodus: Das Beenden der Konstruktion wurde verbessert. Der Bau kann jetzt über „Fertig“, ESC oder das X abgeschlossen werden.

Hinweis: Die ESC-Taste steht leider nicht in jeder Situation zur Verfügung. In diesem Fall einfach „Fertig“ oder das X verwenden.

Und wie immer gilt: Wenn jemand noch einen Fehler findet oder eine sinnvolle Erweiterung vermisst, nur her damit.

Hinweise zu möglichen Erweiterungen:

Tore: Es kam bereits die Frage auf, ob sich auch Tore in den Zaunbaukasten integrieren lassen. Ob und wie sich das sinnvoll umsetzen lässt, muss ich mir noch genauer anschauen.

Funktionierende Schallschutzwände: Auch dieser Wunsch wurde bereits geäußert. Bei den Schallschutzwänden für Straßen und Gleise funktioniert die Lärmreduzierung meines Wissens so, dass der Lärm der Straße bzw. des Gleises reduziert wird, an das die Wand angesnapped ist. Bei frei platzierbaren Wänden oder Assets lässt sich dieses Prinzip natürlich nicht ohne Weiteres anwenden.

Ob es eine andere Möglichkeit gibt, mit der Schallschutzwände oder Assets allgemein den Umgebungslärm reduzieren können, konnte ich bisher leider noch nicht herausfinden.

Beide Punkte sind also nicht grundsätzlich vom Tisch, ich kann derzeit aber auch noch nichts versprechen.

Irgendwo hatte kürzlich jemand gefragt, ob man Texturen aus Transport Fever 2 auch für Mods in Transport Fever 3 verwenden darf. Leider finde ich den Beitrag nicht mehr wieder.

Daher hier eine kleine Information für alle Modder, die bereits Gebäude für TPF2 erstellt haben und nun feststellen, dass bestimmte Texturen in TPF3 nicht mehr vorhanden sind.

Die gute Nachricht: Ihr dürft die Originaltexturen(bzw. allgemein Spieldateien) aus der TPF-Reihe auch für eure TPF3-Mods verwenden! Urban Games hat dies in den offiziellen Modding-Richtlinien ausdrücklich erlaubt.

Originalwortlaut aus dem offiziellen Modding-Wiki:

Zitat von Urban Games – Modding Wiki

Urban Games allows the use of game files from the base game of Transport Fever, Transport Fever 2 and Transport Fever 3 to create mods for Transport Fever 3. When using game files, it is mandatory to state the source of the files. You are not permitted to use the game files for games or projects other than the Transport Fever series without explicit permission from Urban Games.

Deutsche Übersetzung:

Zitat von Deutsche Übersetzung

Urban Games erlaubt die Verwendung von Spieldateien aus den Basisspielen Transport Fever, Transport Fever 2 und Transport Fever 3 zur Erstellung von Mods für Transport Fever 3.

Bei der Verwendung solcher Spieldateien muss deren Herkunft zwingend angegeben werden.

Ohne ausdrückliche Genehmigung von Urban Games ist es nicht gestattet, diese Spieldateien für andere Spiele oder Projekte außerhalb der Transport-Fever-Reihe zu verwenden.

Wichtig: Wenn ihr Texturen oder andere Spieldateien aus einem Transport-Fever-Titel in euren Mod übernehmt, müsst ihr die Herkunft also in eurem Mod angeben.

Ihr müsst also nicht auf bewährte Texturen verzichten, nur weil TPF3 sie nicht mehr mitliefert.

Quelle: Offizielles Transport Fever 3 Modding-Wiki – Publishing

Danke da ist ein Fehler in der descripton.html, wird direkt korrigiert.
Fürs erste: die liegt unter_metadata bitte löschen.

Edit: ist bei mir gefixed mit der nächsten Version dann für alle.

Mariotator es geht um die stdout hier: RE: Infrastrukturmods von Grimes
Wenn Fragen sind musst du dich an PeterLustig wenden

Von welchem Mod sprichst du denn?

Ähm sorry Leute, bitte noch einmal neu runterladen wer Version 1.0 (mod.json = revision: 3) hat.
Stunde 1 Patch. Das Löschen einer nicht mit "Fertig" abgeschlossenen Zaunlinie und anschließender neuer Bau führte zum Crash. Jetzt wird der Bau immer abgeschlossen egal ob man ESC drückt oder Fertig.

Das Update für das Moderne Depot verzögert sich leider noch etwas, da ich zunächst noch einige Mappingfehler beheben muss.

Dafür gibt es als kleine Überbrückung etwas "Neues" bzw. aus TPF2 Altbekanntes:

Den Zaunbaukasten - Basismod für Transport Fever 3

Der Mod ist erstmal als Basis ausgelegt, bei Bedarf könnten zukünftig weitere Funktionen und Möglichkeiten eingebaut werden. Der Mod beinhaltet keine eigenen Modelle, er referenziert auf Modelle aus dem Spiel (soweit ich sie gefunden habe).

Das nicht kaufbar machen funktioniert bei TPF3 so das man das alles leer lässt dann ist es nicht kaufbar. Über multiple_unit was verstecken bringt auch bei Zügen nichts da es schon wieder einen Haufen Mods gibt die das alles wieder auf true setzen.

engineTransportModes = { },
transportModes = { },
filterTags = { },

Steht natürlich nicht im Wiki, war ja klar oder ich habs nicht gefunden...

Das Problem ist

• Die Datei _content.json ist ungültig (kaputt) --> einfach löschen
• Das Gruppenmenü verweist auf sich selbst.
• Einige der anderen .mdl-Dateien haben entweder gar kein Gruppenmenü zugewiesen oder verweisen auf das falsche

Wenn man die 3 Sachen korrigiert geht der Mod, Assets habe ich nicht getestet.

Neben dem Rheingold ist noch ein weitere Mod so gut wie fertig gestellt die Baureihe 143/243 ist nun zusammen mit dem Rheingold in der Endkontrolle

Als nächstes stehen noch ein paar Wagen auf dem Programm diese wollte ich aber nicht ohne eine passende Lok releasen, diese hat aber noch ein paar (kleine) Baustellen die ich für TPF3 erst beenden werde. ..Dann wird beides zusammen released

Zitat von EISFEUER

eher nach einer Konvertierung aus TPF2 aus,

Eher aus Train fever, das Ding hat nicht mal einen Innenraum wenn man nach den Bildern geht.

Zitat von eileeeen (GER)

[ParkAndRide] Initializing Park & Ride Hubs (Catchment Scale: 1.0x, Cost Scale: 1.0x)...

Der Mod ist anscheinend bekannt dafür crashes zu verursachen -->abschalten

Ich hatte gestern schon darauf hingewiesen, dass das so leider nicht funktioniert.

Im Root-Verzeichnis des Mods muss direkt der content Ordner liegen. (Wenn etwas konvertiert werden soll, stattdessen der `res`-Ordner) Wenn man schon vor dem konvertieren nur Würfel angezeigt bekommt dann hat man die auch nach dem konvertieren.
Geh mal aus dem Example mod raus. Lege einen eigenen Ordner an und schiebe den content ordner und die mod.json da rein. Alles in den root des ordners.

Bulk convert sollte eigentlich alle mdl die es findet in einem rutsch konvertieren, das Problem ist das totale Chaos was der ME produziert was die Ordnerstruktur betrifft. Nichts davon ist wikikonform. Da kommt dann mein Modding Tool zum Einsatz weil ich irgendwann einfach die Nase voll davon hatte das jedes mal von Hand zu korrigieren. Einmal oder auch 2-5 mal sollte das jeder Modder gemacht haben um zu verstehen wie es funktioniert. Aber danach kann ruhig ein Tool diese stupide Aufgabe übernehmen.

Das Problem mit der Lodstufe kann man pauschal nicht beantworten, es kommt halt drauf an wie und wie "gut" du die lods bisher gemacht hast. Ohne zu sehen wie die ausschauen kann ich da nix zu sagen. Außer das ich es bisher noch bei jedem meiner mods geschafft habe das die letzte Stufe weit unter den 256kb liegt die UG da als max angibt.
Der Trick ist halt Sachen wegzulassen die man eh nicht mehr sehen kann, das absolut dümmste was man machen kann ist stumpf decimate zu machen ohne vorher nicht sichtbare Details von Hand zu löschen. Das verursacht nicht nur massive Fehler im mesh es sorgt auch dafür das kleinste Tris überall lose im mesh sind.

Wichtiger noch als nur Tris zu reduzieren ist das man mesh zusammenfasst wo es geht (auch schon in lod 0) alles was ein material hat und sich nicht seperat bewegt gehört in ein mesh. Mods die hunderte einzelne Teile haben, eventuell sogar noch über mehrere Lods hinweg weil sich jedes unabhängig bewegt sind für das Spiel performancetechnisch eine Katastrophe. Bei Schiffen kann man alles was unter der Wasseroberfläche liegt ab lod 1 ausblenden, bei Flugzeugen die kleineren klappen oder auch kleinteile das Fahrwerks die man eh nicht mehr sieht, bei Dampfloks lösche ich ab lod 1 alle kleineren Teile des Gestänges usw.

Hier mal ein Beispiel dafür, was meiner Meinung nach ordentlich aufgebaute LODs sind. Die Texturen habe ich absichtlich ausgeblendet, damit man besser sieht, was tatsächlich ausmodelliert ist.

Gezielt mit Decimate gearbeitet habe ich erst ab LOD 2 und auch dort nur bei bestimmten Teilen. Im letzten LOD sieht man die Reduzierung vor allem an den Rädern sehr deutlich.

Natürlich hätte ich noch weiter reduzieren können. UG gibt im Wiki für das letzte LOD aber maximal 1000 Tris an, und darunter liege ich bereits. Wenn selbst die Vanilla-Ressourcen diese Vorgabe teilweise nicht konsequent einhalten, sehe ich keinen Sinn darin, mein Modell noch weiter „kaputt“ zu optimieren, obwohl es bereits wikikonform ist.

Wichtig ist ohnehin, nicht nur auf die reine Anzahl der Tris zu schauen. Mindestens genauso entscheidend sind die Drawcalls. Im letzten LOD habe ich nur noch zwei davon: einen für die Lok und einen für den Tender. Genau das ist für mich der Punkt bei einer sinnvollen LOD-Optimierung: Geometrie dort reduzieren, wo es wirklich etwas bringt, die Zahl der Drawcalls niedrig halten und nicht einfach nur möglichst viele Polygone entfernen, bis vom Modell kaum noch etwas übrig bleibt. Im Lod 2 kann ich die drawcalls leidernicht noch weiter reduzieren, das Problem ist das dieses Lod im Bereich 250 bis 800 liegt und ich brauche dort die Lampenmeshes weil sonst einfach das Licht am Boden ab 250m wegploppt.

Das mit dem msh-Ordner kann man leider nicht so pauschal sagen. Wenn man die .msh mit dem von UG mitgelieferten Tool erzeugt, sind die Dateien teilweise fast doppelt so groß wie bei einem Export mit dem alten TPF-Exporter von Merk direkt aus Blender – bei gleicher sichtbarer Qualität und gleichem Funktionsumfang.

Für die Performance ist die reine Dateigröße oder auch nur die Anzahl der Tris nur ein Teil der Wahrheit. Viel wichtiger ist, wie das Modell über seine LODs aufgebaut ist: wann die einzelnen LOD-Stufen eingeblendet werden, welche Meshes welchem LOD zugeordnet sind und wie stark die Anzahl der Drawcalls dabei tatsächlich reduziert wird.

Gerade die Drawcalls haben deutlich mehr Einfluss auf die Performance als ein einzelnes hochauflösendes Mesh. Ein Modell mit 130.000 Tris in LOD 0 kann völlig unproblematisch sein, wenn es sauber aufgebaut ist, wenige Materialien verwendet und rechtzeitig auf einfachere LODs wechselt. Umgekehrt kann ein eigentlich sehr einfaches Modell unnötig teuer werden, wenn es aus vielen kleinen Meshes und Materialien besteht und dadurch eine große Zahl an Drawcalls erzeugt.

Dazu kommt die Materialwahl in den höheren LODs. In LOD 2 oder 3 sollte man möglichst nicht noch dieselben aufwendigen Materialien, verwenden wie direkt an der Kamera. Besonders ungünstig sind transparente Materialien und mit sorted = true sind diese ganz übel für die Performance. Ein transparentes Material im letzten LOD ist für die CPU-/Renderlast problematischer sein als ein sehr detailreiches Mesh mit vielen Tris in LOD 0, das nur in unmittelbarer Nähe dargestellt wird. (ich will an der Stelle nicht weiter mit Details langweilen wie ein msh gerendert wird, das führt zu weit)

Deshalb sollte man bei der Optimierung nicht nur fragen: „Wie viele Tris hat das Modell?“, sondern eher: Wie viele Meshes und Materialien werden pro LOD tatsächlich gerendert? Wie viele Drawcalls entstehen daraus? Wann wechseln die LOD-Stufen? Werden in höheren LODs unnötige Details oder Transparenzen weiter mitgeschleppt? Ist das letzte LOD wirklich stark vereinfacht?

Die reine Größe des msh-Ordners sagt deshalb über die tatsächliche Performance nur sehr begrenzt etwas aus.

Zitat von pf29x

Ich glaube, ich habe das System vom mod.io Pfad ändern noch nicht richtig verinnerlicht.

Wenn du einfach nur den Pfad ändern willst in den mod.io die Mods speichert musst du nur einmal den Pfad woanders hinlegen. Für Unprofis gibts dafür sogar ein Tool
TF3 mod.io Pfad-Tool