CommonAPI2 Entwicklungsdiskussion, Fragen & Antworten

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.

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)

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

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

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:

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

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.

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

Your log clearly shows commonapi2.init 20191208
As I said I have uploaded 20191213 yesterday...

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