CommonAPI2 Entwicklungsdiskussion, Fragen & Antworten

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


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

    Zitat von WernerK

    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

    Ich hab tatsächlich ein Savegame dessen .sav.lua inzwischen bei 490 KB angekommen ist. Das speichern dauert immer eine halbe Ewigkeit, insbesondere nachdem ich das Spiel für so mindestens 15 Minuten hab laufen lassen, dann kann der Speichervorgang auch mal 3-5 Minuten brauchen.

    Zitat

    oder baut Kreuzungen mit acht Straßen

    Das mach ich eigentlich nur als Trick, um die viel zu engen und bislang nicht zu eliminierenden Verbindungskurven an normalen Kreuzungen zu vergrößern, wenn meine Tramkurven-Mod gerade mal nicht passt. Eigentlich gehe ich sehr sparsam damit um. Aber vielleicht brauch ich's mit CommonAPi bald gar nicht mehr. Aber vorher brauchen wir natürlich den Härtetest. ;-)

    Ich will TpF3 mit Dinos, Zombies und Vulkanen!

    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

    Zitat

    damit Werner vielleicht seine Straßen gebändigt bekommt.

    Na, da woll'n wir doch mal schau'n. :-)


    Tram ohne Oberleitung ist wieder da. :-)


    Und hier mein weiterer Testbericht:

    • Es hat jetzt bei allen Kreuzungen funktioniert. Wie du das umgesetzt hast, spielt keine Rolle, Hauptsache Italien :-)
    • 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?
    • Nach wie vor nicht markierbar sind eingleisige Zweirichtungs-Tramstrecken und natürlich auch Fußwege, also alles, wo die Fahrbahnen mit Minimalabstand oder sehr dicht nebeneinanderliegen. Bei den Fußwegen tut es nicht weh, wohl aber bei den Tramstrecken, denn gerade für sowas wird dieses Feature ja gebraucht. Könntest du da nicht so was wie eine Mehrfachklick-Rundum-Abfrage einbauen, wie ich es bei meinen Markern mache? Die dicht beieinanderliegenden Nodes würden dann zunächst in einer Tabelle landen, und mit jedem Klick würde zwischen den in Frage kommenden Nodes gewechselt.
    • Select base node by mouse sollte generell blau unterlegt sein und nicht nur beim Aufrufen des Dialogs. Dass da ein Button ist, erkennt sonst niemand.
    • So als Zukunftsmusik, und ist auch nicht ganz so wichtig: Gäbe es eigentlich die Möglichkeit, die Verbindungen selektiv nur für Trams herauszunehmen, so dass andere Fahrzeuge passieren können?

    Ich will TpF3 mit Dinos, Zombies und Vulkanen!

    2 Mal editiert, zuletzt von WernerK ()

    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...

    Wie viele Nodes hast du den definiert, damit es langsam wurde?

    Oder Sachen wie Timetables genutzt?


    Ja, ich hab da ne Idee wie ich das Speichern schneller bekomme im Script Bereich...

    Ich muss sagen, ich hab es testweise sehr unüberlegt auf einer sehr großen Map benutzt und auch nur an einigen Kreuzungen rumprobiert, wovon aber alle großen Kreuzungen kein Ergebnis lieferten. Leider hat das dennoch dafür ausgereicht, dass die Autosaves meinen PC komplett einfrieren :/.

    Berliner, BVG <3

    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:

    Beitrag
    RE: CommonAPI2 - Neue Versionen und wichtige Informationen
    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





    …
    eis_os


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

    Zitat

    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...

    Ich bin da ganz ehrlich, ich habe noch einmal versucht, das nachzuvollziehen, und diesmal hat alles geklappt. Ich weiß nicht, ob ich da selber was falsch gemacht habe oder der Fehler sehr versteckt liegt. Ich werde das Ganze mal im Auge behalten, mehr geht da im Moment nicht. Ansonsten bezog sich das auf die erste Testkreuzung, die ich dir geschickt habe.

    Zitat

    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.

    Wo finde ich denn den Hilfetext? Ansonsten stelle ich mir das so vor: Ich klicke auf den blauen Button, dann er scheinen die großen roten oder blauen Kreise. Wenn ich auf einen davon mit der linken Maustaste klicke, erscheinen die Nodes, die ich dann in der Reihenfolge Grün- Blau - Rot - selektieren kann. Um mehrere Verbindungen eines BaseNode zu löschen, klicke ich zwischendurch immer wieder mit Rechts in den Node.


    Was mache ich aber, um zum nächsten BaseNode zu wechseln? Da müsste ich doch eigentlich wieder auf besagten Button oben rechts im Dialogfenster klicken, der dann aber nicht mehr blau unterlegt ist?! Genau das war mein Kritikpunkt.

    Ich will TpF3 mit Dinos, Zombies und Vulkanen!

    Hab jetzt auch die neue Version versucht und leider genau das gleiche Ergebnis. Speichervorgang führt immer noch zum Absturz von Transport Fever + halbem Computer. Meinen Speicherstand habe ich dir hochgeladen, ich hoffe, du kannst daran noch irgendetwas rütteln. Es wäre echt schade um die Karte.


    edit: Besteht die Möglichkeit die Nodes per Konsole zu entfernen?


    edit2: Ich habe mir jetzt mal die Dummy-Mod aus dem Nähkästchen gekramt und ich habe es wieder geschafft zu speichern :) Ich habe ebenfalls versucht eine ältere Common API Version zu laden, aber es ist mir nicht gelungen die Native Dll zu ersetzten, da sie angeblich geöffnet war. Ich hoffe, es besteht irgendwie die Möglichkeit das zu fixen, würde gern die API in Zukunft weiter benutzen.


    Vielen Dank für die Hilfe :)


    https://workupload.com/file/vRamFCY8Q8b

    Berliner, BVG <3

    Einmal editiert, zuletzt von ERXC ()

    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 Version ist drauf. Speichern funktioniert tatsächlich, dauert leider länger als sonst, aber funktioniert. Ich habe als kleinen "Hotfix" die Nodes aus der .lua rausgelöscht und dadurch ging das Speichern auch wieder. Da ich persönlich denke, dass es einzig und allein am Nodefeature liegt, werde ich das aus Liebe zu meiner Karte erstmal sein lassen, aber dennoch bedanke ich mich für die Hilfe, die Frustration sollte damit erstmal beendet sein :D

    Berliner, BVG <3

    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

    Bei 9,3KB kann ich mir beim besten willen nicht erklären warum das Speichern nicht funktioniert... ich werde weiter testen, aber habe gerade keine Idee worin dein Fehler besteht...