Scripting requests

[Thargoid]

Makes sense.

One other thing I notice - shipLostTarget only seems to trigger when the target goes off scanner or is destroyed, but not if you change target or simply turn off the selector (press "U").

Would those two make sense to include as lost target scenarios?

[another_commander]

The naming is inconsistent. Since shipLostTarget() is already deployed and subject-verb-object is the most common word pattern in both English and Oolite message handler names, I suggest we switch to shipAcquiredTarget().

That (shipAcquiredTarget) was initially the name of the handler, but *points finger at Kaks* he changed it

[Kaks]

Oops!

Edit: I was under the impression we were now going to follow the subject-object-verb convention.

We might have to have a proper look at the various events names soon.
At the moment we have quite a mix. A semi-random look around the code reveals:

shipDockedWithStation, playerJumpFailed, playerStartedJumpCountdown, shipAcceptedEscort,
alertConditionChanged, playerDockingRefused, shipReachedEndPoint, shipCloakDeactivated, shipEnteredPlanetaryVicinity, and compassTargetChanged.

[Thargoid]

Could a third parameter be added to JS timers? At the moment we have triggering delay and frequency, but could a duration parameter also be added?

So for example at the moment if we want a timer to fire every 0.5s for 10 seconds (ie 20 times) we would have to add some fancy coding to either count the number of occurrences and manually stop the timer or use a second one to stop the first.

All do-able in scripting, but would be more elegant to include within the command. And of course if the duration is set to zero (or not set at all, as in all current timers) then it would last forever or until stopped.

Could that be implemented?

[JensAyton]

That would be trivial. The question then becomes, should it be a duration or a count? One or the other, but not both.

[Thargoid]

Either would do, given they're essentially the same thing. Count may be better, for if duration isn't exactly divisible by frequency it could get complicated.

[Cmd. Cheyd]

Request: A means to toggle the "scooping system" (Scooping Sound, HUD Icon) on and off via JS.

I believe Cmdr_James has offered to do a tentative implementation.

[Cmdr James]

Request: A means to toggle the "scooping system" (Scooping Sound, HUD Icon) on and off via JS.

I believe Cmdr_James has offered to do a tentative implementation.

I knocked up a very simple implementation based on the misjump stuff, so you can go PS.scriptedScoop = true; or false. Not sure its a wonderful way to do it, but it works. Anyone got an opinion?

[JensAyton]

I’m of the opinion that we’re trying to be in a feature freeze. ;-)

Also, I’m not sure what the name “scriptedScoop” has to do with the requested functionality.

[Cmdr James]

yeah, should be something like scoopOn I guess. Im not intending to commit it during a freeze. Mostly I wanted it discussed here so it doesnt just get forgotten.

[Thargoid]

A small request for 1.74.1 - for the scanner lollipop colour changing functionality, when it's script-set to null (to reverse previous scripted changes) and shipdata.plist key entries exist, can the code restore the colour to those rather than straight to the default scan class ones?

Of course where shipdata keys don't exist then go back to scan class default as now.

[Thargoid]

And another one, can mission.markSystem and unmarkSystem be linked to the script using it please, like setInstructionKey is? At the moment one script can unmark a system that was marked by another, which may lead to OXPs etc being broken if one unmarks a system and that mark is a critical part of what another is doing for a mission etc?

Also then perhaps the mark could also be linked to a short message that could appear at the bottom of the screen when the system in the long-range chart is selected? With message set as a missiontext key or something like that (similar to the current mission screen key methods).

[JensAyton]

A small request for 1.74.1 - for the scanner lollipop colour changing functionality, when it's script-set to null (to reverse previous scripted changes) and shipdata.plist key entries exist, can the code restore the colour to those rather than straight to the default scan class ones?

I consider this a bug fix. Done in r3497.

And another one

Noted.

[Thargoid]

A small request for 1.74.1 - for the scanner lollipop colour changing functionality, when it's script-set to null (to reverse previous scripted changes) and shipdata.plist key entries exist, can the code restore the colour to those rather than straight to the default scan class ones?

I consider this a bug fix. Done in r3497.

And another one

Noted.

Thank you - will update target autolock tomorrow to make use of the 1st one (will make the code a damn sight simpler without having to remember the previous setting).

[Kaks]

And another one, can mission.markSystem and unmarkSystem be linked to the script using it please, like setInstructionKey is? At the moment one script can unmark a system that was marked by another, which may lead to OXPs etc being broken if one unmarks a system and that mark is a critical part of what another is doing for a mission etc?

Also then perhaps the mark could also be linked to a short message that could appear at the bottom of the screen when the system in the long-range chart is selected? With message set as a missiontext key or something like that (similar to the current mission screen key methods).

One request I seem to remember from not too long ago was for marks to show in different colours, and possibly even shapes.

In this context, different colours could be assigned to different oxps automagically, a bit like different ships send different colour messages!