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


    Jein, es gibt halt ein paar Basis Funktionalitäten die ich benötige.
    Zum Beispiel die LUA Runtime, sonst kann ich ja gar keine Daten zwischen TPFLua und CommonAPI2 Lua Daten austauschen.

    Seit gestern findet CommonAPI2 Linux zumindest die typeids für ecs::component::* wieder.


    Es dauert halt, weil UGs exe / linux binaries wieder mal ganz anderen Bytecode haben.

    Macht doch einfach mal das, was ich da oben geschrieben habe.

    Das sollte das Problem für CommonAPI2 lösen, egal was MS da ausliefert oder was ihr da an krummer Software installiert habt.


    Damit auch wirklich das richtige curl genutzt wird, eben die zwei Befehle in die UG Console des Spiels kopieren.

    "true curl 8.9.1 (x86_64-w64-mingw32)" ist wichtig als Endergebnis. Wenn nicht, lest bitte die Anleitung von vorne und befolgt jeden Schritt...



    PS: Windows Update nicht vergessen anzuwerfen, das curl von MS ist uralt....

    Lösungsansatz:


    Geht auf die Seite https://curl.se/windows/


    Dort curl für Windows 64bit herunterladen.


    Ihr erhaltet (oder eine neuere Version):

    curl-8.9.1_3-win64-mingw.zip


    Die Dateien in bin (in der Zip Datei) in das TransportFever2 Verzeichnis (dort wo TransportFever2.exe liegt) legen.


    Das wären diese Dateien:

    curl-ca-bundle.crt

    curl.exe

    libcurl-x64.def

    libcurl-x64.dll


    Transport Fever starten

    UGs interne Konsole öffnen.


    Diese Zeilen nacheinander in der UG Konsole ausführen:


    modmm = commonapi._modmm


    print(modmm.runprocess("curl --version"))


    Ihr solltet diese hier erhalten:

    Code
    true    curl 8.9.1 (x86_64-w64-mingw32) libcurl/8.9.1 LibreSSL/3.9.2 zlib/1.3.1 brotli/1.1.0 zstd/1.5.6 WinIDN libpsl/0.21.5 libssh2/1.11.0 nghttp2/1.63.0 ngtcp2/1.7.0 nghttp3/1.5.0
    Release-Date: 2024-07-31
    Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp ws wss
    Features: alt-svc AsynchDNS brotli HSTS HTTP2 HTTP3 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM PSL SPNEGO SSL SSPI threadsafe UnixSockets zstd


    Wenn das geht, nochmal versuchen den ModManager zu nutzen...




    (Ich gehe davon aus, das ihr entweder einen Virenscanner irgendwo habt, oder ein kaputtes libcurl)

    Kleines Status Update: Ich hab gestern mal 3 Stunden geopfert:


    Für CommonAPI2 sieht es etwas düster aus, bzw. das braucht ne Menge an Zeit und Arbeit.


    BuildNr, LUA Nilobject(linux), C++ VTabellen, UserProfile liegen woanders, sind anders aufgebaut,

    Renderer mag nicht,
    ModRep mag nicht
    UI::CComponent und UI::CCore haben einen anderes Speicherlayout/ liegen woanders



    Und das ist nur die Sachen die mir direkt ins Auge gefallen sind. Die Linux Version hat einen komplett anderen Codeaufbau. Beispiel, ich kann mich nicht erinnern, das ich das LUA Nilobject Fragment ändern musste.


    Dabei sind die eigentlichen Features noch nicht mal geladen... ;(

    Achtung:

    Wegen privater Angelegenheiten wird es für das Herbstupdate voraussichtlich kein direktes Update geben


    Sprich benutzt bitte bei Steam die Stabile Version bzw. bei Release das Build Archive und seht bitte von privaten Nachrichten ab, danke


    Anleitung gibt es hier:

    https://www.transportfever2.co…php?id=gamemanual:updates

    Das sollte dann buildArchive35732 in Zukunft sein


    -edit-

    CommonAPI2 won't work with the new beta version.


    Please use the stable branch, as soon as the beta get's stable, use buildArchive35732

    https://www.transportfever2.co…php?id=gamemanual:updates


    Because of family related issues I can't directly start to development with full speed.


    Please don't send me private messages!

    See later posts for development versions...





    Ich hab das Thema wieder geöffnet, bitte bombardiert mich nicht mit Support anfragen...

    Keine Ahnung, vielleicht funkt wieder mal ein Virenscanner dazwischen.


    In der stdout.txt kann man den letzten Befehl via curl sehen, diesen einfach mal in eine Terminal Fenster eingeben und schauen was curl sagt...


    Sprich eine Zeile wie diese hier:


    curl -f -w "HTTP Status: %{http_code}" -sS -m 150 -L --create-dirs -z "C:/Program Files (x86)/Steam/userdata/79646336/1066780/local/commonapi/repos/tpfnet-tpf2.json" -o "C:/Program Files (x86)/Steam/userdata/79646336/1066780/local/commonapi/repos/tpfnet-tpf2.json" "https://www.transportfever.net/filebase/repos/tpf2.json"


    Natürlich ist bei euch die SteamID anders, daher nimmt die Zeile aus der stdout.txt!

    There is no setText api call. (you only can change the name, and this will change ecs::component::Name

    The only technical way (arrival boards as example) is to use an updateConstruction passing new data as params into it. Then your updateFn creates a new "plan". The construction builder then generates new components like MODEL_INSTANCE_LIST (for models) and CONSTRUCTION and so on.


    Note: It's not possible to directly write into an ecs component. You always have to use a command. (so it is propagated and all stuff knows about updates)


    Technical the label texts are stored into the ecs::component::Construction (that's why my dumpConstructionLabels needs the actual ecs::component::Construction as read only sol element)


    As soon as UG has finished (no more feature updates) TPF2 I consider adding a new cmd for changing texts... (I could not extend setName for this without breaking savegame compatibility, nor can I add a new command as it could collide with new cmds )

    There is special phase TPF2 applies all commands and a phase to copy all modifications to the ui thread..

    Hmm, where do I start.


    Ok, first I reset, I grab a fresh aboag_v2.mdl as base, then I changed there

    filter = "NUMBER", to filter = "NONE",


    I removed the whole vehicle related stuff...



    Then please note:


    To improve performance, for simple constructions that do not contain ground faces, terrain alignments, edges or depot/station/industry/town building definitions, there is no construction placed in the game but just the seperate mdls. These can not be configured afterwards or be deleted all at once. Furthermore these types of assets do not support the labelText custom texts from constructions.


    Without construction, no LabelText. So the build thing has to be configurable (clickable) -> component construction exists.

    Therefore I had to add a groundtexture to the result.


    Then TPF2 code wants 0 based indexes, so

    result.labelText = { [index-1] = {"Hallo", "B", "C"} }


    Note: The preview from the build cursor won't show labels. So you have to actually build the construction... Hope that helps...



    For CommonAPI2 users and heavy construction scripts, CommonAPI2 can show the internal LabelData as seen from C++ side, this may help in debugging:


    commonapi._native.LabelSystem.dumpConstructionLabels( api.engine.getComponent(181798, api.type.ComponentType.CONSTRUCTION) )

    Per transf nicht. (du definierst ja nur einen Punk im Raum und dann die Ausrichtung) Auch wenn du sagen wir die Eckkoordinaten anders platzierst bekommst, hättest du weiterhin nur eine Fläche (4 Punkte im Raum). Du brauchst dann mehr Dreiecke oder müsstest das Ergebnis ändern via Mesh Shader. Dafür hat TPF2 aber keine Möglichkeiten.


    Texte werden in der Regel nur im sichtbaren Bereich gerendert. Wenn du nur ein paar Buchstaben hast, sagen wir mal 6, dann ist das ja noch überschaubar, wenn dann 100 Texte zu je einem Zeichen durch die Pipeline gejagt wird, wird das nicht so toll mit mehreren Fahrzeugen. Ist halt so als würdest ein ne Menge flache Messingbuchstaben anschrauben wollen.

    "Error message: Required key not found: models" result.models wird scheinbar in der Konstruktion nicht zurückgegeben... Sprich TPF2 hat keine Modelle für den "Bauplan"

    Was verstehst du mit einer Operation?


    Ein Funktionsaufruf eines GameScript ist Atomar. Sprich alle api engine Befehle bringen dir das selbe Ergebnis hervor, Gamescripte laufen nicht parallel. (mal LUA SOL2 Problemen ausgenommen, die Probleme mit der Lebenszeit von Zeigern hat, ist das Ergebnis gleich)

    Mit Boardmitteln ist es in TPF2 nicht möglich das Entity System aus lua zu ändern. Du hast also nur die Möglichkeit ein Propsal aufzubauen und mit einem cmd abzuschicken. Bzw. das Propsal abzubrechen.


    Technisch hast du zwar mehrere Threads aber in einem Thread des GameScripts hast du nur eine Ansicht der Welt im Entity System.

    Alle Daten der GameScripte werden dann kopiert in C++ und wieder im anderen Thread "entpackt" zu lua.

    Alle möglichen aufgezeichneten cmds abgearbeitet wenn das Spiel läuft... (Hier ändert sich also der Spielstand)

    -> die Daten für den UI Thread synchronisiert.


    Also solange du in handleEvent bist, bleibt alles gleich. Du darfst niemals LUA SOL2 Pointer aus einer Funktion in eine andere mitschleppen. Also zum Beispiel "update", "load", indem du das Ergebnis an eine Variable außerhalb der Funktion bindest. (oder du machst eine Kopie und hast dann eine echte LUA Tabelle)


    Beispiel:


    local bla

    handleEvent = function (src, id, name, param)

    bla = api.irgendwas()

    end


    --- Intern ändert nun TPF2 das Spiel


    update = function ()

    bla[irgendwas] -- *boom* die Pointer sind nicht mehr valide oder zeigen wild auf anderen Speicher.

    end



    --

    UI Funktionen sind da etwas eigen, entweder gehört dir das Objekt (also dem lua State bzw. UI::MemoryManager) oder der C++ UI.

    Problematisch wird es wenn du ein UI Element an ein Buildcursor / bzw.. Action hängst, das hat wie auch Dropdowns einen eigenen UI::MemoryManager. Wenn das nicht stimmt, gibt es in der UI Chaos und einen Crash.



    Zurück zu getNode2StreetEdgeMap:


    Im NodeEditor nutze ich ipairs ohne Kopie. n2street darf nicht out of scope gehen, aber das userdata hat die Funktionalität von ipairs gebunden.


    local n2street = api.engine.system.streetSystem.getNode2StreetEdgeMap()

    local connectedStreets = n2street[baseNodeEntityId] or {}


    local streetData = {}

    for idx, edgeEntityId in ipairs(connectedStreets) do


    end


    Perfomancetechnisch gesehen, solltest also keinen komplette Kopie der Map anlegen... du kopierst dann nur noch mehr Daten...

    Nutze - die wenn auch umständlichen - UG postRun Methode.


    Ich kann halt keine Garantien geben und musste den Code schon 2021 teilweise abschalten. (Filterung, da es zu einem UG Update inkompatibel wurde).

    Da ich die API Schnittstelle wegen TPF1/2 Alt Mods nicht ändern kann, gibt es technisch auch keine Möglichkeit das groß zu verbessern.

    Sprich, es gab das technisch alles mal für TPF1 + CommonAPI1, für TPF2 sieht es zurzeit eher schlecht aus...