First pics of the prototype Numeric HUDv1 showing condition yellow and green. Work is about 90% complete with minor script tweaks and any potential bugfixes to be done.
Many late nights and all my spare time in the last 10 days have resulted in a nearly finished work. In a couple of days I should be ready to post a download link on a wiki page. As this hud has newly created gauges I will require all willing players to playtest this and post the results to this viewtopic. This is gonna be fun!!!
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.
Very nice, well done man! My only nitpick would be that the numbers seem to be a bit too big for my taste. Any chance of making them somewhat smaller or (even better) configurable in size?
Thank you another_commander! You are going to have fun with this. For the time being there will be the one size of number. The method used to make them requires that the the numbers be at least as thick as they are now. In version 2 I will attempt smaller sizes.
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.
You like? Perhaps a future hud style for one of your excellent ships.
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.
Just saw this: The target range on the HUD in the first screenshot does not agree with the range reported on the reticle. Are you calculating range to the center of the model? It should really be range to the edge of its bounding box.
If you can help me improve it to perform better, please. The updating of each gauge is as quick as it can be(0.25 seconds) and I suspected that a slight delay might have been the cause of the discrepancy in range but the value is determined just prior to updating the gauge. However the target reticle range updates constantly so while mine is waiting to update again the target reticle is getting ahead of my gauge. (0.25 seconds) is a long time in which my target range gauge remains static. The purpose of the target range gauge is to give range when the target reticle is off screen so the slight lag in updating will not be noticed much. This kind of gauge has been requested before several times so I decided to include it for testing in version 1. Someone's gonna be happy!
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.
If you can help me improve it to perform better, please. The updating of each gauge is as quick as it can be(0.25 seconds) and I suspected that a slight delay might have been the cause of the discrepancy in range but the value is determined just prior to updating the gauge. However the target reticle range updates constantly so while mine is waiting to update again the target reticle is getting ahead of my gauge. (0.25 seconds) is a long time in which my target range gauge remains static. The purpose of the target range gauge is to give range when the target reticle is off screen so the slight lag in updating will not be noticed much. This kind of gauge has been requested before several times so I decided to include it for testing in version 1. Someone's gonna be happy!
Are you using timers for your updates? If yes, then this is probably not what you would need. The 0.25 seconds update would most likely get in the way of gameplay, because the HUD information should really be updated per frame, as it happens with the standard "analogue" HUD. You may want to have a look at Frame Callbacks (see here for a starting point).
Regarding the code for calculating distance to the bounding box, it should be something like this:
Thank you another_commander. I will use collision radius and I will take a look into frame callbacks.
Thanks DH.
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.
As for using a timer the gameplay isn't seriously affected as I use an attacked function to immediately update the gauges as well. I will look into frame callbacks when I get a chance as frame updating for these gauges would be truly stellar!
Once again thanx another_commander for the excellent help!
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.
another_commander, I must sincerely thankyou for steering me to the Frame Callback script. I have now in front of me a target range readout that updates just as smooth and quick as the target reticle range readout. It's flipping cool!
Unfortunately I had to disable the rest of my script to do it as it was laid out in such a way that it will require a slight rearrangement to allow the whole hud to work the same way. Cut and paste is my best friend.
One concern I have at the moment is bogging down the hud(and the game) by updating too frequently(never thought that would be a problem). If it becomes a problem is there anyway to put a pause in the frame callback or should I simply use a counter in the script to return out of the separate sections before making any calculations or screen changes as in 1 time in 2(for example) I use a return at the beginning of the appropriate sections of script before they are executed.
In any event I will take just a little longer to try to get the whole script working like this with frame callback but if I can do it this hud is gonna rock!!! Yeehaw!
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.
You like? Perhaps a future hud style for one of your excellent ships. 
