Progress

[Pleb]

I suppose the next step would be 4K support... But saying that does anyone here have SLI and a 4K display?

[Smivs]

...in the case of multiple monitors, the game always launches on the primary one...

Not here it doesn't!
When I start Oolite it always opens on the secondary monitor, and I have to move it to the primary. This is a bit annoying but I've learnt to live with it.
Oolite v1.80
Linux Mint 16
Nvidia GTX550ti graphics card
Primary monitor 1440x900 LCD monitor (via VGA)
Secondary monitor 1920x1080 Plasma TV (via HDMI)
I don't know if it is relevant, but the primary screen is set to the right, secondary to left.

[another_commander]

...in the case of multiple monitors, the game always launches on the primary one...

Not here it doesn't!
When I start Oolite it always opens on the secondary monitor, and I have to move it to the primary. This

Windows and Linux have completely different code paths for handling their window once it's been created. I was referring to the Windows port exclusively in my earlier post.

[Smivs]

I was referring to the Windows port exclusively in my earlier post.

Ah, OK. Thanks.
Is this something that could be looked at/fixed for Linux sometime?

[Getafix]

Is this something that could be looked at/fixed for Linux sometime?

Between "looked at" and "fixed" there is the same distance as between "hope" and "disappointment".
For the time being I can promise you "hope".

[cim]

A few JS modifications today: the following ship attributes are now writable in JS:
maxRoll, maxPitch, maxYaw, maxSpeed, maxEnergy, energyRechargeRate, thrust (was already writable for NPCs), maxThrust. This should allow variable-performance ships without an excessive amount of messing around with destroying and recreating them in-flight.

Note that if you write to these for the player ship, this will be discarded when the game is reloaded from save. Note also that the value of energyRechargeRate includes the boost from EEU/NEU. This means that the following two sequences do not give identical results:
player.ship.energyRechargeRate += 1; player.ship.awardEquipment("EQ_ENERGY_UNIT");
player.ship.awardEquipment("EQ_ENERGY_UNIT"); player.ship.energyRechargeRate += 1;
For the player ship if you're adding or subtracting you need to check which (if any) energy unit is fitted first. For NPCs energy units don't change the recharge rate even if fitted, so this is easier.

Setting an attribute to a particular value should generally just be equivalent to creating a ship with that value in the first place - the exception is that setting a 'max' attribute to below the current value of that attribute is legal, and will generally set the current value to the new max value on next check (the time the next check occurs is usually the next frame or possibly later in the current frame, but this may not necessarily be true for the turn rates, especially not for the player ship, so be careful here).

[Redspear]

A few JS modifications today: the following ship attributes are now writable in JS:
maxRoll, maxPitch, maxYaw, maxSpeed, maxEnergy, energyRechargeRate, thrust (was already writable for NPCs), maxThrust. This should allow variable-performance ships without an excessive amount of messing around with destroying and recreating them in-flight.

Thanks cim, I'd been waiting for that.

Must have a play at some point.

[cim]

As well as the combat balance tweaks mentioned in that thread (adjusted odds calculations, reduced missile damage variation) I've been poking around with the torus drive a bit.

Two experimental changes in today:
- deceleration from torus when mass-locked is a lot quicker. You shouldn't drop off torus so close to the pirates that they're firing on you before you've seen them, now.
- very experimental: torus speed now depends on your distance from the nearest real [1] object (approximately as discussed here onwards, a couple of years back). If you're just going up and down the lanes in a normal-sized system you probably won't notice anything, but if you're heading to really distant objects - a station put at OUTER_SYSTEM or OUTER_SYSTEM_OFFPLANE locations, for example - then you should reach them a little quicker depending on how much is on the route. It might be a little noticeable with OXPs that increase the sun-planet distance, too, though again probably not that noticeable if you head roughly down the lane.

See what you think.

[1] A real object is essentially any object you can collide with - ships, stars, planets as opposed to waypoints and visual effects.

[Zireael]

Updating my trunk build now. Can't wait to see some of those changes.

[Commander_X]

As well as the combat balance tweaks mentioned in that thread (adjusted odds calculations, reduced missile damage variation) I've been poking around with the torus drive a bit.

Two experimental changes in today:
- deceleration from torus when mass-locked is a lot quicker. You shouldn't drop off torus so close to the pirates that they're firing on you before you've seen them, now.
- very experimental: torus speed now depends on your distance from the nearest real [1] object (approximately as discussed here onwards, a couple of years back). If you're just going up and down the lanes in a normal-sized system you probably won't notice anything, but if you're heading to really distant objects - a station put at OUTER_SYSTEM or OUTER_SYSTEM_OFFPLANE locations, for example - then you should reach them a little quicker depending on how much is on the route. It might be a little noticeable with OXPs that increase the sun-planet distance, too, though again probably not that noticeable if you head roughly down the lane.

See what you think.

[1] A real object is essentially any object you can collide with - ships, stars, planets as opposed to waypoints and visual effects.

Just a quick reminder, the torus speed changes are _always_ noticeable through sound, when a sound effects OXP/OXZ is installed (e.g. BGS, HawkSound).
I was almost ready to suspect viruses in my environment when the acceleration/deceleration sounds started to kick in without any visual clue (before I remembered your post, that is ).

[cim]

Just a quick reminder, the torus speed changes are _always_ noticeable through sound, when a sound effects OXP/OXZ is installed (e.g. BGS, HawkSound).

Good point - if we keep this, OXPs will probably need to decide whether to handle speed changes taking place above the base torus speed limit differently (and other OXPs which check for torus speed by checking if current speed == 32*base will also be wrong, but due to floating-point inaccuracy might already be wrong anyway)

[Cody]

... deceleration from torus when mass-locked is a lot quicker.

<grins> Yeah, ain't it just... I'd swear I felt the straps dig into my shoulders!

[cim]

Some tweaks for the OXZ manager under development at the moment.

Filtering:



Current filters are: "none", "not yet installed", "update available", "author is ...", "keyword is ..." (press 'f' to set)
There was a suggestion earlier for "recently added/updated", which will be added but requires a bit of adjustment of the manifest API first. Are there any other filters which people would find useful to have?

Information pages:

You can add a few extra paragraphs to the "description" property, and they'll appear on an 'info' page accessible by pressing 'i'. Your first paragraph will be displayed on the OXZ listing as now, so keep that one fairly short.

Extraction:
You can now press 'x' to extract managed OXZ files into a (disabled) OXP in your main AddOns folder.

If initial testing goes well all of this should be available for you to try in a nightly build some time next week.

[Bogatyr]

Speaking of the expansion pack manager; I'd like to see the left and right arrow keys on the expansion pack manager page forwards / backwards regardless of what line is currently highlighted, like how the current equipment list works. It's such a pain to have to navigate to the More/Previous lines before being able to move forwards/backwards.

[Norby]

Are there any other filters which people would find useful to have?

"Tag is ..."