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


    Sobald ich Zeit habe Mr Nederlandse Spoorwegen werde ich es mit Oppies Station testen.

    As soon as I have time I will test Oppies Station.


    KlausiMaus Das geht leider zurzeit unter Windows noch nicht. Man kann leider unter Windows keine DLL überschreiben, die man gerade offen hat.
    Technisch experimentiere ich da gerade mit Workarounds. Zurzeit unter Windows ist leider manuelle Installation angesagt.

    Hallo liebe Community,


    Build 29131 ist draußen,

    nun gibt es eine Unterstützung von Modgleisen durch UG. Lange hat es gebraucht, dieses habe ich schon vor Release von TPF2 angesprochen.


    Wichtig: Um etwaige Probleme zu umgehen, bitte ich alle Modder die Gleismodule für den CommonAPI2 Bahnhofsadapter in Ihren Mods zu entfernen, bzw. Auszulagern damit alte Savegames noch funktionieren. Eine andere Möglichkeit ist es, die Datums angeben so zu ändern, das das Modul nicht mehr sichtbar ist:


    availability = {

    yearFrom = 0,

    yearTo = 0,

    },


    Dies kann ggf. Probleme mit Mods verursachen, die alles Verfügbar mache...


    Auch hier hätte ich mir eine bessere Zusammenarbeit gewünscht um dieses im Vorfeld zu Planen und auch einen Upgrade Pfad anzubieten. Dieses habe ich auch so an UG kommuniziert.


    Ich bitte euch, bei meiner Wortwahl etwas nachsichtig zu sein, auch werde ich im weiteren Verlauf sehr viele Probleme ansprechen.


    Bedenkt, ich kritisiere und fordere von Urban Games nur so viel, weil ich die Arbeit und die Spiele sehr schätze!


    Ich möchte hierbei aber ganz klar aufzeigen warum es zur CommonAPI kam und warum etwaige Kommentare daneben sind, weil viele Nutzer gar keine Ahnung haben, wie alles zusammen funktioniert: „UG löst das Problem in der CommonAPI2“


    Alle Anstrengen der CommonAPI1 und 2 waren immer auf höchstmögliche Kompatibilität und Modding Freundlichkeit ausgelegt. Inwiefern Urban Games, das in Zukunft leisten kann, müssen etwaige weitere Updates zeigen.


    Ich drücke hier der Community und Urban Games die Daumen, das alles so klappt wie es soll.



    Zur Geschichte der CommonAPI:


    Die CommonAPI ist entstanden weil Urban Games auf die bitte verschiedene Gleismöglichkeiten in TPF1 sinnvoll zu unterstützen nicht reagiert hatte.


    Also sucht ich für meinen Bahnhof eine Lösung. Da dieses auch für andere Modder interessant war, habe ich den Code ausgegliedert und stetig weiter entwickelt. Da der Code recht unschöne Probleme mit einem Shell Fenster hatte und keine weiteren Entwicklungen absehbar waren, habe ich mich mit einer DLL und SO Library beholfen.


    Moderner Bahnhof mit mehr Bauoptionen (Modern train station)


    Das TPF Id zu Objekt zuordnungen abspeichert, damit es kein Chaos in Savegames gibt, habe ich schon zu Train Fever Zeiten gefordert, wohl wegen zu vielen Bugreports gab es dann irgendwann ein einsehen.


    Wegen uneindeutigen Fehlern mit Mods kamen Features wie Crash Debug hinzu.


    Warum? Ich habe versucht vielen Nutzern im Forum zu helfen. Wenn TPF1 eine Datei, sagen wir mal eine Textur geladen hat und diese das falsche Format hatte gab es ein CTD.

    Warum es zum CTD kam, wusste dann eigentlich keiner …


    Auch wurde der Wunsch laut Zugziel Anzeigen zu erhalten.

    Das hat zu TPF1 / CommonAP1 noch nicht ganz geklappt, dafür sind aber variable randomisierte Animationen entstanden.


    Zugzielanzeigen auf Lok, Tram oder Bus via Logo Textur + CommonAPI


    Technisch gab es diese Richtung also schon in der CommonAPI.

    Urban Games war wohl für TPF2 daran auch schon am Werkeln.

    Vielleicht haben Sie da dann etwas mehr Zeit invertiert?


    Für TPF2 mit eine CommonAPI2 Beta habe ich gezeigt, das auch eine Anzeige wirklicher Endhaltestellen technisch möglich sind: LINE_DESTINATION


    Zielanzeigen, Endhaltestellen (Beta Version)


    Und es haben auch Modder getestet, es funktioniert. Der Code steckt technisch in jeder CommonAP2 neueren Datums und ist nur zurzeit nicht mehr verdrahtet.


    Auch wurde der Wunsch nach Einstellbarkeit von Mods angegangen. Hierbei um auch wieder größtmögliche Kompatibilität zu erreichen, habe ich anstatt eine Savegame basierte Lösung das settings.lua System unterstützt. Somit kann man mit Xanos TPFMM, Merks Modutils und der CommonAPI das gleiche System nutzen.


    Dafür brauchte ich die geladenen Mods des Spiels im Savegame Dialog, also Speicher finden wo es drin steht…


    Schauen warum etwas nicht funktioniert oder Debuggen? → Eine Konsole


    Schön ist das Urban Games einen Teil davon nun in das Spiel einbringt, von meiner Seite aus gesehen sind bestimmte Funktionalitäten sehr unglücklich.


    Beispiele:


    Die UG API ist während des Laden von Modifer technisch nicht ansprechbar. Daher gibt es keine sinnvolle Möglichkeit die CommonAPI Interfaces zu portieren ohne die Kompatibilität zu zerstören.


    Eine Konsole, die eine eigene LUA Umgebung hat, zeigt nicht wirklich den momentanen Zustand der LUA Umgebung für Konstruktion oder andere Threads an.



    Zukunft und Ausblick:


    Neuere Funktionen werden immer unwahrscheinlicher.

    Ich brauche keinen störrischen Schraubstock auf beiden Seiten.


    Für Bahnhöfe sind zum Beispiel Höhenunterschiede für Plattformen auch ein Problem:

    Ja, jeder kann Anfangen irgendwelche inkompatiblen Bahnhöfe anzubieten, die irgendwo Probleme lösen, neue bereiten oder zig lua Hooks machen, die sich gegenseitig auf die Füße treten.


    Lösungen gibt es, sind teilweise sogar in der CommonAP2 eingebaut und kann jeder sogar sehen,

    das common.waitarea in stationhelper.lua ausgewertet wird.


    Ich habe immer versucht das große Ganze zu sehen und die Kompatibilität zwischen Mods zu erhöhen. Dieses werde ich nicht mehr leisten können, wenn ich von allen Seiten unter Beschuss gerate.


    Daher werde ich CommonAPI2 nur noch als Wartungsrelease herausgeben und diese in Zukunft aus dem Workshop komplett entfernen, da eben eine kompatible Entwicklung unter den gegebenen Umständen nicht möglich ist.

    Dass UG beim modularen Feature Müll produziert hat war von Anfang an klar.

    Dass sie das später beheben eigentlich auch.


    Tendenziell finde ich es auch gut, weil eben auch nur ein paar die Common Api genutzt haben und anderen Modder trotzdem Extrawurscht gemacht haben.


    Die Kommunikation von UG ist indiskutabel, da brauchen wir nicht drüber reden.

    Letztlich passiert das gleiche auch bei anderen Games wie CS oder bei der iOs Entwicklung.

    Aus der Moddercommunity werden Funktionen vanilla integriert.


    Wenn UG das nur so verkaufen würde, dass es eine Zusammenarbeit ist, wär das ok.

    Aber aktuell ist es eher „du ärgerst dich damit, baust es ein und wir zerstören es dir um es selbst einzubauen - danke für die Inspiration“


    Das ist einfach eine Frechheit.


    Deren Kommunikation ist demotivierend und schädigend für die ganze Community.


    Ich kann es klar verstehen, wenn Modder keine Lust mehr haben.

    Dir geht es so, mir geht es so, anderen geht es auch so.


    Ich würde gern modden, aber UG vermiest einem.



    Das Spiel ist dermaßen unfertig und ... unberechenbar... naja...


    Keiner weiß, wohin die Entwicklung gehen soll, wird es noch neuen Gameplay geben oder nicht, wie tiefgreifend oder nicht, etc.


    Wenn man wüsste „UG wird keine zufälligen Türanimationen machen“ dann würde es sich rentieren sowas zu modden. Gleiches bei Seilbahn.


    Wenn das alles beim nächsten Patch aber drin ist, dann kann man es sich gleich sparen.


    UG ist die Politik, wir die Industrie.

    Gebt uns einen 10 Jahresplan zur CO2 Reduktion mit verbindlichen Zahlen statt jeden Monat neue und andere Regeln.

    So wird das nämlich nix und führt nur zu mehr Frustration.

    3, 2, 1, meins... Lg Edith

    Es geht mir um die technische Sicht, alle Spielstände ohne Problem zu erhalten. Keine Crashes verursachen und auch Mods zu unterstützen, deren Ersteller ggf. gerade kein Update machen kann.

    Ein Mod mit CommonAPI1 Unterstützung läuft aus technischer Sicht auch mit CommonAPI2. (Mit reduzierten Umfang, aber Ok).


    Wenn die technischen Probleme gelöst würden, so das auch Platzformhöhen veränderbar wären, toll.

    So ist das leider immer noch nicht gut. Aber das kann sich ja ändern und vielleicht wird ja meine Kritik auch aufgenommen und zumindest in TPF3 kriegen wir etwas besseres.


    Ich habe die Gleisproblematik sehr sehr sehr früh besprochen. Meine Probleme das mit Konstruktionsparameter später nicht mehr ändern kann auch. Dynamische Parameter? Fehlanzeige. Parameter für Module? Nix.


    Inwiefern die neuen Gleismöglichkeiten zur Steigung und Kurven in Planung waren, kann ich nicht sagen.


    Ich habe aber Tomdotio gebeten, das Sie die Optionen bitte einbauen um Schmalspurbahnen, Zahnrad Bahnen und co zu ermöglichen.

    So das ich das es nicht wieder per Patch durch die CommonAPI2 einbauen muss. (wie in TPF1) Ein Bild hab ich auch geschickt, es stand aber schon auf der Wunschliste.


    Die postFn Funktion wird wohl auch eine Reaktion darauf sein, weil ich in meine letzte Mail nochmalig gefragt habe, wie die UG API zu nutzen wäre. Weil in den Modifern die UG API ja noch nicht zu Verfügung steht und damit deswegen eher nutzlos ist. Wenn das schon geplant war, haben Sie es mir nicht verraten wollen, was dann eher schlimmer wäre und ich ersteres mal Unterstelle


    Verstehe es nicht falsch, ich bin froh wenn die Funktionen alle ins Spiel aufgenommen werden, mit der Umsetzung was dann raus kommt bin ich aber nicht begeistert.
    Besonders nicht, wenn alles dann total Inkompatibel wird und ich das dann via Test Version Update erfahre... (und ob das dann alles so umgesetzt wird, ist auch fraglich. Die APIs sind ja auch schon verändert worden)


    -edit-

    Die Auto Modul tgas sind auch ein Krampf, warum kann man in der track lua Datei nicht einfach zwei neue Keys einfügen für moduleIcon moduleIconCatenary ?

    Kompatibilität scheint bei UG nicht an erster Stelle zu stehen.

    Gibt leider immer noch viele Konflikte unter Mods, die nicht sein müssen, weil es zu wenig Interfaces und schlechte Informationsgrundlage für Modder gibt. Ohne CommonApi wäre das wohl noch schlimmer.


    Sowas wie die Gleismodule oder Mod Parameter muss man doch vor dem Release einbauen und nicht als Patch nachliefern.

    Und es kann doch nicht so schwer sein, Gleise/Straßen mit entsprechenden Parametern zu versehen, sodass man nicht für jede Geschwindigkeit ein eigenes Gleis bzw Modul braucht?


    Die Ingame Konsole im jetzigen Zustand wird die der CommonAPI2 nicht ersetzen können.

    Hallo


    Ich habe nun eine technische Lösung erarbeitet, die das Problem mit doppelten Gleisen umgehen sollte und Spielstand kompatibel bleiben sollten.

    Gleispaket mit 750mm 1000mm für TPF2


    Für die testing Version bedeutet es:

    - Keine doppelten Gleise für 750mm und 1000mm im Bahnhofsbau

    - Alte Spielstände sollten weiter funktionieren

    - Ohne Adapter funktionsfähig (Wenn der Adapter aus einem Spielstand entfernt wird, gibt es Failback Gleise)


    Es wird wohl weiterhin einen Adapter geben, der ggf. die nicht mehr funktionieren Funktionen (Oberleitung Ändern/ up & downgrade) wieder nachrüstet.

    Dafür wird es wohl Anpassungen an den Gleisdateien geben (für up/downgrade), die Entwicklung braucht etwas Zeit. Hätte ich da vorher Einblick gehabt, hätte ich das schon früher umsetzen können.


    Keine Ahnung ob UG das selber noch nachrüstet. luftfisch_ug
    Die Problematik, das die Iconen für Module nicht irgendwie direkt im Gleis zu definieren sind, ist unschön. Jetzt gibt es eben doppelt so viele tga Dateien...


    Den Adapter wird es wohl auch weiterhin geben und dann auch die beschriebenen unterschiedliche Plattformhöhen bereitzustellen.

    Hallo wenn ich ein mod updaten möchte kommt immer "Zugriff verweigert" (siehe Bild). Was muss ich da machen?


    Edit: Gerade gelesen, dass unter Windows (noch?) nicht funktioniert, siehe Post von eis_os

    Zitat von eis_os

    Das geht leider zurzeit unter Windows noch nicht. Man kann leider unter Windows keine DLL überschreiben, die man gerade offen hat.
    Technisch experimentiere ich da gerade mit Workarounds. Zurzeit unter Windows ist leider manuelle Installation angesagt.

    Das Problem mit Zugriff verweigert scheint ein Problem zu sein wenn das besagte Mod im Spielverzeichnis\mods liegt und die Nutzerdaten auf einer anderen Partition. Ich konnte es bei mir nicht Nachstellen.


    Hura, es gibt ein neues Build von UG, und alles ist wieder im Eimer ;( Daher gibt es eine Devversion aus dem Minion Labor, ein neues Fenster ist dazugekommen, damit kann man Mods aus dem Forum einfach herunterladen und installieren (wenn alles funktioniert wie es soll)



    Build 29331 funktioniert mit:

    CommonAPI2 - Build 20200618

    Als ich das Spiel beenden wollte:

    und so weiter... 50000 Zeilen

    50000? Ich glaub ich muss die Warnung komplett unterdrücke, hat es denn beendet oder ist komplett hängen geblieben?

    Der imgui Tabellen Branch ist etwas eigen und imgui.NextColumn() funktioniert nicht immer, der Code verhindert dann eine endlos Schleife wird leider aber ziemlich oft ausgeführt.


    Danke für den Report. Heute Abend gibt es dann ne neue Version.


    Um das kurzerhand zu unterdrücken:


    in res/scripts/commonapi2/_nativeui.lua


    Diese Zeilen entfernen:

    print("imgui.NextColumn() logic error!")

    print(debug.traceback())


    Gibt es zweimal, dann ist erst mal Ruhe...

    Zitat von eis_os

    Das Problem mit Zugriff verweigert scheint ein Problem zu sein wenn das besagte Mod im Spielverzeichnis\mods liegt und die Nutzerdaten auf einer anderen Partition. Ich konnte es bei mir nicht Nachstellen.


    Ja das kann durchaus sein, in meinem Falle sind alle Mods im Spieleverzeichnis unter /mods weil auf der Systempartition C: nicht so viel Platz habe. D.h. wenn ich alle mods unter %appdata%\Transport Fever 2\mods verschiebe funktioniert es?, muss ich mal probieren...


    Meine Pfadconfig:

    Partition 1 (C:): Benutzerverzeichnis: %appdata%\Transport Fever 2

    Partition 2 (F:): Spieleverzeichnis + alle mods


    Verwende die GOG.Version Build 228271


    EDIT:

    Gerade Update eines Mods im Benutzerverzeichnis, er löscht zwar den Mod aber kommt dann nicht weiter, Screen vom neuen Fehler:

    Ich melde mich nochmal hier. Nach den Problemen die ich durch die API und dem letzten Patch hatte kann ich meine alten Spielstände immer noch nicht laden. Die API wird unter Spiele laden in der Modliste als rot gekennzeichnet. Das heisst ich kann den Spielstand nicht laden. Wenn ich jedoch unter Optionen in die Modliste gehe um sie zu deaktivieren taucht sie nicht auf. Sie ist einfach nicht da. Sie ist im WS deabonniert und ich habe auch alle Reste im Steamverzeichnis geputzt.

    [AUT]Superman

    Erstmal, CommonAPI2 löscht keine Mods, die (alt) Mods werden nach Benutzerdaten von TPF2/commonapi/modstorage verschoben!

    Du hast auch bei der Testing Version CommonAPI2 20200619 ? D.h. keine Versions Fehler beim Starten von TPF2?


    gucky

    Ich kann dir nicht sagen was UG an der Modliste geschraubt hat. Du sagst ja die CommonAPI2 ist nicht vorhanden, sie wird auch wohl nicht mehr rechts oben auf dem Bildschirm angezeigt. Du solltest daher deinen Spielstand mit Erweiterte Optionen und dann einfach auf Weiter wieder laden können.

    So ist es aber genau das geht halt nicht. Wie gesagt im Laden Menu wird sie als fehlt gemeldet und das Savegame ist nicht startbar. In den Optionen dann taucht sie nicht auf, selbstverständlich auch nicht am rechten oberen Rand. Wenn ich die neue Version lade hilft das leider auch nicht weiter da er trotzdem die alte aus dem WS haben will. Das Dilemma ist halt das ich die API nicht erst aus den geladenen Mods nehmen kann und danach erst deaktivieren da das Spiel crasht sobald ich die alte Version abonniert habe. Interessanterweise bleibt auch die neue API in der Modliste von anderen Savegames drin wenn sie einmal geladen war. Und das gleiche Spiel wie oben , das Savegame lässt sich nicht laden. Allerdings gibt es keinen Crash wenn die neue API geladen ist. Heisst unterm Strich ohne API lässt sich nicht spielen wenn die API jemals aktiv war.

    gucky Ja, aber wenn man ein nicht mehr vorhandene Mod mit UGs Benutzerinterface nicht mehr entfernen kann, dann ist das doch nicht mein Fehler oder der CommonAPI2, sondern weil UG da was kaputt gemacht hat.. (Wie gesagt, da ja das Mod nicht mehr da ist, kann es ja auch das Spiel nicht mehr beeinflussen) Ich habe es bei mir jetzt lokal mit einer Linux Version getestet:

    Ich kann eine lokale nicht mehr vorhandene CommonAPI2 Installation aus dem Savegame entfernen...

    Nicht falsch verstehen. Eigentlich ist es ja meine Schuld, es ist Beta und ich habe den Patch genutzt mit dem Risiko das es schiefgeht. Passiert, trotzdem wäre es natürlich schön wenn es Hilfe gäbe. :)

    Ich verstehe aber die Arbeitsweise des Mod nicht. Scheinbar wird er ja sofort aktiv sobald er verfügbar ist und nicht erst wenn man ihn explizit in der Modliste für ein Game aktiviert. Muss man das dann überhaupt noch wenn er doch eh schon aktiv ist oder anders was kommt dazu wenn er im Savegame aktiv/nicht aktiv geladen ist?