Is it possible to make the '@' placeholders in descriptions.plist accessible in JS?
In oolite-locale-functions.js, I do this manually: string = currencyFormat.replace("%@", string);. I don’t plan to provide a more convenient way to do this, though.
In fact, I want to do away with the %@s and use [named_expansions] throughout for Oolite 2. They’re easier to read, and using user-provided strings with the %@ expansion mechanism is somewhat unsafe. (Actually, it’s bloody dangerous, at least under GNUstep. There’s a very dangerous feature of this type of formatting string that’s deliberately left out of the Objective-C version in Mac OS X. I hadn’t thought to check, but unfortunately it is implemented in GNUstep. I’m going to add extra verification code to filter it out.)
For reference, the way to use custom named expansions in JavaScript is:
In other words: I can use global.formatCredits(10, true, true) to format the number according to my localization, but I can't combine this with the localized version of the string 'Bounty: '. Correct?
In other words: I can use global.formatCredits(10, true, true) to format the number according to my localization, but I can't combine this with the localized version of the string 'Bounty: '. Correct?
The split("\n")[0] gives you the first line, because the second line says “Total: %@”. I’m not sure how, but you seem to have missed that.
Oops! I 'missed' (rather I accidentally deleted ) the second line when I did my localization. In my German Oolite it isn't there. That's why I was wondering why the thing was named bounty-@-total-@ in the first place.
And that's why I never get a total displayed after killing something.
EDIT: To be honest, I also needed you to spoon-feed me the correct syntax. My grip on JS isn't actually that good. But now I have deducted from your line of code the complete message I want:
where trueBounty is the bounty for the current railgun kill, after accommodating the exception for asteroids. And this now looks exactly like the game-generated message.
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 the pursuit of the creation of new types of hud gauges it has come to my attention that weapon temperature and altitude have no output to JS and therefore the values can't be used in the the creation of new gauges. This has applications in the creation of numeric, needle(analogue) , and various types of animated(button) gauges. In addition it has direct application to allow cleaning up/better drawing of the rounded pie gauges to eliminate the trailing edge on the circumference. Currently it appears I will not be able to improve the weapon temperature and altitude versions of the rounded pie gauges unless there is a JS value to read. I would therefore like to have this added as a feature request if possible.
Take an idea from one person and twist or modify it in a different way as a return suggestion so another person can see a part of it that can apply to the oxp they are working on.
In the pursuit of the creation of new types of hud gauges it has come to my attention that weapon temperature and altitude have no output to JS
I already told you in the other thread that you can calculate altitude in JS as distance of the player ship to the closest celestial body minus the radius of that body. So you don't need an additional JS-property for altitude.
In the pursuit of the creation of new types of hud gauges it has come to my attention that weapon temperature and altitude have no output to JS
I already told you in the other thread that you can calculate altitude in JS as distance of the player ship to the closest celestial body minus the radius of that body. So you don't need an additional JS-property for altitude.
Thankyou Commander McLane the point was well taken however I was only thinking that the bar gauges already have a variable that they are using and that having a JS of them to read might not be a difficult addition. These would then allow created gauges to use the exact same values and simulate the same units or scale. Developers of all oxp's may also benefit not just huds. Hud developers even myself may find it cumbersome and difficult to aquire altitude consistently in the manner suggested. Novices will have much difficulty. As it is, weapon temperature will still be needed so why not provide both? This IS only a request to add a feature. In the meantime I will not have a choice as either fitered entities or an array of all planetary bodies or somesuch(probably a simple solution) will provide the solution to altitude. I have yet to research the exact solution fully. (For testing purposes I have been using a simple reference to the mainPlanet as my primary focus right now is developing the numeric gauge itself.) One must keep in mind the effect of oxp's that add plenetary bodies to the system. Weapon temperature ,however, is out of reach for now.
If you really want to help a fellow oxp' er out please feel free to offer up a tried or tested routine that works properly under all conditions. Scripting is not my strong suit. Only just started scripting in November. How strong could it be? Time permitting I WILL find the correct solution but if one is already available and in use ,specifically, it would save me some time and help future hud developers to have tested code involved. As it is creating new hud gauges is very time consuming and difficult considering the hardcoded restrictions.
Take an idea from one person and twist or modify it in a different way as a return suggestion so another person can see a part of it that can apply to the oxp they are working on.
It turns out my concept of time is 'slightly' different to earth based clocks...
I did make the necessary adjustments to the code, but a couple of things (or three) distracted me from committing those changes when I had the opportunity to do so.
At the moment I'm 'a few' miles away from my oolite computer - so I've little chance of doing much Oolite dev stuff for the next couple of weeks... the fix should be there in .3, though!
I find the AI's in certain stages returns two messages at once for the outcome, as an example 'TARGET_DESTROYED' and 'TARGET_LOST' is added to the message stack at the same, and TARGET_LOST always has the high priority. So it is not easy to understand if the target is destroyed at one glance.
I try to overcome those situations by checking in JS if actual target is destroyed or not.
Another way is to use another state in the AI, to find out what happened really.
I know we are in a future freeze state at the moment, but a javascript object for the pending messages in AI and methods to remove individual ones may solve most of the problems I believe.
You are right that the message order is not always whet you wish. In this case it does not really matter for most of the AI if you get a 'TARGET_DESTROYED' or 'TARGET_LOST'. The reaction will probably be the same. The first is generated first but handled later. As you already noticed, does the destruction trigger first and JS will react on it first. Changing that will potentially crippling existing AI.
You are right that the message order is not always whet you wish. In this case it does not really matter for most of the AI if you get a 'TARGET_DESTROYED' or 'TARGET_LOST'. The reaction will probably be the same. The first is generated first but handled later. As you already noticed, does the destruction trigger first and JS will react on it first. Changing that will potentially crippling existing AI.
You are right about it may cripple the existing AI's, but a read only array of deferred messages on the ships AI, when it goes to another state may help to understand what happened in the previous state actually script wise.
As an example State1 may require a DESIRED_RANGE_ACHIEVED, and the second one may require that as well, if DESIRED_RANGE_ACHIEVED is in the deferred messages from the first stage, it confuses the AI.
a read only array of deferred messages on the ships AI, when it goes to another state may help to understand what happened in the previous state actually script wise.
When the deferred messages are not yet in the executing array, they can be removed with a "dropMessages: " command. And I think it should work in your example to remove the message that could be there.
I don't know if the deferred messages can be read by script. The target inspector for the mac does list that array with pending message, but JS can not access it as far as I know.
But you are right that complex scripting confuses AI quite fast. As soon as the task becomes difficult, JS is the way to go.
It turns out my concept of time is 'slightly' different to earth based clocks...
I did make the necessary adjustments to the code, but a couple of things (or three) distracted me from committing those changes when I had the opportunity to do so.
At the moment I'm 'a few' miles away from my oolite computer - so I've little chance of doing much Oolite dev stuff for the next couple of weeks... the fix should be there in .3, though!
) the second line when I did my localization. In my German Oolite it isn't there. That's why I was wondering why the thing was named 
