Build 5552 Problem mit Kompaktsignalen

Ich habe das selbe Problem. Auch der IC2000 wird mit der selben Fehlerquelle benannt.

Die angegebene Datei mit z.B. Notepad++ öffnen und als UTF-8 wieder abspeichern.

Bringt (zumindest bei mir) nichts, die Dateien sind definitiv alle in korrektem UTF8, auch ein neues Abspeichern bringt nichts. Ist ein Bug, der mit dem TF 5552er Build eingeflogen ist...
Es sind denke ich irgendwelche Zeichen, mit denen TF Probleme hat, anders kann ich es mir nicht erklären, denn manche Dateien werden anerkannt, manche nicht.

Ich hatte ja schon mal festgestellt, dass Thai z.B. nicht korrekt angezeigt wird in TF. Nur Kästchen kamen.

Ich habe eben auch die Datei bei mir mal durchgeschaut. Ist in ANSI abgespeichert im Original bei mir. Jedoch ist die Kodierung bei diesen Zeichen exakt die selbe wie die entsprechenden Zeichen im UTF-8-Format... (ohne Garantie - ist grad aus dem Kopf)

Ich habe alle Mods mit TFMM installiert, da werden die betroffenen info.lua und strings.lua explizit im UTF8 Format erstellt, oder halt vom Mod übernommen, falls sie existieren.

Ich habe dann jetzt alle mods manuell entfernt (einfach aus dem Ordner ausgeschnitten) und einzeln per Hand wieder eingefügt. Die meisten nimmt TF an, bei einer Datei hat es dann schließlich gemeckert. Die betroffene Datei mit notepad++ geöffnet, sie ist ganz normal in UTF8 w/o BOM gespeichert. Neues speichern (per N++) sowohl mit als auch ohne BOM führt immer zum Absturz von TF.

UTF8 und ANSI sind für alle normalen lateinischen Buchstaben identisch, Umlaute und Sonderzeichen sind unterschiedlich, und natürlich hat UTF8 zusätzlich viele Zeichen, die bei anderen Kodierungen nicht existieren.

Bei weiterem Testen: Bei manchen Dateien, die vorher als ANSI abgespeichert waren hilft ein neu speichern als UTF8.

P.S.: Nachdem ich jetzt mehrmals die Dateien in einen temporären "mods_" - Ordner verschoben und wieder zurückgeschoben habe nimmt TF zumindest jetzt im Moment alle meine installierten Mods ohne Meckern an, ich versteh nichts mehr

Ich weis nicht, wie. Ich finde die Dateien nicht mal.

Der Pfad wird Dir in der Fehlermeldung angezeigt @Thorsson. Rein theoretisch (laut Fehlermeldung) sollte ein speichern der betroffenen Datei als UTF8 helfen.

Das speichern hilft nicht immer. Ich hatte in der Datei teilweise so komische Zeichen stehen. Einfach ändern, dann gehts..

@DerLukas: Beim Laden der Datei versucht N++ das Encoding selbstständig zu erkennen. Wenn es ein fehlerhaftes Encoding erkannt hat (oder gar keins), können solche Zeichen auftauchen. Dann kann man mittels des "Encoding"-Menüs selber ein Encoding festlegen. Hierbei wird die Datei nicht verändert, sondern nur mit einem anderen Encoding interpretiert. Sind Sonderzeichen im ANSI-Encoding in der Datei, und man ändert das Encoding einfach auf UTF8, veruscht N++ die Zeichen als UTF8 Zeichen zu lesen, was fehlschlägt und die Zeichen aus deinem Screenshot werden angezeigt. Wenn man die Datei nun speichert, bleiben diese fehlerhaft codierten Symbole weiterhin in der Datei.

Wenn man das Encoding selber ändern möchte, muss man die Optionen unterhalb des Trennstrichs nutzen (Convert to...). Dann werden alle Zeichen sowie sie aktuell dargestellt werden in das neue Encoding umgewandelt.

Also könnte man hier zB auch eine Datei, die zwar als UTF8 markiert ist, aber ANSI-Zeichen enthält erst als "ANSI" laden, dann mittels "Convert to UTF8" umwandeln und wieder speichern.

Edit: Wichtigen Inhalt hervorgehoben.

Ja, habs grad auch festgestellt Danke!

Das ist/wird ja lustig...
Habe hier sehr, sehr viele Gebäude- und Fahrzeug-Mods. Und der "gedit" meines Ubuntus stimmt mit TF bei den angemahnten Dateien überein, daß diese nicht UTF-8, sondern Windows-Ansi sind.
Es scheinen doch einige/sehr viele Mods betroffen. Hat da schon jemand einen Überblick?
Habe nach 10 "korrigierten" Dateien schon keine Lust mehr, da Ende nicht absehbar.

Ich glaube, da muss UG nochmal drüber nachdenken.

Ich kopiere mir erstmal mein Backup zurück...

PS: Und ich dachte damals bei Einführung von Unicode, dieses Codepage-Gefrickel hat ein Ende. Aber nein, der Weltmarktführer für Qualitäts-Desktop-Software hat als Standard auf seinem OS doch lieber sein Fenster-Ansi. Ist doch egal, was der Rest der Welt benutzt. Wäre ja sonst zu einfach...

Es ist einfach traurig das mit jedem Patch der aufgespielt wird immer neue Probleme auftauchen. Bei der Anzahl an Mods´s die ich installiert habe ist das ein sehr zeitaufwendiges Unterfangen ohne Garantie das es danach alles funzt incl. Savegame. Nach dem Absturz und der Fehlermeldung bei nun schon 5 Mod´s hab ich es jetzt erst mal aufgegeben weiter zu machen bevor ich die Tastatur an die Wand werfe.

der Patch ist echt super! NICHT!
Gefühlte 40 Datei später, endlich bis in den Ladebildschirm gekommen

Na ich hoffe mal, dass die das schnell beheben, ich will sicher nicht die Dateien von meinen momentan installierten Mods (124) von Hand durchgehen...

Doch, der Fehler ist erklärbar. Die Dateien sind tatsächlich nicht UTF-8, sondern Windows-Ansi. Und Editoren der nicht Windows-Welt, die den Nicht-Windows-Standard UTF-8 benutzen (z.Bsp. Netbeans, GEdit) mahnen dies auch an.
Da die meisten Mods aber in der Windows-Welt entstanden sind und dort nur "Microsoft-Standards" zählen, sollte UG diese Prüfung rückgängig machen. Ich vermute, daß sonst ein Großteil der Mods von den Autoren aktualisiert werden müsste...

Fun fact: ich hab mal testweise einige der angemeckerten Dateien nach UTF-8 konvertiert. Hat leider auch nicht geholfen

Bis aber alle Mods aktualisiert sind dauert es ewig, es haben ja nichtmal alle bedingt nur auf einer Seite die Tür Anim. Oder gar Loadspeed

Zitat von Thargor11

Hat leider auch nicht geholfen

Bei mir schon. Wenn ich einem meiner Editoren sage "speichere UTF-8", dann macht der das auch. TF ist anschließend zufrieden und mosert den nächsten Nicht-UTF-8-Mod an...

Nur ist das keine Lösung, wenn ich das hier lokal für meine Kopien mache...