Zielanzeigen, Endhaltestellen (Beta Version)

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

  • Hallo


    Backround:

    Da Ihr mich kennt und mich schon viele gefragt haben, ich habe den Code der nächste Linienanzeige (LINE_STOP) technisch in CommonAPI2 nochmal nach gebaut.


    Technisch wäre es also wohl möglich eine Endhaltestellen Anzeige in CommonAPI2 zu bauen.

    Daher mal die Frage in die Runde, am einfachsten wäre es wohl anstatt die Linie bei LINE_NAME eine Endhaltestelle zu zeigen.

    Die andere Möglichkeit wäre es wohl irgendwie da einen neuen Labeltyp zu erfinden. (Zur Sicherheit käme dann ne if Abfrage dorthin, wenn keine CommonAPI2 da wäre, kann man dann ne Alternative nehmen)


    Von der UI her, dachte ich mir eine Liste mit allen Linien via UG UI Interface anzuzeigen, dann könnte man für jede Station in einer Line definieren, ob es eine Endhaltestelle ist.

    Die Liste würde dann an meinen C++ Code geschickt, dieser könnte dann für jede Linie errechnen welche Endhaltestelle, die nächste ist, und diese dann anzeigen.


    Ein Lua Callback wäre zwar flexibler, aber schon eine Sekunde hat mir meine Funktion schon zig tausend mal aufgerufen.

    Also muss ich schon vorher wissen was Ihr als Mod Autoren für ein Fahrzeugset unterstützen würdet und den Code zielgerichtet Planen ;)


    Vielleicht mag ja auch mal jemand unser Lexikon Eintrag hier etwas Feinschliff verpassen:

    Zielanzeigen


    Um frühes Feedback wird also gebeten.

  • Technisch wäre es also wohl möglich eine Endhaltestellen Anzeige in CommonAPI2 zu bauen.

    Daher mal die Frage in die Runde, am einfachsten wäre es wohl anstatt die Linie bei LINE_NAME eine Endhaltestelle zu zeigen.

    Die andere Möglichkeit wäre es wohl irgendwie da einen neuen Labeltyp zu erfinden. (Zur Sicherheit käme dann ne if Abfrage dorthin, wenn keine CommonAPI2 da wäre, kann man dann ne Alternative nehmen)


    Sehr gute Idee, finde ich. Ich finde es schon gut, dass es die Zielanzeige ins Spiel geschafft hat. Leider mit mäßigem Erfolg. Anstatt jedoch nur eine Endhaltestelle einzugeben wäre es nicht besser, direkt zwei Endhaltestellen eingeben zu können. Auch in der echten Welt hat jede Linie zwei Endhaltestellen. Wie das aber realisierbar ist, entzieht sich meinem Wissen.

    Nur als Idee: gäbe es bei der Linienplanung die Möglichkeit hinter einer x-beliebigen Haltestelle die Endhaltestelle auszuwählen?


    Kleines Beispiel: Linie 12

    1. Neustadt Endhaltestelle: Diez

    2. Schweinheim

    3. Nördlingen

    4. Diez Endhaltestelle Neustadt

    5. Nördlingen

    6. Schweinheim


    Wäre so etwas in der Art machbar oder programmiertechnisch ein riesen Aufwandt?


    Liebe Grüße.

  • Wenn man zwei Stationen als Endhaltestellen definieren könnte, wäre das schon der perfekte Fall und ich würde meine Busse sicher einbauen so umbauen, dass das so unterstützt wird.


    Wichtig wäre aber auch, dass bei den Fahrzeugen etwas Sinnvolles angezeigt wird, wenn jemand die CommonAPI nicht installiert hat (zumindest sicher nicht crashed oder deaktiviert wird).

  • Ich habe ja geschrieben, das man jede Haltestelle als Endhaltestelle markieren kann, dies schließt mehrere ein.

    Das Speicherlayout ist schon unter Windows nicht gerade einfach. (Man will ja kein Crash produzieren). Ich habe nun nen neuen Label Type mit interne ID 99. Zumindest ist der zur zeitige UG Code so, das wenn es den Labeltype nicht kennt, einfach NONE annimmt.


    Daher ist leider noch kein vernünftiger Code da, um etwas anzuzeigen, aber naja. Es zeigt schon mal Leerfahrt wenn es ins Depot geht an und CommonAPI2 wenn es eine Endhaltestelle zeigen soll :saint:


  • Den Namen einer Linie oder Stop zu bekommen ist eigentlich unter Windows kein Problem, bei Linux werde ich das wohl auch noch hinbekommen.



    Problematisch ist eben vom CommonAPI2 UI LUA auf den LUA GUI Thread zu gelangen. (Ob das dann alles stabil läuft ist noch eine andere Frage.

    D.h. bei Refresh -> lua_loadstring, lua_pcall remote im GUI Thread, dort die Daten serialisieren, diese im CommonAPI2 lua wieder entpacken.


    Damit komme ich dann an die Linien und Haltestellen Namen, ich nutze dafür meine eigene UI, weil ich UGs UI Code einfach nicht flexibel genug finde. Außerdem möchte ich da auch noch ne Textbox einfügen, damit man auch seine eigenen Endhaltestellen Namen kreieren kann...


    Aber ja, langsam kommen viele Einzelteile im Code wieder zusammen. Es wird nur eben alles etwas dauern...

  • Wie vielleicht die Discord Nutzer in einem kleinen Testvideo gesehen habe, ist eine für Windows lauffähige Version entstanden.


    Nächste Frage:


    Wie möchtet Ihr schauen ob TPF2 + CommonAPI2 mit Patch geladen ist in einer mdl?

    1. Per if Befehl im Modell:
      1. Ich setze die Globale Variable LINE_DESTINATION auf true
        if (LINE_DESTINATION == true) then
        Problem, schreibt jemand (LINE_DESTINATION = true), haben alle weiteren Mods ein Problem wenn die CommonAPI2 mit Patch nicht geladen wurde...
      2. Ich baue so etwas wie commonapi.supports("LINE_DESTINATION") :
        if (commonapi.supports ~= nil and commonapi.supports("LINE_DESTINATION")) then
    2. Per externen Modifier

      1. Alle mdl Dateien werden nach labels.[%platzhalter].alttype durchsucht und der Eintrag von type überschrieben (also technisch type = alttype
        Einfacher: ohne if else blöcke mdl.
        Nachteile:, sehr viel langsamer und man kann andere Parameter wie fitting oder params nicht ändern
    3. Andere Weg

    Ich werde wenn nur eins davon umsetzen.

  • Um das einfacher zu machen, würde dann im Kopf der mdl so etwas stehen: (das ist ein ungetestet Beispiel)


    local function ifLineDest = function(j, n)

    return n

    end


    if (commonapi ~= nil and commonapi.supports ~= nil and commonapi.supports("LINE_DESTINATION")) then

    ifLineDest = function(j, n)

    return j

    end

    end


    Dann kann man im Return eine Funktion aufrufen, die entweder oder zurück gibt:


    return {

    description {

    description = ifLineDest( _("Ja, es ist aktiviert"), _("Nein, LINE_DESTINATION nicht aktiviert") )(),

    }

    }





    Man kann natürlich auch anders machen, und es per Variablen machen:



  • Zu Version 3:


    wäre sowas auch machbar?

    D.h. wenn CommonAPI geladen ist, dann nutzt CommonAPI statt type special_type? Das Standardspiel sollte dies ja ignorieren.

  • Das wäre 2, die Modifier Lösung.


    Ich habe den Metadaten Loader für ENUM type erweitert.

    An dieser Stelle komme ich wenn überhaupt nur mit erheblichen Aufwand an andere Daten.

    Also wenn die LUA Daten in TPF2 eingelesen werden, muss type den gewünschten Type haben.


    Da etwas zu ändern, ist technisch auch sehr fragil. Bedenkt bitte, so etwas TPF2 beizubringen bedeutet, den Programmfluss zu ändern und alle Eingangsdaten und Ausgangsdaten einer Funktion richtig zu deuten. Bei dem Einlesen der ENUM Typen, ist das einfach: std::string geht rein, char/int des type kommt raus.

  • eis_os

    Changed the title of the thread from “Zielanzeigen, Endhaltestellen (Planung)” to “Zielanzeigen, Endhaltestellen (Beta Version)”.
  • Urban Games schraubt da am Code wohl gerade auch herum. Deswegen passten die Fragmente nicht mehr.

    Sie haben mich gebeten, eine Version der CommonAPI2 auf Steam zu veröffentlichen, die mit allen Versionen funktioniert da es weiterhin zu viele Bugrepots gab.


    So habe ich erst mal eine Version ohne diese Funktion veröffentlicht.


    Die letzten zwei Testing Updates haben insgesamt schon 8 Stunden Zeit verbraten um es wieder kompatibel zu machen. Gut 3 Stunden für die letzte Hotfix Version hätte ich mir sparen können wenn Sie mir direkt gesagt hätten: Die Modinfo Struktur dort hat einen neuen Eintrag erhalten.


    Wenn sich der Staub wieder etwas gelegt hat (also es wieder eine Stabile Version gibt), werde ich die Fragmente wieder neu suchen und die Funktionen wieder aktivieren.