Oolite Bulletins

I see what you mean. However, this would go beyond the scope of bug fixing. Double clicking on menu items in gui screens does not take in consideration the position of the cursor at the time of double click, it just activates the selected item and this is consistent throughout all screens. Try it in the load screens and you will see: Select a savegame, then move the mouse to some neutral position and double-click. It will load the selected game.

For now, I would just apply the fix to enable mouse control in mission screens with choices and consider changing the gamewide behaviour for double clicks to take into account the cursor coordinates after 1.76.

Muchas gracias a_c.-)

Very interesting. Down the road there could be control panels that one can use by clicking the mouse on a button or lever or screen. That could be useful and immersive. Post 1.76 is gonna rock.

Can we have all properties for a ship that are defined in the shipdata.plist exposed to JS as read-only please?. After 1.76 ofcourse.

Currently, the only way to 'label' an NPC as 'Alien' is to give it CLASS_THARGOID. However giving an NPC this SCAN_CLASS also gives it certain qualities that may not be wanted.

The Wiki wrote:

Oolite uses scan_class internally to determine the behaviour of some ships .... don't allocate CLASS_POLICE or CLASS_THARGOID to ships lightly!

This became a problem while authoring Xeptatl's Sword, as the game's internal behaviour was overriding an AI which we wrote (for a Thargoid vessel), but could be even more of a problem for anybody wanting to introduce non-Thargoid aliens to the Ooniverse.
Would it be possible (after MNSR) to also have a CLASS_ALIEN made available? This would allow the introduction of other aliens who would show as 'Alien' on the Targeting system, but would not be affected by any of the game's internal mechanisms.

"the clearing of marked systems [is] the main reason I stuck in the ability to manually mark a system as a destination on the map so players can reinstate mission or contract destinations. It won't break a mission or contract if the system isn't marked on the map. Unfortunately there is no way in JS to check if a system is marked or not as it stands."

So...why not add a way for JS to check if a system is marked?

Making markSystem and unmarkSystem return true or false depending on whether the system is already marked or not would do the trick.

Capt. Murphy wrote:

Making markSystem and unmarkSystem return true or false depending on whether the system is already marked or not would do the trick.

Even better - though presumably much harder for the devs to implement - would be to give each worldScript its own mark/unmark namespace (as they currently have for F5 mission texts) and mark a system if any worldScript is marking it.

Could we have read-only access in the Station object to its docking queue and launching queue, please? (Making the length of the two queues available as a shader uniform would be handy, too)

A few thoughts now we're through MNSR:

• A ship/world script event this.equipmentRepaired(equipment), working as a mirror to this.equipmentDamaged(equipment), triggered when things get fixed (go from "EQUIPMENT_DAMAGED" to "EQUIPMENT_OK" rather than the other way about).
• A shipdata.plist key isPlayerWeapon or isSubWeapon or something similar - to make kills made by the entity be attributed to the player or mother entity that spawned it along with bounty, score (kill-score) and legal status adjustments if appropriate. Would ideally send shipDied of the victim the identity of the player or mother rather than itself. Purpose would be to allow the making by weaponry by OXP without the problems of breaking missions and having to mess around simulating bounty and kill awards etc. An extension of the idea of subMunition basically.
• Making beacon code read/write rather than just read - so beacons can be added to existing ships without having to do a swap-over to a like_ship version with it set. So ships can be tagged and untagged on the fly.
• An AI command performFollow - kinda like flyToRangeFromDestination but relating to a target and persistent until told to do otherwise. Ideally with some sort of spacing to allow for formation-flying (ad-hoc escort or group mode) with frustrated if not achieved in a given time period, plus the usual target lost etc if the target dies.

[/color]

Can a station's launch queue be made available as a property, preferably returning the to-be-launched ships in an array? Also, the current launch status, for instance, what, if anything, is preventing the station from launching whatever it was scripted to launch.

It's not so much useful for scripting, but would be very useful for debugging. For instance right now I am watching a station which was ordered by an NPC's AI (via safeScriptActionOnTarget: launchShipWithRole: ...) to launch a ship with a certain role. I am watching the scene for a couple of minutes now, all ships that had been waiting for docking have docked long ago, afterwards a random trader launched, but there is no trace of the ship I'm waiting for. And I don't know any way of debugging the situation and finding out what's happening.

Commander McLane wrote:

It's not so much useful for scripting, but would be very useful for debugging. For instance right now I am watching a station which was ordered by an NPC's AI (via safeScriptActionOnTarget: launchShipWithRole: ...) to launch a ship with a certain role. I am watching the scene for a couple of minutes now, all ships that had been waiting for docking have docked long ago, afterwards a random trader launched, but there is no trace of the ship I'm waiting for. And I don't know any way of debugging the situation and finding out what's happening.

When I was working on Localhero2 I've had a similiar situation. The missionship sometimes simply didn't launch even after minutes. So I had to find a solution. The trick was to place a fugitive nearby (a very weak pirate). This forced the station to react and after launching one or two police ships the missionship was launched too. Funny.

Commander McLane wrote:

. For instance right now I am watching a station which was ordered by an NPC's AI (via safeScriptActionOnTarget: launchShipWithRole: ...) to launch a ship with a certain role.

Yes, the launch queue is not accessible. Therefor I did al my tests with: this.testship = station.launchShipWithRole("myRole"). You than always have access to the ship by examining this.testship, even when still docked. And for mac-only you can use: this.testship = station.launchShipWithRole("myRole").inspect(). That will immediately open a target inspector for the ship. But, it needs JS, it will not work with your old legacy example.

Could we have the ability to access the 'special subentities' flashers and exhausts as well please? for example something along the lines of this.ship.flashersCount, this.ship.flashers[x], this.ship.exhaustsCount, this.ship.exhausts[x] and ability to change their positions, size, color etc. accordingly. The ability to turn specific flashers (and maybe exhaust trails) on and off as well would be nice too.

Can we get a modification to system.info so that when we assign a texture, alter a description, change the sun's corona, etc. - we can pass a parameter that'll tell Oolite NOT to add the change to the save-game file? The default could be to still do so, so it maintains backwards compatibility, but I'd like to be able to tell it NOT to do this.

DH_Systems v1 is bad enough in that I bloat the save-game with the corona information for every system, but v2 was going to have to do it for a whole host more stuff. I don't want to be the cause of 20K lines of crap in someone's save-game. Please, tell me we can?