Beiträge von Xanos

Wenn man nicht konvertiert, sondern die selbe Datei einfach wieder als "UTF-8" speichert, ändert sich natürlich nichts an den bits in der Datei und damit auch nichts an den falschen Symbolen. Ich kann auch gerne noch ein mal hier drauf verweisen, dort habe ich es bereits für den Fall von N++ erklärt: Build 5552 Problem mit Kompaktsignalen

http://www.train-fever.net/ind…n/?postID=47942#post47942
Ergänzung / Erklärung:
Wie alles im PC bestehen auch Textdateien (zu denen lua auch gehört) aus einer Folge von bits. Diese bits repräsentieren die Buchstaben, die dann schließlich angezeigt (oder intern von TF ausgewertet) werden. Das Encoding legt dabei fest, wie die Bitfolge, zur einfacheren Lesbarkeit oft als Hexadezimalzahl dargestellt, in einzelne Symbole übersetzt wird. Das bekannte ASCII-Format umfasst hierbei die Codierungen für den hexadezimalen Bereich 00 bis 7F (Dezimal 0-127). In diesem Bereich sind ANSI und UTF-8 Symbole identisch. Das heißt ein "A" wird sowohl in ANSI als auch in UTF-8 als eine hexadezimale 41 codiert. Ein "ü" hingegen liegt nicht im ASCII-bereich und wird in ANSI durch FC repräsentiert , während es in UTF-8 als C3 BC gespeichert wird.
Train Fever erwartet nun, dass alle Symbole in der Datei UTF-8 kodiert vorliegen. Erscheint nun auf einmal die Bitfolge, die FC entspricht (einem mit ANSI kodiertes "ü"), wird das Symbol falsch interpretiert.

Wenn man eine ANSI-Datei als UTF-8 öffnet, oder auch eine UTF-8 kodierte Datei mit einem angenommenen ANSI-Encoding öffnet, werden nur die Symbole aus dem ASCII-Bereich richtig angezeigt. Alle anderen Symbole (inklusive deutscher Umlaute) werden falsch interpretiert. Einfaches abspeichern einer ANSI-Datei als utf-8 hilft hierbei nicht, solange beim Speichervorgang nicht auch alle Buchstaben richtig codiert abgespeichert werden. Der Texteditor muss also das ü als ANSI lesen (FC) und dann in der Datei als UTF-8 C3 BC wieder speichern. Um diese Umwandlung zu erzwingen, kann man bei Notepad++ zum Beispiel aus dem "Encoding"-Menü die "Convert to..." Optionen nutzen. (Siehe hier unbedingt meinen obigen Link)

Das BOM am Anfang der Datei wurde ursprünglich für UTF-16 und UTF-32 eingeführt. Hierbei geht es um die - wie der Name (Byte Order Mark) schon verrät - "order" - also Reihenfolge, oder "endianness" - sprich ob zuerst die höherwertigen oder zuerst die niederwertigen Bytes gespeichert wurden. Dies ist wichtig, da bei UTF-16 und 32 alle Symbole stehts aus mehreren Bytes bestehen, und die Reihenfolge der Bytes nicht fest ist, sondern eben durch die BOM festgelegt wird. Wenn ein Editor am Anfang der Datei ein BOM findet, kann er dadurch die Kodierung bestimmen. Bei UTF-8 gibt es keine Byte Order, trotzdem kann hier ein BOM eingefügt werden. In dem Fall ist das BOM nur ein Hinweis, dass hier UTF-8 genutzt wurde. Ein BOM ist bei UTF-8 aber nicht zwingend. Auch bei einem fehlenden BOM kann man anhand des Inhalts aber zwischen UTF-8 und ANSI unterscheiden, falls Symbole genutzt werden, die nur in einem der beiden Kodierungen definiert sind. Grundsätzlich leben wir ja nicht mehr in der Steinzeit und Unicode, zB das oft genutzt UTF-8 sollten Standard sein, auch wenn kein BOM darauf hinweist. Bei einigen Windowsprogrammen (vor allem den älteren) ist dies aber noch nicht so ganz angekommen.

Train Fever erwartet immer UTF-8 Dateien, d.h. man braucht kein BOM einfügen, da dies ja nur eine folgende UTF-8 Kodierung angeben würde, die von TF ja eh bereits erwartet wird. Man sollte als Modder eben nur darauf achten, Dateien UTF-8 kodiert zu speichern oder nur ASCII-Symbole zu verwenden, denn wenn nur ASCII-Zeichen verwendet werden und kein BOM eingefügt wird, gibt es keinen Unterschied zwischen einer ANSI und einer UTF-8 kodierten Datei.

Unicode sagt dazu:

