Not sure when this started happening, but downloading the OXP list now results in a download error, and the log has this:
Latest.log wrote:
12:56:21.830 [plist.parse.failed]: Failed to parse C:\DriveD/Oolite/SourceCode/oolite.app/GNUstep/Library/Caches/org.aegidian.oolite/Oolite-download.plist as a property list.
Parse failed at line 14008 (char 539673) - invalid utf8 data while parsing quoted string
12:56:21.833 [oxz.manager.error]: Downloaded manifest was not a valid plist, has been left in C:\DriveD/Oolite/SourceCode/oolite.app/GNUstep/Library/Caches/org.aegidian.oolite/Oolite-download.plist
The error points to this entry in the downloaded file: "description" = "This OXP adds enhanced Viper Patrols, Viper Pursuits, and Viper Interceptors, to richer stable systems; GalCop Deputies to stable poor/average systems; and Bounty Hunters to unstable/dangerous systems. They are not über ships - far from it - but with the advent of heavy pirates and heavy assassins into the core game, some toughening of GalCop Vipers seemed appropriate.";
The same entry appears as follows in the previously existing (and working) Oolite-manifests.plist: description = "This OXP adds enhanced Viper Patrols, Viper Pursuits, and Viper Interceptors, to richer stable systems; GalCop Deputies to stable poor/average systems; and Bounty Hunters to unstable/dangerous systems. They are not \U00FCber ships - far from it - but with the advent of heavy pirates and heavy assassins into the core game, some toughening of GalCop Vipers seemed appropriate.";
The error points to the last character in the string, but my bet is that it is the word über that kills it, since this is the only difference I can see between the two. Something to do with the way the file is UTF-8 encoded server-side maybe? - ü has code 00FC in Unicode.
Github also displays the character in that file correctly, but there is obviously something very wrong with the encoding. It fails to load for you as well, I believe?
Correct, although it was working a couple of days ago, and I know no one has been updating OXP's except for me (because I have direct access to the DB). So the description hasn't changed. Let me quickly update the description on that record and see if we can get things flowing.
But from what I read it seems to me that Oolite does not read the file with UTF8 encoding.
So we can look at the source, we can also check if a BOM might have helped.
No, Oolite reads everything exactly the same as it always has - there have not been any changes to the code that downloads and parses the data. Something changed on the file itself. Anyway, standing by for the cache refresh whenever that might be.
But from what I read it seems to me that Oolite does not read the file with UTF8 encoding.
So we can look at the source, we can also check if a BOM might have helped.
No, Oolite reads everything exactly the same as it always has - there have not been any changes to the code that downloads and parses the data. Something changed on the file itself. Anyway, standing by for the cache refresh whenever that might be.
I did not say that Oolite has changed.
It just appears that Oolite reads the file in some encoding that does not support unicode characters. That is why these characters must not be part of the file, but escaping them helps.
This information is crucial to tools that would generate such catalogs.
I have no clue what is really happening behind the scenes, but when I test right now I neither get a wrong or correct file.
Instead I get a 404 error code. If the response content, which is a nice error messages wrapped in HTML get parsed as a plist file, that obviously has to fail.
Of course, that doesn't explain what's changed. The record that I updated had not changed in over two years. The code that downloads the list in Oolite itself hasn't changed. So, the only component left is the bit in the middle: somewhere between the call to the API to retrieve the list, and the extract from the DB to update the list, something has changed. Maybe in how the file is stored, or how the file is extracted/created, or how it's transmitted back to Oolite. Either way, that's logically where the change must have happened.
At this moment, after downloading, my script (on VPS) fix this and then upload file to GitHub.
But what happened - I don't know :(
My actions have no any effect on the old server.
