Fahrzeuglisten im Lexikon

Wir arbeiten da glaub zusammen. BB-Code wird ja im Normalfall vom Server (php) verarbeitet. Ich habe vor, eine "Offline"-Variante* zu bauen, um eben alle Mods in einer Zeitleiste zu haben. Merk macht es für's Forum. Da mein Programm jetzt schon quasi fertig ist im Bereich des Einlesens aller Dateien, kümmer ich mich um das automatische Generieren der Fahrzeugdaten. Ich mach quasi die Datenbank, Merk liest diese wieder aus und gibt es lesbar zurück.

*Internet wird zum Herunterladen der Scripte benötigt

BR146 => Daten auslesen und in ein Metaformat (BB-Code) konvertieren
Merk => Aus Metaformat Lexikonseite erstellen (ist dann mit allen Fahrzeugen prinzipiell möglich)

ups, Beitrag von BR146 gekonnt übersehen

Ich war noch etwas fleißig @Merk:

Habe BB-Code-Export eingepflegt nach Bauchgefühl, habe mich an deinem Beispiel orientiert. Habe noch ein paar Tags erfunden, um alle mir bekannten Infos dir zu geben. Außerdem habe ich, um verschiedene "Sourcen" (also Vanilla, DCL, MOD) zu trennen, den [vehiclelist]-Tag genutzt und durch die Tags [isMod],[isDLC],[modName] und [modVersion] ergänzt.

Außerdem habe den Tag [lifetime] in [lifespan] umbenannt, da das TF-konformer ist (und auch dass es auf Deutsch "Lebensdauer" heist und nicht "Lebenszeit" ).

Beispiel für Trams hängt an.

Ach ja: In Strings sind Zeilenumbrüche mit [br] maskiert, \ maskiert dazu noch \, [ und ].
Beispiel hierfür: Dieser Text \[Farbe: egal\] bricht hier[br]um, aber nicht \[br\] hier. \\Was ist das?\\ bedeutet:

@Merk und meiner einer sind dann auch so gut wie fertig mit der Rendervorlage. Das Packet muss nur noch von mir zusammen geschnürt werden, dann steht einheitlichen Bildern für das Lexikon nichts mehr im Weg

@Merk: Ich habe einen Bug in meiner BB-Code-Datei gefunden. Im Anhang gibt es neue Dateien (Loks, Waggons, Verbände, LKW, Bus, Tram, KI-Fahrzeuge). Außerdem habe ich die Tags [power] (Gesamte installierte Leistung) und [tractiveEffort] (max. Zugkraft) eingeführt. Hier noch der Hinweis: Der Tag [engine] kann mehrfach auftauchen (z.B. Multiple Unit mit Dampflok und Diesel-Schiebelok oder ähnliches), ebenso der Tag [cargo=160]name (Zahl gibt Frachtmenge an, name das Gut).

@Grimes: Ja da warte ich schon drauf .

Da scheint noch was schiefgelaufen zu sein, [name] hat den selben Inhalt wie [desc]. Dezimalzahlen wenn möglich auch bitte mit '.' ausgeben und nicht ',', es wäre möglich, dass wir die Kommas für was anderes brauchen.
Ich denke aber auch, dass wir fürs Lexikon nur die nötigsten Infos ausgeben sollten, die Beschreibung ist z.B. fürs Lexikon etwas zu viel (dann brauchen wir vermutlich auch keinen [br]-Tag). Meine Vorschläge:

