Oolite Bulletins

I didn't mean the deletion or restoration of your functions, but the last line in the else block executes to presumably setup or initialize the HUD after the HUD is changed. All I did was scan your code quickly and guessed would fix the problem, so I executed it using the debug console. I didn't alter your code because I'm not sure if I need all of that function or just parts of it (or more than that just that). I got the clock & crosshairs and moved on. Sorry but the complimentary free debug offer has expired

I knew I was missing some equipment, so I searched for 'awardEquipment' (you have 31) but the clock only showed up in shipWillLaunchFromStation() and, as the Brits say, Bob's your uncle. I haven't noticed any obvious problems but I'm new to this HUD. As a temporary fix, just insert that one line: It doesn't appear that it matters if it goes before or after shipExitedWitchspace() but who knows.

cag, would I be right in assuming you were in flight when you changed HUD's?

Yes. I had several HUDs I wanted to check out. When I launched, I was set to one that came with HUDselector.

Perfect. Thanks! I imagine updates will be on the way (for this and Xenon HUD).

@cag Xenon HUD has been updated, I will take a look at the code and make a new release as soon as I can.

A new version 1.5 is now available in the extension manager. I have merged the improvements made by phkb on his Xenon HUD (version 1.5.5), including improved HUDSelector integration and performance improvements (thanks, phkb!!).

@cag would you care to take a look and see if things are looking better on your side?

That seems to have fixed it, with one small caveat. Calling shipWillLaunchFromStation() awards me the equipment, so that's good, but it makes an assumption, that you're looking forward. If you have, say, a mining laser w/ different crosshairs in a side view and are in that view when you change HUDs, you get the wrong crosshairs until you cycle your weapon. It's a simple fix, just change line 356 from to I was having fun testing this, in that HUDselector was blowing up, but I cannot reproduce it after all the changes you made. There's a programmer's axiom that says "if you can't reproduce a bug, it never happened"

I'd be interested to know why you (or phkb) switched to storing data in the player's ship's script. You take a bit of a performance hit doing that. You can get much of that back by following Norby's rule that if you use it more than once, store it locally. For example, change to so you only looking for the script object once for the entire function. 'p.script...' appears 179 times over ~20 functions. Same goes for player.ship.
Take $scannerAnimationFrame2 for example. It profiles at 1.263 ms on my machine. By changing it to: it now takes only 0.307 ms. Not much, you say? On my PC, your HUD runs at just under 40 frames/sec. That means there's only 25 ms between frames (1/40) so every little bit helps.

Let me know when you settle on a stable version of the script. I want to take a crack at putting it all in a 'closure', where for some objects, you only fetch them once per game.

cag wrote:

I'd be interested to know why you (or phkb) switched to storing data in the player's ship's script.

That was me, and the reason was to try and avoid going to "worldScripts" for each reference. It seemed to profile better when I did this (on my machine anyway), but it's a bit hard to gauge. I missed the extra step of applying a local to the script object, so I'll be doing an update with that. Thanks!

cag wrote:

I want to take a crack at putting it all in a 'closure'

Can't wait to see it!

Many thanks to both of you, cag and phkb! These fixes and suggestions are excellent. I will work through what you guys wrote and try to make another update soon. I really appreciate all the feedback!!

@cag I have implemented these modifications you suggested and the performance improvement is really huge, many many thanks!! I going to try to get a couple of other things done (fix some other bugs and perhaps add some other things I had on my mind) and make a new release soon.

In case it's not on your list, there's another minor issue in shipWillLaunchFromStation(), just after you award the clock equipment: Like w/ crosshairs, you're awarding w/o regard to the view the player is in. Perhaps a call to viewDirectionChanged(player.ship.viewDirection) after the call of shipWillLaunchFromStation() in $HUDSelectorCallBack() will work. ...<hacking>...
It seems to fix the problem. I'll keep running w/ it and let you know if something bad happens.

Thanks again, cag, phkb has taken care of that on his Xenon HUD and so did I on the Dangerous HUD. I am just trying to solve one more thing before a new release, and then all these suggestions by you will be available to everyone. Many, many, many thanks.

Hi all, version 1.6 has been release with the following changelog:

- performance improvements (many thanks to cag and phkb for all the help!).
- improvements to the minimal crosshair mode: when crosshairs are set to be visible only in red/yellow alert, the gauges are now visible though very transparent.
- fixed a bug which caused JS errors when escape pod was launched.
- HUD now compatible with Breakable HUD/IFF Scanner OXP.

Concerning the minimal croshair mode, this is the regular mode:


And this is the minimal crosshair mode, which turns the main gauges very transparent while in green or green/yellow alert, and they come back to normal when in red alert:

I just uploaded version 1.6.1 fixing a small typo in the code causing a small error.

This is awesome. I once made an ED HUD which was just a recolor of the standard HUD to orange, but I so dearly wished I could pull off a cockpit somehow. Thanks for making this, gsagostinho!