Version mismatch between OXP Manifest and Expansion Manager
This one I don't get. The version number in the EM says "3.3". The version number in the OXZ file loaded to the wiki says version = "3.3";. If you're reading a discrepancy here, I'm not sure where it's coming from. Could it be a type thing? ie reading one value as a string, the other as a decimal?
You are right, all these entries do not look critical. Reading between the lines I would understand you updated the OXP itself but did not upload a fresh manifest.
For the version, for some reason I see "3.3" in the Expansion Manager's list and "3.2" in the OXP manifest.plist file - at least that's what my scanner reports. Should this be a bug on my side?
Whew, I just downloaded the OXP manually, and the manifest indeed contains 3.4. Now I need to sit and think...
Reading between the lines I would understand you updated the OXP itself but did not upload a fresh manifest.
I update the critical data in the manifest - version. Descriptions, info url's etc, aren't as important in the manifest in the OXP because they're not easily visible anywhere. The EM screen has the human-readable version, and those I keep up to date with any relevant changes.
the manifest indeed contains 3.4. Now I need to sit and think...
I released another update today. 3.4 is the new version.
Absolutely. The culprit was my cache. As creating the whole report requires the download of all OXPs and more than 5 GB of disk space, I am keeping a cache with a TTL of 30 days. This is a source of problems of a new kind.
Now that I refreshed the cache I only get one warning regarding the description, and I will check where that stems from since at first glance the strings look identical.
Now that I refreshed the cache I only get one warning regarding the description, and I will check where that stems from since at first glance the strings look identical.
Ok, I found the answer. The reason for the warning is legit as the strings are not identical. However the difference is not visible in the browser:
It's the whitespace, more concisely linefeeds. Now this is very pedantic but on the other hand I do not intend to soften all the checks.
Instead I'd prefer to improve the workflow of publishing OXPs, as today there is a manual upload of a zip file which shall contain some data inside manifest.plist, followed by filling an online form where the data from manifest.plist has to be added manually again. Linefeed discrepancies are almost impossible to prevent here.
Thus I think we need to agree on some OXP repository implementation.
I've not played much lately because [reasons], and I've lost track of some things. I've just switched from Xenon Redux to Xenon full fat. Is it still the case that the BGS backgrounds take precedence over the Xenon backgrounds? I must have BGS for the hyperspace and docking/launching effects, but I want to lose its backgrounds. I've tried fiddling with Config for AddOns on F4, but to no avail. Am I missing something? Any ideas?
I would advise stilts for the quagmires, and camels for the snowy hills
And any survivors, their debts I will certainly pay. There's always a way!
I've not played much lately because [reasons], and I've lost track of some things. I've just switched from Xenon Redux to Xenon full fat. Is it still the case that the BGS backgrounds take precedence over the Xenon backgrounds? I must have BGS for the hyperspace and docking/launching effects, but I want to lose its backgrounds. I've tried fiddling with Config for AddOns on F4, but to no avail. Am I missing something? Any ideas?
I run both with no problems - I wasn't aware that Xenon had any hyperspace/docking effects. Just additions to the sides of the F3-8 screens.
if you have BGS installed with XenonUI, and tell Library GUI to use Xenon, then all the backgrounds should be Xenon. Everything else BGS supplies (launch and witchspace effects, sounds, etc) will work as expected. This is how I run my setup, so it should work for you.
