[Ideensammlung]Standardisierte Individualisierung von Innenanzeigen | Standardisiertes Anzeigen der Umsteigelinien

Moin,

ich finde euren Vorstoß gut.

Was den Umsteigetyp angeht, würde ich noch "Fähre" und "Standseil/Schwebebahn" ergänzen. Ggf. wäre auch an "Seilbahnen" zu denken(in Überlandmaps mit Skigebieten).

Generell würde ich vorschlagen die verfügbaren "Schriftzeichen" zu definieren. Bei meiner Karte bin ich immer etwas ratlos welche Schriftzeichen denn jetzt verwendet werden können. Hier könnte ich mir eine Abstufung vorstellen nach dem Motto:

• Verwendung in Europa (Unterstützung aller lat. Schriftzeichen die im Europäischen Raum vorkommen)
• Verwendung nur in D/A/CH (Unterstützung aller lat. Schriftzeichen die im Deutschsprachigen Raum vorkommen)
• Verwendung nur in Deutschland

So könnten dann Content-Ersteller sehen, für welche Themengebiete sie die Objekte verwenden können.

Zweiterer Vorstoß wäre auch allgemein für alle Objekte die mit viel Schrift arbeiten diskutabel.

Moin,

ansich hat Gegreenpeaced schon einige meiner Wünsche auch geäußert. Was ich noch für mich wünschen würde wären so "Zweitnamen" der Haltestellen. Das z.B. bei Hauptbahnhof untendrunter noch Central Station steht. Ist kein muss wäre für mich aber wünschenswert.
Vielleicht per Zusatzstring für die Haltestelle machbar

Quote from jamobatv

Quote from Gegreenpeaced

Was den Umsteigetyp angeht, würde ich noch "Fähre" und "Standseil/Schwebebahn" ergänzen. Ggf. wäre auch an "Seilbahnen" zu denken(in Überlandmaps mit Skigebieten).

Hab ich ergänzt!

Quote from Nevio0815

Was ich noch für mich wünschen würde wären so "Zweitnamen" der Haltestellen. Das z.B. bei Hauptbahnhof untendrunter noch Central Station steht.

Ich glaube, das würde gegen die Grundidee des FIS-Systems sein, weil Haltestellennamen (und darunter würde ich auch Zweitnamen verstehen) ja im entsprechenden Feld der FIS eingetragen werden.

Aber vielleicht kann Marcel Kuhnt das nochmal bewerten?!

Ich denke Nevio meint folgendes (Jakob-Winter-Platz)

Quote from Gegreenpeaced

Ich denke Nevio meint folgendes (Jakob-Winter-Platz)

