For information and discussion about Oolite.
https://bb.oolite.space/
Just curious if there has indeed been any progress on this issue.Kaks wrote:I think we have a bug!
I changed that function to
And it doesn't seem to fire properly in a few situations... BRB!Code: Select all
this.viewDirectionChanged = function(viewString) { player.commsMessage('Your view is now: ' + viewString); }
I don’t understand the question.Okti wrote: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?
- with hindsight I should have gone and expunged that brb from history... 
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.Commander McLane wrote: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 thecustom_viewsarray can contain totally arbitrary viewpoints, there can't be generic return values for the JS-viewDirectionchecks. But what could probably be done is to add another optional parameter to thecustom_viewsarray, 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.
What aboutCmd. Cheyd wrote:
- Ability to trigger a witchjump from JS
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 theEric Walch wrote:What aboutCmd. Cheyd wrote:
- Ability to trigger a witchjump from JS
exitSystem()that was added with 1.74? Works perfect and since 1.75 we can also set a destination system for the jump.
player.ship.
Edit: Basically what I want is the ability to 'Press H' from JS.Cached Copy of Wiki wrote: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.
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,Svengali wrote: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).
- (void) setMissionChoices:(NSString *)choicesKey method, under line 1939 of the current SVN:
Code: Select all
[UNIVERSE setDisplayCursor: YES];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.another_commander wrote: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.
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).Eric Walch wrote: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.