Fahrzeuglisten im Lexikon

Hallo @BR146, wieder dieser nervige Laie hier, der immer nur blöde Fragen stellt

Diesmal würde ich gerne wissen, wie man deinen Modellister (TFML?) verwendet. Entpacken und Doppelklick auf die *.jar Datei hat mal nicht funktioniert. Und nun?

Öhm . Entpacken & Doppelklick sollte eigentlich gehen .
Normaler sollten sich zwei Fenster öffnen.... Einer davon frägt dich nach dem TF-Ordner...

Hast du Java den installiert (http://java.com/)?

Öhm, ja, war recht lang Minecraft süchtig und hab immer die neuesten 64bit Versionen geholt usw. ...also daran sollte es nicht liegen.
Habs auch ein paar mal versucht, Fenster öffneten sich keine. Hmm. *grübel*

Ja dann sollte es drauf sein... Versuche das Programm mal von der Kommandozeile zu starten mit java.exe -jar "ModelLister v1.4a.jar" und guck mal, ob da was mit dem Fehler kommt....

Beweis, dass es bei mir geht:

Bei mir läuft es ohne Probleme auf Windows 10 (64bit). Ich finde nur das exportierte ein wenig unübersichtlich. Aber vielleicht habe ich auch das mit der Auswahl noch nicht so ganz verstanden.

So. Neuer Tag, neues Glück.
Hab erstmal die allerallerneueste Version von Java gesaugt... und sieh da, es geht.

@fjb hat mit seinem "unübersichtlich" aber leider ein bisschen recht. Aber ich meckere erst, wenn ihr sagt, dass es fertig ist. Bis dahin ist ja sicher noch viel geplant.

Ich habe leider noch einen Fehler gefunden: [from] und [to] haben den selben Inhalt (den von [to]).
Wäre es möglich, dass der Inhalt von name automatisch übersetzt wird (anhand der strings.lua, bzw der .mo(s)), oder ist das zu viel Aufwand?

Och nö. Schon wieder ein Copy-Paste-Bug...

name kann ich mal versuchen zu Übersetzen. Nur weis ich nicht, wie die .mo-Dateien aufgebaut sind. Die könnten Probleme machen. Die Strings.lua dagegen wird wohl machbar sein.

in der strings.lua stehen nur die Übersetzungen fürs Hauptmenü. Fahrzeugnamen und Beschreibungen können damit nicht übersetzt werden.

Zum Aufbau des .mo Dateiformats hab ich auch nichts genaues, aber du kannst die Dateien mit dem Online-Tool gut konvertieren: https://localise.biz/free/poeditor und so vielleicht etwas darüber herausfinden. Die .po Dateien sind dann normale Textdateien.

Oha, habe es eben selber ausgetestet, weil ich das nicht glauben wollte: Nur bei Mods können die Namen per strings.lua übersetzt werden, nicht bei DLCs... . Wieder was gelernt. Also muss ich auch die .mo auslesen...

Medi, die strings.lua muss ich trotzdem lesen wegen den Mods...

@fjb, @YstlDystl: Wie könnte man es eurer Meinung nach übersichtlicher gestalten? Meine GUIs sind meist überladen.

Ich habe hier einen Aufbau der .mo-Dateien gefunden: http://www.gnu.org/software/ge…ual/gettext.html#MO-Files
Muss ich halt selber einen Parser schreiben...

Ich mach jetzt nen Doppelpost, weil neue Version. Ich denk ich bin da in der Modding-Regel drin...

Es werden nun strings.lua und die .mo-Dateien zum Übersetzen von [name] und [desc] herangezogen. Die Ausgabe als BB-Code erfolgt folgend ([desc] geschieht äquivalent):

• [name]blub: Default-Name
• [name=id]Blubberblasen platzen: Name in der Sprache "id", id wie in strings.lua

Es werden immer der Default-Name als auch alle anderen verfügbaren Übersetzungen ausgegeben.

Beispiel: [name=de]TFV (kurz)[name=fr]TGV (court)[name]TFV (short) > Deutsch, Französisch, Default

Außerdem wurde der from-Tag gefixed.

Zitat von BR146

Ich mach jetzt nen Doppelpost, weil neue Version. Ich denk ich bin da in der Modding-Regel drin...

Jupp, bist du Nach 5h Basteln gibt's halt mal auch wichtige Updates

Bezüglich Gui, nicht nur Übersicht, sondern auch Inhalt wär nicht schlecht. Statt gefühlten 50 Reitern, wären zB ein paar Dropdowns sinnvoller (1. Dropdown mit "Straßenfahrzeuge" schaltet nächstes Dropdown frei, wo man dann "Busse" auswählt) wäre zb ein Vorschlag.
In toller selbst-auf-die-schulter-klopf-manier muss ich sagen, dass mein Ösi Modkatalog eigentlich genau das ist, was ich mir vorstelle. Bloß, dass es dann eben ein interaktives Programm sein sollte, wo man Filter setzen kann, usw.
Apropos Filter, nach Ersteller kann man dann wohl hoffentlich auch filtern?

Was das Aussehen und so betrifft, bin ich der Meinung, dass erstmal alle Funktionen funktionieren sollten, bevor man sich darüber den Kopf zerbricht

@BR146: Irgendwie fallen mir die kleinen Fehler immer erst nacheinander auf , ich habe noch zwei bei der Kapazität gefunden:

• Die Kapazitäten sind um den Faktor 2 zu hoch (ich habe ehrlich gesagt keine Ahnung woher das kommen könnte)
• Mit loadConfigs definierte Kapazitäten werden nicht ausgegeben (Infos dazu: http://www.train-fever.com/forums/topic/release-hints/)

Der neue name-Tag gefällt mir gut , habe beim vehiclelist Tag gleich nochmal eine Möglichkeit eingebaut die Sprache der Liste anzugeben: [vehiclelist=lang][/vehiclelist]. Vielleicht mach ich das aber auch noch über JavaScript änderbar.

Zur Programmoberfläche: Es wäre schön, wenn die diversen Einstellungen (Basispfad, ausgewählte Mods/DLCs) irgendwie gespeichert würden, damit man sie nicht jedes mal wieder neu ändern muss. Ansonsten habe ich persönlich mit dem GUI keine Probleme, es sind zwar sehr viele Tabs, aber die Funktionsweise ist ja nicht so kompliziert.
@YstlDystl: Sowas wie den Mod-Katalog kann man damit nur bedingt nachbilden, da ja nur die Mods ausgelesen werden können, die der Nutzer sowieso schon installiert hat. Und dafür die installierten Mods zu durchsuchen war das Programm wohl eigentlich nicht gedacht (obwohl man daraus natürlich so etwas entwickeln könnte, wenn BR146 dazu noch Lust und Zeit hat).

Zitat von Merk

Mit loadConfigs definierte Kapazitäten werden nicht ausgegeben

Oh man... Ich wusste ich hab was vergessen (der Code fehlt dafür komplett - nix mit Überschreiben). Ich habe Seamon hier noch nen Tipp zum Auslesen der Daten gegeben: Balancing-Mod (inkl. Fragen an Nutzer) *Kopf*gegen*Wand*Schlag*

Bie Ursache habe ich bei der Kapazität gefunden. Jetzt muss ich sie nur lösen... (Es ist im Teil, der die Beladung zweier Fahrzeuge bzw. Konfigurationen zusammenführt) Gelöst: Fehler war in meiner Implementierung von Lua-Tabellen.
Ich habe über alle Cargos doppelt iteriert. Und dadurch hatte ich natürlich die doppelte Kapazität (Durch den Fehler hatte ich auch z.B. doppelte Leistung und Zugkraft!!! War also ein richtig großer Bug.)

Changelog
Fixed: Bug, der Werte verdoppelte
Add: loadConfigs-Unterstützung
Add: Ladebalken

GUI: Nein, als Katalog war das nur bedingt gedacht. Es soll nur die Daten der installierten Mods zu einer "Datenbank" zusammenfassen, welche dann bsp. als HTML (also wie eine Website) vorhanden ist. Was ich mir aber auch schon überlegt habe ist, einen Katalog im Programm selber zu integrieren. Und ein Tool, welches den optimalen Zug für die Aufgabe zusammenstellt .
mhhh... Basispfad und ausgewählt Mods speichern . Machen kann ich das, nur muss dann wieder eine extra Datei neben das Tool. Und das wollte ich diesmal eigentlich vermeiden. Aber wenn ihr das wünscht...

Wie wärs mal mit einem JavaFx GUI? Swing ist doch einfach nur schrecklich^^

Ansonsten freue ich mich auf das Endresultat

@BR146: Ich habe jetzt nochmal intensiver gesucht und bin zuversichtlich, dass es beim Lexikon-Export nur noch einen problematischen Fehler gibt. Es wird bei loadingSpeed für Fahrzeuge mit Kapazitäten ein falscher Standardwert genutzt (0 anstatt 1, bei Fahrzeugen ohne Kapazität sollte er wegen der Berechnung bei MUs aber besser 0 bleiben). Ich wäre dann auch dafür den Tag in loadSpeed umzubennen, damit wir auch hier den gleichen Namen wie in der .mdl nutzen, aber das ist natürlich nichts, was die Funktionsweise der Liste stört.

Sonstige Anmerkungen:
Ist eine für eine Multiple Unit benötigte .mdl mehrfach vorhanden, wird für verschiedene Werte der MU über alle .mdls summiert (eigentlich alle Zahlenwerte außer der Verfügbarkeit und der Geschwindigkeit), besser wäre vermutlich nur die Daten der ersten oder letzten .mdl zu nutzen. Allerdings kann man das natürlich auch als Schuld des Nutzers ansehen, daher ist das für mich auch kein kritischer Fehler. Ich hatte z.B. den IC3 zusätzlich zum DLc noch als eigenen Mod, sonst wäre mir das gar nicht aufgefallen.

Fürs Lexikon den path-Tag durch einen image-Tag ersetzen, der bei MUs für jedes Fahrzeug einmal vorkommt: [image=forward,render]UI:
UI: Pfad zum UI-Icon in der Form /(res|dlcs/id|mods/id)/(bus|tram|etc.)/Bildname.png, alternativ einfach den Pfad zum Icon wie jetzt bei path und ich passe den Rest beim Parsen an. Den vorderen Teil des tatsächlichen Pfads auf dem Server trage ich dann direkt ins Script ein.
forward: nur für MUs gedacht (funktioniert dann aber natürlich auch für andere Fahrzeuge), gibt wie der gleichnamige Wert in der .lua an ob das entsprechende Fahrzeug vorwärts oder rückwärts dargestellt werden muss (true/false).
render: gibt es ein Renderbild (true/false), sollte vom Programm standardmäßig nicht gesetz und nur wenn nötig manuell geändert werden

Changelog v1.7a
Fixed: Falscher Default-Wert für Fahrzeuge mit Kapazitäten
Changed: loadingSpeed umbennant zu loadSpeed (Konsistenz mit MDL-Bezeichnungen)
Fixed: Mehrfach vorhandene MDL für Multiple Unit führten zu verfälschten Werten (Werte wurden summiert). Achtung: Verwendete MDL wird zufällig vom Programm ausgewählt (kein Verhalten spezifiziert)!

@Merk: Für den image-Tag muss ich noch paar Daten auslesen. Das kommt in einer späteren Version.

Changelog v1.8a
Added: [image=forward,render]UI hinzugefügt; Merk ich habe mal versucht deine Konvention zu interpretieren . Ich habe aber den Leading Slash weg gelassen. Unnötiges Zeichen . Die Reihenfolge spiegelt die Reihenfolge in der Definition wieder (da bin ich die meiste Zeit dran gesessen ).

ich habe gestern abend mal vit der v1.6a rumgespielt (bei einer GOG-Version). Ich gehe davon aus, dass das anzugebende Basisverzeichnis das TF-rootdirectory ist, also z. B. C:\what\ever\the\path\is\TrainFever. Da rödelt das Script dann ewig rum, ohne irgendetwas zu bewirken und ohne timeout.
Ich probier das heute abend oder morgen nochmal zuhause bei meiner Steam-Installation.