[IMG:https://upload.wikimedia.org/wikipedia/commons/thumb/d/d7/Ngtd8ddfahrgastinfosystem2.jpg/1280px-Ngtd8ddfahrgastinfosystem2.jpg]

Richtig! Das meinte ich.

Hallo, ich finde es sehr praktisch das sich hier um die Standardisierung der Anzeigen Gedanken gemacht würd und würde gerne noch ein paar Vorschläge machen:

• Symbol für einen Servicepunkt.

• Alternative Rahmenformen wie zum Beispiel:
• Der Möglichkeit die Uhrzeit und Datum zu der bestimmte Linien angezeigt werden zu begrenzen.

Außerdem würde mich interessieren ob Filme als Werbung grundsätzlich denkbar sind?

Moin,
da ich ebenfalls eine TFT-Innenanzeige baue, es aber recht schwierig finde, meine Gedanken verständlich in Text zu fassen, haue ich hier jetzt mal ganz egoistisch das rein, was meine Anzeige für ihre Funktionen braucht. Es handelt sich um eine Anzeigensoftware, wie sie in Leipziger Trams (und vermutlich auch Bussen) verwendet wird.

VianovaSpecs_DEU.pdf

Die Reihenfolge und Formatierung der Parameter ist hier natürlich jetzt nur als Beispiel zu verstehen, die kann ich gern jederzeit anpassen. Die FIS-Klasse ist logischerweise ebenfalls irrelevant.

Theoretisch sollte meine Anzeige auch die Anschlüsse mit Ziel und Countdown zur Abfahrtszeit anzeigen können, da sich letztere aber derzeit noch nicht ohne Weiteres auslesen lässt, fällt das vorerst weg. Sollte das irgendwann möglich sein, dürfte das allerdings auch keine weiteren Infos aus der speziellen FIS benötigen.
Was auch noch fehlt, ist die Anzeige von Informationen zu bspw. SEV oder Störungen auf der Strecke, wobei ich mir nicht sicher bin ob das eine haltestellen- oder linienspezifische Sache ist bzw. sein sollte.
Die Farbe der Liniennummer ist nur schwarz-weiß einstellbar, weil ich sie so im Alphakanal der Linienfarbe speichern und mir so im Script ein Cardinal-Array sparen kann. Wäre aber bereit, das zu ändern.

Generell sind zusätzliche Werte, die dann von meiner Anzeige einfach ignoriert werden (Ausstiegsseite, Zweitnamen der Haltestelle...) ja kein Problem. Was ich allerdings etwas fragwürdig finde, sind die "Konfigurationsmöglichkeiten" à la Hintergrundfarbe und Aussehen des Linienfeldes. Diese sind so spezifisch zur jeweiligen Anzeige, dass eine Integration in den Standard schwierig ist. Nur als Beispiel: Was passiert, wenn eine Anzeige einen Farbverlauf als Hintergrund hat? Welche Hintergrundfarbe wird dann angezeigt, wenn sie in der speziellen FIS geändert wird? Ich würde daher entweder dafür plädieren, solche Konfigurationsmöglichkeiten des Systems entweder ganz wegzulassen oder so auszuweiten, dass man die Anzeige fast komplett frei gestalten kann. Letzteres wäre natürlich ein Traum besonders für fiktive Maps, aber eben auch extremst viel Aufwand und wahrscheinlich auch mit einer recht hohen Performancelast verbunden.
Ein Ding spezifisch zu den Farben für die Liniensymbole: Ich habe die bei mir in den generellen Zusatz-Strings, weil ich sie für die Anschlüsse brauche. Die Farben aus den Routen-Strings rauszufischen wäre sehr aufwendig, deshalb müsste man dann die Farbe bei jeder Haltestelle für jeden Anschluss neu definieren. Ich weiß nicht genau wie man um dieses Problem herumkommt, auch weil ich weiß dass meine Lösung nicht unbedingt ideal ist (z.B. wenn man die Liniennummer gegenüber der regulären FIS ändern möchte).

Entschuldigt wenn ich jetzt nochmal dazwischen funkte. Das Thema Standartisierung von Schriftzeichen ist erstmal abgelehnt/vertagt oder?
Ihr hattet euch dazu nur nicht geäußert, deswegen frage ich nochmal nach.

Moin zusammen erstmal

Quote from tramkatze

Die Farbe der Liniennummer ist nur schwarz-weiß einstellbar, weil ich sie so im Alphakanal der Linienfarbe speichern und mir so im Script ein Cardinal-Array sparen kann. Wäre aber bereit, das zu ändern.

Also in der aktuellen Umsetzung vom Parser wird die Farbe der Liniennummer sowieso, wie auch alle anderen Farben, direkt als eine 32Bit-Ganzzahl gespeichert. So kann jede Anzeige separat entscheiden, wie es mit den Daten umgeht. Und in deinem Fall kann aus der Farbvariable der Alpha-Wert ermittelt werden, sodass die Anzeige trotzdem die schwarz-weiße Liniennummer handhaben kann.

Quote from tramkatze

Was ich allerdings etwas fragwürdig finde, sind die "Konfigurationsmöglichkeiten" à la Hintergrundfarbe und Aussehen des Linienfeldes. Diese sind so spezifisch zur jeweiligen Anzeige, dass eine Integration in den Standard schwierig ist. Nur als Beispiel: Was passiert, wenn eine Anzeige einen Farbverlauf als Hintergrund hat? Welche Hintergrundfarbe wird dann angezeigt, wenn sie in der speziellen FIS geändert wird? Ich würde daher entweder dafür plädieren, solche Konfigurationsmöglichkeiten des Systems entweder ganz wegzulassen oder so auszuweiten, dass man die Anzeige fast komplett frei gestalten kann. Letzteres wäre natürlich ein Traum besonders für fiktive Maps, aber eben auch extremst viel Aufwand und wahrscheinlich auch mit einer recht hohen Performancelast verbunden.

Am Ende soll der Standard nur alle relevanten Möglichkeiten abdecken, die der Display-Ersteller braucht/brauchen könnte, damit nicht jeder sein eigenes Püppchen kochen muss.

Und welcher Hintergrund am Ende angezeigt wird, ist eigentlich egal. Solange in der Dokumentation der jeweiligen Anzeige erläutert ist, welche Standard-Funktionen unterstützt werden und welche nicht, sollte es kein Problem darstellen.

Funfact: Ein Farbverlauf ist tatsächlich auch vom FIS-Ersteller einsetzbar. Zurzeit kann über die spezielle FIS eine Auflistung mit Startfarbe, Endfarbe und Richtung übergeben werden und über ein "zusätzliches" Script wird das dann auf die Textur gemalt. Selbstverständlich werden Parser und Hilfsfunktionen zeitnah für alle bereitgestellt.

Quote from tramkatze

Ein Ding spezifisch zu den Farben für die Liniensymbole: Ich habe die bei mir in den generellen Zusatz-Strings, weil ich sie für die Anschlüsse brauche. Die Farben aus den Routen-Strings rauszufischen wäre sehr aufwendig, deshalb müsste man dann die Farbe bei jeder Haltestelle für jeden Anschluss neu definieren. Ich weiß nicht genau wie man um dieses Problem herumkommt, auch weil ich weiß dass meine Lösung nicht unbedingt ideal ist (z.B. wenn man die Liniennummer gegenüber der regulären FIS ändern möchte).

Ein Kompromiss wäre, wenn in den Zusatzstrings der Route oder der Haltestelle mit Verweisen auf vorher definierte Liniensymbole aus den generellen Strings gearbeitet werden könnte. Somit muss einerseits nicht unbedingt alles mehrfach abgetippt werden, anderseits bleibt die Flexibilität, um für Haltestellen/Routen separat Abweichungen/Änderungen vornehmen zu können.

Quote from jamobatv

Ich würde tatsächlich auch vorschlagen, den Block Rahmenart und Art der Darstellung rauszuschmeißen und es wie tramkatze zu machen. Also einfach nur Auflistung der Linien und allgemeine Umsteigesymbole.

Wie die Linie dann konkret angezeigt wird, kann dann jede Anzeige selbst entscheiden. Was meinst du, Nutzer 5.158 ?

Schwierig. Wenn nämlich die Option rausfliegt, kann z.B. meine Anzeige, wie oben etwas angeschnitten, nicht mehr entscheiden, welche Darstellungsart (Symbol oder Block bzw. Rahmen) verwendet werden soll. Ich bin dafür, dass beides drin bleibt und die jeweilige Anzeige dann je nach Konfiguration entscheidet, ob es das anzeigen kann oder auf einen Backup-Fall springt und die Nutzereingabe "ignoriert".

Quote from Nutzer 5.158

Also in der aktuellen Umsetzung vom Parser wird die Farbe der Liniennummer sowieso, wie auch alle anderen Farben, direkt als eine 32Bit-Ganzzahl gespeichert. So kann jede Anzeige separat entscheiden, wie es mit den Daten umgeht. Und in deinem Fall kann aus der Farbvariable der Alpha-Wert ermittelt werden, sodass die Anzeige trotzdem die schwarz-weiße Liniennummer handhaben kann.

Generell ging es mir bei meiner Umsetzung auch weniger darum, dass die Liniennummer nur schwarz oder weiß sein kann, ich wollte nur die Variable sparen und in einem Anfall geistiger Umnachtung habe ich mir dann gedacht, dass ja keiner eine graue Liniennummer wolle und man die Farbe dann gleich als Boolean (wenn auch mit Integer-Wert) eingeben kann. Gegen eine farbig einstellbare Liniennummer habe ich nichts, das bisherige ist einfach nur eine komische Spezialität meiner Anzeige.

Quote from Nutzer 5.158

Am Ende soll der Standard nur alle relevanten Möglichkeiten abdecken, die der Display-Ersteller braucht/brauchen könnte, damit nicht jeder sein eigenes Püppchen kochen muss.

Und welcher Hintergrund am Ende angezeigt wird, ist eigentlich egal. Solange in der Dokumentation der jeweiligen Anzeige erläutert ist, welche Standard-Funktionen unterstützt werden und welche nicht, sollte es kein Problem darstellen.

Funfact: Ein Farbverlauf ist tatsächlich auch vom FIS-Ersteller einsetzbar. Zurzeit kann über die spezielle FIS eine Auflistung mit Startfarbe, Endfarbe und Richtung übergeben werden und über ein "zusätzliches" Script wird das dann auf die Textur gemalt. Selbstverständlich werden Parser und Hilfsfunktionen zeitnah für alle bereitgestellt.

Da war meine Aussage tatsächlich nicht sehr durchdacht, das sollte ja eigentlich kein Problem darstellen.
Beim Farbverlauf habe ich auch nicht bedacht, dass sich sowas mit den vorhandenen Funktionen ja eigentlich recht einfach selbst basteln lässt. Einzige Problematik könnten komplexere Grafiken sein, die man als Textur darstellen muss, aber da muss man dann halt Abstriche machen und die Konfigurationsmöglichkeit weglassen.

Quote from Nutzer 5.158

Ein Kompromiss wäre, wenn in den Zusatzstrings der Route oder der Haltestelle mit Verweisen auf vorher definierte Liniensymbole aus den generellen Strings gearbeitet werden könnte. Somit muss einerseits nicht unbedingt alles mehrfach abgetippt werden, anderseits bleibt die Flexibilität, um für Haltestellen/Routen separat Abweichungen/Änderungen vornehmen zu können.

Meinst du damit, dass man die Farben etc. zwar in den generellen Strings festlegt, aber dann in den Routen-/Haltestellen-Strings optional nochmal anpassen kann? Wenn ja, sollte das ja eigentlich machbar sein, auch wenn mir von der Scriptbastelei darum schon jetzt der Kopf dröhnt.

Quote from jamobatv

Wenn es später in die Syntax geht, finde ich die von dir schon sehr gut. Mit den Sachen, die dann noch dazu kommen, würde ich das dann mehr oder weniger 1zu1 übernehmen.

Bitte nicht. Das Problem an meiner Syntax ist, dass sie komplett unflexibel ist und Erweiterungen kaum möglich sind, weil die einzelnen Parameter nicht selbstständig und nicht reihenfolgenunabhängig definiert sind. Entsprechend könnte man für zukünftige neue Funktionen nichts "mittendrin" einbauen und müsste alles hinten dran hängen. Abgesehen davon dürfte das Ganze sehr schnell sehr unübersichtlich werden, wenn man viele Parameter hat, da sie nicht gekennzeichnet sind und nur von der Reihenfolge abhängig gemacht werden. Der OMSI-Script ähnliche Ansatz von Arupa (zumindest für das IBIS, für die MFDs gibt es ja anscheinend noch keine Doku) ist da deutlich sinnvoller, weil man die Reihenfolge der Parameter komplett frei bestimmen kann und zudem viel leichter erkennt, was was bedeutet. Das war mir gestern Abend auch noch nicht so richtig bewusst, aber als ich heute nochmal drüber nachgedacht habe, ist mir das aufgefallen. Damit könnte man dann einfach eine Liste aller möglichen Parameter machen und die Anzeigen lesen die, die sie brauchen, aus und ignorieren den Rest. Auf Anfrage ließen sich neue Parameter einfach hinzufügen, da man sie einfach irgendwo reinbauen kann, wo man will.

In einen OMSI-Script-Stil umgeschrieben sähen meine Parameter so aus:

Und hier nochmal als Bild, falls die Darstellung z.B. auf Mobilgeräten verhunzt sein sollte:

Wer da seine Parameter hinzufügen möchte, möge das gern tun.

Quote from tramkatze

Meinst du damit, dass man die Farben etc. zwar in den generellen Strings festlegt, aber dann in den Routen-/Haltestellen-Strings optional nochmal anpassen kann? Wenn ja, sollte das ja eigentlich machbar sein, auch wenn mir von der Scriptbastelei darum schon jetzt der Kopf dröhnt.

Jo genau!

Die Scriptbastelei kannst du dir (zum Teil) sparen. Angedacht ist es auch einen Standard-Parser bereitzustellen, welcher das Einlesen der PISSP und die Verarbeitung zu einer bestimmten Datenstruktur übernimmt. Der Ersteller der jeweiligen Anzeige muss "nur" noch noch aus der Datenstruktur nach Bedarf die Daten "entnehmen" oder wie bei den Farbübergängen separat mitgelieferte Funktionen aufrufen - so grob wie bei den Sonderansagen.

Quote from tramkatze

In einen OMSI-Script-Stil umgeschrieben sähen meine Parameter so aus:

Sieht schon deutlich besser aus als die andere Variante

Wir haben uns (auch wieder zum Teil ^^) an dem INI-Datei-Standard orientiert und dabei kam folgendes für die generellen Zusatzstrings raus:

Würde mich für Feedback freuen, bin noch nicht 100% damit zufrieden

Wie wäre es mit TOML?

Quote from Teneberus

Wie wäre es mit TOML?

Jo, warum eigentlich nicht? Ist keine größere Abweichung zum IST-Stand und sieht auf dem ersten Block (genau Block :facepalm) etwas geeigneter aus.

Ich würde dann soweit alle Ideen aus diesem Thread zusammenfassen, das Ergebnis hier posten und und danach das Script darauf anpassen.

Btw. falls jemand noch heimlich im Hintergrund an einer Anzeige arbeitet und sich auch beteiligen möchte, sollte nicht mit einem Post hier zu lange geartet werden, um rechtzeitig von Anfang an im Standard berücksichtigt zu werden.

Quote from Gegreenpeaced

Entschuldigt wenn ich jetzt nochmal dazwischen funkte. Das Thema Standartisierung von Schriftzeichen ist erstmal abgelehnt/vertagt oder?
Ihr hattet euch dazu nur nicht geäußert, deswegen frage ich nochmal nach.

Das sollte eher Extern standardisiert werden. Sobald so ein Standard existiert, kann eine Option zur Auswahl der Zeichenliste hier ergänzt werden.

Wichtig dafür wären, wie du schon geschrieben hast, die jeweiligen Gruppen der Zeichen und die darin enthaltenen Zeichen aufzulisten, um das zu vereinheitlichen.

edit: tramkatze was bewirkt eigentlich [circle_line] bei dir?

Quote from Nutzer 5.158

was bewirkt eigentlich [circle_line] bei dir?

Wenn das aktiv ist, wird der Index der folgenden Route rausgesucht und die Anzeige geht "fließend" über, d.h. nach der Endhaltestelle werden direkt die nächsten Haltestellen angezeigt und die Anzahl der angezeigten Haltestellen bleibt immer gleich. Lässt sich, wie der Name schon sagt, für Ringlinien verwenden, wo es keine klare Endhaltestelle gibt, damit die Anzeige nicht an der letzten Haltestelle der Liste "aufhört". Hat so kein reales Vorbild, aber ich würde davon ausgehen, dass es so gehandhabt werden würde.

Hab mir TOML jetzt genauer angeguckt und einige Konzepte übernommen, aber auch nicht alle, da es vermutlich zu "overkill"* wäre.

Hier die angekündigte Zusammenfassung:

- Kommentare beginnen mit # (//, % oder Semikolon)*

- Farben werden entweder im Binär- (falls jemand Bedarf hat), Dezimal- oder Hexadezimalsystem angegeben und jeweils für den roten, grünen und blauen Farbkanal von 0-255.

- Eingaben im Binärsystem haben den Präfix "0b" und beinhaltet je Farbcode 8 Bit (00000000-11111111)

- Eingaben im Hexadezimalsystem haben den Präfix "0x" und beinhalten je 8 Bit (00-FF)

- String-Eingaben erfolgen mit Anführungsstrichen -> "Ich bin ein String"

- Strings über mehrere Zeilen mit """

- Gleitkommazahlen werden wie folgt verwendet -> 0.5

- Zuweisungen sollten mit = durchgeführt werden, können notfalls auch mit einem Doppelpunkt oder := erfolgen

- Alle Blöcke sind freiwillig und müssen nicht verwendet werden.

- Sollte eine Anzeige bestimmte Blöcke nicht unterstützen, werden diese einfach ignoriert

- Farbblöcke und -schlüssel sollten als col, können aber notfalls als color oder colour, geschrieben werden

- Die Reihenfolge der Keys und Blöcke ist nicht unbedingt relevant

- Die Groß- und Kleinschreibung ist auch nicht relevant, sollte aber im UpperCamelCase erfolgen

- Unterstriche, Striche etc. können, aber müssen oder sollten eher nicht in den Blöcken und Keys verwendet werden

- Alle Blöcke können in allen Zusatzstrings verwendet werden (Falls jemand aus irgendwelchen Gründen irgendwelche Eigenschaften im nachhinein ändern möchte)

Sollte hoffentlich alles sein. Falls ich etwas vergessen habe, oder noch weitere Ergänzungen bestehen, bitte mitteilen

Alles in allem sieht das schon sehr gut aus. Paar Sachen noch:

Quote

CharacterSet = "German" # Welcher Zeichensatz verwendet werden soll -> Gibt bisher keinen richtigen Standard

Warum wäre das relevant für die Anzeige? Der Font wird ja sowieso das darstellen was er darstellen kann, und an den Einträgen in der FIS ändert diese Deklaration ja nichts. Sollten sich darin im Font nicht vorhandene Zeichen befinden, werden die eben entweder ausgelassen oder der Anzeigenentwickler legt Ersatzzeichen fest. Eine Standardisierung der verfügbaren Zeichen wäre sicherlich sinnvoll, aber das hat dann ja nichts mehr mit der FIS zu tun.

Quote

[System_BG_Col] # System-Hintergrundfarbe (z.B. Titelzeile etc.)

ColorTransition = [222022069, 054035124, false, 0.5] # [StartColor, EndColor, Vertical, midpoint]

[System_FG_Col] # System-Vordergrundfarbe (z.B. Titelzeile etc.)

Color = 0x073777

[Row_Divider_Col]

ColorTransition = [222022069, 054035124, false, 0.5] // [StartColor, EndColor, Vertical, midpoint]

Display More

Diese Unterteilung in Vordergrund, Hintergrund und Row Divider (was auch immer das genau ist) finde ich etwas fragwürdig, da sie bei manchen Anzeigen zutreffend sein dürfte, bei anderen allerdings nicht. Ich würde vorschlagen, hier nur "Farbe 1", "Farbe 2" und "Farbe 3" zu definieren und es dem Ermessen der Anzeigenentwickler zu überlassen, welche Farbe jetzt was einfärbt.

Quote

ContentID = [955234783, 955234783] # Werbung 1 + 2 als Integer-Array

Verstehe ich das so richtig, dass man hier "beliebig" viele IDs in das Array (die eckigen Klammern) eintragen kann? Bin mir nur nicht ganz sicher, weil hier beide IDs gleich sind.

Quote

Ankunftsgleis (Sollte eigentlich aus dem Fahrplan auslesbar sein)

Kann durchaus sein, allerdings sind die Gleisnamen von Map zu Map unterschiedlich und manche Entwickler fügen z.B. die Bezeichnung "Bahnsteig" mit in den Gleisnamen hinzu, was dann potenziell unpraktisch aussieht. Wenn ich wüsste wie man den Gleisnamen ausliest, könnte man das allerdings natürlich als Alternative anbieten.

Abgesehen davon gibt es von meiner Seite keine Einwände mehr und man könnte von mir aus jetzt damit beginnen, einen Script-Parser zu schreiben, das ganze in die Anzeigen einzupflegen und die Dokumentation hübsch aufzuschreiben.

Quote from tramkatze

Warum wäre das relevant für die Anzeige? Der Font wird ja sowieso das darstellen was er darstellen kann, und an den Einträgen in der FIS ändert diese Deklaration ja nichts. Sollten sich darin im Font nicht vorhandene Zeichen befinden, werden die eben entweder ausgelassen oder der Anzeigenentwickler legt Ersatzzeichen fest. Eine Standardisierung der verfügbaren Zeichen wäre sicherlich sinnvoll, aber das hat dann ja nichts mehr mit der FIS zu tun.

Hatte ich jetzt auch nur aufgenommen, damit es nur untergeht. Aber hast schon recht.

Quote from tramkatze

Diese Unterteilung in Vordergrund, Hintergrund und Row Divider (was auch immer das genau ist) finde ich etwas fragwürdig, da sie bei manchen Anzeigen zutreffend sein dürfte, bei anderen allerdings nicht. Ich würde vorschlagen, hier nur "Farbe 1", "Farbe 2" und "Farbe 3" zu definieren und es dem Ermessen der Anzeigenentwickler zu überlassen, welche Farbe jetzt was einfärbt.

Wenn die Farben einfach nur durchnummeriert werden, könnte es passieren, dass bei bestimmten Anzeigen die in der PISSP eingestellten Farben sich überschneiden bzw. zu Unschönheiten führen. Also wäre es schon sinnvoll, die "Farben" konkret zu bezeichnen.

Wie wäre es, wenn mehrere zur Verfügung stehen und jede Anzeige sich dann das zieht, was es braucht?

z.B.:

- Title_Bar_Color (mit BG_Color und FG_Color als Key)

- General_Color (mit BG_Color und FG_Color als Key)

- Divider-Color (Trennstriche zwischen den Zeilen)

- Terminus_Color (mit BG_Color und FG_Color als Key)

usw.

edit: die Auflistung wurde ein bisschen optimiert.

Zudem sollte es dem Parser egal sein, ob col, color oder color verwendet wird

Quote from tramkatze

Verstehe ich das so richtig, dass man hier "beliebig" viele IDs in das Array (die eckigen Klammern) eintragen kann? Bin mir nur nicht ganz sicher, weil hier beide IDs gleich sind.

Genau, da ist wohl beim Kopieren etwas schief gelaufen - sollen zwei bzw. beliebig unterschiedliche IDs sein

Quote from tramkatze

Kann durchaus sein, allerdings sind die Gleisnamen von Map zu Map unterschiedlich und manche Entwickler fügen z.B. die Bezeichnung "Bahnsteig" mit in den Gleisnamen hinzu, was dann potenziell unpraktisch aussieht. Wenn ich wüsste wie man den Gleisnamen ausliest, könnte man das allerdings natürlich als Alternative anbieten.

Guter Einwand! Platform bleibt drin und wer es nicht braucht, nutzt es ,wie bei den anderen Sachen auch, einfach nicht ;D

Quote from tramkatze

Abgesehen davon gibt es von meiner Seite keine Einwände mehr und man könnte von mir aus jetzt damit beginnen, einen Script-Parser zu schreiben, das ganze in die Anzeigen einzupflegen und die Dokumentation hübsch aufzuschreiben.

Perfekt, dann geht es voraussichtlich morgen mit dem Parser los. Letzter Aufruf für Flug.... ähh Feedbackgeber.

Wer noch seine Wünsche und Anregungen einbringen möchte, sollte es heute tun. Alles andere wird dann erst mit späteren Versionen des Standards eingebracht.

edit: hab die Auflistung oben nochmal etwas angepasst und TOML-Tables integriert, um die Arrays übersichtlicher zu gestalten