Progress

[Cody]

The Rock Hermit can have different clearance comms messages...

Hermits requiring clearance/having clearance messages? That doesn't really fit, in my opinion.

... if I were a hermit, and somebody docked unannounced and without permission, there's be a face full of shotgun waiting for them when they opened the door.

To digress slightly... what is the 'lore' behind hermits? Are they one-man operations, do they fly their own defender ship?
You see, to avoid Diz's shotgun, I often tempt the hermit/defender out, then quickly dock and go about my business.

[Diziet Sma]

To digress slightly... what is the 'lore' behind hermits? Are they one-man operations, do they fly their own defender ship?

I tend to think of them as similar to old Charlie, the asteroid miner in Heinlein's Space Family Stone, aka The Rolling Stones. Some of them may have a partner..

[cim]

I've not often seen a rock hermit with much traffic in/out - it's only the occasional ship that docks/launches.
As it happens, I'd like to see more traffic in/out at hermits. However, do whatever works best, cim - I'll adjust to it.

Don't know what happens/will happen, but I'd like the core game to look to see what dockables (OXP or core) are in the system and route traffic to them/from them automatically. It might have the effect of reducing the amount of traffic on the spacelane, and having traffic all over the system (especially if there are a lot of other stations).

Some of this is in already - pretty much every AI in 1.79 if it needs to dock will pick a random suitable station (if the main station is suitable, there's a heavy bias towards it, though). Similarly when the standard repopulator wants to launch a ship, it will pick a random station to do so (sometimes biased to the main station, sometimes not).

So hermits - especially those relatively close to the planet in busy systems - might end up with a fair bit of traffic. The length of time an Anaconda+escorts takes to dock you might well get some launch requests coming through as well.

NPC hunters/police won't attack a rock hermit with a bounty, because it's CLASS_ROCK. Of course, without OXPs, or by blowing it up to see what happens, the player will for the same reason have no way to tell either. We can make some of them more piratey than others without giving them a bounty, though, by changing the allegiance flag - hermits default to "neutral" (anyone can dock, but pirates prefer not to) but some of them could randomly be set to "chaotic" (anyone can dock) or even "pirate" (pirates dock, everyone else avoids). Varying the probabilities of each by government type would give a subtle distinction between systems, too.

There should be some sort of visual clue to the player, though

Because the NPC docking routine and the docking computer approach are basically identical, probably the closest that could be done in terms of station lights is to distinguish between docks in "launch", "dock" or "unused" modes.

Are they one-man operations

I think it probably depends on where they are and how busy / actively-mined they are: one out in the middle of nowhere that's basically mined out might well just have a single inhabitant who dislikes company and maybe does a little bit of mining as a hobby; the busier ones on the spacelanes might well have maybe thirty or so miners hoping to strike lucky, plus various traders, smugglers, etc. temporarily docked.

[CheeseRedux]

To digress slightly... what is the 'lore' behind hermits? Are they one-man operations, do they fly their own defender ship?

Rock Hermits Pirates, aging bounty hunters, or planetary outcasts, who create living space out of asteroids. They usually choose large asteroids, and set up signal beacons to warn off miners. GalCop Law protects Rock Hermits, but since most of the asteroid is hollowed-out, there is little advantage to be gained by "mining" them anyway.

[cim]

A few extra HUD plist parameters which might come in useful for simplifying some existing HUD OXPs or writing new ones.

Firstly, alert_conditions - lets you specify alert levels that the HUD item (legend or dial) is visible at. You should be able to use that to put together a fairly complex switching HUD without needing scripts, though obviously not everything can be duplicated that way.

Secondly, various new colour parameters so you can recolour the various bar gauges away from the red/yellow/green theme of the default HUD.

As suggested elsewhere, the "weapons offline" notice has been moved somewhere a bit more noticeable, in case you accidentally press it.

In non-HUD improvements, you can put "[oolite_key_something]" in your descriptions.plist entries, and it will be replaced with a description of the "key_something" entry in the current keyconfig.plist.

[cim]

On we go...

Most importantly, as you'll already have seen, the nightly builds are now pointed at the 1.79 developments, so you can try out all this new stuff yourself much more easily. Take a backup of your savegames first just in case, though! We've got a few bug fixes in already from early testing, and I expect to be doing quite a bit more over the next couple of weeks.

Thanks to CaptSolo and Griff, the asteroid models are now also updated and retextured.

Now, a couple of big changes which we've been working on in the last few weeks, which you should be able to try out in tomorrow's build.

Expansion pack format
The first is a new format called OXZ for distributing expansion packs: the old format still works, but this one is designed for ease of end user distribution - it's just a single file (with an .oxz extension) which you can download and place in your AddOns folder. Here's an OXZ version of Camera Drones if you want to give it a go.

The OXZ is basically just a renamed ZIP file, with the various folders of an OXP as subfolders within it. At the top level of the structure there is a new file called manifest.plist, which looks like this:

Code: Select all

{
	identifier = "oolite.oxp.cim.camera-drones";
	version = "1.3";
	title = "Camera Drones";
	required_oolite_version = "1.77";
	description = "Drone cameras which provide a variety of alternative external views for your ship";
	category = "Equipment";
	author = "cim";
	license = "CC-BY-SA 3.0";
	download_url = "http://compsoc.dur.ac.uk/~cim/oolite/Camera_Drones_1.3.oxz";
	information_url = "http://wiki.alioth.net/index.php/Camera_Drones";
}

and is used instead of requires.plist. It has a lot of fields - only the first four are required by Oolite, though many of the others are worth entering. I'll put some documentation of what fields are available and what they're used for up on the Wiki soon.

You can also explicitly specify dependencies - if an OXZ requires another OXZ to function, or conflicts with one, you can add an entry and it won't try to load it unless the requirements are met. Obviously this is only generally useful for OXZs since the existing OXPs don't have a manifest.plist (though there's nothing to stop you adding one - it's harmless in 1.78 or earlier and will be processed for OXPs as well as OXZs in 1.79 or later)

The filesystem within an OXZ is explicitly case-sensitive, so this should stop some problems with OXPs developed on Windows not working properly on Mac or Linux.

OXP format continues to work as before, of course.

Sound changes
The second big change came out of that one, due to a problem with accessing sounds inside zip files in the SDL sound library we were using on Windows and Linux. We've now moved to OpenAL for sound support, across all three supported operating systems. OpenAL is a positional sound library, so rather than just simple stereo or mono sounds, it can make sounds appear to come from any specified direction. You'll now be able to hear where those hits on your hull are striking, if you have a good enough sound set up, and at least be able to tell the difference between "hit on left side" and "hit on right side" even just with headphones.

For OpenAL to position a sound, it has to be recorded as mono. Previously this hasn't mattered and a lot of sound sets - including Oolite itself - have had a random mix of stereo and mono sounds. In general - and OXPers may be able to find exceptions to this rule, which is why we're not enforcing it within Oolite - you should probably make the contents of the Sounds folder mono and the contents of the Music folder stereo.

The SoundSource JS object now has three extra properties, all of which can safely be changed while a sound is playing:
- positional (whether the sound is positional [1])
- position (where the sound is coming from relative to the player. This is a vector, in player-ship coordinates, with the player being assumed to be at the origin)
- volume (the relative volume of the sound from 0 to 1)

[1] Strictly, all mono OpenAL sounds are positional. Setting this to false forces the position to be the same as the listener.

If you're compiling your own, then on Linux, you'll need to install libopenal-dev or a similarly-named package from your distribution. Windows dependencies are included, and it's a system library on Mac OS, so those should be fine.

[pagroove]

Good news Cim. Oolite is getting better and better.

slightly off-topic:
I tried to grab a mac-nightly but it won't unzip. Maybe wait to tomorrow when a new nightly is build?

[JensAyton]

I tried to grab a mac-nightly but it won't unzip. Maybe wait to tomorrow when a new nightly is build?

Yep, seems broken today.

[pagroove]

I tried to grab a mac-nightly but it won't unzip. Maybe wait to tomorrow when a new nightly is build?

Yep, seems broken today.

Ok thnx for the confirmation. I tried unzip it with different programs but it won't let me.

[Tricky]

Liking the OXZ feature. Managed to test it before the power adapter on my laptop died (new one on the way), one question I wasn't able to resolve, can we have OXZ within OXZ? I have my AddOns setup with each author as a directory.oxp, then each of their OXPs within that directory.

I'm thinking it would be easier to create add on packs this way. It would mean creating a manifest for the base OXZ. Would this work?

[cim]

Liking the OXZ feature. Managed to test it before the power adapter on my laptop died (new one on the way), one question I wasn't able to resolve, can we have OXZ within OXZ?

No. It would require a lot more work to support that, and it shouldn't be needed.

I'm thinking it would be easier to create add on packs this way. It would mean creating a manifest for the base OXZ. Would this work?

That's what the dependency resolver is for. You'd create a base OXZ with a manifest which had the others in its requires_oxps field. At the moment this just tells you that they're missing at startup and you have to find them yourself: long-term the point of having the download_url field in the manifest is that Oolite could - with user permission! - check an OXZ server for the manifest files of missing dependencies, and then download and install them for you. I don't know if that feature will make it into 1.79/1.80 yet: it requires careful design and implementation, and I haven't spent any time on the design stage yet.

[Tricky]

Interesting.

[pagroove]

Now that exhaust colors are possible I wonder if some of the Griff Ships could have white or yellow plumes (some not all). Or could this even be randomized in the standard sets?

BTW I observed the new AI's and they are wonderful! Good work Cim. Also the ship naming is great.
And last question:

Some time ago you mentioned a new system for the contracts (with danger levels and so on). Do you still plan to add that?

[cim]

Some time ago you mentioned a new system for the contracts (with danger levels and so on). Do you still plan to add that?

Parcels and passengers have that at the moment. Cargo contracts I haven't touched yet - I'm still thinking about the best way to approach them.

[pagroove]

As posted in Mac Trunk topic. But also here: Still can't unzip the Trunk build on Mac.