Wir begrüßen euch in der Fan-Community zu den Spielen Transport Fever und Train Fever, den Wirtschaftssimulatoren von Urban Games. Die Community steht euch kostenlos zur Verfügung damit ihr euch über das Spiel austauschen und informieren könnt. Wir pflegen hier einen freundlichen und sachlichen Umgang untereinander und unser Team steht euch in allen Fragen gerne beiseite.
Die Registrierung und Nutzung ist selbstverständlich kostenlos.
Wir wünschen euch viel Spaß und hoffen auf rege Beteiligung.
Das Team der Transport-Fever Community
Kann ich nicht nachvollziehen, weder die Argumente von fido, noch die von Tom.
Wie viele Leute hatten vor dem Patch Probleme und wie viele nachher? Wenn ich mich hier und bei UG im Forum umsehe, gab es nach dem Patch bei deutlich mehr Spielern Probleme, als vorher. Und das ist das genaue Gegenteil von dem, was ein Patch bewirken soll.
MS kann es sich leisten, eigene Standards zu verwenden. Daran muss man sich als Entwickler anpassen.
Mein Hinweis bezog sich darauf, dass es definitiv unter Windows Probleme gab.
Natürlich hat die erste Fehlerhebung das Problem für die Community verschlimmert. Wer aber an dem UTF-8 Fehler die Schuld trägt, ist für mich völlig offen. Die Ursache kann zB. daran liegen, dass UG Libs von externen verwendet, die zu dem Fehler führten. Es kann genauso auch an Libs des Betriebssystems liegen.
Wer aber an dem UTF-8 Fehler die Schuld trägt (...)
Unterm Strich? Die Modder die Sonderzeichen in Bezeichnern verwendet haben und UG, die dieses Problem offensichtlich nicht erwartet hat. 
Ich glaub nicht, das man da wirklich mit dem Finger auf jemanden zeigen kann. Meine Kritik beschränkt sich auf den Umgang mit diesem Problem, respektive die uns von UG präsentierte Lösung.
Hallo
MS kann es sich leisten, eigene Standards zu verwenden. Daran muss man sich als Entwickler anpassen.
Mit Verlaub, das ist Humbug.
1. Der UTF-8-Desaster-Patch hat originär nichts mit Problemen unter Mac oder Linux zu tun.
2. Für Mods wurde von UG von Anfang an auf allen Betriebssytemen UTF-8 als Kodierung vorgeschrieben.
3. MS Windows unterstützt UTF-8/Unicode problemlos. Das Problem ist hier eher, dass bestimmte Programme unter Windows standardmäßig (aber durchaus umschaltbar) eine unpassende Kodierung verwenden und mancher Modder nicht darauf geachtet hat, das vor dem speichern umzuschalten.
4. Es gab bis vor kurzem keine wirksame Prüfung, so dass Mods mit anderer Kodierung Verbreitung fanden.
5. Mods mit falsch kodierten Dateien führten nach Aussagen von UG zu Programmabstürzen.
6. Der UTF-8-Desaster-Patch führte eine zu wirksame Prüfung mit den daraus resultierenden neuen Abstürzen ein. Mit einer breiteren Testbasis wäre das vermeidbar gewesen.
Conclusio: Wäre von Anfang an eine wirksame und dabei nicht über die Stränge schlagende Prüfung der Mods vorhanden gewesen, die schon dem testenden Entwickler ansagt, dass diese oder jene Datei falsch kodiert ist, hätte es das Problem nie und in keinem der unterstützten Betriebssysteme gegeben.
Tschö, Auge
Kurze Erklärung:
Bei Betriebssystemen und Anwendungen die nicht von Microsoft sind, also der Rest der IT-Welt von mobilen Geräten bis zu Großrechnern, ist Unicode (16 Bit pro Zeichen) der Standard bzw. die Codierung als UTF-8 aus Platzgründen. Editoren und andere Programme aus dieser Welt lesen und schreiben Texte automatisch in diesem Format - der Benutzer muss dazu nix besonderes machen. Zur Sicherung seines Monopols ignoriert Microsoft dies und läßt seine Programme (Compiler, Notepad, etc.) Windows-ANSI lesen und schreiben. Wie der Name schon verrät, ist dies etwas Windows-eigenes. Soll eine andere Codierung verwendet werden, muss man dies den Programmen explizit mitteilen (Speichern als... u.ä.).
Für Computernutzer, die dies nicht wissen und sich nur in der Microsoft-/Windowswelt bewegen, haben kein Problem solange sie nicht Daten mit anderen austauschen wollen/müssen.
Und nein, es gibt nicht nur Windows. Und nein, es ist auch nicht das Beste was es gibt...
Conclusio: Wäre von Anfang an eine wirksame und dabei nicht über die Stränge schlagende Prüfung der Mods vorhanden gewesen, die schon dem testenden Entwickler ansagt, dass diese oder jene Datei falsch kodiert ist, hätte es das Problem nie und in keinem der unterstützten Betriebssysteme gegeben.
Ja, aber genau das schreibe ich doch seit Tagen...
Soweit ich das verstanden habe, sind die Probleme aber nur in Verbindung von falscher Kodierung und gleichzeitiger Verwendung von Sonderzeichen aufgetreten. Der UTF-8-Desaster-Patch führte nicht zu einer Prüfung, sondern das war bereits die Auswikung der Prüfung...
Aber ich schreibe ja Humbug.
Windows bzw. Microsoft sind das Problem!
Und nein, es gibt nicht nur Windows. Und nein, es ist auch nicht das Beste was es gibt...
Heute wieder Hobbytroll?
Zu den Aufgaben eines guten Programmierers gehört es nun mal auch, falsche Eingaben zu filtern. Mods mit ANSI-Kodierung hätte man schlicht und einfach aussortieren können. Eine Info in die stdout.txt sowie ein kleines Hinweisfenster Ingame wären da die richtige Lösung gewesen. Eventuell eine Konvertierung auf Vorschlag durchführen. Also in etwa das, was nach dem zweiten Patch gemacht wird. Daß dies mit der ersten Version des Patches absolut nicht geklappt hat muss man jetzt nicht Microsoft in die Schuhe schieben wollen. Auch als Linux/Mac Programmierer muss man die Windows-typische Kodierung in seine Konzepte mit integrieren wenn man Programme für Windows erstellt. Ein nicht zu verachtender Anteil der Nutzer nutzt diesen Standard. (ca 90% der Train Fever-Spieler)
Hallo
Ohne jetzt ins Korinthen kacken zu verfallen …
Ja, aber genau das schreibe ich doch seit Tagen...
Das tust du in dem Posting, auf das ich antwortete explizit nicht. Du hast dort sinngemäß geschrieben, da der Großteil der Benutzer Windows nutzt, müsse man als Entwickler das Verhalten, welches in unserem Fall zu Fehlern führt, mitmachen, damit bei eben diesem Großteil der Benutzer keine Fehler zutage träten. Du ignorierst dabei den Fakt, dass die Kodierungsfehler in den Mods vorhanden bleiben und somit weiterhin zu Abstürzen an anderer Stelle führen.
Soweit ich das verstanden habe, sind die Probleme aber nur in Verbindung von falscher Kodierung und gleichzeitiger Verwendung von Sonderzeichen aufgetreten. Der UTF-8-Desaster-Patch führte nicht zu einer Prüfung, sondern das war bereits die Auswikung der Prüfung...
Der Patch war die Prüfung, da erst er sie überhaupt einführte. Dass das fehlerhaft gedacht und umgesetzt war, bestreite weder ich noch irgendwer anders (soweit ich mitbekommen habe). Und ja, das Problem war (wie Merk schon an anderer Stelle schrieb), dass ANSI/ASCII-kodierte Dateien als Ausschnitt von UTF-8 als solches durchgehen, solange man keine Zeichen verwendet, die nicht von ANSI bzw. ASCII abgedeckt werden.
Zu den nicht enthaltenen Zeichen gehören eben auch die deutschen Umlaute (ä, ö, ü) und Ligaturen (ß). Werden diese in einer richtig™ UTF-8-kodierten Datei richtig benutzt, verursachen sie auch keine Probleme. Bei den selbst umkodierten Dateien blieb nach der Umkodierung halt das Problem, dass dort mit den Umlauten etc. nun Zeichen enthalten waren, die immer noch ihrer ANSI-Kodierung entsprachen, was in UTF-8 halt nicht funktionierte.
Dafür gibt es nach dem letzten Update ja nun eine Lösung. Wenn die Modder nach und nach die Korrekturen in die Quelldateien einpflegen, fällt über kurz oder lang auch das Wegklicken der Meldungen flach.
Aber ich schreibe ja Humbug.
Du darfst natürlich schmollen, ich bleibe aber dabei, dass der im vorigen Posting zitierte und kritisierte Absatz Humbug ist.
Tschö, Auge
(...) ich bleibe aber dabei, dass der im vorigen Posting zitierte und kritisierte Absatz Humbug ist.
Meine Aussage zu MS-Standards? Das ist so, glaub mir.
Im übrigen ist mir neu, dass ich in jedem Post alle bisherigen Argumente neu aufzählen muss. Das führt auf Dauer auch zu ermüdend langen, sich ständig wiederholenden Posts. Das wollen wir doch nicht, oder? 
Heute wieder Hobbytroll?
Na dann noch ein Versuch des unprofessionellen Trollens:
Zu dem zum Zitat gehörenden Text: Das UG das nicht elegant und professionell und viel zu spät gemacht hat, hatte ich auch schon geschrieben.
Mir ging es hier um Ursache und Wirkung. Wenn man ersteres abstellen würde, hätte man mit letzterem nicht zu kämpfen.
Welchen vernünftigen Grund gibt es, dass die Programme des genannten Herstellers dieses Verhalten an den Tag legen, obwohl sein Betriebssystem selbst intern alles mit Unicode erledigt?
Wahrscheinlich wäre es dann viel zu einfach...
Ich mache dann hier mal dicht. Geht ja nicht mehr um die Signale.
