Beiträge von eis_os

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


    Das muss an eurem Ende liegen, das Zertifikat ist doch gültig. Ist ja der selbe Server


    Start der Gültigkeit: Mon, 25 Nov 2024 23:07:46 GMT

    Ende der Gültigkeit: Sun, 23 Feb 2025 23:07:45 GMT

    (Laut Firefox Zertifikat Anzeige)


    und die CommonAPI2 hat sich das Update von heute Mittag der repo Datei gerade auch ohne Probleme hier geladen. :/

    Ich sehe das immer noch hier:


    Loaded 1 of 24 mod descriptions from disk

    Update of mod descriptions: 6.884 ms

    Found 23 mods

    Loaded 1 of 24 mod descriptions from disk

    Update of mod descriptions: 6.804 ms

    __CRASHDB_DUMP__ 3997417d-55ed-4e6f-bf27-eaf89c573a3e

    Found 23 mods

    Loaded 1 of 24 mod descriptions from disk

    Update of mod descriptions: 6.292 ms

    Found 23 mods

    Wie geschrieben sieht man mit CommonAPI2 halt die __CRASHDB_DUMP__ Einträge nicht.

    Ggf wenn es zu viele Crashs auf einmal gibt, kann es passieren das irgendwann das Abfangen der Crash dann es zu einem Stackoverflow kommt im Crashhandler.


    -OT-
    Bedanken könnt Ihr euch bei Sprache C++. Die try catch Blöcke bzw. Boost Exception Objekte können nicht über DLL Grenzen hinweg "transportiert" werden. Zumindest mag TPF2 diese dann nicht mehr.
    Sprich wenn es ein Exception gibt, kann ich das Mühe abfangen aber nicht durch meinen Code gut weiterleiten. Auch wenn mein Code ein Exception macht, kann TPF2 damit leider nichts anfangen. Wenn LUA dazwischen kommt, wird es erst recht kompliziert.


    CommonAPI2 macht dann zur Anzeige von Fehlern in TramTrackTypes einen Stunt, ruft TPF2 Code auf der mir ein Exception erzeugt, bekomme dann ein Objekt, schreibe das Objekt um und gibt den Fehler an TPF2 wieder zurück.

    -/OT-


    Du musst halt schauen ob du ggf. ein neues Spiel startest mit reduzierten Mods...

    Warum hast du den Spielstand gespeichert? Hatte ich das bei meinen Schritten geschrieben? ||


    Aber ja, dein Spiel erzeugt ständig CrashDumps weil etwas nicht stimmt.
    Die Zeile __CRASHDB_DUMP__ <irgendwas> sollte nicht ständig in der stdout.txt bzw. Spiel auftauchen


    Erster Schritt, stelle unter dem Spiel -> Einstellungen -> Erweitert mal Absturzberichte senden an UG aus sofern du das noch nicht gemacht hast. Da darf kein Häkchen sein.


    Da scheint ein Mod schon beim Laden der mod.lua zu crashen.

    Deine stdout.txt sollte keine __CRASHDB_DUMP__ Einträge haben...


    Beispiel:

    Code
    Loaded 1 of 462 mod descriptions from disk
    Update of mod descriptions: 109.163 ms
    __CRASHDB_DUMP__ 2b193883-6f4f-44a4-a8be-b88bcf3dc40f

    Und nein, ich kann dir nicht sagen welches Mod das ist...

    Da wird CommonAPI2Native immer noch geladen. Entferne eis_os_commonapi2_1 komplett.


    Also nochmals

    - eis_os_commonapi2_1 komplett entfernen / deinstallieren

    - Spiel starten

    - Spiel Laden (eis_os_commonapi2_1 aus dem Spielstand entfernen um Spielstand zu starten)

    - Eine Brücke bauen

    - Ist das Problem noch vorhanden?

    - Spiel beenden

    - stdout.txt dieses Versuchs hochladen

    Irgendwelche KI Erzeugnisse erzählen aber auch genügend Unsinn.

    Ich hab schon ne ganze Menge an Linux Systeme wieder flott machen müssen, deren Kunden mit KI Hilfe und "force" irgendwelche Systemrelevante Pakete per Paketmanager entfernt haben.

    Der Unterschied ist, bei Windows gibt es noch ein Schutz der wichtigen Systemdateien, bei Linux darfst dir halt selber in den Fuß schießen.

    Wenn dann Systemdienste nicht mehr Starten, zum Beispiel der Loginmanager.


    Mod Probleme sind meist kaputtes UTF8 oder "groß und KLEIN" Schreibung von Dateinamen.

    Zur Eingrenzung bitte ich dich mal CommonAPI2 nicht zu nutzen. Die CommonAPI2 hat ja Einstellung, 100% alles Abschalten geht nicht, aber es gibt ja nicht umsonst die Einstellungen.


    Es haben aber auch Leute Probleme ohne CommonAPI2, wie viel CommonAPI2 noch zusätzlich da hinspielt wäre aber gut zu erfahren...

    Die Repositories unter api.res

    autoGroundTexRep

    groundTextureRep

    cargoTypeRep
    haben kein setVisible


    api.res.<name>.isVisible(index) ist eine Funktion


    Das Attribut ob ein Eintrag "angezeigt" wird, liegt außerhalb der Daten der get Funktion , hier mal ein Beispiel.


    Code
    struct StreetTypeRep_Entry
    {
        std::string name;         // genutzt durch api.res.streetTypeRep.find bzw. getAll
        StreetType *streetType;   // Zugriff via api.res.streetTypeRep.get   (in postRunFn schreibbar sonst nur lesend)
        bool visible;             // Zugriff via api.res.streetTypeRep.setVisible  isVisible
    };

    Wie immer der Hinweis, das ist meine eigene Interpretation des Arbeitsspeicher Inhalts und spiegelt nicht UGs Code wieder. (Ich bin aber sehr dicht dran) ;)


    Bitte bedenkt auch, TPF2 hat ein Limit von 255 GroundTexturen wenn ich mich recht erinnere...

    Entferne die CommonAPI2 mal komplett.
    CommonAPI2 wird in jedem LUA State nochmals durch das Spiel geladen. Zwar wird 99% des Codes übersprungen für den init, aber commonapi._native muss trotzdem als Lua Tabelle erstellt werden.


    Ein Problem war mal mal das CommonAPI2 Fehler abgefangen hat, das führte dazu das bei einem Brückenmod zig Fehler im Hintergrund ignoriert wurden anstatt einen Crash zu produzieren.

    Auch hilfreich: Debug Modus abschalten, TPF2 wird für jede Kollisionsneuberechnung die Brücken updateFn neu laden. Alternative: Fast debug mode einschalten (Speichern und Neustart des Spiels nicht vergessen), damit unterbindet CommonAPI2 das neue Laden bei der updateFn und man hat trotzdem die Debug Funktionen...


    Die Kollisionsneuberechnung wird für jede Brücke soweit ich das Verstanden habe, einzeln durchgeführt. Dies hat dann folgen wenn man zig Brückenmods geladen hat...


    -edit-

    CommonAPI2 muss zum testen komplett entfernt werden. (Einfaches deaktivieren in der Modliste reicht nicht)

    Deine Installation ist kaputt, da ist was doppelt...

    Zip Datei im Verzeichnis gelassen?

    Ich warte auf Rückantworten (die bis jetzt noch nicht gekommen sind) auf angebliche Fehler.



    Die Version 35924 ist am 12.12.2024 raus gekommen, da hab ich das hier hinzugefügt:


    https://steamcommunity.com/gro…ns/2/4763206964692168667/

    und hab den Beitrag noch mal editiert...


    Ggf. werde ich heute noch die selbe Version nochmals hochladen. Das kommt aber auf meine Motivation an...