Scripting requests

[Svengali]

I'd like to see Mouse support on missionscreens.

As the mouse cursor is already available on other screens it could open some interesting ways for missionscreens and would simplify user input. Maybe it would be enough to get the coordinates and a handler for one mouse button (left-click).

[another_commander]

I'd like to see Mouse support on missionscreens.

As the mouse cursor is already available on other screens it could open some interesting ways for missionscreens and would simplify user input. Maybe it would be enough to get the coordinates and a handler for one mouse button (left-click).

In my opinion, the inconsistency of having some GUI screens that do not allow choices by use of mouse while other screens allow it, is a bug. I believe I have a fix for the mission screens mouse handling, which is just too simple to be true and I am testing it now. (For those who would like to have a go, it is just adding the below line in PlayerEntityLegacyScriptEngine.m, - (void) setMissionChoices:(NSString *)choicesKey method, under line 1939 of the current SVN:

Code: Select all

[UNIVERSE setDisplayCursor: YES];

Unless someone can see a reason why this would not work, I would like to go ahead and commit it. It enables the mouse cursor only when there are choices in the mission screen, not when "Press Space Commander" is the only possibility.

[Eric Walch]

Unless someone can see a reason why this would not work, I would like to go ahead and commit it. It enables the mouse cursor only when there are choices in the mission screen, not when "Press Space Commander" is the only possibility.

It works for me, but only the selecting of the choices, not the confirmation of a choice. When you still need the key board for the confirmation, you can do the selection as well by keyboard.
But, i think that is not what Svengali had in mind. I think he mend screen coordinates, so he can put up a picture and find out at what part of the picture the player clicked.

[Svengali]

I think he mend screen coordinates, so he can put up a picture and find out at what part of the picture the player clicked.

Yep, Eric. That's exactly what I've had in mind. On missionscreens the cursor coordinates exposed to JS and a handler in case of a mouse click (or even more simple a handler with cursor coordinates passed as arguments).

So for me enabling the mouse cursor is a first step and if this qualifies as bugfix - even better .-)

[another_commander]

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.

[Svengali]

Muchas gracias a_c.-)

[CommonSenseOTB]

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.

[Okti]

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.

[Smivs]

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.

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.

[Switeck]

"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?

[Capt. Murphy]

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

[cim]

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.

[cim]

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)

[Thargoid]

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]

[Commander McLane]

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.