Beiträge von VacuumTube

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


    Irgendwie bin ich unzufrieden mit den Möglichkeiten, realistische Felder darzustellen... Es gibt zwar einige Mod Texturen, aber keine hat den passenden Gelbton.


    So stell ich mir typische deutsche Felder vor (GoogleEarth)


    (mit NEP) hier noch der NEP Raps

    von links nach rechts: NEP Mais (Vanilla overwrite), NEP Weizen (Vanilla overwrite), NEP Gerste, NEP Hafer, Weizen von Farm Land textures, Weizen von Sexy Vegetation

    die NEP Felder sind irgendwie alle zu dunkel und der Raps ist vergleichsweise grell.


    (ohne NEP)

    ok, NEP beeinflusst offenbar das Aussehen von Sexy Vegetation...

    insgesamt sieht 5. noch am passendsten aus von der Farbe


    Ein zusätzliches Problem ist, dass die Farbe sich mit dem Zoom total ändern kann.


    Der Vanilla Weizen sieht eigentlich auch ganz ok aus, allerdings von nahem bekanntermaßen radioaktiv strahlend.


    Hab ich irgendeine Mod übersehen?

    Sehr schön!


    Also ist im Prinzip nur eine Konstruktion, die ein Signal unter vielen verschiedenen Parametern zusammensetzt, und eine "Registrierung" bei dem Better Signals Skript in der mod.lua nötig. Das heißt, die lange von UG geforderten Signalkonstruktionen sind nun möglich! Statt eine Flut an Varianten im Signalmenü kann man nun alle möglichen Geschwindigkeiten, Zusätze und Signalzustände in einer einzigen Datei vereinen. Man muss nur entsprechend auf die dynamsichen Parameter von Better Signals reagieren.


    D.h. die Hauptherausforderung ist der .con Code und das Parameterhandling. Damit das nicht explodiert, sehe ich bei vielen Implementierungen noch Optimierungspotential. Kann über sowas ggf. auch mal drüberschauen, gerne auf mich zukommen. Oder mal ChatGPT fragen, für genau sowas ists ja da.

    Wahrscheinlich ist das auch das Problem, die Grundflächen bei Gebäuden zu verändern

    Ja wahrscheinlich, also die Frage konkurrierender Bodentexturen überlappender Konstruktionen. Die Häuser gewinnen in der Regel, aber nur manche Texturen können sich doch durchsetzen. Für mich erscheint es wie ein Glücksspiel, weil es nicht so wäre, dass das mit der priority erklärbar wäre (Texturen mit höherer haben sich wieder nicht durchgesetzt). Aber insgesamt scheint mehr priority im Durschnitt doch zu helfen. Ich habe gerade die Prioritäten erhöht und jetzt können deutlich mehr Texturen die vorhandenen Grundflächen überschreiben.


    Kann man auch Daten selber einpflegen?

    Klar, das ist möglich und prinzipiell nicht viel Aufwand.


    Rutel

    Ja scharfe Kanten sind wohl nur mit Meshes möglich.

    Eine solche Lösung, Texturen über Modelle ins Spiel zu bringen wäre aber sehr unflexibel: keine beliebige Form, verzerrt eine Skalierung die Textur, und nur in der Ebene praktikabel.


    Wenn du "Ingo's Vegetation" Mod meinst, die ist schon drin.


    Das mit der "Vorzugsrichtung" meinte ich hiermit:

    Zusätzlich wollte ich mit dem Upgrader den Parameter alignmentDirMode von result.groundFaces zugänglich machen, um die Richtung der Textur zu ändern, was z.B. für Ackertexturen mit eindeutiger Richtung praktisch wäre. Leider musste ich auf die harte Tour lernen, dass man damit nur die Orientierung der Texturmaske verschiebt, aber die eigentliche Bodentextur bleibt anscheinend immer gleich in ihrer Ausrichtung..

    Also meine Vermutung ist, dass Terrain Texturen immer eine feste Orientierung zur Karte haben. Ich hoffe jemand hier kann das bestätigen oder hat tatsächlich eine Lösung.

    So... nun der nächste Zwischenstand, im fast finalen Status denke ich.


    Der Ansatz, lediglich die vorhandenen ground_texture auszulesen, war ja wenig zufriedenstellend. Daher erstelle ich nun für jedes terrain_material (also jede sichtbare Bodentextur in Maltools) eine extra ground_texture. Da es für die terrain_material wie gesagt leider keine API gibt, für die ground_textures zwar schon - allerdings das Repository nicht schreibbar ist (kein api.res.groundTextureRep.add()) - war das ein großer Spaß an manuellem Dateien erstellen mit Copy&Paste. Ich habe die wichtigsten mir bekannten Mods bereits unterstützt (NEP, 2 mods von Ingo und einige von Mariotator).


    Zum Problem des Upgradens: Es gibt jetzt ein spezielles Upgrade Fenster, mit dem man auch nachträglich einfach die Textur ändern kann. Das macht die Sache deutlich bequemer.


    Man kann sogar die Fläche flach machen, ist also gleichzeitig ein Planierer.


    Zusätzlich wollte ich mit dem Upgrader den Parameter alignmentDirMode von result.groundFaces zugänglich machen, um die Richtung der Textur zu ändern, was z.B. für Ackertexturen mit eindeutiger Richtung praktisch wäre. Leider musste ich auf die harte Tour lernen, dass man damit nur die Orientierung der Texturmaske verschiebt, aber die eigentliche Bodentextur bleibt anscheinend immer gleich in ihrer Ausrichtung..


    Eine andere Sache aus der ich bisher nicht schlau geworden bin ist die Priorität. Ich sehe kein System dahinter, welche Fläche oben ist, wenn man mehrere Polygone übereinander legt. Es gibt ja auch den priority Parameter, aber ich habe das Gefühl, der hat keinen Einfluss (kann sein, dass er nur für die Reihenfolge innerhalb einer Konstruktion zuständig ist?)


    Download: https://github.com/Vacuum-Tube…a687156ac85467cd87bbb.zip

    Gerne testen, für Feedback zur Usability und potentiellen Problemen.

    Falls es noch wichtige Mods mit Bodentexturen gibt, bei denen eine Anwendung mit dem Paver sinnvoll ist, sagt Bescheid.

    Stimmt nicht, es gab mal einen @Lollus hier.

    Sein Account war erst gesperrt, dann hat er offenbar eine Löschung des Profils beantragt


    lollus


    Auf den Workshop Einträgen seiner Mods beantwortet er i.d.R. Fragen.

    Das ist einfach der gesamte Gewinn/Verlust in einem Zeitraum. Je nachdem liegen zufällig die punktuellen Umsätze drin, wenn das Fahrzeug was abgeliefert hat. Wie definierst du den durschnittlichen Gewinn von einem Fahrzeug? Über welchen Zeitraum? Eigentlich müsste es eine komplette Linienumrundung sein, welche aber schwanken kann. (Dieselben Probleme gibt es in der echten Wirtschaft genauso)


    Ich schaue nie da drauf, sondern in die Finanz Historie, da hast du ein besseres Bild von der Entwicklung und man sieht gut, wie es sich einpendelt. Es gibt auch extrem Beispiele, wenn ein Zug seltener als 1mal im Jahr Umsatz macht. Das muss man sich dann genau anschauen, ob das rentabel ist.

    Ich denke der Kauf einer neuen GraKa ist etwas übertrieben.

    Dass bei TPF2 der VRAM vollläuft ist seit Beginn Standard (das Spiel ist 5 Jahre alt, da hatten wir ja ganz andere Hardware zu erwarten). Das sollte eigentlichTM keine Auswirkungen auf die FPS haben, sondern höchstens für Ruckler beim Bewegen sorgen.


    Du könntest es nochmal mit einer flachen Map versuchen, unter sonst gleichen Bedingunen testen. Vielleicht liegt es an den vielen Bergen.


    OpenGL läuft manchmal einfach besser, je nach Hardware.


    Außerdem kann man noch folgende Einstellungen in der settings.lua ausprobieren:

    enableDeferredTextures

    terrainTesselationEnabled


    weitere Kompromisslösung: Auflösung runterstellen bringt einige FPS (dann aber auch immer Vollbild)

    Das Grundgerüst steht soweit. Das Polygon ziehen und Pflastern von Bodentexturen funktioniert an sich erstmal.

    Ich drope hier einfach mal eine öffentliche Beta Version.



    snowball s Förster von TPF2 und der Pflasterer von TPF1 waren hilfreich als Vorlage. Allerdings habe ich die Gui erweitert und bin auf die neue api umgestiegen, wobei mir viele komische Fehler mit der legacy api begegnet sind, die ich vor 3 Jahren schonmal debuggt hab.


    Es gibt eine Liste, die alle geladenen "ground textures" (Dateien in res/config/ground_texture) anzeigt. Im Gegensatz zu einer begrenzten vorgegebenen Auswahl, war meine Idee das dadurch flexibel zu halten und automatisch Texturen von anderen Mods bauen zu können. Allerdings sind die ground_textures im Gegensatz zu den Terrainmaltools (res/config/terrain_material) nicht direkt für den Benutzer sichtbar, daher gibt es weder gescheiter Name noch Icon zur Vorschau (anders als z.B. Brückenauswahl für ZeroHeightBridge). Es werden aber zusätzliche Infos der Datei angezeigt. Ich weiß noch nicht was ich von der automatischen Auswahl halte, weil einige Terraintexturen hier fehlen. Das würde aber bedeuten, dass ich für jede Textur nochmal eine eigene ground_texture erstellen müsste... mal schauen.


    Um das Problem der fehlenden Vorschau zu entschärfen, gibt es beim Marker schon im klassischen Konstruktionsmenü eine Auswahl der Textur (via Alle Ressourcen zur Auswahl in Konstruktionsparametern) was einfach eine dummy Fläche zeigt. Die Marker werden nach Abschluss natürlich mit dem gezeichneten Polygon ersetzt wird. Also es zählt die Auswahl der Liste.


    Wer sich mit Bodentexturen auskennt, weiß dass es auch Möglichkeiten gibt den Rand einer Fläche zu texturieren (Stroke). Dazu gibt es ebenfalls eine Auswahl wofür sich eine 2te Liste öffnet:



    Lange habe ich gebraucht, um die erzeugte Fläche anklickbar zu machen. Trotz der angegeben face für die groundtexture, wollte die weiße Linie einfach nicht erscheinen. Der Clou ist, dass zum einen die gebaute Konstruktion dem Spieler gehören muss, was normalerweise Standard ist, aber bei Bauten via game.interface.buildConstruction noch mit game.interface.setPlayer ergänzt werden muss (witzigerweise konnte man es trotzdem bulldozen im Bereich der BoundingBox). Und dann reicht es nicht aus, dass die groundtexture da ist, es müssen auch noch unsichtbare Modelle her, nicht nur eins, sondern an alle Eckpunkte, um eine passende BoundingBox zu bekommen. (Danke snowball an den Kommentar im Code - genau deswegen sind Kommentare wichtig!). Der Vollständigkeit halber: Faces im Uhrzeigersinn erzeugen triangulierte weiße Linien, was unschön aussieht, daher wird das Polygon noch überprüft.


    Nachdem ich endlich in den Upgrade Dialog kam, um mit Parametern ein Nachbearbeiten möglich zu machen, kam die Enttäuschung: TPF2 gibt mir in der updateFn strikt nur params die Zahlen sind, wie für standardmäßig definierte Parameter vorgesehen. Meine parameter sind ja das Polygon (table) und die groundTexture direkt als string, welche auch in der construction entity gespeichert sind! Das ist sehr schade, dass dieses Vorgehen (erst manuell individuelle Struktur einer Konstruktion festlegen und dann klassisch über den Upgradedialog mit vielen Parametern verfeinern) nicht so funktioniert.

    Wenn ich es richtig sehe gibt es in TPF2 bisher keine vergleichbare Mod von Der Farmer oder Der Pflasterer ?


    Trotzdem denke ich, dass das eine sinnvolle Sache wäre, Bodentexturen von beliebieger Form und Größe einfach aufzubringen. Die Maltools sind für große Flächen einfach zu aufwändig und scharfe Kanten sind schwierig. Und Assets/Konstruktionen sind unflexibel.


    Wie seht ihr das?


    Eine Neuauflage mit dem Förster (TPF2) als Vorlage sollte nicht allzu schwierig sein.


    Mit api.res.groundTextureRep kommt man wohl auch an alle verfügbaren Texturen um eine dynamische Auswahl zu haben. (da scheint aber auch ganz schön viel (unnötiges) Zeug dabei zu sein?)


    Allerdings kann man über Konstruktionen nur "groundTexture" erzeugen. Die terrain Textures, welche man über das Maltools bedient, sind nochmal ein anderes System. Hierfür gibt es ja auch keine API.

    Um noch mal auf den Konflikt mit Street Fine Tuning zurück zu kommen:

    Lollus schaltet einfach ohne Gnade alle Straßen mit Trams ab.

    Was ändern will er wohl daran auch nicht...

    Mit einer kleinen Änderung werden nur Straßen von Lollus versteckt. Das funktioniert bei mir ohne Probleme.

    Ich habe ihm einen Pull Request auf Github gemacht, allerdings bisher ohne Reaktion.

    Ihr könnt die modifizierte Version hier runterladen oder die Änderung selbst vornehmen.


    Den [Splitter] gibt's woanders auch separat

    Weiß ich natürlich ;) aber der von Lollus funktioniert in manchen Situationen besser

    Bulldoze with Collision kann jetzt einfacher genutzt werden - direkt mit Rechtsklick!



    Wie bisher auch, sollte man vorsichtig sein. Isolierte Fahrzeuge erzeugen einen Crash. Bei Brückenpfeiler Situationen klappte es bei mir immer ohne Komplikationen.


    v1.10 ---> Build with Collision

    Ich wollte etwas ähnliches bauen, einen Bahnhof teilweise als Brücke. Also 1 oder 2 Module als Zentrum mit normaler Motras Station platzieren, dann Gleise weiter mit (unsichtbarere) Brücke, und dann symmetrisch Bahnsteig Assets (damit Züge mittig halten).

       

    Funktioniert prinzipiell, wobei mir auffiel, dass bei dieser hybriden Bausweise die Texturen der Module und der Assets farblich nicht ganz zusammenpassen. Ein weiteres Problem war bei mir die Steigung (ab der Brücke geht es abwärts). Das kann man mit den Parametern nur begrenzt ausgleichen und ist sehr fummelig. Man sieht die Stufen.


    Die Ultimate Station könnte hier flexibler sein, da sie gleichzeitig Brückenmodule, gebogene Bahnsteige und Steigungen möglich macht (habe das mit Steigung aber auf die Schnelle nicht hinbekommen).