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


    Zitat von snowball

    1. Manche Mods sind eher Tools die irgendwas ausgeben, z.B. die Vermessungswerkzeuge von BR146. Aktuell wird aus den Missionszonen Text erstellt, das ginge eleganter.


    2. Manche Mods haben viele Parameter und es gibt auch bekannterweise ungültige Kombinationen. Da wäre ein Bereich zum ausgeben von Fehlern nett. Oder kann man irgendwie die roten Meldungen am Mauscursor erweitern?

    1. Da bin ich aktuell dran per Missionsskripte das Fenster zu erstellen. Aber erstmal muss der MiMa fertig werden.
    2. Also beim Schienenbau geht das (über Missionsskripte). Ob es das für Konstruktionsplatzierung gibt, glaube nicht.

    Hallo


    Wieder mal eine Dev Version.


    Nach langem Testen und ausprobieren habe ich die Funktion(en) gefunden, die entscheiden ob ein Snappoint an der "richtigen" Stelle als Ziel beim Schienenbauen ist.
    Daher ist es wieder möglich Schienen mit hoher Steigung und wahnsinnigen Kurven zu Bauen.


    Der UI Code ist noch nicht fertig, aber nun kann man auch Fenster mit festen Größen erstellen. Labels nutzen anstatt name nun caption!
    Das Speichern führt nicht mehr zum Verlust des LUA States.


    Viel Spaß

    Ich habe die 20181226 in Gebrauch.


    Etwas verwirrt mich:
    Damit ich überhaupt beim Gleis- oder Straßenbau "snappen" kann, muss ich erst zwei Häkchen setzen in der UI:


    StreetTrackToolbox

    • Disable Curve check
    • Disable slope check


    Was mich verwirrt, ist die für mich "umgekehrte Logik" - mir scheint es so, als müsste es andersrum sein; ohne Häkchen ist alles normal und mit Häkchen snappt es nicht mehr.

    Nunja, es macht genau das was es sagt. Es schaltet Code von TPF ab, der dazu führt das die Snappoints nicht genutzt bzw. aussortiert werden. Im Endeffekt hast Du dann mehr Snappoints die für den Gleisbau genutzt werden können.


    Technisch gibt es sogar noch einen dritten Status, ignoriere alle Snappoints.


    Ich Plane daher nächsten beide Funktionen unter den Checkboxen zusammenzufassen in einem DropDown:


    Normal
    Erlaube mehr Kurven und Steigungen
    Ignoriere Snappoints (d.h. Normal ohne Snappoint)


    Damit sollten das klarer sein.
    Wenn Du dafür andere Vorschläge hast, gerne mehr davon. Ich arbeite auch daran, die Fenster endlich übersetzen zu könne und Einstellugen der UI Skalierung auch gespeichert werden können.




    -edit-


    Das sieht dann nun so aus:



    Hallo


    Das letzte Update für 2018:


    • Neues UI Layout für StreetTrackToolbox
    • Fix: Ändern der Einstellungen für Grafik crasht CommonAPI
    • Console merkt sich nun die Befehle (einfach Hoch oder Runter drücken)
    • Übersetzung der UI

    Hallo und danke für das Testen.


    Die Konsole bietet den direkten Draht zu stdout.txt und zur TPF LUA Runtime.
    (Die LUA Runtime wird beim Laden eines Spiel erstellt und ist daher zum Beispiel im Hauptmenü noch nicht verfügbar und somit ist keine Eingabezeile vorhanden).


    Mit print oder commonapi.dmp(<Lua Befehl>) kann man sich das Ergebnis anzeigen.
    Des weiteren werden Exceptions von Befehlen abgefangen. D.h. schreibst du dort game.interface.getEntites() würde TPF bei so einen Fall meckern, es fehlen Parameter und das Spiel wird beendet.
    In meiner Konsole wird zwar auch die MsgBox angezeigt, nach Bestätigung der Fehlermeldung läuft das Spiel aber weiter.


    • stdout.txt Ausgabe (auch im Hauptmenü beim Laden eine Spiels)
    • LUA Befehszeile
    • Exceptions werden abgefangen, Spiel läuft weiter

    Das ist also Primär für die Modentwicklung interessant.


    Für die Zukunft:
    Ich habe dazu auch Idee um die Konstruktionsfunktion damit auch abzusichern, sprich sollte es einen Fehler in einer updateFn geben, würde dies nicht mehr zum Spielabbruch führen.

    ?( You started with a fundament different topic. game.config.construction is simple the game storage of the updateFn's by file after TPF applied the fileFilters.
    I never said I want to call constructions updateFns by LUA.


    Let the game survive an exception when the game calls a broken lua function is my goal. (as in the console) Thus making TPF overall more development friendly.
    This means that certain errors won't be fatal any more and you game simple won't quit to desktop and survive such situations.


    Hopefully it's now more clear.

    For syntax error, people can use static check tool like luacheck to make sure it's correct. I use it with vscode and it's real time, no need to go into the game to test it.


    Use a mock .con to call the target .con via game.config.construction, that way you get a promote when exception happens but the game continues, same thing by pcall, but with pcall there's no promote and you need to dump the exception by yourself.


    It would be more appreciated if the commonapi can hot update .lua files

    Ach, ich habe eigentlich keine Lust mehr herum zu argumentieren.


    Seid mir nicht Böse, ständig lese ich wie ich es anders machen soll, warum man CommonAPI sowieso nicht braucht oder warum ich total falsch liege.


    Eigentlich zeigt das Nutzen des Lintchecks, das ein lua safe call doch nicht so sicher ist wie angenommen.


    Natürlich kann man die embankmentSlopes in den Configs ändern. (Wie ich mit der CommonAPI dll angefangen habe, gab es die Einstellung noch gar nicht)
    Aber will man wirklich ständig die Configs von Strassen und Gleise ändern oder sich seine Gleisbautools mit zig Varianten eines Gleis füllen. Ich zumindest nicht.


    Um ehrlich zu sein, diese ständige Diskussion geht mir gehörig auf den Wecker.


    Es wird also erst mal keine neuen Dev Versionen mehr hier geben.
    Ich werde die Native UI für meine eigenen und etwaige privat angepassten Mods Nutzen und das Thema ist erst mal durch...

    I would only relay on CommonAPI that is on Steam so the dev version here won't be considered until it's on Steam, if not it will be a trouble for these who don't know here or who don't want to take time to installer manually (or by TPFMM which isn't available on Steam), and I didn't said you are wrong, I just point out there maybe something you didn't know, and I don't understand why you feel angry.


    I don't change embankmentSlopes or the configs, I lay track terrains by myself :D

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

    3 Mal editiert, zuletzt von Enzojz ()

    Wäre schade, wenn es keine neuen Versionen mehr gäbe. Ich habe die dev-Version gerade erst vor ein paar Tagen endlich mal ausprobieren können. Die neuen Möglichkeiten, insbesondere das direkte Modifizieren der Eigenschaften von Schienen ist der Hammer! Stabil war das Spiel bisher auch damit.


    Eine Kleinigkeit habe ich gefunden: wenn nach dem Bau mit geänderten Werten (Steigung, Krümmung) die Optionen wieder rausgenommen werden, snappen Gleise nicht mehr aneinander. Vielleicht kennst du das Problem ja schon.


    Ich zumindest würde mich über weitere neue Versionen freuen, die bisherigen Funktionen sind schon mal toll!


    Schöne Grüße
    Dirk

    Hallo
    Ich weiss nicht ob dass schon vorgekommen ist aber mir ist aufgefallen dass die RhB-Gleise nicht mit der Common Api kompatibel sind.
    Ich weiss nicht ob ich zu dumm dafür bin aber es ist eigentlich eine coole Mod und ich wäre erfreut wenn das hinzugefügt würde ;)
    MfG BSHSOaS

    Es gibt da zwei Möglichkeiten:

    • TPF Nachfolger wird großartig zu modden sein.
    • TPF Nachfolger ist wie TF>TPF eine Art 2.0

    Inwiefern CommonAPI eine Rolle spielt wird man sehen.


    Wenn es großartig wird umso besser, technisch gesehen brauchen wir die CommonAPI dann nicht mehr.
    Vielleicht hat aber die CommonAPI UG etwas dazu gebracht bestimmte neue Funktionen einzubauen.


    Die CommonAPI soll auch immer so verwendet werden, das man Mods auch ohne Sie nutzen kann.
    Für eine neues Spiel müssen Mods sowieso komplett überarbeitet werden, da fällt die CommonAPI gar nicht mehr ins Gewicht.


    Nur weil wir eine Ankündigung zur Ankündigung haben gleich den Hammer fallen lassen und gar nichts mehr tun?


    Ich möchte auch darauf hinweisen, das ein komplett neues Spiel auch nicht unbedingt automatisch ein Erfolg wird. Auch in der Zeit der Hochzeit von Chris Sawyers Locomotion war die Community rund um Transport Tycoon immer stärker. (Locomotion hat nur dazu geführt, das Josef noch mehr am TTDPatch Signalsystem gebaut hat)



    Nochmals zum Thema CommonAPI und Modder.


    Viele Modder wollten eine alternative, bessere UI. Nun gäbe es eine Möglichkeit, zum Beispiel um Texteingaben zu ermöglichen.
    Ja meine Lösung bedeutet einmalig Mehrarbeit, aber das Feedback war bis jetzt derart Negativ und geht schon in Richtung Anfeindung, das ist überhaupt nicht mehr schön.


    Ich war stets bemüht mit der Community zu Arbeit und auch gewisse Fragestellungen immer so gut wie möglich zu beantworteten. Meist ging es da weder um die CommonAPI noch um meine Mods. Damit ist aber erst mal Schluss. Ich konnte meine Mods nicht zu Ende bauen, Die CommonAPI ist ja eigentlich die Abspaltung von Gleis Problemlösungen meines Modernen Bahnhof mit mehr Bauoptionen.


    Was würde ich also beim nächsten mal anders machen?
    Keine öffentlichen Schnittstellen mehr bauen
    Mich mehr um meine eigenen Mods kümmern, egal ob andere Probleme haben.
    Weniger auf Wünsche der Community eingehen, Sprich mein Mod ist so, wenn Du Ihn nicht magst, benutze Ihn einfach nicht.

BlueBrixx