.xml wird fehlerhaft zurückgeserzt

    Als ich die Hebelsensitivität der 474 Plus anpassen wollte, wurde die Datei (und NUR diese) "DBBR474_ThirdRail.xml" nicht korrekt zurückgeserzt. Ich habe genau die gleichen Einstellungen vorgenommen wie bei der "DBBR474.xml", welche korrekt zurückgeserzt wurde. Sobald ich nun aber die besagte Datei zurückserze, mit der Originaldatei austausche und den TS starte, wird der Content nicht geladen. Wenn ich nun die bearbeitete .bin Datei serze, um zu gucken, wo der Fehler liegt, so ist in der nur noch die utf=8-Codierungszeile vorhanden. Das passiert jedes Mal. Die Datei schrumpft zudem auf 1KB.


    Was verändert wurde: Im Container "IrregularNotchedLever", was den Kombihebel meint, wurden die Werte AnalogInputSensitivity und DigitalInputSensitivity beide von 1 auf 0.5 herabgesetzt, was den Kombihebel langsamer zu bedienen macht. Dies funktionierte bei allen anderen .bin-Dateien bisher ohne Probleme. Hat jemand eine Idee?

    @DerHood,


    hast Du die geänderte XML-Datei mal genau auf Logikfehler (irgendein XML-Tag versehentlich kaputtgemacht).
    Ist mir letztens auch bei dem Süwex Mapper passiert...hatte ziemlich am Anfang eine Zeile Versaut und es ging dann ab dem letzten sauberen XML-Tag keine Funktion mehr, die ersten paar im Text haben funktioniert.


    Das wäre zumindest eine Möglichkeit.


    Grüße


    -setter-

    Meist ist der Fehler, daß man mehr als Werte korrigiert hat und z.B. auch eckige Klammern aus versehen löscht.
    Verwende Notepad++ oder einen anderen Editor, der Syntaxhighlighting unterstützt. Dann siehst Du wenigstens, wo der Fehler liegt.


    Für Notepad++ gibt es auch ein wertvolles Plugin ist auch das Compare Plugin http://docs.notepad-plus-plus.…hp?title=Plugin_Central#D . Kann man über den Plugin-Manager installieren. Damit kannst Du 2 Dateien Zeile für Zeile vergleichen. Versuche notfalls nochmal Deine Modifikationen in eine neue Datei zu schreiben (dann machst Du maximal andere Fehler), und vergleiche dann Deine erste und Deine 2. Version.
    Kris

    @120 Ich werds zwar nochmal mit nem anderen Editor ausprobieren, aber ich hab wirklich nur zwei Zahlen ausgetauscht und sehr genau darauf geachtet, nichts anderes anzurühren. Und es ist wirklich danach nichts mehr da, auch nicht die Sachen bis zum veränderten Abschnitt.
    Folgende Zeile (ist die allererste) bleibt übrig.
    <?xml version="1.0" encoding="utf-8"?>
    Das spricht auch gegen @-setter- s Theorie. Ganz merkwürdig. Ich teste das jetzt mal mit Notepad ++ und melde mich dann nochmal.


    Edit: Mit Notepad++ geht´s - auch wenn ich nicht verstehe, warum. Vielen Dank euch beiden ;)

    Der TS verlangt die XML-Dateien kodiert als "UTF-8 without Byte Order Mark".
    Das kann aber nicht jeder Editor, bzw. gibt es Editoren, die die "UTF-8 w/ BOM"-Kodierung beim Öffnen über den Haufen werfen und stattdessen UTF-8 (mit BOM) oder gar ANSI nehmen.
    Und dann ist die XML kaputt (aus Sicht des TS oder der SERZ.EXE).


    Das macht sich besonders dann bemerkbar, wenn man irgendwelche Sonderzeichen in der XML-Datei hat, wie z.B. Umlaute: "äöü".
    Da wird dann in ANSI aus "äöü" dann sowas draus: "äöü".
    Und das bringt die serz.exe aus dem Tritt und erzeugt kaputte BIN-Dateien, die den TS crashen lassen können.


    Überhaupt sind Umlaute immer ganz schlecht in solchen Dateien. Auch wenn wir bereits 2016 haben,... fast 2017... der Spruch ist schon über 20 Jahre alt: Verzichte auf Sonderzeichen in Dateinamen, Passwörtern und allen Arten von Code. Der Spruch gilt auch heute noch.

    Wenn ich euch doch sage es waren nur zwei Zahlen... kein Umlaute, kein nichts. Codierung wurde bei allen anderen bisher bearbeiteten Dateien korrekt beibehalten. Das einzig mögliche wäre tatsächlich dass die Zeilen verrutscht sind. Ab jetzt arbeite ich jedenfalls mit Notepad++ ;)

    Die Sonderzeichen müssen ja nicht deiner Änderung entsprungen sein, sondern können ja schon vorher irgendwo in der XML-Datei gewesen sein.
    Erst dein Speichern mit einer falschen Kodierung (ANSI?) machte dann daraus ein Problem für die serz.exe.


    Aber schön, dass das Problem behoben ist.

    Egal, wie weit Draußen man die Wahrheit über Bord wirft, irgendwann wird sie irgendwo an Land gespült.

    Danke 1