Oolite Bulletins

Thank you cim, your work is awesome!

I will enjoy to check the new event handlers. Can I help to document it?

Norby wrote:

Can I help to document it?

Thanks for offering: mostly they're not documented because I haven't tried to use them for a "real" application yet, and it may turn out I need to alter the API when I do. The changes not related to the Javascript AI project should be fairly stable, though, so if you want to add those to the wiki, go ahead - use the {{Oolite-prop-added|1.79}} or {{Oolite-method-added|1.79}} templates to mark them.

More changes on the 1.79 branch:
- there is now a "primable equipment" dial. It remains invisible until you have at least one piece of primable equipment fitted to your ship, and then it displays the currently primed equipment. It has been added to the two default HUDs. Custom HUDs can make it a multi-line dial, showing the next/previous equipment items as well.
- some more Javascript extension to allow JS to access the docking instructions given by stations
- new sun appearance
- sun colour no longer generated from star colour, corona parameters slightly randomised if not set
- hostility indicator for enemy ships no longer depends on weapons range of those ships
- a few bug fixes

I've started work on Javascript AIs in a feature branch. So far, they're possible, and the priority-based AI library is starting to come together: the framework is there and works to process the priority list, but most of the work is in setting up a comprehensive library of standard conditions and behaviours.

A PE dial on the hud, new sun/colour thingy, etc - all good stuff, cim.

The new Javascript-based AIs are ... well, not finished by a long way, but at least in a playable state. If you can build from Github, they're in the "javascript-ai" branch. (If you're using a shipset OXP, you'll probably get a mix of old and new AIs in use. All the new AIs should cope fine in that case, but if you want to test all the new AIs you'll need to remove the shipset)

Here's an example: the bounty hunter AI. There's some draft documentation on the AI methods too.

Here's the new Integrated Targeting System in action. Boa+escorts:

Mid-battle:


I've not yet decided how much it should cost, or what its availability should be. For now it's 1500 credits at TL:12 if you want to try it out, and it needs both a Scanner Targeting Enhancement and a Target System Memory Expansion already fitted.

Mostly it's been continuing work on the new AIs based on the discussions about extended ship roles. I'm using the "steady-state-ecosystem" branch for this, which is uploaded to Github for people who can try it that way. So far it's going quite well in terms of writing the individual AIs and having them behave sensibly, but once it's done it'll need a lot of playtesting.

In the meantime, as well as a few extra ship properties and methods that turned out to be necessary to duplicate old AI functions, here's a little bit that some of you might find interesting: This is the new escort set up for the (trader) Anaconda. The actual numbers of each role added will vary - as before - dependent on the danger level of the system, between the maximum and the minimum. There is some randomness - a ship could end up with the maximum in a Corporate State, or the minimum in an Anarchy - but the opposite is far more likely. You can push the minimum below zero to make it much less likely that certain escort types show up except in the most dangerous systems, and you can also leave a line with a blank role to allow a ship to take more escorts than it started with should it meet a wandering escort ship that's lost its original job.

The old shipdata escort keys still work as before, of course.

Steady-state-ecosystem continues: a potentially more generally useful change here is that I've added an "auto_weapons" flag (default false) to shipdata similar to the existing "auto_ai". This is readable by JS in ship.autoWeapons, and the populator will only change the ship's assigned weapons (and occasionally equipment) according to role if it's set, letting us vary the weapon use in pirate, escort and hunter packs without having to define several variations on the same ship.

With the split into "light", "medium" and "heavy" for a lot of the combat-oriented roles, this should save OXPers some work (and also make it possible for OXP ships within the power range of core Oolite ships to potentially be safer against future rebalancing). OXPs which themselves modify existing ships with script will be encouraged to check this flag first: I'll be doing that with Skilled NPCs at some point, for instance.


In other news, it's now possible to save at non-main stations, provided those stations were added by a populator function marked as "deterministic", and aren't moving. Obviously for now that's just Rock Hermits.

cim wrote:

In other news, it's now possible to save at non-main stations, provided those stations were added by a populator function marked as "deterministic", and aren't moving. Obviously for now that's just Rock Hermits.

<looks up> That's very interesting - I like rock hermits.

Wow, this sounds great cim, the saving at non-main stations feature sounds like it's going to be possible for the oxp script wizards to really give the player outlaw status and ban them from the galcop stations until they clear their legal status

Griff wrote:

... give the player outlaw status and ban them from the galcop stations until they clear their legal status

The Viper jocks will be mightily relieved at not having to deal with me fighting my way into main stations!

cim wrote:

In other news, it's now possible to save at non-main stations, provided those stations were added by a populator function marked as "deterministic", and aren't moving. Obviously for now that's just Rock Hermits.

There, fixed that for you.

My only true gripe with the game has been removed - I am so happy...

A few new features in development.

Most importantly: commander name and save file name are now separate variables. You'll no longer get "Welcome to Lave, Commander CimM4" as you're half-way through a big OXP mission and following the good advice to keep some backup save games...
(BIG NOTE: you probably want to backup your save games before updating. I think it all works properly, but there could be some bugs, especially on the Mac port which I can't test personally)

As a result, you need a way to set your commander name (since setting the save file won't do it, though old save files will set the commander name up compatibly). So ... new mission screen feature: arbitrary text entry.

...and a new interface screen entry to let you enter your commander name.

While I'm poking around with names, I've added distinct variables for shipClassName (defaults to name) and shipUniqueName (defaults to the empty string), to reduce the need to try to parse ship names if you just want particular components. displayName still works as before, but if it's not set will be assembled sensibly from the name components. Again, there's an interface screen to let players set their ship name without having to go to the lengths of making an OXP if all they want is the name. (This will also be needed later in the core game development for the Scanner Targeting Enhancement label customisation, and for some of the comms in the new AIs)


Another prototype feature which needs more testing: I've added a hidden "anti-aliasing" parameter to the config settings in GNUStepDefaults. You'll need a reasonably good graphics card to make use of it without trashing frame rate (mine isn't up to it ) and so far it only works on the SDL ports (Windows, Linux), but it basically does what it says.

(Without on left, with on right)
If it works okay in testing on a range of graphics cards, then I might add it to the config menu somewhere. Please give it a go if you can.

cim wrote:

(BIG NOTE: you probably want to backup your save games before updating. I think it all works properly, but there could be some bugs, especially on the Mac port which I can't test personally)

Seems to work.

Thanks cim, both of these are great!

I asked for a text entry in HudRequests OXP to make a Logbook OXP, now I missing the documentation only.
If you describe then I put into the wiki and make some OXP.

Antialias is a must-have in any visual game imho, it is worth to backport into the 1.77.1 to get it without compiling. Please port it if it is possible.