Posts by eis_os

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

    stdout.txt? iOS? Tablet / Handy wäre mir neu. Oder meinst du MacOS?


    Also ich hab erst vorgestern CommonAPI2 Inspector ohne so lib benutzt um etwaige Änderungen der UG Schnittstellen auszuschließen.

    (Ich hab keine Daten erhalten, also habe ich ohne Lib getestet und das selbe Problem gehabt).


    Ggf. musst du den API Knopf zweimal drücken, das Menü Fenster will manchmal die Größe nicht berechnen.


    Hier mal ein Bild von gerade eben auf Linux ohne CommonAPI2 so library, man sieht auch hat man auch nur noch 3 Optionen in der Menüliste.


    PS: Du benutzt aber nicht die Steam Version ohne Inhalt der als Platzhalter fungiert damit ich keine Supportanfragen bekomme, weil Spieler CommonAPI2 nicht aus Ihrem Spielstand entfernt bekommen haben?

    https://commonapi2.bytetransfe…requirements/requirements

    • Windows 10 1803 or higher (see windows requirements)
    • Linux
    • TransportFever2 Steam or GOG Version

    Nix MacOS


    99% der CommonAPI2 funktioniert nicht auf Mac:

    - Das Inspector Fenster funktioniert, kann aber nur Daten der offiziellen API anzeigen.

    - Checkmods sollte funktionieren.


    Es wird keine Mac Version geben.

    Ich müsste einen Apple Developer Account haben inkl. Mac und noch mehr Zeit verbraten.

    Jede x86 Version ist anders, jede Build ist anders. Linux & Windows benutze ich halt selber und bekommen daher Unterstützung.


    Obwohl ich eher auf Linux "Spiele" bekommen ich eine Unterstützung für Windows Builds schneller zusammen, da GCC weit mehr optimiert und daher leichte Änderungen schon erhebliche Binäränderungen hervorrufen.


    PS: Vergleicht CommonAPI2 nicht mit irgendwelchen Mods für Spiele wie Unity. Der C# Bytecode ist für alle Plattformen normalerweise identisch und wird erst auf dem Zielsystem optimiert. x86-64 Assembler ist halt ne andere Hausnummer...

    oberhausener68

    Also wenn du eine Version 20240607 nutzt wird das natürlich nicht gehen :rolleyes:

    Ich tippe mal, du hast auch das Fenster für Neuerungen noch nicht abgeschaltet.

    Code: stdout_old.txt
    commonapi2.init    20240607
    commonapi2.init: Your TPF2 version 'steam_35915_1' isn't listed as known good version, please update CommonAPI2


    Wenn man mal in den Release Thread schaut:


    Und das wiederum verlinkt drei Nachrichten über deine Nachricht...



    WernerK


    Ein entfernen der Einträge würde zum verschieben der internen Ids führen, danach ist das Savegame Schrott.

    stdout.txt, settings.lua der CommonAPI2, Gibt es ne Nachricht auf dem Hauptmenü von TPF2 unten links? Wie soll man den Helfen wenn man keine Informationen bekommt.


    Es sollten alle Funktionen laufen... unter Linux wie auch unter Windows in der Steam Version... Zur GOG Version bin ich nicht zu gekommen bis jetzt... (Aber dann gibt es wie immer eine Nachricht unten Links im TPF2 Hauptmenü)

    Ja, die Verbindungen sind nicht an irgendwelche transportModes gebunden.


    TPF2 speichert eine ConnectionMap, die ich beeinflusse. Das ist im Endeffekt eine Liste mit (QuellStraße, QuellNodeID) -> (ZielStraßen, NodeID) Verbindungen.
    Das hat sich seit Build 359xx geändert intern, da ist technisch nun sogar wenig Platz drin, sprich da hat UG Speicher optimiert.


    Das steht auf meiner Todoliste noch mal nachzuforschen, ob ich da noch was anders Handhaben kann. Die UI für so etwas wäre dann auch spannend...


    Wenn mir jemand ne Idee bringen kann wie ich es verhindere, das sich zwei Trams auf der Eingleisigen Strecke begegnen und deswegen stehenbleiben...

    (Der Betriebshof hat zwei Haltestellen, eine "Ausstieg", damit die Line richtig rum funktioniert. )


    Da ist nix überbaut, das ist via Nodeditor advMode verbunden.

    Wer es ausprobieren möchte, muss


    advMode = false,  in advMode = true, in der Datei res/scripts/commonapi2/ui2/NodeWindow.lua  (Zeile ~325) ändern.

    Dann habt Ihr im NodeEditor Lila Start Nodes für "Gegenverkehr" Nur zu empfehlen bei Lanes mit reinen Gleisen, sonst habt ihr bald alles Geisterfahrer :)

    Was mich ärgert ist, das meine CommonAPI2 so hingestellt wird, als würde das Spiel dadurch total instabil. "Beta"


    Ich arbeite an Sachen, die mir Spaß machen und Sinnvoll erscheinen. Bei meinen Tramstraßen habe ich UG genau berichtet was ich haben möchte, das ich die auch ohne CommonAPI2 bauen kann. Daraus wurde mal wieder nix, wenn ich dann schon den Code komplett auseinander nehmen muss, kann ich direkt auch bestimmte Sachen ändern.

    (Trams in der Mitte hab ich schon früher versucht in TPF1)


    CommonAPI2 ist aus dem ignorieren des Feedbacks zu den miesen Anbindung von Modgleisen bei Release in Konstruktionen entstanden. Das wurde ja erst später mit postRunFn gerade gebogen. So richtig glücklich bin ich damit aber nicht.


    So führte die Einführung der Tramlanes in der Mitte einer Straße zur Analyse wie Lanes überhaupt funktionieren, das führte zum Inspector Fenster, das zur Analyse der Attribute Map.

    Hatte ich irgendwann mal verstanden wie UG die Straßen baut und dann Rendert, konnte ich mir das mit den Nodes anschauen. Daraus wurde dann der Nodeeditor. (Weil Wendeschleifen so schrecklich aussahen) und ich Konstruktionen wegen echter Stadthäuser auch schrecklich finde.


    Bei der Überlegung wie ich Eisenbahngleise dazu bringe eine andere Fahrleitung anzuzeigen, bzw. den Mast nicht auf meine Weiche zu pflanzen hab ich nach Möglichkeiten gesucht, irgendwo dort ein paar Bits zu speichern. Da ist halt nur an/aus Oberleitung drin, aber das führte mich dazu das man ja eigentlich bei Trams mindestens 3 zustände braucht. In so ein Byte bekommt man dann halt mal 256 Zustände rein. Zum Glück optimierte UG das nicht und hab da quasi fast überall Platz ;)


    Der Prototype ist dann innerhalb zwei Tagen entstanden!.

    Die Infrastruktur, laden von Modgleisen, schauen wie ich Trams das als elektrischen Weg verkaufen kann war dann eine Menge Arbeit.

    Funfact: Das erste Modtramgleis zum Laden lag im ATS Mod Verzeichnis, da schließt sich der Kreis, :P


    Ich würde behaupten, mit dem direkten Zugriff auf den Quellcode hätte ich das Feature innerhalb eines Monats Vollzeit komplett erstellt.

    Es ist halt sehr viel Mehrarbeit wenn ich erst ne Infrastruktur bauen muss um zum Beispiel die Tramgleise zu laden als wenn ich in TPF2 Code einfach ResType<TramTrack> hinzufügen könnte. Zurzeit muss ich mich auch begnügen alle Gleise als elektrisch zu betrachten. Das ist eine Byteänderung, mehr Platz hab ich dort nicht.

    -edit ausgelagert in eigene Nachricht -


    Erstmal etwas generelles: Es gibt in TPF2 Straßen und Eisenbahngleise


    Straßen haben einschaltbare Tramgleise mit Oberleitung und Masten.(Poles)

    https://www.transportfever2.co…ing:tracksstreets#streets

    Wenn du in TPF2 sagst, eine Straße solle bitte Tramgleise haben, werden noch Trammaterialen gerendert, bei "Elektrisch" gibt es noch Oberleitung mit Masten.

    Sowohl Trammaterial für die Schiene, die Oberleitung und die Masten werden in der Straße definiert


    Möchtest du also eine Straße haben mit 1000mm Tramgleise und 1435mm, musst du die Straßen verdoppeln und die Materialien ändern,

    bei 10 Straßen brauchst du 10*2 Typen = 20 Stück!


    CommonAPI2 Newstreets hat noch einen neuen Typ neben Straßen: Tramgleise (diese werden auf Straßen genutzt)


    Ein Tramgleis kann nun nicht nur die Materialen sondern auch die Erstellung der Oberleitung überschreiben:

    http://commonapi2.bytetransfer.de/#/modding/TramTracks


    Hast du nun ein Tramgleis "1435mm" dann kannst du das nun beim Straßenbau auswählen,

    du hast 10 Straßen mit 1000mm Gleisen ganz normal definiert. Kannst diese aber auch mit Tramgleis 1435mm bauen


    Du kannst nun beim Bauen mit CommonAPI2 newstreets sagen:

    Bau mir nun die Straße aber mit Tramgleis 1435mm.

    Die Straße ist dabei egal, daher ist ein Tramgleis nicht an eine bestimme Straße gebunden.

    Warum das UG nicht so von Anfang an gemacht hat, keine Ahnung... :/ (Funfact, TPF nennt das intern sowieso tramTrackType https://www.transportfever2.co…tructionbasics#edge_lists)

    Ich finde die Trennung viel logischer. Dem Schienenhersteller bzw. Verkehrsgesellschaft ist es doch egal wie der Asphalt bzw. Gehweg einer Straße aussieht...


    Und ja, ich habe keine Maste in meinem Paket.

    Wenn das hier halt nix wird, bin ich geneigt meinen eigenen Mastbauer anzubieten... und nein Werners Baukasten funktioniert bei meinen Straßen nicht.

    Die Assets gehen, aber da fehlen halt die Isolatoren oder die Verbindungen zwischen den Masten und den Fahrdraht. Die Automatische Erstellung geht bei meinem breiten Straßen gar nicht.
    Hier hätte ich auch lieber nur Masten im Grünstreifen, sind halt andere Anforderungen.


    Wenn mir also jemand Masten anbieten könnte, inkl. Isolatoren wäre ich schon happy und mach dann halt mein eigenes Konstruktionssystem... Vielleicht kann ich ja mal einen Prototypen basteln...

    Ganz einfach:

    Auto Tram Elektrisch benutzen die Oberleitung & Masten der jeweilig Straßen.

    Danach ist alles "elektrisch" für Fahrzeuge, einer ladbaren Konfiguration für Gleise aus res/capi_config/tramtrack/


    Die Details könnt Ihr meinem Handbuch entnehmen, dir steht es frei eigene Konfigurationen anzubieten (in eigene Mods, CommonAPI2 lädt das dann analog zu anderen Ressourcen):

    http://commonapi2.bytetransfer.de/#/modding/TramTracks


    Irgendwann wird das Menü halt unübersichtlich und das System kann ich quasi nicht groß ändern. Dropdown war nur mir gut zureden möglich.


    Anstatt Dummy Poles zu rendern, wird bei hasCatenaryPoles = false nur noch die Oberleitung gerendert, keine Isolatoren oder sonst noch irgendwelche Leitungen.

    hasTramTrack = false schaltet die Tram Texturen ab.
    hasOwnTramTrack / hasOwnCatenary sagt aus, überschreibe Gleisematerialen/Oberleitung der Straße


    Im Endeffekt hast du dann einerseits eine Straße und irgendein Gleispaket mit Oberleitungskonfiguration.

    An der Umsetzung aller Ecken und Kanten bin ich noch dabei, aber es läuft eigentlich schon recht gut.


    -edit-

    Da es für "Nur Fahrleitung" keine Masten gibt, würde ich gerne ein generelles Paket nur mit einem Mastbauer haben, den wir übergreifend Nutzen können.

    Zum besseren Verständnis, das sind keine Straßen.


    CommonAPI2 trennt Tramgleise & Straßen.

    Du kannst also auch die Gleise wegschalten und quasi ne Obuslinie bauen, oder andere Wilde Sachen. Auch sind damit zwei Spurweiten möglich ohne das es eine Straßentypexplosion gibt.


    Mit CommonAPI2 wird wirklich nur der Fahrdraht gerendert.

    Damit sind dann zum Beispiel Einzelmasten in der Mitte möglich.


    https://commonapi2.bytetransfe…racks?id=hascatenarypoles


    In meinem Tramtrackpaket gibt es auch elektrifizierte Gleise ohne Fahrdraht,

    das wäre dann zum Beispiel Akkutrams interessant oder an Bahnübergängen.


    Leider hab ich einen kompletten Renderer zusammen, somit ist die Fahrdrahthöhe noch fest.


    Und wenn es um Performance geht:

    Seit dem Herbst Update von TPF2 werden alle Straßen in TPF2 komplett geladen. Also 1000 Straßen zu erstellen ist auch nicht der Hit...

    Damit wird verhindert, das die Engine während des Spiel crasht weil Texturen einer Straßen fehlen...


    PS: Du kannst auch nur das Tramgleispaket laden mit der CommonAPI2 Funktion oder dein eigenes Tramgleis Mod erstellen.

    Nochmalig öffentlich die Bitte meinerseits, die Masten als Einzelpaket als Assets anzubieten.


    Die würden sich gut auch mit dem CommonAPI2 Straßen bzw. Tramgleispaket vertragen.

    Also bei CommonAPI Tramgleispaket nur Oberleitung auswählen, und dann die Masten per Hand setzen.


    Wie verhinderst du das zwei Bahnen auf den eingleisigen Strecken begegnen?

    Technisch kannst du via CommonAPI2 eine nur Tramgleis Lane so zusammenschalten an Kreuzungen, das die Strecke in beide Richtungen genutzt wird. (ohne internes Doppelgleis).

    Das Problem was ich habe ist immer noch, wie ich das hinbekomme das mit keine zwei Trams auf der Strecke begegnen...

    Da ich die UI Bilder gestern auf Windows erstellt habe, bin ich mir sicher, das die Funktion sowohl auf Linux und auch auf Windows läuft:


    (Oben rechts, neben der Suche hast du den NodeEditor als Symbol und auch den Magneten für das Einrasten...


    Ich gehe davon aus, CommonAPI2 fehlt im Spielstand als Mod und oder improveui ist nicht angeschaltet (1 oder 2)

    Development Version 20241024 Build 35915

    Now for linux too! Nun auch für Linux



    Neue Version 20241024, endlich gibt es eine Linux Version.

    Technisch hat das bedeutet, das ich alle Fragmente neu erstellen musste.

    Daher hoffe ich mal, das UG nicht direkt wieder ne neue Version herausbringt, die alles komplett anders macht.


    Da mir das Einrasten nicht immer gefällt, gibt es nun eine Funktion in improveui.

    Man kann das Einrasten abschalten:

    >


    Damit wird intern die Tastenfunktion "Einrasten" umgedreht. Dieses gilt getrennt für Konstruktionen und Gleis/Straßenbau


    Wer die Gruppierung nicht mag, kann mit improveui 2 den Standard auf nicht Gruppierung umschalten.


    New version 20241024, finally a linux version.

    Technical I had to rebuild all fragments for all functions.

    Hopefully a next version of TPF2 won't change totally again.


    As I don't like the new snapping function to be enabled all time, I added a new function to improve ui.


    There is a new magnet icon: >

    This will invert the snapping key functionality. This setting is split between constructions and street and track building


    If you don't like grouping by default, now it's possible to use improveui 2



    1.9.20241024-dev

    - !!! BUILD 35915 Linux and Windows only !!!

    - !!! THIS IS A DEVELOPMENT VERSION, backups required !!!

    - Fixed all linux fragments

    - improveui: disable grouping with improveui setting 2

    - improveui: add new toggle button to switch snapping

    - UIHacks: add internal lua interface to invert constructNoSnap key meaning for ConstructionBuilder and StreetBuilder

    Ganz simple einfache Fragen:


    Wenn UG die API Funktion der UI ändert via Update, nun einen anderen Art Parameter erhalten möchte und das nicht im Changelog vermerkt. Ist das dann der Fehler eines Mod Authors?


    Wenn du eine API anbietest und du nirgends öffentlich ansagst, das deine API Bindung Probleme hat und man das nur mit temporären Zwischenvariablen lösen kann? Ist das ein Fehler eines Mod Erstellers?


    In der Zeit der Entwicklung des Mods hat die UI noch sehr komische Sachen gemacht...


    Und so eine API anzubieten ist nicht einfach.

    Ich kämpfe da selber ständig mit in der CommonAPI2. Ich kenne beide Seiten und erlaube mir daher ein Urteil.


    -edit-

    Da ich da nicht noch weiter ausholen möchte, nein ich denke da Beispiele in der Community, die keine wirkliche Hilfe von UG bekommen haben, bzw. nicht hilfreich waren...

    Auf den Fork hatte ich schon verwiesen.


    Das liegt an der Natur der Sache wenn man mit Pointern arbeitet eines Iterators.

    Noch schlimmer wird es wenn du einen Crash erzeugen kannst,

    wenn du Daten von der API erhältst und dann nicht wieder in die selbe API kippen darfst.


    Mein VehicleScript Objekt in LUA darf eine Kopie der Daten machen damit ich einen Zug ändern kann. Alle anderen Versuche haben da Fehler produziert.


    Wenn man dann keinen Support durch UG erhält , bzw. der Support selber nicht weiß warum etwas passiert, ist das etwas bescheiden.


    Zum Beispiel hat die UI des Build Cursors (zum Akzeptieren/Abbrechen) einen eigenen UI Manager. D.h. Angebunden UI Elemente müssten theoretisch eine eigene LUA Runtime erhalten, damit da nix durcheinander kommt.


    Es gibt bei UG wohl geschätzt zwei Angestellte, dir das beantworten könnten.


    Man kann mit einer instabilen API nicht arbeiten. Wenn man nicht viel Zeit investieren möchte, bleibt eigentlich nur die Entwicklung eines Mods nicht weiter zu verfolgen. Das API Funktionen offensichtlich kaputt gemacht werden ist dann noch ein anderes Thema. UGs Lösung. Der LUA Thread wird ohne Fehlermeldung abgebrochen! Sehr toll beim Debuggen...


    Das ich offensichtlich Böse werden muss und das an die große Glocke hängen muss, das ist dann auch Übel.


    Beispiel: mod.lua Parameter Crash bei doppeltem Key. Das hätte UG debuggen können, es war Ihnen egal. Irgendwann musste ich sehr unfreundlich werden, weil CommonAPI2 immer beschuldigt wurde, diesen Fehler zu produzieren....




    Hier ein Beispiel, das nirgends im "Handbuch" steht und recht schnell komplex wird:


    Du darfst keinen Zeiger zu Entity Daten über GameScript Funktionsgrenzen halten.

    Warum?


    Nehmen wir an UG, bindet via Sol eine API, der dir zu einem c++ vector<irgendwasausdenentitysystem> zeigt.


    Du baust dann ein sehr einfachen LUA code


    local d = getIrgendEtwasAusDemEntitySystem()

    p = d[1]


    <Aufruf nach einem Update der UI>

    print(p.irgendwas)



    Was ist nun p?

    Ein sol Objekt das auf ein Element im Vector im Arbeitsspeicher zeigt, ggf. ist es ein Const Pointer. Sprich du darfst es selber nicht mal ändern über die Schnittstelle.


    Was passiert wenn du nun d irgendwie änderst durch eine andere API, du fügst ein Element hinzu?

    - Wenn der C++ Vector noch groß genug ist, bleibt alles gut

    - Wenn der C++ Vector nicht groß genug ist, wird ein neuer Speicher alloziert und die Daten + das neue Element dort hin kopiert. p ist nun im Eimer.


    In C++ heißt es, das Iteratoren oder Pointer invalid werden, das bekommt man aber nirgends zur Laufzeit mitgeteilt. das steht im Handbuch deiner STL Library deines Compilers.


    Ok, du sagst ich ändere ja im UI Thread mit keiner API diesen vector.


    Was passiert aber nach dem Aufruf einer Funktion im UI Thread deines GameScript?


    Vielleicht erst mal gar nichts, weil das Teil im UI Bereich liegt, aber wenn durch Userinteraktion irgendwo der Vector verändert wird?


    Dein LUA Sol Lua Objekt zeigt nun ggf. auf einen validen anderen Eintrag, ggf. auf etwas anderes im Arbeitsspeicher oder gar nichts. Bravo, dein Game Script im UI Thread ist instabil geworden.


    Was passiert wenn dein Pointer auf Entity Daten zeigen?

    - GameScript UI Funktion wird aufgerufen

    - Spiel läuft weiter

    - Neue Daten werden von Simulations/Script Thread -> zum UI Thread kopiert.

    - Deine UI Funktion wird aufgerufen.

    - p.irgendwas

    *Kaboom*


    Für LUA und SOL hat sich eigentlich nichts geändert.


    Nunja, aber die Welt drumherum hat sich massiv geändert, du hast eine neue Kopie der Daten im Arbeitsspeicher an ggf. einem ganz anderem Ort!

    Dein Pointer zeigt irgendwo hin...


    Schauen wir mal das ganze bei einem Game Tick an:


    -GameScript Simulations Thread Funktion wird aufgerufen:

    - Spiel läuft weiter

    - <irgendwas passiert hier>

    - Deine Funktion wird erneut aufgerufen.

    - p.irgendwas

    *Kaboom*


    Jetzt die große Frage? Passiert das ständig, nein. Wenn deine Daten im Vector immer noch am selben Platz liegen kannst du 1000 Spieljahre durchlaufen lassen, dein Mod funktioniert. Ist p.irgendwas als Integer gebunden, bekommst du halt mal falsche Daten. Als float, kann es dir passieren das du den Pointer als Float nicht lesen kannst. Das mag dein CPU gar nicht und du bekommst ein Exception.


    Du hast nun ein Spieler, der 1 Zug mehr hat oder irgendwas macht. Der Vector muss größer werden und liegt an einem anderen Platz.


    Und nein, das kann dir auch keine KI richten oder erklären...

    Ich spiele TPF2 eher auf Linux als auf Windows, Savegames sind kompatibel (selbe Build nutzen!) Mods in der Regel auch, Dateinamen waren halt problematisch. Seit TPF2 mehr auf UTF8 achtet, hat sich das aber verbessert. (Spiele aber mit nur wenig Mods)


    Auch zwischen GOG und Steam kann ich problemlos Zeugs verschieben.(Gut meine GOG Version mit CommonAPI2 nutzte dann halt auch mal den Steam Workshop Ordner mit.)


    Fehlerhaftes verhalten zwischen Scripts und TPF2 führen auf Linux eher zu Speicherüberläufen, das mag die GCC Runtime überhaupt nicht. Durch die andere Kompilierung werden auch fehlerhafte Nutzung der TPF2 UI via LUA nicht so sehr verziehen.


    Proton hab ich für TPF2 noch nie genutzt, das ist überflüssig.


    CommonAPI2 sollte hoffentlich bald auch wieder laufen, das ist aber ein anderes Thema.

    Also wenn du die Haupt Linien UI meinst, die ist sehr speziell.

    CommonAPI2 nutzt die UG Linien UI und hab den Code dafür schon 3 mal neu gemacht, ich muss den Liniennamen suchen, damit ich die richtige Linie herausfinden konnte.


    Grundsätzlich bindet UG keine Spezialelemente, bedeutet, du hast dann zwar ne Tabelle aber keine Funktion um herauszufinden welche Line der Nutzer gewählt hat.

    Es kann sein das UG das mittlerweile geändert hat...


    (Wegen der ständigen UI Änderungen hab ich ja meine UI Inspector geschrieben, damit kann man dann die UI zur Laufzeit erkunden)