Zitat von The Unicode Standard 5.0, Chapter 2: General Structure - Page 36

Use of a BOM is neither required nor recommended for UTF-8, but may be encountered in contexts where UTF-8 data is converted from other encoding forms that use a BOM or where the BOM is used as a UTF-8 signature

Wie bei allen Daten, sollte man einfach vorher festlegen, wie sie ausgetauscht werden. Bei den meisten Dateiformaten wird dies ja durch irgendwelche Flags, Konventionen, Formatversionen, etc... festgelegt. TXT ist "leider" so ein einfaches, Format, dass hier der Editor meist selbst mit der Codierung klar kommen sollte. Ein BOM ist bei UTF-16 und UTF-32 wichtiger, bei UTF-8 würde es nur allgemein kennzeichnen, dass UTF-8 überhaupt vorliegt. Bei TF muss die Datei aber per Definition eh in UTF-8 kodiert sein, also ist ein BOM redundant, sollte aber nichts an der Lesbarkeit ändern.

@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.

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

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

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.

Zitat von Revyn112

Added UTF-8 check for resource files

Bei mir hat er einige eindeutig als utf8 gespeicherte Dateien nicht korrekt erkannt... Da warte einfach auf den nächsten Patch, der ein neues Feature mal wieder sauber patcht

Meine Meinung:
Allgemein sollten ein Programm nicht nur mit Fehlermeldungen um sich werfen sollte sondern auch immer in der Lage sein sollte, sich selbst aus Fehlersituation zu retten, ohne abzustürzen... gehört zum Guten Ton, wenn ein Programm erstens im Hintergrund versucht, Fehler selbst zu bereinigen, dem Nutzer dafür Warnungen ausgibt, und nur im Zweifel sagt: hey, da kann ich leider nichts machen. In dem Fall (wenn angeblich eine mod-ressource fehlerhaft ist) sollte aber nur der Mod nicht nutzbar sein, statt das ganze Spiel ins Nirvana zu schicken!!! Das selbe fordere ich ja auch seit der Beta bereits im allgemeinen zB für das Laden von Spielständen: Fehlt eine mdl, dann wird sie halt nicht geladen, das Objekt fehlt also einfach im Spiel -> Der Nutzer bekommt nach dem Laden dazu eine Meldung. Im Zweifel sollte wenigstens das Laden nur abgebrochen werden, statt direkt den ganzen Prozess zu killen! Aber wem sage ich das...

P.S.: Bei mir war im Endeffekt (nach einigem Hin- und Herkopieren von Daten) nur eine Datei betroffen (Überbleibsel eines alten Test-Mods), welche wirklich im ANSI-Format gespeichert war - jetzt lädt das Spiel wieder. Die vom TFMM erstellten Dateien werden bei mir alle ohne Probleme erkannt und geladen.

Suchfunktionen in Foren reichen leider niemals an die Macht von einer wirklich "Guten" Suchmaschine heran, da mache ich Dir nicht ein mal einen Vorwurf. Ich wusste halt, dass es diese Themen bereits gibt, habe aber selber über die Forensuche auch nichts gefunden
Dann habe ich schnell Google gefragt und das erste Ergebnis zur Suche site:train-fever.net Hauptmenü Auflösung hat mir das richtige Thema beschert.

Könntest Du eine Quelle zu Deiner Aussage mit den 65000 simulierten Einwohnern liefern, @Blowfly?

Zu dem "großspurig angekündigten Millionen von simulierten Citizens": Auch da würde mich eine Quelle interessiern, weil alle Infos, ich ich direkt von den Entwicklern gelesen habe haben ausdrücklich gesagt, dass sie auf "Millionen" von Einwohnern verzichten, sondern eher kleinere Einwohnerzahlen auf den Karten haben wollen, die dann dafür aber vollständig simuliert werden. Daher hat ein Hochhaus mit 40 Balkons zB trotzdem nur 16 Haushalte, im Endeffekt erreicht man aber locker 100.000 Einwohner auf normalen Karten, bis zu einer Million wenn man alle Quadrate freischaltet. Ob alle simuliert werden ist schwer überprüfbar, aber aufgrund der Beobachtungen und allen Bürgern, die man sieht, verfolgt, benennt, etc. sieht es wirklich danach aus, als wenn alle einzeln simuliert werden. Warum sollte man hier als Entwickler auch lügen und sich aktiv für unrealistisch kleine Einwohnerzahlen entscheiden, wenn man diese dann trotzdem nicht auch alle simuliert?

