Page 23 of 56
Posted: Tue Apr 13, 2010 8:23 pm
by 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?
Posted: Tue Apr 13, 2010 8:39 pm
by another_commander
Ahruman wrote: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
Posted: Tue Apr 13, 2010 9:43 pm
by 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.
Posted: Sun May 09, 2010 11:42 am
by 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?
Posted: Sun May 09, 2010 12:38 pm
by JensAyton
That would be trivial. The question then becomes, should it be a duration or a count? One or the other, but not both.
Posted: Sun May 09, 2010 1:15 pm
by 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.
Posted: Tue Jun 01, 2010 8:08 pm
by 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.
Posted: Tue Jun 01, 2010 8:15 pm
by Cmdr James
Cmd. Cheyd wrote: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?
Posted: Tue Jun 01, 2010 8:22 pm
by 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.
Posted: Tue Jun 01, 2010 8:27 pm
by 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.
Posted: Wed Jun 09, 2010 5:47 pm
by 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.
Posted: Fri Jun 11, 2010 11:32 am
by 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).
Posted: Fri Jun 11, 2010 11:49 am
by JensAyton
Thargoid wrote: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.
Noted.
Posted: Fri Jun 11, 2010 3:53 pm
by Thargoid
Ahruman wrote:Thargoid wrote: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.
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).
Posted: Fri Jun 11, 2010 11:09 pm
by Kaks
Thargoid wrote: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!
