Oolite Bulletins

I have been play testing Oolite 1.82 today for more hours than I should , and would like to add my note of gratitude to the developers and contributors to this release. I can only begin to imagine the life consuming nature of building this project. So hats off to you folks

I only got a few minutes of play time on 1.82 last night before getting mass locked by my wife. I must say, I love the slick way that the map screens switch over.

Imaginos wrote:

I love the slick way that the map screens switch over.

Then try pgup/pgdown keys: my default zoom is the smallest where system names still displayed since this feature is implemented.

Thanks! It's a beatyful release. I'm trying it now from Arch Linux repository.

The new planets are very nicely rendered, and with a FOV of 69 it looks more natural on 16:10 display.

My first impression of 1.82 is very, very good! Thanks guys

Imaginos wrote:

I only got a few minutes of play time on 1.82 last night before getting mass locked by my wife.

New feature in tonight's build - one which people have occasionally requested for some time. There's a new "concealment" parameter to planetinfo.plist and JS equivalents. This determines how much information about the system is unknown. It's a number, and the following values are recognised

0 (default): all information visible
100 or more: F7 screen shows no information, economy/gov/TL/star colour not visible on chart either
200 or more: system name is not shown
300 or more: system vanishes entirely from chart, will not be used in route plotting, cannot be targeted by player (NPCs can still jump to it, though)

There's quite a gap between numbers to allow for future gradations to be added - are there any you can think of which might be useful?


Some other recent changes and bug fixes:
- scanner 'V' lines now match the FOV setting (kanthoney)
- comms and console GUIs will now keep their screen position as defined in the HUD if you resize the screen. Previously ones with x_origin or y_origin not equal to zero would move relative to everything else if you did this.
- the radius property in planetinfo can be set by JS if you're outside the system
- some docking routine bug fixes
- cargo_carried should be processed correctly again to allow commodity names as well as keys
- equipment scripts work properly with carry-multiple items
- obscure bug in generation of secondary planet procedural textures fixed

cim wrote:

There's quite a gap between numbers to allow for future gradations to be added - are there any you can think of which might be useful?

50: 'Cosmetic'/'Observable' information only - i.e. average radius, inhabitants, planet name.

Could be used to simulate known planets that are potentially any of the following:

• Non GalCop worlds
• Other species being 'human-shy'
• Where the other details might not be as 'permanent', such as government, productivity and even economy*

* This need only be theoretically true, funtioning as an excuse to hide such useful information from a commander who has yet to visit such a system - therefore pro exploration.

A couple of requested JS features are now in the build:
player.ship.hudAllowsBigGui to query that HUD parameter (mainly when building mission screens)
and a new world event playerDockingClearanceExpired for when they run out of time.

Rolling and tumbling demo ships! Very cool! <wanders off singing a Rolling Stones song>

Imaginos wrote:

I only got a few minutes of play time on 1.82 last night before getting mass locked by my wife.

Are you saying she's fat? Haha!

I just saw cim working on multiple lasers on Git. So hyped!

Zireael wrote:

I just saw cim working on multiple lasers on Git. So hyped!

Likewise..

And here's a screenshot:

be still my beating heart.......

Multiple lasers will be available in tomorrow's build.
"weapon_mount_mode" enables them - "single" is the default value and disables them; "split" and "multiply" enable them - split splits the weapon damage across the mounts, and multiply effectively fits one full power weapon (with heat and energy costs to match) to each mount.

In split or multiply, "weapon_position_forward" and others must be specified as arrays of vectors even if there is only one weapon specified, so: becomes There is a backward incompatibility here for JS in OXPs: the weaponPositionForward (etc) properties are now arrays of vectors rather than vectors (even for "single"-mode ships). As this is a relatively recently added property which hasn't had a lot of use, I thought this was acceptable. If you want to make an OXP which uses this property compatible with <=1.82 and >=1.83, you will need to detect the version and read the property accordingly.

Do remember the joke about the mathematicians out hunting when you set up the weapon mount positions.

Abusing the system:


Fear my Lazors!!