• [name]
• [image] müsste beide Links zu den Bilder enthalten (UI und Render), könnte man vielleicht anhand von [path] bestimmen, oder einfach manuell eintragen. Zum genauen Aufbau überlege ich mir nochmal was.
• [type], hier müssten wir uns dann eine einheitliche Liste der möglichen Einträge überlegen: (BUS, TRUCK, TRAM, TRAIN_STEAM, TRAIN_DIESEL, TRAIN_ELECTRIC, WAGON_PASSENGER, WAGON_GOODS, MU)? KI-Fahrzeuge würde ich auf jeden Fall weglassen, da sie fürs Gameplay nicht wirklich relevant sind und auch kaum Daten haben.
• [from], [to]; sollte einer ober beide in der lua nicht vorhanden sein, würde ich sie auch hier einfach weglassen
• [costs], [running_costs], [lifespan]
• [weight], [topSpeed], [power], [tractiveEffort]; die einzelnen Engines sind mMn fürs Lexikon zu viel
• [loadingSpeed], [cargo]; über den genauen Aufbau des Cargo-Tags muss ich mir nochmal ein paar Gedanken machen. Wenn ich es hinbekomme, den, so wie er ist, ohne größere Problem zu parsen, können wir ihn aber gerne auch so verwenden.
• [color] nur für die Timeline, gibt die Farbe des Balkens an. Wenn nicht gesetzt, wird die Standardfarbe für den Fahrzeugtyp genutzt.

Die Mod bezogenen Sachen würde ich im Lexikon so eher nicht verwenden. @mediziner und ich waren der Meinung, dass es für die Übersichtlichkeit besser wäre, für das Originalspiel und die DLCs jeweils eine eigenen Seite zu machen, dafür dann aber dort alle entsprechenden Fahrzeuge zu haben.
Eventuelle Listen für Mod-Fahrzeuge müsste man dann am besten nach Länder oder so aufteilen. Hier könnte ich mir auch noch einen [author] und [download]-Tag vorstellen.

@BR146

Da du in deinem Programm ja mehr TAGS anlegst, als Merk benötigt, ich und Medi denke ich mal auch, bräuchten ein TAG für die BoundingBox um die Kapazitäten automatisch anzupassen. (+X + (-x*-1)) =

@Merk: die Liste schau ich mir mal morgen nochmal an. Dafür bin ich gerade nicht mehr fit genug. Nur eines: für type würde ich "BUS, TRUCK, TRAM, TRAIN, WAGGON, MU" vorschlagen, für den Antrieb einen vereinfachten engine-Tag mit den Werten "HORSE, STEAM, DIESEL, ELECTRIC". Ob es Passagiere oder Güterwägen sind läst sich ja aus cargo bestimmen. Und danke für die Bug Info.

Uff... ihr wollt die BoundingBox haben? Heißt ich muss die Meshs auch noch laden... Gut machbar ist es, hab's ja schon für den SignalMaker getan (dort wird auch die BoundingBox benötigt).

Die "BB" steht doch in der MDL, der Hinweis war nur das man +X und -X addieren muss. Mesh auslesen bräuchte man nicht.
Anmerkung zu den Kapazitäten für N-DLC hat Medi ja erwähnt.

Wenn er den Mesh ausliest ist es zwar genauer, Problem könnte aber eine MDL mit Multimesh werden.

Ich sollte schlafen gehen... Die BoundingBox steht ja in der mdl Dann ist das kein Ding und in 30min drinnen... Auslesen , Variable, Getter, MU Verarbeitung und Export...

Nicht bei jedem Model ist eine BoundingBox in der MDL eingetragen

@BR146: Okay, ich denke das lässt sich bei mir einrichten, nur eine Sache noch zum Cargo-Tag: Wie wäre es mit [cargo=passengers]130 anstatt [cargo=130]passengers? Fürs Parsen ist mir das eigentlich egal, aber ich denke falls jemand einen Eintrag manuell erstellt ist das intuitiver ([cargo=type]value).

1. [name]-Bug behoben
2. [cargo=passengers]130 ist machbar
3. Dezimalzahlen mit '.': Okay, kann ich machen.
4. BoundingBox merke ich mir mal vor. Ich denke Merk, dass wäre für's Lexikon evtl. auch interessant als [length]-Tag.
5. [color] und wie soll ich die bestimmen
6. [image] gib mir eine Konvention und ich versuche mein Bestes.

Zitat von DarkMo