Colossal Order hat hier natürlich die geballte Erfahrung aus 2 Spielen, in denen sie auch bereits alle Einwohner simuliert haben. Während in CiM2 die Berechnungen etwas flotter von statten gingen als in CiM1, die Darstellung großer Menschenmengen aber immer noch zu Ruckelorgien geführt hat wurde für C:SL die Wegfindung offensichtlich noch ein mal deutlich performanter gestaltet. Trotzdem sind die Wege immer noch durchaus realistisch. Auch die Darstellung großer Menschenmassen drückt nun nicht mehr die FPS, allgemein kommt das Spiel auch mit großen Mengen an Objekten (egal ob dargestellt oder nicht) sehr gut klar. Cities:Skylines ist definitiv ein Spiel, an dem sich so ziemlich alle Spiele in Hinsicht auf Performance und Simulationsgenauigkeit einige Scheiben abschneiden können - aber wie gesagt, genau damit hat sich der Entwickler seit CiM1 ja auch ausgiebig beschäftigt.

Bildschirmauflösung ändern / Fehlende Knöpfe im Hauptmenü

Zu Grosses Bild Für den Biltschirm.. :/

Lieber einen guten i5 als einen mittleren oder schlechteren i7. Vor allem: lieber mehr GHz als mehr Kerne, 4 Kerne reichen total aus.
8GB RAM ist Pflicht, mehr ist schön aber der Sprung auf 16 ist nicht unbedingt nötig. Je nach preis sind vll 12 GB drin.
Bei der GPU darauf achten, ob die Bezeichnung nicht nur ein Deckname für eine alters Serie ist.Benchmarks können hier helfen. Außerdem mag TF vor allem viel Graphic RAM sehr gerne
Bei den platten: SDD + HDD kosten meist mehr Geld bzw brauchen natürlich auch mehr Platz. Viele 15"er kommen deswegen mit einem Hybrid daher - sicherlich keine schlechte Wahl.

P.S.: alle Tipps beziehen sich bei mir allgemein darauf, ein gutes Preise-Leistungs Verhältnis für die Mittelklasse (ca 700€) herauszuholen. Natürlich würde man evtl gerne einen i7 und 32GB RAM haben aber wenn man sich vorher eine bestimmte Grenze für die Kosten festlegt und dort dann mit ausgeglichenen Komponenten das maximum raus holt ist es deutlich effektiver als sich einfach dir teuersten und neuesten Komponenten zusammenzuschustern.

Ich bin auch der definitiven und überzeugten Meinung, dass man auch unter (oder bis max) 700 € gute Laptops bekommt die die meisten aktuellen spiele zufriedenstellend und TF zumindest auf mittleren maps meistern können sollte

Bestimmte Marken wie Apple, Sony, spezielle Gamimg-Serien oder auch Ultrabooks schlagen mit extremen Preisen zu Buche die nicht immer dem Gerät sondern oft dem "Guten Namen" zu Grunde gelegt sind. Mit ein bisschen Vergleichen und abgestimmten Komponenten kann man aber auch bei "Marken"-Modellen wie zB von Dell, Aus, Acer, ... Schnäppchen landen.

@EAT1963, die meisten erkennen hier die Ironie wenn dann nur aus dem Wunschdenken heraus, dass es eine so absurde Frage ist, dass man hofft es sei nicht ernst gemeint
Oder aber die Frage ist absolut rein theoretischer Natur um allgemein zu fragen wie verschiedene Verstöße im Verbund geahndet werden - auch wenn das Beispiel in dem Fall sehr außergewöhnlich gewählt ist

Oberleitungen sind dort leider (verständlicherweise) meist nicht fahrtauglich
Dafür existiert die Brücke, in TF hätte ich da große Angst vor Brückenpfeilerkollisionen

Das Mods Errungenschaften deaktivieren ist kein Gerücht sondern steht sogar in den offiziellen patch notes von urban games!
Dabei handelt es sich natürlich nur um mods im mods/ Ordner liegen, mods direkt im res/ Ordner können vom Spiel ja gar nicht identifiziert werden!

@Lukas1: TFMM vorm starten in einen Ordner entpackt, indem es Schreibrechte hat?...
Alle benötigten Dateien wie unrar und die Sprachen werden beim Start automatisch im selben Ordner erstellt. Dies war auch schon beim alten TFMM so und daran hat sich nichts geändert.

Die Bilder vom Tag muss ich erst mal sortieren (zu viele) daher hier nur mal das:

Einen schönen abend wünsche ich euch von der Große Freiheit

Erstes Treffen

Eine kleine Auswahl meiner Fotos von Freitag Nachmittag "vorm" User-Treffen.

Die Steam und gog Version können nicht die selbe build Nummer haben, da eine Version ja mit Steam und die andere ohne kompiliert werden muss.