Posts by eis_os

Willkommen in der Transport Fever Community

Welcome to the fan community of Transport Fever and Train Fever, the economic simulators of Urban Games. The community is free for you to share and inform yourself about the game. We cultivate a friendly and objective interaction with each other and our team will be happy to answer any questions you may have.

 

Registration and use is of course free for you.

 

We wish you a lot of fun and hope for active participation.

The Team of the Transport-Fever Community

    Ist das Mod im Spielverzeichnis / mods installiert oder in userdata\xxxxxx\1066780\local\mods ?


    Testweise wäre es hilfreich wenn das zu Updaten bestimmte Mod unter local\mods liegen würde, damit können wir dann besser herausfinden wo der Fehler liegt, dann wäre ein Mod ja auf der selben Partition..

    Den Namen einer Linie oder Stop zu bekommen ist eigentlich unter Windows kein Problem, bei Linux werde ich das wohl auch noch hinbekommen.



    Problematisch ist eben vom CommonAPI2 UI LUA auf den LUA GUI Thread zu gelangen. (Ob das dann alles stabil läuft ist noch eine andere Frage.

    D.h. bei Refresh -> lua_loadstring, lua_pcall remote im GUI Thread, dort die Daten serialisieren, diese im CommonAPI2 lua wieder entpacken.


    Damit komme ich dann an die Linien und Haltestellen Namen, ich nutze dafür meine eigene UI, weil ich UGs UI Code einfach nicht flexibel genug finde. Außerdem möchte ich da auch noch ne Textbox einfügen, damit man auch seine eigenen Endhaltestellen Namen kreieren kann...


    Aber ja, langsam kommen viele Einzelteile im Code wieder zusammen. Es wird nur eben alles etwas dauern...

    Ich habe ja geschrieben, das man jede Haltestelle als Endhaltestelle markieren kann, dies schließt mehrere ein.

    Das Speicherlayout ist schon unter Windows nicht gerade einfach. (Man will ja kein Crash produzieren). Ich habe nun nen neuen Label Type mit interne ID 99. Zumindest ist der zur zeitige UG Code so, das wenn es den Labeltype nicht kennt, einfach NONE annimmt.


    Daher ist leider noch kein vernünftiger Code da, um etwas anzuzeigen, aber naja. Es zeigt schon mal Leerfahrt wenn es ins Depot geht an und CommonAPI2 wenn es eine Endhaltestelle zeigen soll :saint:


    Deine stdout.txt zeigt leider klar eine Laden eine Spielstands.

    Es kann möglich sein das Windows kein Atomic Move zwischen Partition unterstützt. Dann müsste ich mir etwas anderes Ausdenken zum verschieben der Daten.

    Ich habe MOVEFILE_COPY_ALLOWED als Flag gesetzt und MSDN sagt: "If the destination is on another drive, you must set the MOVEFILE_COPY_ALLOWED flag in dwFlags." Das muss also gehen, ist das Verzeichnis oder irgendwelche Dateien dort drin noch geöffnet? Zugriff Verweigert kommt klar vom Betriebssystem, das sagt, es kann es gerade nicht...

    Hallo


    Backround:

    Da Ihr mich kennt und mich schon viele gefragt haben, ich habe den Code der nächste Linienanzeige (LINE_STOP) technisch in CommonAPI2 nochmal nach gebaut.


    Technisch wäre es also wohl möglich eine Endhaltestellen Anzeige in CommonAPI2 zu bauen.

    Daher mal die Frage in die Runde, am einfachsten wäre es wohl anstatt die Linie bei LINE_NAME eine Endhaltestelle zu zeigen.

    Die andere Möglichkeit wäre es wohl irgendwie da einen neuen Labeltyp zu erfinden. (Zur Sicherheit käme dann ne if Abfrage dorthin, wenn keine CommonAPI2 da wäre, kann man dann ne Alternative nehmen)


    Von der UI her, dachte ich mir eine Liste mit allen Linien via UG UI Interface anzuzeigen, dann könnte man für jede Station in einer Line definieren, ob es eine Endhaltestelle ist.

    Die Liste würde dann an meinen C++ Code geschickt, dieser könnte dann für jede Linie errechnen welche Endhaltestelle, die nächste ist, und diese dann anzeigen.


    Ein Lua Callback wäre zwar flexibler, aber schon eine Sekunde hat mir meine Funktion schon zig tausend mal aufgerufen.

    Also muss ich schon vorher wissen was Ihr als Mod Autoren für ein Fahrzeugset unterstützen würdet und den Code zielgerichtet Planen ;)


    Vielleicht mag ja auch mal jemand unser Lexikon Eintrag hier etwas Feinschliff verpassen:

    Zielanzeigen


    Um frühes Feedback wird also gebeten.

    Bitte versuche ein Update eines Mods im Lademenü und nicht während Du schon den Spielstand spielst...

    (wenn es dann auch nicht geht, bitte eine stdout.txt anhängen).


    1. Transport Fever 2 starten
    2. Spiel laden klicken im Hauptmenü (nicht das Savegame starten!)
    3. CommonAPI2 Mods -> Mod Einstellungen
    4. Dann ein Mod versuchen zu updaten

    Wenn es nicht geht, die stdout.txt senden.

    In den ersten Kasten steht:

    "Ihr könnt die CommonAPI nur einmal installieren [...]"

    CommonAPI2 Schnelleinstieg


    1947572332 ist aktiv, also ist die CommonAPI2 noch via Steam abonniert und zusätzlich auch aus der Webdisk...


    Nochmals, bitte haltet euch daran und installiert keine Mods doppelt...

    (Wenn Ihr weitere Probleme diesbezüglich habt, macht im Problem Forum Teil ein Thema auf und erwähnt mich, damit ich ein Hinweis bekomme)

    Ahh, ok, das liegt eher daran, das ich den Fehler nicht abgefangen bekomme. Wenn du etwas in die Konsole schreibst oder Enter drückst?
    Das sieht mir eher danach aus,

    a) Es steht commonapi.dmp(game.interface.getGameTime()) in der Console zum Ausführen

    b) Du hast nen Game Thread der gerade läuft

    c) Du drückst Enter zum Ausführen oder machst Tab Completion


    Dann wird der Befehl commonapi.dmp(game.interface.getGameTime()) an den Game Thread gegeben.

    TPF2 ist gerade in einer Subfunktion. setMaximumLoan

    game.interface.getGameTime() kann nicht ausgeführt werden. -> Ein Crash entsteht.

    Der Crash wird trotz Exception Handler nicht abgefangen...


    Das Threading von TPF2 ist leider ein sehr leidiges Problem. Da ich keinen Mutex habe wenn TPF2 gerade in einem LUA Thread ist, kann ich auch nicht wirklich alles verhindern.

    Ich versuche es aber weiterhin auf dem Radar zu haben und empfehle entweder nen Debugger an zuwerfen, der den Thread anhält oder in den Pause Modus zu wechseln...

    Ich denke du versuchst da gerade in einem GameScript game.interface.getGameTime() aufzurufen, an diesem Punkt gab es ein Problem und das Spiel crasht.

    Ich müsste dann schon deine geänderte base.lua sehen um das nachzustellen um da etwas genauer zu untersuchen.


    Das Problem was ich gefixt habe, hat technisch eigentlich nichts mit Lua zu tun.

    Es gab ein Problem wenn meine Streamumleitung von mehreren Threads gleichzeitig Daten erhalten hatte, konnte es dazu führen, das ein Leeren der ältesten Zeilen zu einem Crash führen.


    Das TPF2 auch ohne CommonAPI2 schon von mehreren Threads ohne Mutex auf stdout schreibt, wird daran nichts ändern.

    Dies kann zu fehlerhaften Daten kommen. std::cout wird zwar nicht crashen aber das Ergebnis ist eine undefinierte Reihenfolge der Ausgabe.

    Das geht jetzt aber am Thema vorbei. Alle Model Daten (lua/cons/mdl) werden bei Start eingelesen, es gibt natürlich einen Textur Manager, der nur die Daten wenn sie benötigt werden eingelesen. Der Model Manager hat auch ein Caching verhalten, da kann ich keine Aussage drüber machen, Modelle und Lod stufen werden teilweise erst später aus dem Blob gelesen.


    Nochmalig die Schreiblast geht hoch wenn du keinen Arbeitsspeicher mehr zur Verfügung hast. Ergo Du hast 8GB Arbeitsspeicher und es klemmt an allen Ecken und Kanten.

    Es sind nur hypothetische Annahmen, es werden nicht andauernd 250MB/s geschrieben. Und ob es jetzt 1, 2 oder 3 Monate dauert, ist jetzt auch nicht der Punkt.

    Ich bleibe bei meiner grundsätzlichen Haltung, es ist gar nicht gut für die SSD und beeinträchtigt die Lebensdauer der SSD auf jeden Fall und man sollte es nicht unterschätzen...


    Nochmalig, zurück zum Thema:

    Die ersten TPF2 Versionen braucht schon die Kampagne mehr als 8GB Ram. Ergo, wer mit Mod spielen will, braucht 16GB oder muss sich mit einer winzige Karte begnügen.

    Macongo


    Bitte zitiere nicht aus den Zusammenhang. Jetzt lies mal meine Beitrag noch mal aufmerksam durch, ich habe nicht geschrieben das Du die Auslagerungsdatei abschalten sollst, sondern nicht vergrößern.


    Du sollst genügend Arbeitsspeicher haben, das du während des Spielens die Auslagerungsdatei nicht nutzen musst. Wenn Du zu wenig Speicher hast, dann wird versucht ggf. gerade nicht genutzte Speicherseiten auf den Datenträger geschrieben.


    Wenn diese Daten ständig genutzt werden und verändert, typischer Weise bei einer WiSim kann es dir passieren, das die Schreiblast durch die Decke geht. Zum Beispiel wenn gerade ein Savegame erzeugt wirst, hast du den Spielstand im Speicher, dann noch die komprimierten Daten, die Zwischenstationen. Gerade NVMe Systeme ohne eigenen Cache sind da gefährdet, da Subjektiv das Spiel noch gut genug läuft. Nochmalig es geht hier darum das dein Programm, d.h. dein Spiel ständig geänderte Daten zwischen Arbeitsspeicher und SSD hin und her kopiert. Gegenbeispiel, ich lagere 10GB an Daten auf die SSD aus, die sich in den nächsten 2 Monaten nicht ändern, hast du nur 10GB auf deine SSD geschrieben. Wenn Du 5GB geänderte Daten aber jede Sekunde neu auslagerst? Da ist mal schnell 1TB Weg...

    Auslagerungsdatei (Swap) wird genutzt wenn der Arbeitsspeicher nicht mehr ausreichen wird. Es werden Teile von weniger genutzten Speicherseiten auf einen relativen langsamen Datenträger ausgelagert. (Das Betriebssystem macht dieses automatisch)



    Technisch können zwei Sachen passieren:

    • Es ist ein Fehler im Spiel oder Mod und der Speicher füllt sich und wird nicht mehr freigegeben => Irgendwann ist er Voll *
      (Auch andere Sachen können Probleme bereiten, Virenscanner, Grafikkarten Treiber)
    • Du hast einfach nicht genügend Arbeitsspeicher um die Menge an Daten zu verarbeiten.
      (Im TPF2 Sinne, zu große Karte, zu viele Mods)


    Die Auslagerungsdatei für TPF2 bzw. WiSim / Aufbauspiele Allgemein zu vergrößern bringt nichts. Die ganzen Daten werden technisch immer gebraucht. Daher ist die Auslagerungsdatei zu nutzen der falsche Weg. Wenn der PC/Notebook eine konventionelle Festplatte nutzt wird die Sache relativ langsam.

    Mit einer schnellen SSD ist vielleicht noch erträglich, die Abnutzung derer ziemlich hoch.(Weil dann die Auslagerungsdatei ständig geschrieben wird, nach nen Monat ist die SSD dann durch)


    TPF2 brauch mindesten 16GB Arbeitsspeicher.

    Jedes weitere Mod braucht Arbeitsspeicher. (Sonst muss man sich auf eine kleine Karte beschränken)



    * Vielleicht ist der TPF2 Texturcache beschädigt, wenn es bei einmaliger Texturkompression hängt. Mal leeren. Und nimmt nicht eine Tonne Mods zum testen...

    Allgemeine Info für CommonAPI2 Nutzer, nun gibt es wieder eine neue Version. Diesmal keine Dev , sondern eine "fertige" Version.


    Wichtig: Um Crashes bei zu viel Nutzung von print in Lua zu umgehen, bitte ich euch dringend ein Update zur neusten Version zu machen.

    Steam Release wohl heute Abend... Veröffentlicht


    Der FileFilter Fix bewirkt, das nun auch Fahrzeuge aus Mods, die im Benutzerverzeichnis / mods liegen, auch wirklich als Mod Fahrzeuge im Spiel geladen werden und nicht heraus gefiltert.

    Dies kann dazu führen das ehemals gefilterte Fahrzeuge nun doch auftauchen, man kann den Fix via Einstellungen abschalten.


    1.2.20200407

    - Fix crash with heavy concurrent access to stdout.txt by using mutex

    - Refactor code for ModList handling, don't call lua in render state but while constructor/destructor runs, should reduce race conditions

    - linux build with active luasocket

    - Add FileFilter fix so staging_area and userdir/mods won't be filtered by region settings


    Hier geht es zu unserer Download Datenbank:

    CommonAPI2 Herunterladen