The majority of users use Windows, and the default editor for .txt files on Windows is Notepad, which can only read files with DOS/Windows-style CRLF line endings. So users on Windows might get confused if init.txt or the .xml files are not editable in Notepad. I DIDN'T change the line endings for any makefiles or scripts, those probably HAVE to be UNIX-style line endings. Line endings in .cpp and .h files can be either way, compilers know how to read both types. Text and documentation files, it make sense for them to be readable on Windows. .Xml files, in them line endings don't matter, since XML is far more advanced than that, it's part of the XML specification. I think Linux text editors are quite well-programmed and able to view files with CRLF line endings quite well nowadays in the various text editors such as Emacs, vim, etc., while Windows is not quite as good at displaying files with UNIX-style line endings, at least not in its default text editor Notepad (which a lot of people still use). And while Windows' WordPad CAN view files with UNIX-style line endings, if you save them it changes them all to DOS/Windows-style line endings. So on Windows the support for UNIX-style line endings is quite bad, at least in everything bundled by Microsoft as part of the operating system. Linux is far more robust at dealing with this sort of thing.
As for sitemaps.txt, there is a bug parsing it on Linux? Well this probably needs to be fixed in the code of Liberal Crime Squad. Can you confirm that this bug is still present? It ought to be fixable in the code. I could write a wrapper function for the getline() function that reads a line of text from a file, and have it remove any CR or LF characters that are at the beginning or end of the line, and then call this wrapper function everywhere the regular function for reading a line of text from a file is used. Or, since getline() is polymorphic and has several variants, I could call a function to remove CR and LF characters right after each call to getline(). That would allow it to work perfectly on Linux, if that bug is present, and then it would have no difficulty parsing files with Windows line-endings on POSIX-compliant operating systems (not just Linux, but Mac OS X and others too). If the game is unable to parse both types of line endings, I would definitely consider that a bug that needs fixing, and luckily I can probably fix it too. The game is supposed to be cross-platform after all, and being unable to read certain types of line endings on certain operating systems is definitely a bug. After all, the plaintext-formatted files have to have either one type of line ending or the other, we can't have both.
UPDATE: The bug with the game not properly parsing CRLF line endings has been fixed in
revision 727. Now the game parses both DOS/Windows-style CRLF and UNIX/Linux/Mac OS X-style LF line ending perfectly, and it can even parse files that have an inconsistent mixture of the 2 types of line endings with no difficulty whatsoever, and this code should work on all platforms. Even LFCR line endings (VERY rare) work fine. The only type of commonly used line ending that WON'T work is the type of line ending used on old Macs (up to Mac OS 9) and Commodore 64s, the CR line ending. But that doesn't really matter, since nobody plays the game on those ancient systems anyway, and even if they did somehow manage to port the game to those systems, they wouldn't have any problems with line ending parsing unless they manually edited the configuration files and changed the line ending style to CR, and anyone brilliant enough to successfully port the game to, for instance, Mac OS 9, wouldn't be dumb enough to make a mistake like that. So anyway, yeah, you can use UNIX style line endings on Windows or Windows style line endings on UNIX style operating systems, for any of the LCS configuration files, with no problems now.
Author
Topic: Some bugs (Read 2463 times)