I'm back with another question!
I want to add a custom dial which displays the reaminig time until entering witchspace as soon as the player starts the countdown.
So far so good - no problem until here... Set up a small script, edited a copy of HUD.plist, the bar fills nicely and smooth via a addFrameCallback...
So, that's it... ... not!
I realized that what I was doing was a replacement for the standard HUD. But that is not what I want to do.
Instead I just want to add this little drawCustomBar dial to the current HUD. So no matter what HUD is currently being used, the dial shows up.
I think you might be stuck with this one. HUD's are fairly static, so you can't really inject anything into them. And it would be difficult to anyway, as it would be hard to know what part of the screen was free for your additional element - each HUD puts things in different spots, so what might be OK for one might be on top of something in another.
But you still have some options. Using a Multi-function display may work for you. Or you can individually set the crosshairs for the player ship independently of the HUD, by using player.ship.crosshairs = "my_crosshairs.plist";. I hope that helps a bit.
But first off: thank you for your reply. Actually it just confirms what I suspected when I was browsing through the wiki.
Designing a complete HUD is on my list but more like "at the end of it..." I just wanted to check if this is possible. It would have made some design steps easier...
But I thought about the same problems when it comes to element placement on screen...
Thanks again, phkb (...and of course everyone else for reading )
Or you can individually set the crosshairs for the player ship independently of the HUD, by using player.ship.crosshairs = "my_crosshairs.plist";. I hope that helps a bit.
That one. Trivial problem if you can be bothered with the tedious task of creating the cross-hair files.
I'm thinking about that one for quite a while now...
But it raises some gameplay / compatibility questions:
When that animation is played it will completely replace the players crosshair.
When using a OXP-HUD, there's a good chance that the size / shape of the animated crosshair doesn't fit the layout
Plus the controlling script needs to check if the crosshair was changed (HUD selector) and override that setting as long as the animation plays. Afterwards switch back to the old one...
I think I'll create a custom HUD for my project. But I'll definitely use that one for something.
Thinking about it a bit more, another option is to do something like what Snoopers does when there is a news item to view when you're on your way to the station. It slides down a little graphic in the top right corner of the screen. You might be able to leverage some of that code to achieve what you want. I can't give you any more pointers that that, though. I haven't looked into Snoopers to see how it works.
CCL is using a shader/effect to show the overlays, right? Had a brief look at the package last night...
Yes, Cabal_Common_Overlay uses shaders for the overlays. It was (and still is) the only approach to reach what I had in mind when I wrote it back in 2012. And as long as HUD elements can't be created, injected and animated on the fly it doesn't make sense to change it. Since Oolite v1.80 it would be possible to do the basic overlays for non-shadered machines as well, because view_position is exposed to JS now, but the more advanced options (e.g. in Vector.oxp) still wouldn't work at all, or would be much more inefficient.
Just wondering... Don't know if it's a good idea to implement something with shaders without a simple fallback...
Please, don't give up developing if the idea is not working on non-shader setups. Players using non-shader setups just don't use it, thats all. And at least it's a proof of concept. If the idea proves to be solid enough, then the devs just might start thinking about including a more more generic support for it to the core game.
ah, misunderstanding... I just wanted to add the point to the discussion, that there should be something like a simple fallback, not giving up building something with bling, bling
Sure, a fallback would be nice, but I think it depends. Creating mechanisms which work for both cases usually means to limit the possibilities and/or makes it a lot harder to develop and maintain. And doing advanced (read CPU/Mem intensive) stuff on non-shadered machines is something to be considered carefully, because these machines are more likely lower-end machines. In the end it all boils down to what you have in mind .-)
... not! 
![[EliteWiki]](/images/elitewikismall.png){kind=small}
wiki