Da das wohl auf meinem Mist wuchs

Nein, den [color]-Tag wollte mediziner haben, bzw. sind wir zu dem Schluss gekommen, dass eine Standardfarbe nach Typ mit dieser individualisierungsmöglichkeit ausreichen sollte. Da er optional ist, muss das Script den Tag meiner Meinung nach auch nicht unbedingt generieren. Allerdings finde ich den Vorschlag auch nicht schlecht.

In Sachen Mehrfarbigkeit müsste ich mal recherchieren, was CSS da für Möglichkeiten bietet.

Zitat von BR146

4. BoundingBox merke ich mir mal vor. Ich denke Merk, dass wäre für's Lexikon evtl. auch interessant als [length]-Tag.

Ist Script-technisch kein Problem, ich muss mir nur noch überlegen, wo ich die ganzen Infos in der Tabelle unterbringe, mehr als die bisherigen acht Spalten sollten es besser nicht werden (Übersichtlichkeit auf kleinen Bildschirmen).

Zitat von BR146

6. [image] gib mir eine Konvention und ich versuche mein Bestes.

Da müssen wir nochmal im Team besprechen wo die Bilder abgelegt werden sollen, aber ich würde sagen auf jeden Fall in der Art [image=Render]UI, wobei Render und UI sich jeweils aus einem noch zu bestimmenden Basispfad, entweder res, dlcs/"id" oder mod/"id" und dem Namen des UI-Icons mit der Endung .png zusammensetzen sollten. Dann bräuchte man dafür fast nur Infos die bis jetzt in [path] drinstehen.

Hallo

Zitat von Merk

In Sachen Mehrfarbigkeit müsste ich mal recherchieren, was CSS da für Möglichkeiten bietet.

Ich denke mal, background-image mit linear-gradient oder repeating-linear-gradient (ebenda) sind deine Freunde. Die Unterstützung in den relevanten Browsern ist jedenfalls mehr als ausreichend.

Tschö, Auge

Hey Merk.

Ich habe noch einen "Einwand" zum type. Wie sollen TRAIN und WAGGON unterschieden werden? Nach der "Typdefinition" von TF gibt es nur BUS, TRUCK, TRAM, TRAIN (MU geb ich dir extra dazu, wenn's sein muss auch WAGGON). Aktuell unterscheide ich dazwischen durch power > 0.

Ich hätte jetzt gesagt alle Züge ohne Engine sind Wagen (kommt vermutlich aus Gleiche raus wie power = 0), ich glaube so macht das TF im auch Kauffenster.
Für den vereinfachten [engine] Tag würde ich dann übrigens immer die "beste" Antriebsart nehmen, wenn es mehrere gibt, also bei HORSE und STEAM -> STEAM, bei STEAM und DIESEL -> DIESEL, bei STEAM und ELECTRIC -> ELECTRIC, usw.

Edit: Was [color] betrifft: Der Wert wird wohl wirklich nur gebraucht, wenn jemand unbedingt die Farbe eines bestimmten Fahrzeugs in der Timeline änder will. Standardmäßig werde ich mich wohl an dem System von @DarkMo orientieren und bei mehreren Farben den Balken mit Streifen versehen (Danke fürs Raussuchen der CSS-Eigenschaft @Auge). Wenn aber [color] gesetzt ist, wird der Balken nur in der damit angegebenen Farbe gezeichnet.

Edit2: Weitere Farbvorschläge für die verschiedenen Fahreugtypen (Bus, LKW, Tram, Dampf/Diesel/E-Lok, etc.) und Frachtarten sind willkommen.

Hier das aktuelle Programm, mit Exportdaten. Ich hoffe die sind so genehm. Und ich habe nochmal das mit den Wägen geschaut: Es sind für mich dann Wägen, wenn kein Engine vorhanden. Und das mit der "besten" Antriebsart habe ich schon so implementiert gehabt bevor du geschrieben hast - wir verstehen uns also.