Enable Oolite development (2)

[phkb]

Could you give me a screenshot?

Sure. Here you go:

Do I understand correctly that these folder names end on .oxp and they have a manifest.plist file? How would I then distinguish an ordinary addon from such a folder?

They have to have a ".oxp" extension to be picked up by Oolite. Anything else and Oolite ignores them. Which I use to my advantage, renaming entire folder structures quickly. If you were to go down the path of allowing subfolders, you would just have to assume that any folder with ".oxp" could have another folder inside with ".oxp", and you keep going down until you run out of folders. The manifest file is irrelevant - I put one there just to suppress the messages you get in the log file when OXP's don't have one.

Did you notice the window title? It is visible from all tabs - even from the taskbar.

I didn't, which tells you the information might be a bit too subtle!

That was the original sequence when I developed OoliteStarter. Until I noticed that when using the software you need to add versions once, change addons once in a while but always use the Start Game panel. And I switched. So which is 'better'?

You could default to opening on the "Start game" tab after the first run.

But I decided to have them there as a visual clue that the panels can be resized. It may help the occasional user.

I'd probably just darken the entire separator between both sides to indicate it's there.

Just to be clear, the reason for my mentioning things like changing the tab name to "AddOns", and removing the identifier column, is because I'm trying to think like an inexperienced user, not as a developer. I understand perfectly what an identifier is, and what it means in terms of Oolite, but if we want to push this resource as something for first time players to use, it has to be as super smooth as possible. The interface should not ever create a question in the mind of the user that it can't answer immediately.

BTW, one last thing: I think the Save button isn't necessary. I expected it to save any changes I made automatically, and was surprised when it didn't. Also, I got this dialog with Mr Gimlet that says:

Nice try kiddo!
Your configuration was stored in C:\Users\.....\.oolite-starter.conf
But... you still ain't got an active Oolite version. Expect trouble to follow your pants.

Err... "Expect trouble to follow your pants"? Ah, no. Humour is one thing, but that one has the potential to be misconstrued.
Also, the message should say something like "you still haven't selected a version of Oolite to be active". It certainly needs to mention the actual action the user needs to do.

[hiran]

Just to be clear, the reason for my mentioning things like changing the tab name to "AddOns", and removing the identifier column, is because I'm trying to think like an inexperienced user, not as a developer. I understand perfectly what an identifier is, and what it means in terms of Oolite, but if we want to push this resource as something for first time players to use, it has to be as super smooth as possible. The interface should not ever create a question in the mind of the user that it can't answer immediately.

In terms of Oolite you are developer and I am user. In terms of OoliteStarter the roles are switched.
I am happy about your feedback and definitely take it into account.

Some things already changed. Yet do not expect everything to work as intended on the prerelease.
OoliteStarter v0.1.18-abukir.9

[Cholmondely]

That reference mentions info.plist for Oolite itself. Being an AppleMac project, it is the file that any application bundle should come with. MacOS will read and interprete that file. With that the specification should be here: info.plist Reference.
I am more surprised that this same file would get applied to OXPs. They are no applications to MacOS and thus the information needs to be digested in Oolite.

I scanned the the Oolite source code and saw no evidence that the file <someexpansion>/Index.plist is read at all.

Index.plist?

I promise you, if these presumably useless (for two decades) info.plists allow your zecchini to recognise old .oxps, that I will not utter one single murmer of complaint!

I've found some more oxps with info.plists

Railgun.oxp (Commander McLane - 8 oxps not on the Expansions Manager)

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>CFBundleGetInfoString</key>
	<string>railgun 1.3</string>
	<key>CFBundleName</key>
	<string>railgun</string>
	<key>CFBundleShortVersionString</key>
	<string>1.3</string>
	<key>NSHumanReadableCopyright</key>
	<string>Commander McLane 2011</string>
</dict>
</plist>

