Page 22 of 56
Posted: Fri Apr 02, 2010 9:16 pm
by Svengali
It would be pretty nice if performAttack could be influenced by scripts.
The current way - I think - works pretty well for escorts in groups of ships and prevents the player from being roasted too fast, but single ships with odd IDs are still problematic in mission contexts, specially if wormholing or heavy injector usage would break the story.
So maybe it would be an option if the decision (check odd/even) would consider some other factors too. Bounty, accuracy and a scriptable (read/write) property - e.g. Ship.maxAggression (JS) and max_aggression (shipdata) - maybe?
Posted: Tue Apr 13, 2010 7:52 pm
by Thargoid
We have a world script event for shipLostTarget, but we seem to be lacking in it's mirror image - shipAcquiredTarget(target).
Would such a trigger be possible, firing when the ships target goes from null to something, or something to something else?
Posted: Tue Apr 13, 2010 7:58 pm
by another_commander
Thargoid wrote:We have a world script event for shipLostTarget, but we seem to be lacking in it's mirror image - shipAcquiredTarget(target).
Would such a trigger be possible, firing when the ships target goes from null to something, or something to something else?
We actually do have it already in trunk: ship.shipTargetAcquired(target).
Posted: Tue Apr 13, 2010 7:59 pm
by Thargoid
Now that's what I call service! 
Posted: Tue Apr 13, 2010 8:03 pm
by JensAyton
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().
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.