Zielanzeigen, Endhaltestellen (Beta Version)

**eis_os** · 18. April 2020

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.

**Yoshi** · 18. April 2020

Ich würde einen neuen Labeltyp wie z.B. LINE_DESTINATION gemäß deiner Beschreibung befürworten.

Frostbite · 18. April 2020

Zitat von eis_os

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.

**Yoshi** · 18. April 2020

Soweit ich es verstehe, ist es genau das, was er erreichen will. Man kann für jede Haltestelle einer Linie entscheiden, ob sie eine Zielhaltestelle ist oder nicht und es wird immer die nächste im Linienverlauf liegende angezeigt.

Seamon · 18. April 2020

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

**Yoshi** · 18. April 2020

Dazu kann man ja eine if-Condition in das mdl einbauen, sodass z.b. auf LINE_NAME zurückgefallen wird.

**MaikC** · 19. April 2020

Zitat von Yoshi

neuen Labeltyp LINE_DESTINATION gemäß deiner Beschreibung.

Ich schließe mich da an.

**eis_os** · 19. April 2020

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

wicked1133 · 26. April 2020

eis_os hast du gesehen es gibt einen stopIndex für jedes Fahrzeug. der erste Haltepunkt einer Linie ist immer stopIndex = 0 des Fahrzeuges. somit die zweite die StopIndex 1 usw. vielleicht kriegst du es ja hin über die line ID die in der Fahrzeug entity geschrieben wird den index und somit den namen abzufangen?

**eis_os** · 26. April 2020

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

**eis_os** · 2. Mai 2020

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?

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
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
Andere Weg

Ich werde wenn nur eins davon umsetzen.

**Yoshi** · 2. Mai 2020

Sehe ich das richtig, dass Variante 1.2 weder das Performanceproblem noch die Problematik mit dem Fehlscripting hat?

Dann wäre ich für die

Marcolino26 · 2. Mai 2020

Wenn if nicht der Fall ist (nicht installiert) kann ich ja trotzdem nen anderen Labeltype nehmen richtig?

Wäre auch für 1.2

Wenn möglich würde ich dann auch gern den Beschreibungstext ingame im Depot ändern wenn das Feature aktiviert ist.

Geht das, weiß das jemand?

**eis_os** · 2. Mai 2020

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

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:

Code

function data()

local desc = _("Nein, LINE_DESTINATION nicht aktiviert")
local labels = {
    ...
}


if (commonapi.supports ~= nil and commonapi.supports("LINE_DESTINATION")) then
    desc = _("Ja, es ist aktiviert")
    labels = {
       ...
    }
end


return {
    description {
         description = desc,
    },
    metadata = {
       labelList = {
             labels = labels
       }
      ...
   }
   ...
}

Alles anzeigen

Marcolino26 · 2. Mai 2020

Ahja das wär ideal!

**mediziner** · 2. Mai 2020

Zu Version 3:

Code

{
    type = "NEXT_STOP",
    special_type = "LINE_DESTINATION",
    transf = {0, 1, 0, 0, 0, 0, 1, 0, -1, 0, -0, 0, 5.157, -0.250, 2.70, 1, },
    size = { 0.86, 0.25 },
    color = {255 / 255, 142 / 255, 49 / 255, 1.0},
    fitting = "SCALE",
    alignment = "CENTER",
    verticalAlignment = "CENTER",
    renderMode = "EMISSIVE",
    childId = "mgt6d_vorne",
},

Alles anzeigen

wäre sowas auch machbar?

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

**eis_os** · 3. Mai 2020

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** · 3. Mai 2020

Zugzielanzeiger Testversion:

CommonAPI2

majuen · 21. Mai 2020

Hi eis_os

erstmal danke das du so viel Zeit und Arbeit in die CommonAPI rein steckst!

Wollte mal nach fragen ob die beta der LINE_DESTINATION nicht mehr supported wird? In der Console erhalte ich nämlich diesen Hinweis.

**eis_os** · 21. Mai 2020

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.

Zielanzeigen, Endhaltestellen (Beta Version)

Willkommen in der Transport Fever Community

eis_os 3. Mai 2020

Teilen