MandotechIndStation.oxp (Mandoman - who wrote 60 oxps not on the Expansions Manager)
Just checking two others of his, they also have info.plists

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>CFBundleGetInfoString</key>
	<string>MandotechIndStationV1.4</string>
	<key>CFBundleName</key>
	<string>MandotechIndStation</string>
	<key>CFBundleShortVersionString</key>
	<string>1.0</string>
	<key>NSHumanReadableCopyright</key>
	<string>mandoman</string>
</dict>
</plist>

I've also looked at another couple of Stranger's Roolite oxps - they also have info.plists (he has maybe 20 Roolite oxp's unpublished over here).

So that is 90 or so oxps including the crucial and putatively untouchable Galactic Navy all with info.plists lurking at the top level of the oxp or in the config folder.

[hiran]

So that is 90 or so oxps including the crucial and putatively untouchable Galactic Navy all with info.plists lurking at the top level of the oxp or in the config folder.

But what do you want to do about them? The information in Index.plist is unusable. Ok, we have a title and an author (although it seems to be the author's nickname).
And he seems to hold the copyright. But there is no additional license granted. What possiibilities does that give to us other than chasing people for a license?

[Cholmondely]

Does it not identify the oxp?

And with the licenceless Galactic Navy, obviate the need for tweaking it to add the information?

And I would guess with the less-likely-to-be-used 60-odd Mandoman oxps obviate the need to download them, tweak then, and then store them on the wiki?

We are talking of 400-odd OXPs which don't have a manifest.plist.

[hiran]

@Another_Commander:
I tried to better structure reported issues that are coming in on the OoliteProject/oolite repository.
Although I followed the GitHub documentation as much as possible it seems I do not hold sufficient privileges.

Is it possible to ramp me up so I have access to the settings tab?

[szaumix]

I want to add a salient point that I don't know if developers have considered.

-overwrites.plist

If y'all are considering an overhaul or consolidation of the future of Oolite, this would be the neglected consideration. How many of you have -overwrites.plist scattered around your oxz folders presuming to make unasked-for changes to vanilla and oxp ships, even in competition with one another? The amount of super awesome addons that I have rejected because I couldn't bear unnecessary (read: matter of taste) changes to my carefully tailored balance of danger and cost and reward is enormous. I was so excited for Hermitage, but had to let it go because for some reason phkb added -overwrites.plist that included ship specifications instead of just the necessary additions. This has been the single-and-only reason I have rejected more oxps and addons than I can count.

Last year I literally had to spreadsheet the library of plists -- just plists! that were affecting my ooniverse. Balance could not have been achieved any other way.

This is not a small or tangential issue. In the early days I was running Oolite with OXP's willy nilly, and it was a chaos universe of pretty things and nice models and colorful lasers and fancy equipment as the designers saw fit. My problem was that I disagree with ALL the tastes of ABSOLUTELY EVERYONE in terms of what things should cost, and of risk, reward, danger, ship specifications, sizes, what have you. Scanner Targeting Enhancement -- easily both the most complicated and most useful technology a ship can have in a fight, for a grand? Yeah no, mine is ten grand and I salivate as I approach affording it in a new ship. Mambas are "heavy" support? Yeah no, three-laser kraits are heavier than that. Etc, etc.

OXP designers have got to make things cost something or other, that's one thing. But those who release OXPs with changes to other OXPs, or to vanilla specs, I can not countenance.

Those particular examples are me-things for sure, but the underlying logic is actually sound. I don't want to tell anyone else how to run their ooniverse, and I don't want anyone else's pumpkin-eater tastes in mine. I found Vanilla to be hideously unbalanced in every metric: economy, population, pack sizes, role weights, you name it. This isn't even just a matter of taste, I believe I can fairly objectively criticise a great deal of it just in logical terms, but I wouldn't bother because I know it's been done to death and this is not the time.

Therefore in all this consideration of furtherance of Oolite development, please consider this: standardize not working any matter-of-taste change into your OXPs please k thank you.

[szaumix]

I have been thinking of consolodation of Oolite data for years, and Cholmondely makes some good points. Packaging OXPs into 'sets' (if that is what I'm understanding?) is a great idea.

The reason I brought up what I brought up is because in this last year, I have finally after long long long wanting to do so, manually changed everything about Oolite that I thought ought to be so. (Partially because there is NO version of Oolite, nor any combination of OXPs, which provide me unedited what I want in terms of danger + risk + glory + realism. I am achilles and all I want from Oolite it to be the baddest pilot ever or to die in glory, and no combination of OXPs provide me with either. Every single thing makes something or other too easy, cheap or ridiculous). And yes, it was a gargantuan task, and no, I'm still not quite done working out the niggles.

Some things can be fixed with dial-settings (see: Skilled NPCs, Configurable Populator), and the more dial settings we have the less manual labour this is. I don't know how hard it is to code the flags and settings into phkb If I had any suggestion to maximise playability and minimise personal labor it would be to increase dial-settings. If more things about plists and ships and equipment could be dial-set, consolidation of OXPs would be implied at the user level.

[phkb]

*phkb frowns at config files in Hermitage*
*pauses*
*deletes shipdata-overrides.plist*

[phkb]

I don't know how hard it is to code the flags and settings into phkb

I'm a bit old to have new flags and settings added!

[szaumix]

I don't know how hard it is to code the flags and settings into phkb

I'm a bit old to have new flags and settings added!

Typo! That was supposed to be, "into phkb's Config for Addons."
I must be getting senile. Who said that?

[phkb]

"into phkb's Config for Addons."

Although Lib Config was developed by Svengali, I can foresee I'll need to maintain it someday.

have finally after long long long wanting to do so, manually changed everything about Oolite that I thought ought to be so.

I'd be fascinated to see the list of changes. Unifying parts of Oolite so they make more sense is a huge task, and one I've often contemplated, but have always found other things that needed my attention. If you have everything in *-overrides.plist files, even if I don't agree with all the changes, it would be a great starting point for me (and potentially others) to reform their Oolite world a little more.

[phkb]

I've had a bit more of a play with OoliteStarter, and have a couple more observations.

1. The UI can become unresponsive after clicking "Install" for an OXP (particular large ones). I found myself, on several occasions, wondering if I'd clicked the button at all. You should, at least, change the mouse pointer to an hourglass if you start a process that might taken more than a second (like downloading a file). Even better would be to queue the downloads into a background process, so I can keep clicking on other OXP's to download.

2. By using OoliteStarter, you effectively break the built in Expansions manager. Because you put a file version into the name of every file you download, particularly into the ManagedAddOns folder, the Expansion Manager doesn't recognise them when it tries to update to a new version, effectively putting two versions into the ManagedAddOns folder. Then, when you go back to the main menu your screen gets filled with red warnings about there being two versions of the OXP present.

My suggestion is, if you're going to do anything inside the ManagedAddOns folder, do it in the same way as the Expansion manager does. Filename is the identifier with ".oxz". If you want to keep with the "@version" in the filename, do it in the AddOns folder, so that the Expansion Manager knows not to do anything with it.

The point is, I should be able to switch back and forth between using the ingame manager and OoliteStarter, without issues.

[szaumix]

I'd be fascinated to see the list of changes. Unifying parts of Oolite so they make more sense is a huge task, and one I've often contemplated, but have always found other things that needed my attention. If you have everything in *-overrides.plist files, even if I don't agree with all the changes, it would be a great starting point for me (and potentially others) to reform their Oolite world a little more.

It's the sort of thing you think you want to do until you set about doing it. Then it turns out you're not just cleaning your room, your task is actually more like cleaning every messy and disorganized room in the neighborhood.

[phkb]

Oh. My.

That's certainly more organised than I was ever going to be! Can you easily export the results as *-overrides.plist files? Writing scripts in Excel is my bread and butter.