Scripting requests

[Wildeblood]

Expose the galaxy seed numbers as read-only, so that scripts can confirm they are actually dealing with the galaxy configuration the scripts' authors assume they are. (There is no Oresrati in my ooniverse.)

[Switeck]

AI.plist ways for mothers and other group members to send messages to each other like:
"INCOMING_MISSILE" = ("messageGroup: INCOMING_MISSILE", fightOrFleeMissile);

...and maybe add logic to avoid message loops.

"WITCHSPACE OKAY" = (wormholeEntireGroup); for instance can cause error messages in the log and even crash the game last time I checked.

Ideally, Police Vipers could ECM pirate missiles heading at trade ships and even the player's ship...but only if the Vipers have high or full energy.
...and maybe not getting shot at the time.

checkGroupOddsVersusTarget could probably use a rework considering how hugely varying each ship can be.

A scanForEnemies could locate/target hostile ships (pirates attacking other traders for instance) instead of only ships already attacking the scanning ship like scanForHostiles does. (besides Thargoids!) ATTACKED does well enough locating/targeting ships already attacking.

More diversity in escorts! Why aren't Morays, Geckos, and Kraits ever seen as rare escorts? Or even Cobra 3's...they're certainly fast enough. Even Anacondas might use something besides old Cobra 1's occasionally.

[CommonSenseOTB]

I think we have a bug!

I changed that function to

Code: Select all

   this.viewDirectionChanged = function(viewString)
   {
      player.commsMessage('Your view is now: ' + viewString);
   }

And it doesn't seem to fire properly in a few situations... BRB!

Just curious if there has indeed been any progress on this issue.

[Okti]

Currently we can check for the world scripts by JS but can not check for ship scripts, can there be a way to check before the next stable release?

[JensAyton]

Currently we can check for the world scripts by JS but can not check for ship scripts, can there be a way to check before the next stable release?

I don’t understand the question.

[Kaks]

Okti:
thatShip.script should give you all the the properties of the script currently attached to thatShip, in a similar way to what you get when you do worldScripts['thatOXPname'] / worldScripts.thatOXPname when you want to access world script properties.

Btw, I'm saying 'currently attached' because any oxp can always replace a ship's default script with any other script - at any time...



about the viewDirectionChanged event:
good-ish news: I'm now reunited with my dev computers - once jetlag clears off sufficiently, I'll be committing the fix, hopefully free of new, 'exciting' bugs... sorry about the delay guys - with hindsight I should have gone and expunged that brb from history...

[CommonSenseOTB]

In addition to the view direction displays there emerged the idea to be able to distinguish between various external views. Currently the JS-methods only return VIEW_CUSTOM for any external view.

Because the custom_views array can contain totally arbitrary viewpoints, there can't be generic return values for the JS-viewDirection checks. But what could probably be done is to add another optional parameter to the custom_views array, containing a string that would be returned by JS instead of VIEW_CUSTOM. If it isn't defined, the return value would still be VIEW_CUSTOM.

The request popped up in relation to HUD making, where HUD creators would like to be able to customize special ship HUDs not only for the different standard (internal) view directions, but also for different external (or custom) views.

In hindsight and for posterity it would really make some useful things possible if instead of just reading the strings I could also write them. In effect I would like to be able to have script be able to change the VIEW_DIRECTION , CUSTOM_VIEW to any one of the specific custom view descriptions in the ships shipdata.plist instead of having to scroll through a loop by pressing a button manually. Just one of many purposes I've thought of and plan to pursue, relates to the automatic selection of the zoom view in the Sniper Camera System.oxp that I'm working on. If the whole VIEW_DIRECTION was writeable it would be even much more useful and I would not object to that. Thank you.

[Kaks]

OK, from tonight's build .viewDirectionChanged should fire correctly. It took me a while to figure out the source of glithches that were plaguing my original implementation...

[Cmd. Cheyd]

• Ability to read player.ship pitch, roll, yaw values from JS
• Ability to trigger a witchjump from JS (We can change velocity and orientation. We can fire the ECM. Why can't we trigger a jump?)

[Eric Walch]

• Ability to trigger a witchjump from JS

What about exitSystem() that was added with 1.74? Works perfect and since 1.75 we can also set a destination system for the jump.

[Cmd. Cheyd]

• Ability to trigger a witchjump from JS

What about exitSystem() that was added with 1.74? Works perfect and since 1.75 we can also set a destination system for the jump.

Unfortunately, won't work for what I want to do. Maybe I wasn't clear enough. I want to do this on the player.ship.

Cause the ship to jump out of the system, if possible. If targetSystem is specified, it will attempt to jump to the specified system, otherwise a random system within range is chosen.

This method can fail for various reasons, in which case it returns false. It always fails for the player ship.

Edit: Basically what I want is the ability to 'Press H' from JS.

[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 .-)