CommonAPI2 Entwicklungsdiskussion, Fragen & Antworten

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

  • Dieses ist der CommonAPI2 Entwicklungsdiskussion, Fragen & Antworten Thread. (ein Split aus dem Release Thread)


    Um die Id im Forum zu erhalten, muss ich leider etwas um verschieben, der alte Inhalt folgt.


    Neue Test Versionen und wichtige Informatione gibt es weiterhin im ursprünglichen Beitrag hier:

    CommonAPI2 Releases



    Hallo


    da mich viele aus der Community angesprochen haben. Hier also meine Idee zur CommonAPI2:

    • Eine neue Schnittstelle zwischen Bahnhofs Mods und Gleispakte.
      Dabei würde dann in Richtung result.commonapi2.addTrack(result, ..., "tracktype", caternary) gehen. Dafür muss der Bahnhof angepasst werden. (Wird wohl eine API Funktion sein)
      Bei UGs Bahnhof bin ich bei der Umsetzung noch nicht sicher. Ich würde dann wohl einen Adapter anbieten (ergo technisch leider den Bahnhof komplett überschreiben, weil es anders nicht möglich ist)


    • Für die Schnittstelle ein Schmalspur Gleis anbieten. Bzw. eine Referenz für die Community. (UGs Modularer Bahnhof mit Adapter würde dann mit jedem Gleis nach dem CommonAPI Standard funktionieren, bzw. jeder Bahnhofsmod der auch die jeweiligen API Funktionen aufruft)
    • Repository Funktionen vielleicht für Schienen?
    • Dokumentation wieder in luadoc

    Eure Wünsche? Meinungen, Fragen?


    Ob ich wieder einen nativen Teil programmiere?

    Eine LUA Console mit stdout.txt Ausgabe fände ich auch schön, auch eine komplette UI. (Siehe CommonAPI Modeinstellungen direkt in TPF)

    250 Fragmente im Code zu suchen und auch wieder alles verstehen ist etwas sehr viel Arbeit. UG hat das auch nicht vor irgendwie zu fördern, ergo fange ich da recht wieder am Anfang an, daher ist das zurzeit eher unwahrscheinlich.






    Ich hab zwar mit dem UI Toolkit von UG schon mal ein Fenster gebaut, aber fast keine Möglichkeit dieses aufzurufen. Das ist also für mich kein guter Weg. Ich bin auch an überlegen für ein anderes Mod, - eine neue Station - wie ich Krümmungen verheirate mit der UI. Mein alter TPF Bahnhof hab ich komplett gekrümmt. Dafür braucht es aber eine Beschreibungssprache (Merk hat was ähnliches) um die Teile miteinander zu verbinden.


    Auch Ankerpunkte für Teile würde ich gerne Spezifizieren. Güterlanes, Passagierlanes, Strassenlanes, Treppen für Etagen rauf/runter. Das hab ich bei meinem TPF Bahnhof gemacht, und auch Lanes automatisch verbunden.
    Ich bin nicht gut in 3D Objekte basteln und hoffe doch sehr, das wir das diesmal mit Modulen irgendwie zu einer Zusammenarbeit kommen können. Also ein Bahnhof mit 1000 Modulen anstatt 300 Bahnhöfe mit jeweils 3 Modulen ;)

  • Leider nein. TPF2 hat zu viele LUA Runtimes am laufen. Technisch ist es so, das TPF2 beim Laden seine LUA VMs nicht mehr weiter nutzt. Früher hatte ich einen Preloader, der nach dem klar war welche Mods wirklich geladen wurden, dann alle Gleise und Co in eine Liste einträgt. Vor allen anderen Mods, damit war die Reihenfolge von Gleismods egal zu Bahnhöfen.


    Das war das berüchtigte Konsolen Fenster. Das wurde mit dem nativen Teil etwas anders gelöst (viel schneller, mit meinem nativen Filesystem Code)


    Unter TPF2 ist das dann so:
    CommonAPI sieht alle Mods -> Preloaded alle Dateien -> TPF2 startet eine neue VM -> CommonAPI lädt erneut, hat aber keinen Zugriff auf die Modliste -> keine Gleise mehr.
    Technisch müsste eigentlich der Filefilter einspringen für Gleise, für Tunnel geht es, das scheint aber leider bei Gleisen nicht zu funktionieren.

  • 3D-Objekte einfach in Auftrag geben. Wenn ich nix scripte n muss, geht es auch schneller. ;)


    Ich weiß nicht, ob UG da noch was liefert, aber ne Möglichkeit die Linientexte per Skript selbst zu manipulieren wäre nicht schlecht. Oder vllt könnte man die Stationsanzeigen zumindest etwas intelligenter machen ...

  • Proof of Concept für die Gleise funktioniert schon mal.


    Also bei einem Gleis Modul würde es so aussehen: (wer mag kann ja dann auch andere APIs unterstützen und ein Failback oder ähnliches einbauen)

    Code: eis_os_750mm.lua
    updateFn = function(result, transform, tag, slotId, addModuleFn, params)
    		if (result.common_trackinterface ~= nil and result.common_trackinterface.makeTrackByTrackType ~= nil) then
    			result.common_trackinterface.makeTrackByTrackType(result, transform, tag, slotId, addModuleFn, params, "eis_os_750mm.lua", true)
    		else
    			-- Normal without CommonAPI2  (failback to normal track type)
    			trainstationutil.makeTrack(result, transform, tag, slotId, addModuleFn, params, 1)
    		end
    	end,

    In der Modularen Station brauch ich zurzeit nur das Interface binden, also dem result.commonapi2_interface den richtigen Kram hinzufügen. Und die cumsum Tabelle etwas manipulieren.



    Für Bahnhofs-Module mit Parametern, nunja, ich hab da eine Idee zu. Aber bis jetzt hab ich noch ne ganze Menge an crashes nur um ein einfaches Fenster an einen vorhandenen Button zu binden.


    Auch hierbei, ich würde hier einen Standard bevorzugen, den auch alle Mod Autoren unterstützen, damit nicht X Fenster aufploppen. Die UI von UG ist aber sehr limitiert. Also wenn überhaupt könnte man nur ein paar Buttons darstellen.


    Man müsste dann auch eine gute Möglichkeit finden, wann man Parameter vom Nutzer einliest und speichert, sonst würden ja die Parameter auf alle Module wirken.



    PS: Scheinbar brauchen Gleise nun zwingend trackStraightModel? Zumindest eine leere Liste führt zu einem Crash.



    -edit-
    20191208: Beispiel angepasst an neues Interface

  • For every game_script there are two lua environement, graphics and game engine, the state data in game engine can be copied to graphics, from graphics event can be sent to game engine


    All datas can be saved and reload in gamesave automatically.


    We can have interface with text, image and button with text/image, a simple layout system.


    I don't know if data can be shared between game_scripts (except event system), if it's possible, common api as a public on call game_script is enough.


    What I suppose to do:


    With an event request, pop up a icon list of tracks, on clicking on the icon, broadcast an event with track.lua name, that's simple and elegant


    However I think UG should merge track upgrade function into station, that's much more simple.

    This guy is too lazy to create a signature. 8o

  • I am sorry, could you please a bit more specific?


    Currently I bind a ug ui lua window with a button as debug aid (runs a script ) onto the "?" Help Button.


    There seems to be no proper way to create a new button into the menu bar.
    Doing a bit code research this time I couldn't find yet the code to create other ui elements. (internally the lua system works quite a bit different when adding new stuff)
    At least tooltips and vertical lines are creatable it seems.


    I started to port CommonAPI to TPF2, the preloading code doesn't work anymore at all.
    (The mod list is in a different LUA context, so preloading works, but the information is completely lost)


    The split brain problem:
    I asked several times UG: How these parts should work together and a proper way to sync data between contexts -> Until now nothing. (I call this the split brain problem)



    Track Type selection:


    You mean for building a construction the first time having three buttons:


    Normal, HighSpeed, Custom

    • If the player chooses custom, -> a window with all tracks (ok filtered with some kind) should be shown.
    • Player selects track. -> game.interface.sendScriptEvent (sends tracktype.lua and tracktypename.module)
    • Some game event mugging tries to change a commonapi variable to hold the new current track type that is reachable in construction script.
      I have currently no idea how the lua thread running construction scripts can receive game events.
    • Somehow tell the game rerun the construction script. (aka update the damn thing)

    In the construction script, how do you think the current state could be saved (by construction) and by module?


    For modular station modules parameter my idea was:


    • All modules add a special commonapi callback for UI code to show a parameter selection
    • CommonAPI will listen to UI events clicking the module name.
    • CommonAPI calls the parameter callback function on the module to get a list of options.
    • The option list is transformed to a window.
    • User selects options
    • Somehow the user selection data is transferred back to the lua thread running construction scripts
    • The updated settings are reachable via a commonapi function in the module script.

    Again some stuff is a a bit unclear for me:

    • To get the data back to the construction lua runtime. (same problem as track types)
    • And how to store possible settings for this module when build so later will still use the these parameters. (and not live data from the new ui)


    Sidenote:
    TPF2 has a new memory protection / crash handler, so even in my windows debugger the game quits and frees all memory. This makes the code analyze and porting a bit harder

  • From my understanding, in tpf2 the graphics and logical engine are run in async way that's why they are split.


    in general in a game_script you have guiEventHandler and eventHandler, the communication from guiEventHandler to eventHander via game.interface.sendScriptEvent, then load/save get datas from game engine back to graphcis engine.


    In general the two saves different states.


    I have uploaded my Underpass mod yesterday and there is what I discovered in the mod about this.


    I can create a floating window, put a button or text in it, run a script when clicking, open it and close it program also highlight it.


    You can't get data into the constructions, everything is top level down, the only injection that I find is calling the construction from eventHandler, but I have yet tried to access a game_script global from the construction, I don't know if it works


    But at least there's a way:


    in common api game_script : guiEventHander -> proposalPreview -> open track selection window -> (waiting for) -> proposalApply -> (if the mod is declared to support api) -> sendScriptEvent -> (in mod script) upgradeConstrdution with injection trackType -> (close track selection window) --> in general what you said above but so far there's a bug there is no event when modification is on the way/done, nothing reacts to the module.


    The states in params.module is saved, params will be clear each time.


    Modular station is not mandatory, old construction script is working too

    This guy is too lazy to create a signature. 8o

    Edited 8 times, last by Enzojz ().

  • As far as I can see I can build two underpasses. But it uses game.inferface to rebuild the construction to join them. (as we did in TPF1). As said, I did create a window via gui.lua too. I use it to run lua scripts it this context. (loadfile + pcall)


    I guess I have to wait for the GOG Version as attaching a debugger to the steam version is not possible any more because of DRM stuff ;(

  • Wie man in unserer Webdisk sehen kann, habe ich nun mal eine Testversion hochgeladen.


    Für Modul für Gleise kann man nun dies hier nutzen:

    Code
    if (result.common_trackinterface ~= nil and result.common_trackinterface.makeTrackByTrackType ~= nil) then
        result.common_trackinterface.makeTrackByTrackType(result, transform, tag, slotId, addModuleFn, params, "eis_os_750mm.lua", true)
    else
    ...
    end


    Der Bahnhof muss dann result.common_trackinterface.makeTrackByTrackType bereitstellen, wie Ihr das umsetzt ist euch überlassen.
    Die CommonAPI2 hat nun einen "stationhelper" Damit wird das ziemlich einfach. Siehe dazu auch den Bahnhofsadapter. Die zwei stellen für den Support hab ich mit CommonAPI2 gekennzeichnet.


    Es wird bald auch noch die Möglichkeit geben, Gleise mit Oberleitung zu updaten..

  • Ist das "normal"?

    Quote

    commonapi2.init: Can't load native code CommonAPI2Native: module 'CommonAPI2Native' not found:
    no field package.preload['CommonAPI2Native']
    no file 'mods/eis_os_commonapi2_1/bin/CommonAPI2Native.so'

    Edit:

    Quote

    ~/.local/share/Steam/steamapps/common/Transport Fever 2/mods> ls -la eis_os_commonapi2_1/bin/
    total 2728
    drwxr-x--- 1 pane users 40 Dec 11 12:41 .
    drwxr-x--- 1 pane users 160 Dec 11 12:41 ..
    -rw-r----- 1 pane users 2791936 Dec 8 17:08 CommonAPI2Native.dll

    Dell Precision T7600, 2 x Intel(R) Xeon(R) CPU E5-2665 (8 cores per CPU, 2 threads per core, 20MB L3 cache, 2.4/3.1GHz) (⁼32 logische CPUs), 512 GiB DDR3 ECC registered 1600 MT/s, NVIDIA Corporation GP102 [GeForce GTX 1080 Ti] (11GB GDDR5X 352 bit), SAS Hardware RAID Level 1

    Linux version 5.14.21-150400.24.60-default (geeko@buildhost) (gcc (SUSE Linux) 7.5.0, GNU ld (GNU Binutils; SUSE Linux Enterprise 15) 2.39.0.20220810-150100.7.40) #1 SMP PREEMPT_DYNAMIC Wed Apr 12 12:13:32 UTC 2023 (93dbe2e)

    Edited once, last by tsilaicosneknurd ().

  • Ja das ist leider noch normal, CommonAPI2Native.so ist noch nicht fertig. Ich muss alle Code Fragmente neu suchen und Steam hat zu viele Anti Debugger Kram.
    D.h. erst heute mit der GOG Version komme ich hoffentlich besser voran. Auf den Stationscode hat das keinen Einfluss.

  • Ok, gut zu wissen...
    wäre es möglich, die CommonAPI2Native.so kompatibel zu älteren glibc zu linken?
    openSuSE ist da wohl etwas weiter zurück als, wie heisst der debian fork nochmal?..

    Quote

    Can't load native code CommonAPILua: error loading module 'CommonAPILua' from file 'mods/eis_os_commonapi_1/bin/CommonAPILua.so':
    /lib64/libm.so.6: version `GLIBC_2.27' not found

    (in TPF1)

    wobei openSUSE tumbleweed schon glibc 2.27 beïnhaltet.

    Dell Precision T7600, 2 x Intel(R) Xeon(R) CPU E5-2665 (8 cores per CPU, 2 threads per core, 20MB L3 cache, 2.4/3.1GHz) (⁼32 logische CPUs), 512 GiB DDR3 ECC registered 1600 MT/s, NVIDIA Corporation GP102 [GeForce GTX 1080 Ti] (11GB GDDR5X 352 bit), SAS Hardware RAID Level 1

    Linux version 5.14.21-150400.24.60-default (geeko@buildhost) (gcc (SUSE Linux) 7.5.0, GNU ld (GNU Binutils; SUSE Linux Enterprise 15) 2.39.0.20220810-150100.7.40) #1 SMP PREEMPT_DYNAMIC Wed Apr 12 12:13:32 UTC 2023 (93dbe2e)

  • Du ich habe gleich nach dem Aufrufen von Transport Fever 2 einen CTD bevor überhaupt die Titelseite vom Spiel kommt.
    Die "stdout.txt" habe ich angefügt.

    Files

    • stdout.txt

      (1.46 kB, downloaded 359 times, last: )
  • Ich hab gestern Abend noch ne neue Version hochgeladen, Linux Version ist noch nicht fertig ;(


    Es gibt auch eine neue Version des Bahnhofsadapter und auch der Gleise. Damit wird Oberleitungsbau via Gleismodifikationstool ermöglicht.


    Für unsere Gleisbauer:
    CommonAPI2 Bahnhofmodule mit eigenen Gleisen via Bahnhofsadapter

  • Du ich habe gleich nach dem Aufrufen von Transport Fever 2 einen CTD bevor überhaupt die Titelseite vom Spiel kommt.
    Die "stdout.txt" habe ich angefügt.

    I'm getting essentially the same error. The only difference I see is the lua_State pointer:
    seed: 1576089385



    double buffering: 1
    sample buffers: 0
    samples: 0 (0)
    swap interval: 1
    video memory: 4096 MB



    ============================================================



    OpenGL version: 3.2.0 NVIDIA 441.41
    Renderer (vendor): GeForce GTX 980/PCIe/SSE2 (NVIDIA Corporation)
    Shading language version: 1.50 NVIDIA via Cg compiler



    ============================================================



    opened device OpenAL Soft
    sampling rate: 48000 Hz



    commonapi2.init 20191208
    CommonAPILua stdout.txt logging enabled
    CommonAPILua: InitDone
    TPFLUA_NewLuaState: lua_State* 00000000084AC830
    commonapi2.init: loadTranslationSystem en
    GUIBridge_setRenderFn 00000000084AC830



    LUA_SetEventCallback 00000000084AC830



    error: error: res/scripts/mod.lua:148: attempt to call global 'getTextRes' (a boolean value)
    stack traceback:
    [C](-1): getTextRes
    res/scripts/mod.lua(148): ?
    ...commonapi2_1/res/scripts/commonapi2\ui\ModListWindow.lua(17): ?
    [C](-1): require
    ...s_commonapi2_1/res/scripts/commonapi2\ui\modsettings.lua(9): ?
    [C](-1): require
    mods/eis_os_commonapi2_1/res/scripts/commonapi2\init.lua(209): _init
    mods/eis_os_commonapi2_1/strings.lua(126): ?



    TPFLUA_GC: old lua_State* 00000000084AC830

  • Indeed it did. Here it is with the 20191213


    PreventSetUnhandledExceptionFilter: 1
    locale name: * (en_US.utf8)





    ========================================
    Startup at Sat Dec 14 14:47:11 2019
    ========================================





    seed: 1576352831



    double buffering: 1
    sample buffers: 0
    samples: 0 (0)
    swap interval: 1
    video memory: 8192 MB



    ============================================================



    OpenGL version: 3.2.0 NVIDIA 432.00
    Renderer (vendor): GeForce RTX 2070/PCIe/SSE2 (NVIDIA Corporation)
    Shading language version: 1.50 NVIDIA via Cg compiler



    ============================================================



    opened device OpenAL Soft
    sampling rate: 48000 Hz



    game not found
    commonapi2.init 20191213
    CommonAPILua stdout.txt logging enabled
    CommonAPILua: InitDone
    TPFLUA_NewLuaState: lua_State* 000001F40A1FB320 (2147653497632)
    commonapi2.init: loadTranslationSystem en
    GUIBridge_setRenderFn 000001F40A1FB320



    LUA_SetEventCallback 000001F40A1FB320



    error: error: res/scripts/mod.lua:148: attempt to call global 'getTextRes' (a boolean value)
    stack traceback:
    [C](-1): getTextRes
    res/scripts/mod.lua(148): ?
    ...commonapi2_1/res/scripts/commonapi2\ui\ModListWindow.lua(17): ?
    [C](-1): require
    ...s_commonapi2_1/res/scripts/commonapi2\ui\modsettings.lua(9): ?
    [C](-1): require
    mods/eis_os_commonapi2_1/res/scripts/commonapi2\init.lua(243): _init
    mods/eis_os_commonapi2_1/strings.lua(126): ?



    TPFLUA_GC: old lua_State* 000001F40A1FB320

  • Hallo,


    eine neue Testversion, trotz intensiver Suche nach einer Möglichkeit gibt es leider immer noch keinen Fortschritt, zumindest sollte das getTextRes Problem nun nicht mehr auftauchen.



    Hello
    There is a new testversion, I did invest a lot of time but there is still no progress. Atleast the getTextRes Bug should be fixed.
    To all users, if you post stdout.txt, please use the board attachment function, adding stdout.txt. Please don't post it in the normal text, or only the relevant part. Thank you.



    1.1.20191215-dev
    - native: add syncing data between lua states code via lua-marshal
    - replace translate2 with own version checking if getTextRes exists
    - add syncing between repositories (currently not working)
    - disable hooking (crashes game)
    - don't try to load CommonAPI2Native.so (unfinished)


    CommonAPI2

  • https://www.transportfever.net/index.php/User/36029-Drei69/
    This is causing the game to crash when I start the game up:


    error: error: res/scripts/mod.lua:148: attempt to call global 'getTextRes' (a boolean value)
    stack traceback:
    [C](-1): getTextRes
    res/scripts/mod.lua(148): ?
    ...commonapi2_1/res/scripts/commonapi2\ui\ModListWindow.lua(17): ?
    [C](-1): require
    ...s_commonapi2_1/res/scripts/commonapi2\ui\modsettings.lua(9): ?
    [C](-1): require
    mods/eis_os_commonapi2_1/res/scripts/commonapi2\init.lua(209): _init
    mods/eis_os_commonapi2_1/strings.lua(126): ?

BlueBrixx