TB TUMA Climbing protection xx Fehler in Version 4.7 (TRS2019 SP2)

  • Guten Mittag,


    Falls jemand ein Problem mit den "tb tuma climbing protection" hat und sich das TRS19 SP2-Update heruntergeladen hat, sollte die folgende Anleitung befolgen, um seine eigene Strecke wieder sinnvoll nutzen zu können:


    1. Die fehlerhaften Objekte anzeigen und sicherstellen, dass die Objekte ein Problem beim Laden von "lochraster_03" hat.

    2. Das Objekt im Explorer deiner Wahl öffnen und die Datei "lochraster_03" mit deiner Bildbearbeitungssoftware öffnen.

    3. Wichtig: Am Bild (lochraster_03.tga) nichts bearbeiten, da sonst etwas anders sein könnte als zuvor.

    Nur das originale Bild als lochraster_03.tga (Titel der Datei) speichern und das "fehlerhafte" Objekt übernehmen.

    Nun sollte es wieder funktionieren!

    (Falls der Content Manager weiter mit "dies und jenes darf nicht im Container sein" nerven möchte, solltet man die jeweiligen Einträge löschen, um das Objekt "freigeben" zu können)


    Falls die Objekte "tb_tuma_climbing protection_18_3", "tb_tuma_climbing protection_18_2", "tb_tuma_climbing protection_18_1" und "tb_tuma_climbing protection_'x'" trotz der "Reparatur" als Fehlerhaft und keine Fehler anzeigt, kannst du dir sicher sein, dass du nicht der Einzige bist.

  • "tb_tuma_climbing protection_18_3", "tb_tuma_climbing protection_18_2", "tb_tuma_climbing protection_18_1" und "tb_tuma_climbing protection_'x'" können weiterhin fehlerhaft sein. Ich habe keine Ahnung, wie ich die Objekte zum Laufen bringen konnte. (Da bei mir kein Fehler angezeigt, aber als Fehlerhaft ausgegeben wurde)

  • Die meldung kommt aber bei allen Objekten, da werd ich wohl weiter mein glück versuchen müssen bis es da wo passt :wacko:.

    Schade wärs, da das System eigentlich gut (wenn auch inzwischen etwas veraltet) ist.:loudly_crying_face:

    mfG Jens

  • Bei allen 4 Objekten ist die Ursache die Datei lochraster_03.tga . Das TGA-Format diese Datei wird anscheinend von TRS19 (nur als Alpha-Maske ?) nicht korrekt verarbeitet. Korrektur mit z.B. Irfanview:

    - Objekt vom ContentManager aus im Explorer Öffnen

    - Datei lochraster_03.tga mit Irfanview öffnen

    - Datei speichern (im Originalverzeichnis), Erstzen erlauben

    - Irfanview beenden

    - Das Objekt im ContentManager wieder übernehmen

    Da die Datei lochraster_03.tga bei allen 4 Objekten gleich ist, kann man die korrigierte Version einfach kopieren. Das Verfahren gilt ebenso für die anderen 4 'climbing protection'-Objekte aus dem Paket.


    Der ContentManager von TRS19 (mit SP2) scheint den Fehlerstatus nicht immer sofort zu aktualisieren (sowohl nach Installation als auch nach Übernehmen). Ein Doppelklick auf den Eintrag des Objektes aktualisiert den Status.


    Peter



    -

  • Hallo Peter!
    Vorweg schöne Grüße und alles Gute sowie viel Erfolg in 2021. Von mir und nach einem Telefonat mit Hartmut (EW). Eine fast lustige Geschichte mit den Weichenlaternen von chwerwick unter Kahlschlag war mit der Auslöser.

    Das Dateien wie
    <kuid:42778:11405> tb tuma climbing protection 12 0 eine derartige fast Katastrophe auslösen können hätte ich nie gedacht. Äußerlich entsprechen diese einer Freihandskizze um Maße einzutragen.
    Zum Update,
    scheinbar ungewollt das RS19 SP2-Update danach war ich ziemlich sauer. Es sind ja nicht nur die Turmmasten. Wie ist das mit den Eigentumsrechten bei Veränderungen? Liegen die immer noch beim Autor, bei Auran oder wenn sich der Autor von Auran zurück gezogen hat?
    Das ist nur eine Frage und nicht ein Vorwurf dir gegenüber. Bin Hoch erfreut das die Masten wieder gebrauchsfähig sind.

    Gruß Klaus :clap::smiling_face_with_halo:

  • Das Problem an den Lochrasterdateien ist, das sie ein falsches Bildfarbformat haben. Ich meine Greyscale statt Truecolor gesehen zu haben was aber mit der alphakanal-Logik von Trainz irgendwie nicht (mehr?) geht. Mit Peters Bescheibung werden sie korrekt umformatiert. Das Problem, das der CM Fehler sehr verspätet anzeigt, hatte er auch schon in der SP1 version. Besonders bei Abhängigkeiten ist das mühsam.

  • Hallo RD65!
    Ich bin mit dir der gleichen Meinung, das die Bezeichnung *.tga für ein anderen Datentyp erschaffen wurde, wenn auch eine Grafik dahinter steht. Eigentlich wären *.bmp oder *.jpg angebracht. Das war auch in den Anfängen bei diesem Simulator der Fall.

    Gruß Klaus :)

  • hm ja nicht ganz... so wie in einem bmp format rle oder plane bitmaps in 8, 16 oder 24/32 bit gespeichert werden können, so gibts in TGA diese Variationen auch.. und noch einige mehr. Tga ist aber wie bmp ein Grafikformat wie jedes andere auch aber es gibt da eben sonderformate wie grayscale bitmaps, welche Trainz eben nicht verarbeiten kann. jpg nutzt loosy compression und ist für sowas absolut ungeeignet zumal es wie rle erst dekomprimiert werden muss. Die Grafikverarbeitung in Trainz ist zu Lasten von Speicher auf maximale Geschwindigkeit ausgelegt. (und das ist gut so!)
    Dann gibts noch einen zweiten wichtigeren Aspekt. In älteren Trainz versionen hat die Engine Dinge einfach nicht gemacht wenn es zu Problemen kam. Die Engine in TRS19 wird inzwischen so abgefangen, das alles was nicht klappt zu einem Fehler gemeldet wird. Ein Beispiel dazu:
    Ein Att Point welcher in der config existiert aber im Mesh nicht, wurde früher einfach ignoriert. Heute meldet das System, das es den Att Punkt nicht findet und verweigert das Laden des Assets. Das Asset wurde nie verändert aber nach 15 Jahren fällt der Engine auf... uh... da gibts was womit ich nicht klar komme also streike ich! Ich bin mir nicht sicher aber sowas wäre auch in Verbindung mit den Grafiken hier möglich. Die brauchen bei Auran im laufe der letzten Versionen nur die "komplizierte" Laderoutine für TGA Grayscalebitmaps abgeschaltet zu haben... und Zack... plöppt das Problem auf. Aber es liegt eben nicht an TGA selbst... man könnte das ganze auch mit rle im BMP Format durchexezieren... wenn man schnell Speicherkompatible Bilder verarbeiten will, muss man eben auf Sonderformate und Compression verzichten. Tatsächlich ist das TGA Grayscale Format hier das effizienteste Grafikformat gewesen... weswegen das Grafikprogramm es vermutlich so gespeichert hat... nur eben nicht das am schnellsten verarbeitbare, wenn man es zusammen mit einem 32 Bit TGA verdengeln will - was Trainz jedoch macht um die Löcher ins Blech zu stanzen. Das eigentliche Problem an der ganzen Geschichte ist, das BMP kein Alphachannel kennt. TGA kennt Alphachannels, aber dafür müsste sich Auran mal aufraffen und das komplette Set für TGA import unterstützen. Und so lange das nicht der Fall ist, "basteln" wir uns eben diese Grafiken mit 2 Dateien ... die aber halt im Aufbau gleich sein müssen. Siehe dort

    (es wäre sogar möglich das inzwischen TGA mit alpha in Trainz funktioniert - ich habs länger nicht probiert. In TRS04, PTB2 und TRS09 ging es meines Wissens nicht.)

    Einmal editiert, zuletzt von rd65 ()

  • Solange das Grafikformat von Trainz unterstützt wird, ist es für die Geschwindigkeit im Spiel (ziemlich) egal. Beim Übernehmen in Trainz werden die Dateien für die Texturen immer in das interne .texture-Format gepackt. Die Originaldateien bleiben dabei erhalten und werden mit gespeichert, aber nicht im Spiel verwendet. Trainz kann den Alphakanal von TGA-Dateien schon mindestens seit TRS2004 verwenden, Dazu enthält die .texture.txt-Datei für Primary und Alpha denselben (TGA-)Dateinamen. Bis TS12 konnte Trainz keine komprimierten TGA-Dateien verarbeiten, ab TANE geht das aber.


    Peter