Beiträge von Relozu

Ihr, die den Fehler reproduzieren können, könntet entscheidende Hinweise liefern. Dabei kann euch das Skript helfen, das ich vor einiger Zeit hier bereitgestellt habe. Im bisherigen Verlauf wurde mithilfe meiner Mod eine Liste von verdächtigen Mods von manuel_zockt bereitgestellt, was aber als einzelne Aktion leider noch keine große Aussage hat bzw. aufwendig nachzustellen ist. Mein neueres Skript ist diesbezüglich besser, weil schon ein einziges Ergebnis fehlerhafte Mods konkret aufzeigen kann.

Sobald jemand problematische Mods identifiziert, kann der-/diejenige damit natürlich sich selbst, aber potenziell auch anderen helfen, die den selben Fehler haben.

Was die Spielentwickler oder betroffenen Modder aus neuen Ergebnissen machen, ist mir im Moment aber tatsächlich unwichtig.

PeterLustig  P8_2401_Coeln Die Mod Gepäck- und Warentransporter für den Flughafen (gvdb_tug_flughafen_1) ist insofern auffällig, weil sich z.B. folgende Zeilen innerhalb einer Datei befinden, was eigentlich keinen Sinn ergibt (es wird Konfiguration für Schienen- und Straßenfahrzeuge gleichzeitig gemacht):

        railVehicle = {
            configs = {
                {
                    axles = { },
                },
            },
            engines = { },
            soundSet = { name = "",    },
            topSpeed = 0,
            weight = 0,
        },
        transportVehicle = {
            carrier = "ROAD",

Wie ich bei diesem Thema immer anmerke, sollte das Reparieren der Mods aber letztendlich an den Erstellern der verursachenden Mods hängenbleiben und nicht an den Erstellern der Mods, bei denen der im Verdacht stehende Modifier-Fehler auffällt. Wird jetzt z.B. die Gepäckwagen-Mod verbessert, gibt es die Mods mit den schwerwiegenden Fehlern ja weiterhin.

Die Detailgröße (detailSize bzw. Skalierung) einer Terrain-Textur muss manuell angepasst werden, die Größe der Spielwelt hat keinen Einfluss darauf. Die Detailgröße muss außerdem je Terrain-Textur festgelegt werden. Für das Beispiel einer riesigen Spielwelt im Format 1:3 ist die kleinste ausfüllende Detailgröße 1 / 5888 (angegebene Breite von 11,5 km * 1024 / 2 = 5888). Möchte man eine höhere Auflösung erreichen, ist eine höhere Detailgröße zu wählen, z.B. 1 / 2944 (5888 / 2). Je nach Bildmaterial können auch Detailgrößen wie 1 / 6000 oder 1 / 3000 sinnvoll sein, selbst wenn am Rand der Spielwelt dadurch die Texturen abgeschnitten werden.

Ich habe mich jetzt auf den Hinweis von VacuumTube (Danke!) fokussiert (sobald ich speziell etwas zu den anderen Beiträge in diesem Thema beitragen kann, werde ich das auch noch tun). Es sind einige neue Skript-Zeilen entstanden, die ihr an eine originale Skript-Datei anhängen und dadurch Probleme mit Modifiers und FileFilters deutlich effektiver identifizieren könnt. Das neue Skript kann Fehler, die in Modifier- und Filefilter-Funktionen während des Ladevorgangs eines Spielstands auftreten, abfangen und daraufhin entsprechende Fehlermeldungen in der Datei stdout.txt ausgeben (die Meldungen meines Skripts werden mit [relozu_find_modifiers_and_filefilters] eingeleitet). Zusätzlich werden die Rückgabetypen der Modifier-/Filefilter-Funktionen überprüft.

Eine Mod-Lösung mit den selben Möglichkeiten ist mir leider nicht gelungen, dazu aber weiter unten mehr.

Möchtet ihr mein Skript nun an die besagte originale Skript-Datei anhängen, hier der Hinweis, dass ein Spielstand, der nach der Änderung der Skript-Datei geladen wird, ungewollte Veränderungen aufweisen kann. Ein derartiger Spielstand sollte daher nicht einfach so gespeichert werden! Bevor ihr die Skript-Datei ändert, könnt ihr zur Vorbeugung von beschädigten Spielständen beispielsweise ein Backup eurer Spielstände machen. Auch können lediglich die Spielstände, die in Bezug auf Modifier-/FileFilter-Probleme überprüft werden sollen, mit neuem Namen gespeichert und danach als Test-Spielstände verwendet werden.

Wenn ihr die Änderungen in der originalen Skript-Datei wieder zurücksetzen wollt, müsst ihr die hinzugefügten Skript-Zeilen entfernen und das Spiel danach am besten neu starten. Auch eine Überprüfung der Spieldateien auf Fehler kann die Datei in den ursprünglichen Zustand zurücksetzen. Bedenkt dabei bitte, dass bei so einer Überprüfung all eure Änderungen an Spieldateien und Steam-Workshop-Mod-Dateien zurückgesetzt werden!

Hier sind die Skript-Zeilen, die am unteren Ende der Datei [...]/Transport Fever 2/res/scripts/mod.lua eingefügt werden sollen: relozu_find_modifiers_and_filefilters_script_1_0.txt

Hinweise

Dieses Skript ist mit der gleichnamigen Mod relozu_find_modifiers_and_filefilters_1 nicht kompatibel!

Mein Skript habe ich getestet, dennoch sind Fehler nicht ausgeschlossen. Wie üblich, hier noch der Hinweis, dass ich für durch mein Skript entstandene Schäden an Hardware und/oder Software nicht hafte.

Einige Details zur Funktionsweise

Die Skript-Änderung wirkt sich auf den Ladevorgang neuer und bestehender Spielstände aus. Wird ein Spielstand geladen, wird beim Hinzufügen von Modifier- und Filefilter-Funktionen die zugehörige Mod und der Typ des Modifier/FileFilter zwischengespeichert. Im weiteren Verlauf werden Modifiers und FileFilters ganz normal vom Spiel angewandt, die Besonderheit mit dem geänderten Skript ist, dass bestimmte Fehler, die beim Aufruf der Modifier- und FileFilter-Funktionen auftreten können, abgefangen werden. Nach dem Abfangen wird eine Fehlermeldung in die Datei stdout.txt geschrieben. Außerdem wird der Rückgabetyp der Modifier- und FileFilter-Funktionen überprüft, falls dabei ein falscher Rückgabetyp festgestellt wird, wird ebenfalls eine Fehlermeldung erzeugt. Wird eine Fehlermeldung von meinem Skript ausgegeben, wird die weitere Verarbeitung des aktuellen Modifier/Filefilter abgebrochen. Zur Zeit ist es so, dass die Änderungen eines fehlerhaften Modifier, die er bis zum Auftreten des Fehlers durchgeführt hat, übernommen werden.

Beim Ladevorgang eines Spielstands könnte mein Skript potenziell sehr viele eigentlich gleiche Fehlermeldungen in die stdout.txt-Datei schreiben, weshalb mein Skript Fehlermeldungen, die sich wiederholen, filtert. Standardmäßig reduziert mein Skript Wiederholungen von Fehlermeldungen auf ein Minimum, dieses Verhalten lässt sich bei Bedarf beeinflussen, indem das Feld rReduceErrorMessagesToMinimum auf den Wert false geändert wird.

Fehlermeldungen werden nach folgenden Eigenschaften gefiltert:

Die Realisierung einer Mod ist mir vorerst nicht gelungen. Die mod.lua-Skript-Datei zu überschreiben, hat nichts gebracht und die Funktionen in einer neuen gewöhnlichen Skript-Datei zu überschreiben, sorgte für Probleme beim Laden, was mit einem Spielabsturz und der folgender Fehlermeldung endete: ..\..\src\Game\transport\street\StreetShapeFactory.cpp:898: struct StreetGeometry::StreetContext __cdecl CreateStreetContext(const struct StreetType &,int,bool,bool,bool,bool): Assertion `Valid(result.laneConfigs)' failed.

Ausgerechnet jetzt habe ich so wenig ins Forum reingeschaut... hier gab es interessante Entwicklungen, die muss ich mir aber in Ruhe anschauen. Meine Mod hat mich übrigens dazu gebracht, mich mehr mit Lua zu beschäftigen, in dem Bereich sollte ich jetzt also auch noch etwas mehr hinbekommen können.

Das habe ich hier noch vergessen zu schreiben, war die find-Mod an der ersten Position der Ladereihenfolge? Das steht bisher nur in der Mod-Beschreibung drin.

Aber es kann natürlich auch sein, dass es doch nichts mit Modifiers zu tun hat.

Das Problem mit der stdout.txt verstehe ich nicht so ganz, wurde ein Spielstand komplett geladen? Normalerweise endet die stdout.txt dann ja mit "Goodbye." usw.

Ausgaben sehen z.B. so aus:

--------------------------------
[?relozu_find_modifiers_and_filefilters_1] Modifier and fileFilter results:
--------------------------------
Registered fileFilters (in the registration order):
--------------------------------
No registered fileFilters!
--------------------------------
Registered modifiers (in the registration order):
--------------------------------
Modifier type: loadModel, Mod: ?relozu_freeze_your_game_1
--------------------------------

Wenn du kein richtiges Tool dafür hast, dann warte vielleicht noch mit dem Weitersuchen. Ich würde diesen Beitrag später aktualisieren.

Edit: Ich musste etwas experimentieren, aber hier ist jetzt eine Mod, die Modifiers und FileFilters den Quell-Mods zuordnen und die Ausführung verhindern kann. Wenn ihr die ersten drei Mod-Einstellungen aktiviert, werden Modifiers und FileFilters abgefangen und zugehörige Informationen in die stdout.txt-Datei geschrieben. Auf diese Weise sollte man die Mods identifizieren können.

Die Mod ist zwar schon getestet, jedoch ist sie noch sehr frisch. Zu verdeutlichen ist außerdem, dass Spielstände, bei der diese Mod aktiviert ist, nicht einfach so gespeichert werden sollten. Insgesamt übernehme ich für durch meine Modifikation entstandene Schäden an Hardware und/oder Software natürlich keine Haftung.

Bis jetzt habe ich die Möglichkeit des nachträglichen Tests der gefundenen Funktionen noch nicht erwähnt, für die übrigens Beispiel-Daten in der mod.lua-Datei eingetragen werden können. Modding-Kenntnisse sind für das Eintragen sinnvoll, das Testen kann man auch so ausprobieren, berücksichtigt werden muss aber, dass es sich dabei nur um eine kleine Simulation handelt und z.B. nicht alle Fehler gefunden werden können. Der Test wird über die vierte Mod-Einstellung aktiviert.

Vielleicht macht die Mod ja Sinn, ich selber werde sie wahrscheinlich auch noch gebrauchen können. Aktuell ist sie aber auf jeden Fall noch in einer Testphase, also wäre Rückmeldung super.

Die Dokumentation zur Mod ist aktuell noch knapp, wenn ihr euch bei etwas nicht sicher seid, wartet besser ab oder fragt nach.

In meiner Mod wird eine leere Variable (Wert nil) mit einer Zahl verglichen, was zu der in meinem letzten Beitrag gezeigten (geplanten) Fehlermeldung führt.

Wenn man sich jetzt nur auf modifier oder genauer den loadModel modifier konzentriert, wäre es interessant, welche Mods solche modifier hinzufügen. Stichworte in Skript-Dateien dafür sind:

• addModifier
• "loadModel"
• addModifier("loadModel"

Auch meine Mods nutzen modifier, Probleme kann ich da nicht komplett ausschließen, für Tests kann man die Mods schon mal deaktivieren. Mir ist aber natürlich auch klar, dass das mit den Tests aufwendig sein kann, wenn der Ladevorgang immer eine längere Zeit andauert.

Zur Fehler-Situation allgemein: Vermutlich treten in irgendwelchen Mods unerwartete Modell-Strukturen für eine oder mehrere Mod(s) mit Modifiern auf, was dann eben zum Einfrieren führen kann. Die Modder mit den Modifier-Mods müssten in so einem Fall ran.

Das was ich jetzt hier beschreibe, könnte (muss aber nicht) mit der Ursache für eure Probleme zu tun haben.

Vor rund einem Jahr ist mir dieses Problem aufgefallen, bei dem der Ladevorgang bei 2 % (im Debug-Modus sichtbar) anhält und nicht mehr weiterläuft. Es wurde dabei ebenfalls keine Fehlermeldung in der stdout.txt erzeugt. Bei mir konnte ich das auf einen Fehler in einem Test-Mod-Skript zurückführen (Fehler in einer hinzugefügten modifier-Funktion für loadModel).

Beschrieben habe ich das Fehler-Verhalten auf Steam, jedoch wurde das Problem noch nicht behoben (zumindest tritt es bei mir immer noch auf) und die Steam-Diskussion wurde wohl irgendwann zur Kategorie „Old Issues“ verschoben. Mehr weiß ich dazu nicht.

Zu diesem Post hier im Forum habe ich eine (kleine) Mod hinzugefügt, mit der ihr euer Spiel bewusst und ohne Fehlermeldung in der stdout.txt einfrieren lassen könnt. Vielleicht hilft euch das zumindest für einen Vergleich der Fehler-Situationen.

Warum das bei euch übrigens eine Art Glücksspiel ist, ob und wie weit das Spiel lädt, ist vermutlich deshalb, weil das Spiel zum Beispiel die Modelle parallel lädt. Dabei kommen theoretisch immer andere Reihenfolgen zustande (also wird ein Modell einmal früher und beim nächsten mal evtl. später geladen) – ein Nicht-Experten-Erklärungsversuch.

Edit: Ein Spielstand, der normalerweise nach weniger als einer Minute geladen ist, hat jetzt mit der Freeze-Mod nach rund 30 min Ladezeit inkl. Einfrieren wohl doch noch eine Fehlermeldung erzeugt (so lange habe ich bis jetzt noch nicht abgewartet, eine Fehlermeldung nach so langer Zeit ist dennoch suboptimal):

Exception type: Lua exception


This error is usually caused by modding. Some game resources contain incorrect data.


Details:


Error message: error: ...[...]/1066780/local/mods/relozu_freeze_your_game_1/mod.lua:25: attempt to compare number with nil
stack traceback:
=[C](-1): __lt
@[...]/1066780/local/mods/relozu_freeze_your_game_1/mod.lua(25): v
@res/scripts/mod.lua(99): ?




File name: res/models/models.zip/model/animal/bird_crane.mdl


Minidump: [...]/1066780/local/crash_dump/6eb2aa24-3140-4438-af04-fb24aed9b963.dmp


Mod: no mod


In file: ..\..\src\Lib\lua\State.cpp:592


In function: void __cdecl lua::State::Call(int,int)




__CRASHDB_CRASH__ struct lua::LuaException: ..\..\src\Lib\lua\State.cpp:592: void __cdecl lua::State::Call(int,int): error: ...[...]/1066780/local/mods/relozu_freeze_your_game_1/mod.lua:25: attempt to compare number with nil
stack traceback:
=[C](-1): __lt
@[...]/1066780/local/mods/relozu_freeze_your_game_1/mod.lua(25): v
@res/scripts/mod.lua(99): ?

Die Fehlermeldung zielt auf das mutmaßlich zuerst zu ladende Modell (den Kranich) ab, auf das der modifier angewandt wurde.

Zitat von eis_os

_() Should work mostly in all states since the summer update.

I remember a bug report about game_script and translation not working once...

This is actually also important... with one of my mods such a problem became known once. That's the reason why a default language can be useful, which is always selected if the translation fails. For this purpose, I also have a language setting via the modParams to be able to set a language as default.

The fact that the translation problem has been fixed in the meantime was unknown to me until now. However, catching possible errors is relatively simple and therefore acceptable to me.

doug Earlier it was possible to change the language of TF2 via Steam, but this has meanwhile changed and your solution should therefore also work. The effort is greater, however, because as far as I know there is no access to the two files via common ways.

Have you tried translating a text value and deriving the language from it?

_("game_language") could e.g. result in "lang_de" or "lang_en". Or do you want a method that is "cleaner"?

In future versions of my mods this will be used if needed.

Does this help? -> OpenGL error (help)

Um genau diese Mod ging es tatsächlich schon mal, dieser Beitrag und das Wiki könnten dir weiterhelfen:

• fliegende Sims und blaue Straßen
• https://www.transportfever2.co…l:gamefilelocations#steam

Wenn du Lust hast, kannst du dir auch das komplette verlinkte Thema durchlesen, einige Dinge habe ich da beispielsweise noch etwas ausführlicher erklärt, jedoch ist dort natürlich alles auf eine andere Problemstellung zugeschnitten, die nur teilweise übertragbar ist.

Für die Sache mt den Ausfahrtschildern wäre ein Screenshot interessant, eventuell habe ich sowas schon mal gesehen, jedoch bin ich mir nicht mehr sicher.

In der Regel besteht bei so einem Verhalten ein Fehler in einer Mod, die Personen als Asset anbietet (wie von VacuumTube angedeutet). Ich meine, dass es das sogar schon bei mehreren Mods gab. Das Verhalten entsteht dann für gewöhnlich dadurch, wenn eine Mod neue Personen-MDL mit ewigen Animationen hinzufügt und die Personen-MDL wegen des unveränderten metadata-Blocks jedoch immer noch als normale Personen gelten und daher vom Spiel auf die Reise geschickt werden.

Den metadata-Block im Nachhinein zu korrigieren funktioniert leider nicht, das führt zu einem Absturz beim nächsten Start-Versuch. Die Fehlermeldung ist dann die metadata-Fehlermeldung von hier.

Eine Reparatur ist möglich, aber etwas aufwendig. Der einzige Weg den ich kenne, ist die betroffenen Personen-MDL-Dateien zu kopieren, den metadata-Block zu korrigieren und in den Mod-Skripten auf die neuen MDL-Dateien zu referenzieren. Die vom Spiel genutzten Personen-MDL sollten dann außerdem noch so verändert werden, dass die ewigen Animationen korrigiert werden. Möchte man sich von der Personen-Asset-Mod trennen, wird das ganze etwas simpler, weil man sich dann z.B. die Korrektur der Referenzen sparen kann. Eine konkrete Anleitung ist jedoch erst möglich, wenn man die konkrete Mod kennt (Name, Version... aber am besten ohne Link und ohne Download-Plattform - Links zu Download-Seiten werden hier vom Team entfernt, wenn die verlinkten Download-Seiten z.B. gegen Urheberrecht verstoßen).

Im Spiel findet man die Mod am einfachsten, indem man Personen-Asset-Mods einzeln auf einem kleinen Test-Spielstand testet (dabei ggf. mehrere Städte im Sandkastenmodus setzt) und sich die Personen anschaut.

Hat man die Mod gefunden, kann man sie theoretisch auch einfach deaktivieren, dann gibt es jedoch das Problem, dass alle Personen aus der jeweiligen Mod durch Platzhalter-Modelle ersetzt werden.

Ich weiß nicht, ob die Idee mit den Kollisionsbereichen zum Aufmalen schon mal irgendwo anders vorkam, aber ich würde dabei parallel in die Richtung der Spieleentwickler gucken, die so eine Funktion z.B. im Rahmen des Sandkastenmodus hinzufügen könnten.

Die Kollisionsbereiche könnten dabei dann, wie von dir beschrieben, so funktionieren, dass das Spiel darin nichts Neues mehr bauen darf, der Spieler jedoch schon. Solche Funktionen kann eine Mod möglicherweise liefern. Wer die Zeit (allerdings auch die Motivation) dazu hat, kann sich damit mal beschäftigen, falls nicht schon geschehen...

Es stellt auch für mich kein großes Problem dar, wenn es bei höheren LOD-Stufen Probleme mit fakeBogies gibt, nur habe ich am Anfang ja gedacht, dass fakeBogies selbst fehlerhaft sind. Der Berkhof Duvedec sollte das Beispiel dazu sein und jetzt steht er eigentlich nur noch für ein eher unspektakuläres Skript-Problem da.

Die genannten Busse habe ich mir jetzt mal genauer angeschaut:

• Berkhof Duvedec: setzt man für LOD 1 und 2 die fakeBogies von LOD 0 ein (Gruppen-ID muss dabei angepasst werden), sieht die Rotation bei allen LOD-Stufen gleich aus
• eCitaro: die fakeBogies sind für alle LOD-Stufen gleich, allerdings gibt es bei LOD 2 keine echten Achsen mehr, daher kommt die Abweichung –> fakeBogies für LOD 2 müssten wohl angepasst werden
• MAN SL 192: alle LOD-Stufen enthalten die gleiche Anzahl an Achsen, die gleichen Achspositionen und die gleiche fakeBogies-Konfiguration, daher unterscheidet sich die Rotation nicht

Vielleicht hat es irgendeinen Zweck, warum die fakeBogies beim Berkhof Duvedec so sind, wie sie sind. Der Unterschied zwischen den LOD-Stufen wirkt jedenfalls unnötig.

Danke euch, die Situation ist anders als erwartet. Der erste Beitrag ist entsprechend korrigiert.

An meine Mod muss ich also nochmal ran, dort gibt es nämlich mehrere Probleme mit der Kombination von richtigen Achsen und fakeBogies, es ist also ein Mod-Problem.

Beim Modding beschäftige ich mich aktuell mit fakeBogies. Ab LOD_1 aufwärts funktionieren diese allerdings nicht wie sie sollen. Hier am Beispiel Berkhof Duvedec (Original-Modell):

Im Model Editor gibt es einen Anzeigefehler der fakeBogies, sobald die LOD-Stufe geändert wird:

Im Spiel Der Berkhof Duvedec Bus hat wohl ein nicht optimales Skript, aber Probleme bei fakeBogies selbst scheint es nicht zu geben (GIF):

Im Model Editor ist zu sehen, dass die Mesh-IDs von allen LOD-Stufen auf LOD_0 angewandt werden. Im Spiel scheint dadurch auch nicht alles zu stimmen, der gezeigte Bus verhält sich nicht optimal.

Sollte es wider erwarten doch keine Auswirkungen auf das Spiel geben, muss ich an meine Mod wohl nochmal ran.

Während der letzten Updates wurden fakeBogies ja schon mal behandelt, allerdings ging es da um Fehlermeldungen und Abstürze durch fehlerhafte Mods.

Ob die hier geschilderten Probleme etwas mit den letzten Updates zu tun haben, kann ich selber nicht einschätzen, jedoch ist z.B. die Funktion zum Anzeigen der fakeBogies im ModelEditor ja relativ neu.

JS39 Es müssen nicht zwingend Flächen mit Kollisionsobjekten ausgefüllt werden, es reicht die Flächen damit abzugrenzen. In meinem letzten Beitrag habe ich die Kollisionsplatte auf Steam verlinkt, wo diese Bauweise gezeigt wird. Neben Assets mit aktivierter Kollision kenne ich außerdem noch folgende Mods:

• https://steamcommunity.com/sha…iledetails/?id=2023358803
• Invisible Collision Tool

Die Mod von VacuumTube könnte dir aber auch schon genug weiterhelfen.

Du solltest dir natürlich das aussuchen, womit du am besten klarkommst.