Common API

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


    Wenn ich das Spiel mit der neusten dev Version starte, öffnet sich das Fenster und schliesst sich ohne Fehlermeldung direkt wieder.


    Spiele mit Win 10


    Dateien

    • stdout.txt

      (1,33 kB, 192 Mal heruntergeladen, zuletzt: )

    Hmm, da scheint ein Fragment falsch zu sein, komisch das es bei mir läuft.
    Werde mal vom Beta Branch auf Release umschalten und schauen ob es da einen Unterschied gibt.



    @Enzojz:
    There is no technical way to link to TPF Lua,
    CommonAPI uses a modified LUA Runtime (statical linked to the DLL/so) that can manipulate TPF Lua state.


    @Freahk
    Die nächste Version werde ich hoffentlich mit einer alten glib Version compilieren können.

    Zitat von eis_os

    CommonAPI uses a modified LUA Runtime (statical linked to the DLL/so) that can manipulate TPF Lua state.

    I suppose for Windows dlls it's a Lua runtime that matches address of each function entry and Lua state of tfp.exe, and these address are statically manually analyzed, so for different versions you need to have do things differently? for Linux it should be easier since the OS exposes these?

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

    You need the dummy node location (table), the nil location to match.
    The LUA VM normally uses a fixed position, my version uses a dynamic location.


    Then you need to play with compile flags that the memory layout matches.
    So I am stuck with MSVC 2010 compiler, certain flags and the same LUA VM version. (Same SDL Version, no memory protected c++ containers)


    If you now run in in the right thread, (thread local memory) you can alloc memory and pass the LUA State of TPF to CommonAPI LUA and both will do the same on the same memory. (Tested with lua iterators, strings, basic datatypes, tables only without gc yet)


    The Linux Version is technical the same. However the compiled code is different.
    The so library has some other code fragments to search. So the code now has a lot #ifdef OS_LINUX.
    To be memory identical the gcc c++ compiler needs to compile std containers with the same memory layout.


    Technical something capstone would be nice for fragment searching and a patched nasm64 so I could write fragments in assembler code.
    However my own code seems to be still good enough and uses simple byte code sequences.


    Code flow:
    Find TPF memory layout
    Find basic stdout function
    Find LUA Locations
    Setup LUA
    Find and hook Render Loop and SDL Event loop
    Find and hook TPF Street, Track Repository init/deint.



    Freahk:
    Eine ältere Meson Version mag mein buildscript nicht, das muss ich irgendwie umgehen, dauert daher leider noch etwas. Hätte wohl besser ein klassiches makefile geschrieben, als so neumodiges Python zu nutzen :D

    Zitat von snowball

    I don't know specifically how the figures are with LUA and C++, but usually, calling a native function in a scripting environment has an overhead which will not justify the calculation time of any sort of math.

    that depends the architecture of your binary lib and how you designed the memory layout for the communication, I have written a C interop lib with Tcl/tk for a calculate intensive project, the gain of performance was very significant.

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

    Neue Testbuild 20181101.


    So, hab das Fragment angepasst. Einen Startcrash sollte es nun nicht mehr geben.
    Getestet hab ich es in Windows Steam, Windows GOG alte Version, Linux GOG. (mit Ubuntu 16.04 chroot gebaut, für alte GLIBC)


    Leider habe ich trotz intensiver Suche nicht den Code gefunden, der für den Gleisradius eines offenen Endes zuständig ist, auch immer noch nicht den Brückenpfeiler Code.
    Da ich da jetzt keine Lust mehr habe, werde ich mich wieder an die Analyse den Konstruktionscode setzen.


    Vielleicht gibt's ja für die letzte TPF Version Debugdaten, dann wäre es einfacher...

    Das würde ich mir auch wünschen.
    Würde die moddingmöglichkeiten auch nach einem letzten TPF Update deutlich verbessern.
    @tomdotio
    Zum Schluss wäre sowas nochmal ein schönes Weihnachtsgeschenk an die Modder, die das Spiel grenzenlos bereichern.

    Hallo @eis_os,
    hast du evtl. noch eine Version, welche die "exe" nicht verändert, aber dennoch Unterverzeichnisse beim Befüllen der repos berücksichtigt?


    Edit:
    @tomdotio, von UG-Seite her würde es mir schon völlig reichen, wenn die Params über eine Art runGetParams gelöst würde, welche unmittelbar vor der updateFn aufgerufen würde. Tja...

    Auch ein alter Fuchs schaut gern ein Huhn, selbst wenn er's nicht mehr Reißen kann. ^^

    163393-cpuz-ryzen9-5900-png

    Zitat von eis_os

    Möchte aber schon gern wissen warum Du den alten Code nutzen möchtest?

    Die Gründe sind recht simpel:

    • Ich möchte vor allem die Params befüllen und das möglichst dynamisch. Teste das gerade mit Straßen und wenn ich es für handhabbar halte nutze ich es in einem meiner Mods.
    • Eine UI-Erweiterung sehe ich für mich (noch) nicht als notwendig an.
    • So ich mich nicht irre, hat ein Hacken der exe immer den Nachteil, daß bei einer Änderung der exe der Hack evtl. nicht mehr funktioniert. Hier bin ich (noch) nicht bereit mitzugehen.

    LG Enno :)


    PS: Das Obige bedeutet nicht, daß ich dich oder deine Arbeit geringschätze (eher das Gegenteil ist der Fall). Bitte nicht Miss(t)verstehen. ;)

    Auch ein alter Fuchs schaut gern ein Huhn, selbst wenn er's nicht mehr Reißen kann. ^^

    163393-cpuz-ryzen9-5900-png

BlueBrixx