Continuation of OXP versions?

[spara]

Hehe.. the Archive Manager and Gedit in Gnome/Cinnamon do exactly the same thing.. without the legendary KDE bloat.

Indeed. I'm not too fond of either, Gnome or KDE, but that aside Norby makes a good point. There's really no real need for distributing oxps using the old oxp. If someone wants to edit oxzs, it's easy enough.

[Diziet Sma]

Indeed. I'm not too fond of either, Gnome or KDE

That's why I've abandoned Ubuntu, after they went insane.. Mint and Cinnamon for me now, all the way..

(Well, I do also use Ubuntu Studio with the low-latency kernel, and Arch with Enlightenment - right tools for the job, and all that.. )

[tonyhippy]

Can someone tell me where the contents of OXZs added by the manager are stored, since theyre not in the AddOns or Resorces folders? I want to give the Aquatics ships the same re-skin I gave the OXP versions but I can't find 'em!!

[Cody]

~:\Oolite\oolite.app\GNUstep\Library\ApplicationSupport\Oolite\ManagedAddOns

[spara]

Can someone tell me where the contents of OXZs added by the manager are stored, since theyre not in the AddOns or Resorces folders? I want to give the Aquatics ships the same re-skin I gave the OXP versions but I can't find 'em!!

If you want to tweak them, I suggest donwloading directly from Oolite page and saving to your AddOns.

[Stormrider]

Can someone tell me where the contents of OXZs added by the manager are stored

I wondered this too, took me a while to find them.

~:\Oolite\oolite.app\GNUstep\Library\ApplicationSupport\Oolite\ManagedAddOns

I think this info needs to be in the OXZ manager somewhere.

[spara]

Can someone tell me where the contents of OXZs added by the manager are stored

I wondered this too, took me a while to find them.

~:\Oolite\oolite.app\GNUstep\Library\ApplicationSupport\Oolite\ManagedAddOns

I think this info needs to be in the OXZ manager somewhere.

Not sure about that, they are "managed" after all, so a new version will replace the old one and if you do your tweaks there, they will be gone. It's a matter of opinion of course, but I would leave the managed ones alone and download the oxz straight from the Oolite page and tweak that. In other words, I don't think it's a good idea to put that information to the manager. Wiki would be better for that kind of information.

[cim]

I think this info needs to be in the OXZ manager somewhere.

Not sure about that, they are "managed" after all.

Exactly. If you do need to know where they are, it's easy enough to find out from Latest.log, but if you need to know where they are, you're probably about to do something which will void your non-warranty (same as if you find Oolite's OXP Cache file and edit it). If you want to customise an OXZ, download and install it to AddOns instead - it'll show up as red for "manually installed" in the manager screens, and the OXZ manager will know not to touch it.

[Neelix]

Will externally moving an OXZ from ManagedAddons to Addons cause any issues with the Extensions manager? (ie is it "safe" to do that, if I want to mod one)

- Neelix

[Diziet Sma]

Will externally moving an OXZ from ManagedAddons to Addons cause any issues with the Extensions manager? (ie is it "safe" to do that, if I want to mod one)

That's quite safe.. I move OXZs in and out of ManagedAddons all the time, when I need to disable something for testing. I keep a special "Disabled OXZs" folder alongside of ManagedAddons for that purpose. Though it's probably a good idea to tell Oolite to rebuild its cache after you move something. If you're playing around with OXP/Zs a lot, it's simplest to add

<key>always-flush-cache</key>
<string>YES</string>

into your .GNUstepDefaults file. This forces Oolite to rebuild the cache every time it starts. (sometimes referred to as "putting a brick on the shift key")

[Neelix]

Will externally moving an OXZ from ManagedAddons to Addons cause any issues with the Extensions manager? (ie is it "safe" to do that, if I want to mod one)

That's quite safe.. I move OXZs in and out of ManagedAddons all the time, when I need to disable something for testing. I keep a special "Disabled OXZs" folder alongside of ManagedAddons for that purpose. Though it's probably a good idea to tell Oolite to rebuild its cache after you move something.

Good to know. - ta

If you're playing around with OXP/Zs a lot, it's simplest to add

<key>always-flush-cache</key>
<string>YES</string>

into your .GNUstepDefaults file. This forces Oolite to rebuild the cache every time it starts. (sometimes referred to as "putting a brick on the shift key")

Somewhat more useful than a brick on the shift key really, as that would make it difficult activate most of the keyboard controls in-game.

- Neelix

[Stormrider]

it's easy enough to find out from Latest.log

Of course you are right cim I must have looked at that path in the log a thousand times without it registering, but when I saw it in a post here, I was like oh that's where it is.

I'll just go hide in that beautiful solar corona over there now.

[cim]

If you're playing around with OXP/Zs a lot, it's simplest to add

<key>always-flush-cache</key>
<string>YES</string>

into your .GNUstepDefaults file. This forces Oolite to rebuild the cache every time it starts. (sometimes referred to as "putting a brick on the shift key")

This shouldn't be necessary if you're using OXZs - Oolite checks the existence and timestamp of all OXZ files against the cache, and if there's anything different, rebuilds it anyway.

[Diziet Sma]

I wasn't aware of that.. thanks for the info!

[cim]

The only type of change, in fact, that Oolite won't automatically detect, is when you edit the contents of an OXP, in place in the AddOns folder, in such a way that it doesn't change the timestamp of the OXP folder itself. If you have an OXP development workflow where you edit them outside of AddOns, then copy the folder into AddOns when you're ready to use it (which has other advantages, too) you should never need to force-clear the cache.