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


    Kurz überflogen


    function data()

    local function makeParams()


    Was denn nun? Ne lokale Funktion in der Funktion Data? Einfach so geraten,

    local function makeParams() willst du gar nicht haben, da es nicht aufgerufen wird...


    Wenn doch, sollte es wohl vor dem return enden?


    Am Ende der Datei hast du:


    } -- Ende von Tabelle gestartet bei return {

    end -- Das eigentliche Ende von function data() da nichts mehr weiter kommt.


    Ergebnis:

    Der Interpreter sieht die function data gestartet, dann die lokale Funktion makeParams,

    dann wird ganz unten mit end nun die lokale Funktion beendet, aber die data ist immer noch nicht fertig: Du siehst den end Fehler in der Fehlermeldung mit einer nicht geschlossen Funktion aus Zeile 6.



    Nutze mal Texteditor der dir den Code formatiert. Das sieht grauenhaft aus...
    Das hilft beim Code "Schachteln" ungemein :)

    "starting up build version: 35716"


    Wie ich schon mehrmals geschrieben habe, man kann nicht einfach eine CommoAPI2 Version mit einer beliebigen Build Version verwenden. CommmonAPI2 muss die genauen Interna von TPF2 kennen und kann die Fragmente in der exe Datei nicht finden. In anderen Worten:

    Jedes mal wenn UG eine neue Version herausbringt ist die EXE Datei anders - der Byte Code und die Instruktionen und das Speicherlayout ändern sich.


    Du brauchst die GOG Version Build 35720, die Testing Version 35731 oder via buildoverwrite 35732 zusammen mit CommonAPI2 20231215.


    Das steht aber auch so in jeweils in den Changelogs drin, wie in deinem Fall:

    1.8.20231206

    - BUILD 35720 Version Steam windows and linux support


    -----

    As I said numerous times you can't simply use a random ComonnAPI2 Version with a random TPF2 Build Version. CommonAPI2 does need to know the exact inner workings of TPF2 and technical can't load because it can't find all code pieces in the exe. Or in other words. Every time UG releases a new build the release binary has a different byte stream, instruction encoding and or memory layout.


    You need tpf2 gog version Build 35720 stable, 35731 or ( 35732 via buildoverwrite to use the last CommonAPI2 20231215


    The changelog of the installed version says:
    1.8.20231206
    - BUILD 35720 Version Steam windows and linux support

    Das liegt eher an der UI, das du das nicht sehen kannst. Im Entity Fenster der Linie kannst du mit Longer Names da 255 Zeichen rein bekommen:



    Aber weder das Haltepunkt Übersicht & Terminal Fenster, noch die Linienliste können dir das dann zeigen...

    Neue Version 1.8.20231215


    Nun gibt es Unterstützung für die Windows und Linux Build 35731 (testing)

    Dauert das Speichern sav.lua Daten zu lange? Dafür gibt es nun fastsave. Diese Funktion ersetzt UGs serialize.lua und sollte ab 100KB sav.lua Dateien schnelleres speichern ermöglichen.

    Sprich für Nutzer von LINE_DESTINATION, NodeDaten und Timetables kann das sehr hilfreich sein.

    Mit commonapi.nodedata.removeAll() kann nun in der Console ausgeführt werden, dieses entfernt alle gespeicherten NodeDaten und gibt einen Umbau Auftrag für jede Kreuzung mit NodeDaten an die Engine.

    Der Neubau der Kreuzungen kann ggf. lange dauern...



    1.8.20231215

    - BUILD 35720, 35731 Version GOG, Steam windows and linux support

    - nodedata: sort BASE_NODES by distance in getOrCreateNodeDataForPositions

    - nodedata: new console command "commonapi.nodedata.removeAll()", removes all NodeData and rebuilds all basenodes at positions

    - new fastsave feature: replaces serialize.lua with a much faster version



    Downloads:

    >>> CommonAPI2 Download

    >>> Streetpackage Download



    CommonAPI2 1.8.20231215 mit / with Build 35732 :

    Buildoverwrite:

    Steam Linux: steam_35732_2

    Steam Windows: steam_35732_1


    GOG Linux: gog_35732_2

    GOG Windows: gog_35732_1

    Wie gesagt, ich bin immer noch daran interessiert ne sav.lua Datei zu bekommen mit den NodeDaten,

    wie soll ich sonst etwas verbessern?


    Um euch mal ein Eindruck zu geben zu den Unterschieden:


    Für 700KB sav.lua Testdaten braucht mein Code nun:

    Using eis_os_turbosave for serializeStr

    elapsed time for serializeStr: 0.16


    Und UGs Code:


    Using UG serializeStr

    elapsed time for serializeStr: 29.61


    Also unter einer Sekunde vs. 29 Sekunden, das Ergebnis ist identisch bis auf ["guidesystem.lua"] = { time = 118377.80000062, aber das ist ja klar...


    Auch wenn ich jetzt mal genug Testtoleranzen einrechne, umso mehr Daten in der lua Datei geschrieben werden müssen, umso langsamer wird das ganze mit dem Code von UG:



    Zweiter Test:


    882KB Testdaten:


    NodeData_SaveScriptData:

    NodeData_SaveScriptData: done, converted 9970 entries to luaTPF::Value

    anonymousSaveScriptData_gsu_save_Hook: done

    Using eis_os_turbosave for serializeStr

    elapsed time for serializeStr: 0.27



    NodeData_SaveScriptData:

    NodeData_SaveScriptData: done, converted 9970 entries to luaTPF::Value

    anonymousSaveScriptData_gsu_save_Hook: done

    Using UG serializeStr

    elapsed time for serializeStr: 48.54


    Ich glaube das lohnt auf Windows portiert zu werden .... :D

    Ehm, du kannst die Karte doch laden oder?

    Ich brauche dann immer die Paar sav und sav.lua Ich muss wissen wie viele Daten dort drin sind für eine Analyse.


    Speichere niemals auf den selben Speicherstand, habe immer ein Backup.


    Nein, zurzeit gibt es keine alles entfernen Funktion, aber das sollte ich einbauen können. Die Daten sind in der sav.lua drin. Ich kann mir das immer noch nicht erklären. Ich speichere 11000 Nodedaten, das dauert zwar knapp 4 Minuten.

    (32GB DDR4 3200), aber dann läuft es weiter. Und die sav.lua ist dann eben auch recht groß.


    Eine Verbesserung des Serializer ist aber auch schon in Arbeit,

    aber das sieht sehr nach einem anderen Fehler aus.


    Ich kann 100 Nodes ohne Probleme hier speichern, je mehr Nodes um so langsamer wird das Speichern. Die neuste Version sollte

    eis_os_commonapi2_1_20231206.zip

    jedenfalls schneller sein, da weniger Daten anfallen.



    -

    Wenn du Dll nicht überschreiben kannst, hast du TPF2 noch im Hintergrund gestartet. TPF2 sauber beenden oder via Taskmanager schließen.


    Die CommonAPI2 Dll Dateien können nur immer mit der "richtigen" Version genutzt werden. Du kannst nicht eine neue DLL mit alten LUA Code mischen. Das Format der NodeDaten hat sich geändert. Aber alte Version werden neue Daten einfach ignorieren und das wäre dann auch ein Ladefehler und kein Speicherfehler.




    ---

    WernerK

    Die Beschreibung steht im Fenster, über den Farben,

    du kannst alle Modi via Rechtsklick verlassen.

    Jetzt machst du mich unsicher...


    *lädt CommonAPI2 herunter*

    Mal die strings.lua anschauen:

    -- stateNodeEditor

    ["Please select a source lane node by left clicking on highlighted green anchor,"] = "Eine grün hervorgehobene Quelle mit linker Maustaste wählen,",

    ["right click to exit and back to node selection."] = "mit rechter Maustaste zur BaseNode Auswahl zurückkehren",

    ["Currently selected node data:"] = "Selektierte Nodedaten: ",

    ["Delete additional data and reset base node"] = "Nodedaten entfernen und BaseNode reset",


    Muss dann nochmal schauen in TPF2


    Funktionieren denn nun die RTP Strassen richtig?



    -edit2-

    Neue CommonAPI2 Version 1.8.20231206 für TPF2 Build 35720


    FlexStreets Fehler das bei Straßenbahngleisen immer Oberleitungen angezeigt wurden beseitigt (aus -dev Version)

    Die showSomethingBoxes Rendereinstellung im Inspektor wird nun nicht mehr angezeigt.


    Es können nun Node Anker via NodeWindow ausgewählt werden auch wenn die Fahrbahnbreite (laneWidth) sehr klein ist.

    Beispiel: Straßen die beide Richtungen quasi übereinander legen.


    Downloads:

    >>> CommonAPI2 Download

    >>> Streetpackage Download



    1.8.20231206
    - BUILD 35720 Version Steam windows and linux support
    - inspect window: hide rendersetting showSomethingBoxes
    - nodedata: don't cleanupStreetGraph in rebuildNode
    - NodeWindow: fix non-clickable nodes when lane width is very small (use 0.5 as minimum clickable radius)
    - NodeWindow: make stacked node anchors selectable by filtering by lane forward flag


    1.8.20231202-dev
    - BUILD 35720 TEST Version Steam windows only!
    - native: NodeData use simple lua array for savegame storage, bump to version 2
    - native: FlexStreet Generator show catenary only when ETram attribute is set
    - NodeWindow: move rebuildNode to nodedata, support error reporting, always ignore collision
    - native: NodeData try to get best matching angle for street matching
    - native: NodeData use sorted linear vector instead of map, faster node lookup time by position, slower getById lookups
    - native: NodeData don't add empty removeCon, addCon tables to lua output to reduce size
    - native: reduce debug output of StreetTerminal Hook

    1.8.20231202-dev benutzt oder älter?


    Ich bräuchte dann auch mal die sav.lua des Spielstands, der kein Autosave mehr kann...

    -edit- Als lokale Änderung hat es funktioniert, als mod geht die Änderung nicht. Also leider doch nur für CommonAPI2 Nutzer :/


    -edit-


    Neue CommonAPI2 Version 1.8.20231206 für TPF2 Build 35720:


    Damit sollte man auch die Straßen mit übereinanderliegende Spuren wie im RTP Gleisset erfolgreich ändern können.

    Einfacher Test:

    CommonAPI2 zum Testen einmal komplett entfernen, deinstallieren, läuft es dann?


    Wenn ja, hast du ein Update gemacht?

    Es kann nicht sein, das es von heute auf morgen nicht mehr funktioniert,


    Nein, wenn du Steam Mods nutzt, gab es ein Update für irgend ein Mod?


    Ggf. mal via Steam die Spieldateien überprüfen.

    Was aber jetzt gar nicht mehr funktioniert, ist die mit BwC konstruierte Kreuzung. Da kann ich den zweiten Node nicht mehr markieren. Was spricht dagegen, den Kollisionscheck beim Proposal generell abzuschalten, statt die Markierung zu sperren? Oder ist sie gar nicht gesperrt, und es ist nur ein gewöhnlicher Bug?

    Es ist kein Code drin, der etwas abschaltet, umschaltet oder verhindert. Ist das die Testkreuzung in einem Testspielstand, den du mir schon geschickt hast?

    Beide Umbauten im Code werden via nodedata.rebuildNode(pos, callback, ignoreCollision) abgewickelt.


    In Zeile 854, wird nd.rebuildNode(statedata.nodeData.pos, fn, true) aufgerufen, d.h. ich verstehe nicht warum du mir immer wieder sagst, ich würde etwas verhindern?

    Ggf. ist dein BaseNode und NodeData nicht mehr zueinander ausgerichtet. Blaue Markierung und Rote Markierung liegen nicht mehr aufeinander?

    Gerade wegen deinen Beschwerden hab ich im Code die NodeDaten Umkreissuche von 3m auf 1m reduziert...



    Der Button "Wähle ein BaseNode" ist selektiv Blau, sprich nur wenn du da drauf klicken sollst. Wenn er nicht mehr genutzt werden soll, ist er nicht mehr hervorgehoben.

    Steht aber auch im Hilfetext, das man via rechter Maustaste wieder zurückkehren soll.

    Ggf in Zukunft werden bestimmte Einstellungen nicht direkt gespeichert/umgesetzt.


    Wenn du da auf "Wähle ein BaseNode" klickst, machst halt ein reset ohne etwas zu Speichern.



    Verbindungen via transportModes selektiv abschalten geht nicht, nochmalig, das was ich dir auch schon per Nachricht geschrieben habe:

    TPF2 will die Verbindungen errechnen, ruft eine Funktion auf, die eine Liste mit Einträgen aus:

    { QuellstraßeIndex, QuellLaneIdx, ZielStraßemIndex, ZielLaneIdx} erstellt. Da gibt es keine transportModes.


    Genau das Ergebnis dieser Funktion manipuliere ich. Etwaige andere Änderungen bedürften ein neu schreiben von 7 Funktionen, da diese unter Linux alle zu einer optimiert wurden. Dafür müsste ich dann auch noch Menge mehr wissen anhäufen wie lanes, transportModes in das TransportNetworkSystem gespeichert werden. X Winkelberechnungen und noch ne Menge andere Sachen.


    Bitte sei mir nicht Böse, aber das ist kein Vergleich zu irgendwelchen Änderungen von Lua oder con Dateien.

    Da kannst im Binärcode nicht einfach was ändern. Da TPF2 regen Gebrauch von Exceptions macht, gibt es nur bestimmte stellen im Code, x86_64 long jmps, calls wo Du wirklich neuen Code aufrufen kannst. Wenn da Stackmanipulationen wie push/pop drin sind oder du eine Grenze eines try / catch Blocks überschreitet wird dein Spiel definitiv abstürzen.


    Auch wenn ich etwas in LUA errechnen kann, heißt das nicht nicht das ich da Zugriff genau an der Stelle habe, wo ich Code im Binärcode einfüge. Das kann wegen Unwissenheit von Strukturen/Speicherlayout sein oder weil die Funktion die Daten einfach nicht geliefert bekommt, da sie nur einen Teilaspekt abdeckt.


    Mit der Einführung der Änderung der Nutzung eines Vektors, hatte ich mal Debug Ausgaben eingebaut.

    Bei einer Kreuzungsänderungen via api.cmd gab es gleichzeitig zwei nebenläufige Threads, noch nicht mal diese hatten die selben Straßen zu StraßenIndex Mapping.



    Also nochmalig, ich versuche viel umzusetzen und auch alle Bugs auszumerzen.

    Es gibt in meinem Code nie stellen wo ich aktiv etwas verhindere ohne Grund.

    Wenn ein Code Teil etwas aktiv verhindert, wird der Grund meisten sein, dass das Spiel abstürzt oder das Gameplay sehr stark negativ beeinflusst.

    Beispiel, der NodeWindow Code lässt es nicht zu das du zwei Lanes so verbindest, das nachher Verkehr in die falsche Richtung einen Deadlock verursachen. Das ist der abgeschaltete Advance Modus...


    Warum die Kreuzung sich also nicht mehr umbauen lässt, keine Ahnung.

    Es kann kann halt sein das die Änderung der Behandlung der Kurven dieses Problem auslösen... ich danke dir für deine Tests, wenn etwas nicht mehr läuft, müssen wir halt den Grund herausfinden...

    Testversion


    Da ich ja bei Straßenbahngleisen die Oberleitung immer angezeigt habe, nun mal eine Windows Test Version, dieser Fehler sollte nun behoben sein


    NodeDaten:

    NodeDaten werden nun anders intern und in lua gespeichert.

    D.h. es gibt eine neue Savegame Version für die lua Daten in sav.lua, alte Daten werden beim Laden konvertiert...


    Darüber hinaus wird nun versucht ab 1.5° die Straße mit der wenigsten Winkeldifferenz zu nutzen (wie vorher wird die absolute Differenz genutzt)

    Damit sollte der Code auch sehr ähnliche Winkel verdauen können, damit Werner vielleicht seine Straßen gebändigt bekommt. ;)

    Für großartige Test war keine große Zeit.


    1.8.20231202-dev

    - BUILD 35720 TEST Version Steam windows only!

    - native: NodeData use simple lua array for savegame storage, bump to version 2

    - native: FlexStreet Generator show catenary only when ETram attribute is set

    - NodeWindow: move rebuildNode to nodedata, support error reporting, always ignore collision

    - native: NodeData try to get best matching angle for street matching

    - native: NodeData use sorted linear vector instead of map, faster node lookup time by position, slower getById lookups

    - native: NodeData don't add empty removeCon, addCon tables to lua output to reduce size

    - native: reduce debug output of StreetTerminal Hook

    sav.lua, da sind die GameScript Daten gespeichert... Nicht die sav Dateien...

    Die Frage aus meiner naiven Sicht wäre dann eher: Musst du wirklich alle Base Nodes speichern? Oder würden auch die reichen, an denen was verändert wurde.

    Ich speichere doch nicht alle Nodes bei allen Karten... :S "Ich hab mal in meine Testmap mal alle 10k BaseNodes mit NodeDaten hinzugefügt "

    Es geht hier um Performance Tests. Natürlich wird nicht alles gespeichert, sondern nur die vom Nutzer definierten, aber wie will man Code optimieren mit 20 Nodes ;) ...


    Außerdem ich kenne euch doch, Ihr baut dann jede zweite Kreuzung um, oder baut Kreuzungen mit acht Straßen, das muss der Code aushalten... :P

    Hallo,


    hat jemand Spielstände mit großen .sav.lua Daten?


    Wenn ja wie groß werden die bei euch? 200KB 300KB 500KB noch mehr?


    Ich hab mal in meine Testmap mal alle 10k BaseNodes mit NodeDaten hinzugefügt und stelle fest das Speichern wird nun extrem langsam (außerhalb meines Codes) so bei 80% (siehe Grafik)

    Hab nun gut 1MB an sav.lua Daten :/ Gut ich glaube es gibt kaum jemand der 10000 BaseNodes definieren wird aber das Speichern zerrt an den Nerven...


    Sprich die Anzeige bei Speichern... bleibt dann so stehen:

    Hmm, kann sein das TPF2 da was in ein Cache packt... Bit ist gefunden und zumindest meine Test zeigen auch wieder Gleise ohne Oberleitung.

    Morgen (wenn nix dazwischen kommt) gibt es ne neue Bugfix Version.


    -edit-

    Bugfix Version findet man gerade hier: