Oolite Bulletins

Thargoid wrote:

Hmm, ok. But there's still the question of both the background transparency and more importantly having the ship control keys still accessible with the mission screen visible.

Fair enough point for Gimbal's use....however inflight Mission Screens could be used for all sorts of other useful Shenanigans.

mission.runScreen works pretty well inflight. The only limit is that you can't display a model there. But using missionscreens inflight is simply a bad design decision for OXPs as it takes away control from the player. OXPs can use other ways if they really need to display additional infos or to give the player options.

Is it possible to change player-ship's cargo capacity on-the-fly?

I have a ship in the pipeline, that has 2 subentities that can be shot off - it would be cool if losing the subents would reduce cargo space and repairing them would give the space back.
I think I could get away with one such subent with a bit of scripting & invisible Lagre Garco Bay, but not with two...

Zieman wrote:

Is it possible to change player-ship's cargo capacity on-the-fly?

I have a ship in the pipeline, that has 2 subentities that can be shot off - it would be cool if losing the subents would reduce cargo space and repairing them would give the space back.
I think I could get away with one such subent with a bit of scripting & invisible Lagre Garco Bay, but not with two...

Have a look at Thargoid's HyperCargo and Vortex oxps for some ideas on 'virtual' cargo bays. Then beware that you'll need to make them compatible with cim's new Cargoes, and I'll have to update Illegal Goods Tweak. But don't let that put you off it sounds like a fun idea.

Svengali wrote:

But using missionscreens inflight is simply a bad design decision for OXPs as it takes away control from the player.

That would be the only reason I'd ever use them in flight - the player wouldn't be in control, they would be a kind of holding screen whilst a script does all sorts of weirdness that you don't really want the player to see the effects of.

Capt. Murphy wrote:

Svengali wrote:

But using missionscreens inflight is simply a bad design decision for OXPs as it takes away control from the player.

That would be the only reason I'd ever use them in flight - the player wouldn't be in control, they would be a kind of holding screen whilst a script does all sorts of weirdness that you don't really want the player to see the effects of.

One is used for LongRangeScanner as a cheat or debugging tool . I know it is not elegant but no other choice. Also as Thargoid said same aproach is used in Vortex. If you are in need to give inflight choices for the player there are two options: mission screens or custom messages via a special equipment. Choice is up to the scripters.

Can anyone tell me what I'm doing wrong in attempting to add a Passenger via script / debug console.
The eta is in the future, there is space for a passenger, but the addPassenger method is returning false?
Current trunk.
Edit to add - it appears to be a minor Oolite bug when you purchase a new ship or use the new player.replaceShip method. If the current ship has a passenger when you purchase or replace the ship examining the save files before and after shows that <key>passenger_record</key> isn't updated, although <key>passengers</key> is. And attempting to add a passenger with the same name as one present in <key>passenger_record</key> fails, even if <key>passengers</key> is empty.

Capt. Murphy wrote:

Edit to add - it appears to be a minor Oolite bug when you purchase a new ship or use the new player.replaceShip method. If the current ship has a passenger when you purchase or replace the ship examining the save files before and after shows that <key>passenger_record</key> isn't updated, although <key>passengers</key> is. And attempting to add a passenger with the same name as one present in <key>passenger_record</key> fails, even if <key>passengers</key> is empty.

Thanks - will fix.

EDIT: fixed in r4892. Since it could theoretically cause problems in 1.76 in very obscure circumstances, fixed in maintenance as well as trunk.

Can anyone explain why this isn't allowed in a JS script:
Can I not add passengers to a ship using stored variables?

Pleb wrote:

Can I not add passengers to a ship using stored variables?

It should make absolutely no difference whether the function is called with stored variables or not.

Just to check the obvious things first:
1) The ship has at least one empty passenger cabin
2) The ship does not already have a passenger with the same name as missionVariables.mission_taxi_passenger

Assuming that's not it, feel free to PM me a link to the OXP and I'll have a look for more obscure things.

Possibly relevant or possibly not (depending on where you are getting your variables from) but the wiki entry http://wiki.alioth.net/index.php/Oolite ... passengers is wrong in the passengers[0].fee is not returned as an integer as stated but a string (albeit a number in a string). Same goes for http://wiki.alioth.net/index.php/Oolite ... #contracts

Not sure if this is a documentation error or a bug.

However both addPassenger and awardContract require fee to be a number.

Conversion is straight forward. e.g this.fee = Number(player.ship.passengers[0].fee)

Capt. Murphy wrote:

However both addPassenger and awardContract require fee to be a number.

The interface between Javascript and the Oolite engine is fairly flexible about this - provided the number is recognisably a number, it can be 528, 528.0, "528", or "528.0". If the problem is the JS type of a variable being provided to a function, I'll be surprised.

As for the Wiki entry, that looks more like a bug rather than a documentation error (since all the other numeric values are both documented as and returned as numeric types), and I'll fix that now.

EDIT: fixed in r4900. Just in case there's some OXP code that relies on the old type, I won't push this change to the maintenance branch yet.

For reasons unknown I've managed to get my code to work now. I still can't explain why it wasn't working, but I think it was to do with the time...however it is working now so never mind cheers anyways though.

Pleb wrote:

For reasons unknown I've managed to get my code to work now. I still can't explain why it wasn't working, but I think it was to do with the time...however it is working now so never mind cheers anyways though.

Looking at the code, there are only two reasons when adding a contract fails:
A: When there is no free passenger cabin.
B: When that passenger is already present.

I assume B can easily happen during testing. At least it should be added to the wiki that there can not be two passengers with the same name. (edit: done)