Kombinierung mehrerer MDLs in CON-Datei zu zusammenhängender Konstruktion

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


  • Hey,


    im Rahmen der Umsetzung der Mod-Anfrage, stoße ich schon mal auf das ein oder andere Problem. Meistens lässt sich so eins mit etwas Recherche oder Überlegung ausräumen, doch zum folgenden Problem habe ich noch keine akzeptable Lösung gefunden:


    Problem:

    • Trennung aller MDL-Einzelteile beim Einsetzen der Konstruktion ins Spiel

    Ziel:

    • Zusammenhängendes Objekt
    • Möglichkeit des Abreißens in einem Stück
    • Optional keine Konstruktions-Eigenschaften (kein Hover-Effekt)

    Rahmenbedingungen:

    • Spielobjekt mithilfe mehrerer MDL-Dateien
    • Construction vom Typ ASSET_DEFAULT
    • Keine Edges, Stocks etc.

    Gescheiterte Lösungsansätze:

    • Kollisionsobjekt hinzufügen → keine Veränderung
    • In result.models weitere MDL-Liste reinschreiben → Crash
    • result.edgeLists und constructionutil.makeStocks([...]) Nil-Parameter oder andere unmögliche Werte verpassen → Crash

    Erfolgreiche Teillösungen:

    • Verwendung anderer Typen für die Construction → Falsche Einsortierung

    Ideen:

    • Bei der Verwendung von Stocks oder EdgeLists lassen sich eventuell Dummy-Objekte eintragen, aber das könnte Probleme mit Kollision geben und es ist unschön
    • Bei einer anderen Modifikation habe ich gesehen, dass ein bereits platziertes Spielobjekt über game.interface zu einer Konstruktion „umgewandelt“ wird, jedoch ist das nicht auf diese Situation übertragbar und im besten Fall kann über die result-Variable in der CON dem Spiel mitgeteilt werden, dass das Spielobjekt später eine anklickbare Konstruktion sein soll

    Habt ihr noch andere Ideen oder sogar Lösungen dazu? Ich halte das für ein kniffliges Problem, da Assets aus mehreren MDLs scheinbar nicht vorgesehen sind.
    Wenn das gelöst ist, ist das größte Problem weg. ;)

  • Da bin ich wieder, mit positiven Nachrichten!


    Es reicht, wenn in einer einzigen Modelldatei für eine Konstruktion diese Zeile* im metadata-Block eingetragen wird:

    Lua
    particleSystem = { emitters = { { } } }


    Im Ganzen:

    Lua
    metadata = {
        particleSystem = { emitters = { { } } }
    },


    *Natürlich funktioniert das Ganze auch, wenn zwischen den Klammern noch mehr drinsteht.


    Normalerweise ist beim Zugriff auf das particleSystem das Ziel, einen Partikel-Effekt zu erhalten. In dem Fall ist dafür alles frei gelassen.


    Auf die Lösung bin ich durch weitere Experimente mit Konstruktionen aus der Kampagne gekommen. Das Asset custom_indian_village besitzt nämlich die Eigenschaften, die ich erhalten wollte (siehe ersten Beitrag). Durch ein Ausschlussverfahren mit den enthaltenen Modellen, kam ich darauf, dass es an dem Modell campfire_smoke liegen muss. Das greift auf das particleSystem zu, also probierte ich das aus. Damit hat es tatsächlich geklappt!
    Anschließend reduzierte ich den metadata-Teil auf die obige Zeile und bin damit zufrieden. :)


    Mein einziges Manko daran ist, dass das Asset später den Hover-Effekt hat und noch angeklickt werden kann, jedoch finde ich das besser, als die Einzelteile.

  • Auch die von dir angesprochenen Möglichkeiten habe ich in verschiedenen Weisen getestet, aber kein zufriedenstellendes Ergebnis bekommen. Könntest du ein Skriptbeispiel machen, wo es klappt? Vielleicht hast du da noch andere Umsetzungen im Sinn.

  • Code
    result.groundFaces = {}
    	groundFace = { {0.1, -0.1}, { 0.1, 0.1}, {-0.1, 0.1}, {-0.1, -0.1} }
    	result.groundFaces[#result.groundFaces + 1] = { face = groundFace, modes = { { type = "FILL", key = "industry_floor" } } }
    	result.groundFaces[#result.groundFaces + 1] = { face = groundFace, modes = { { type = "STROKE_OUTER", key = "industry_floor_paving" } } }

    so funktioniert das bei meinen Schwebebahnpfeilern.

    Warum einfach, wenn es auch schwer geht?


  • Ok, mit:

    Lua
    result.groundFaces = {}
    groundFace = { { 0, 0 }, { 0, 0.001 }, { 0.001, 0 } }
    result.groundFaces[#result.groundFaces + 1] = { face = groundFace, modes = { { type = "FILL", key = "industry_floor" } } }

    konnte ich es auf ein nicht mehr sichtbares Maß reduzieren und daher ist es optisch kein Thema mehr. Bei deinem Beispiel wurde nämlich noch Waldtextur o.ä. darunter gelegt und das kleine Quadrat wurde beim Hovern sichtbar.
    Damit mache ich noch paar Tests und werde es dann wohl übernehmen.
    Es könnte sogar besser, als die Partikelgeschichte sein, weil Objekte mit Zugriff auf das Partikelsystem eventuell gesondert behandelt werden.
    Mit den Groundfaces kommt halt eine Mini-Fläche dazu, die eine Textur besitzt.
    Keine Ahnung, was am Ende besser für die Performance ist, aber da hilft dann wohl nur testen.

  • @RPGFabi Ob das für die Performance besser ist? Vielleicht, mit den Bodentexturen kenne ich mich aber zu wenig aus.
    Es kann halt auch sein, dass egal ob an einer Stelle die industry_floor-Textur oder eine unsichtbare Textur vorkommt, kein Unterschied für die Performance entsteht. Durch die unsichtbare Textur wäre wahrscheinlich die Standardbodentextur sichtbar.

BlueBrixx