Oolite Bulletins

NumericHUDv2.1.oxp is now available.

Now with a redesigned crosshair and a few minor script tweaks.


Download here:

http://wiki.alioth.net/index.php/Numeric_Style_HUDs


Playtest results and comments are welcome.

Have fun with this!

Cheers!

I will have an interesting picture to post in a few days or so when it's ready. Just tweaking this crazy discovery.

Hint: works with 1.75.3 and earlier and allows to put on the hud something hud designers might have used had they known about it.

hehe!

CommonSenseOTB wrote:

1.75.3

This is not the version you're looking for!

Or, may I advise all commanders to install the new - improved - 1.76 stable version, rather than any of the old - inferior - test versions?
Looking forward to your crazy discovery, though!

A most triumphant sneak pic!


NumericHUDv3 WIP by CommonSenseOTB, on Flickr

This discovery is compatible with 1.76 and earlier versions of oolite and it will be used both for version 3 of the numericHUD and a version 2 of the chupacabraHUD. Both should be available in the next 4 or 5 weeks.

Cheers!

Congrats CSOTB - you're persistence with this has certainly paid dividends for the whole community (especially for those who have always desired a "proper" HUD (numeric) display)

NumericHUDv3 WIP by CommonSenseOTB, on Flickr

It's ready to go. Final shakedown and wiki page/pictures to do. Only a few days left.

And I have a surprise, something cool has been done to how the gauges operate and it's not visible in this picture, haha!

Here it is: NumericHUDv3

Leaving the station

NumericHUDv3 #1 by CommonSenseOTB, on Flickr

Picking a fight

NumericHUDv3 #2 by CommonSenseOTB, on Flickr

Dogfighting

NumericHUDv3 #3 by CommonSenseOTB, on Flickr

The big improvement in number design came about as I was experimenting with the selector drawStatusLight and experimenting with its' dimensions led me to discover that if one dimension was under 4 that you would actually get a grey line drawn instead of the status light. So any hud could use this technique to draw equipment icons, animated crosshairs, custom bar gauges both straight and curved, custom number or letter animations, etc, etc.

The real improvement in NumericHUDv3 comes from keeping the normal readouts just barely visible and not distracting while making them glow/pulse a bright color to draw your attention to the gauges that need to be monitored closely. This concept works quite nicely, particularily during combat when your attention is focused on killing or being killed rather than the gauges and NumericHUDv3 is now quite close to what I had originally envisioned for a numeric hud display when I first set out to make version 1 over 10 months ago.

Enjoy yourselves and have fun with this product!



Download link:

http://wiki.alioth.net/index.php/Numeric_Style_HUDs

@CommonSenseOTB

I've never tried your previous HUDS but thought it's about time i did. And now i feel that i've missed out as your HUD is awesome mate. Don't think i'll go back to my previous HUD now. Awesome work!

Thanks for all your hard work, appreciated!

Jon

Wahoo! That looks so much like what I'd hoped V3.0 would look like that it's amazing!

Excellent work, sir!

<back later.. got some Cobra flying to do>

Every now and then in my work, I accomplish something remarkable, be it some cool script or some innovative creation. When I have these moments, I indulge myself in a little self congratulations and I utter the phrase "Shit, I'm good!"

CSOTB, I've been lurking in the background and watching what you've been achieving with your numeric HUD. I've yet to give it a spin as I've been in between repeated computer OS reinstallations but nevertheless, I think that you can take a moment for yourself and say:

Shit, I'm good!

Wow... that's different, isn't it?

Let me say right off the scanner is brilliant -- the pale grey lines solve all my difficulties with seeing the lollipops, as you call them. I'm able to pick up cargo pods much more easily now, as the little blighters can no longer sneak above or below the datum plane as I approach in 'gobbler' mode. Pirates, too, are at much greater risk of destruction, the poor devils.

I did think having the screen half-filled with data would prove a distraction, but that isn't the case, is it? And putting the laser temperature gauge where it is was a stroke of genius, IMHO.

Like everyone else, I'm extremely impressed -- it's a terrific implementation. Something that feels a little awkward right now is the numbers themselves: I've no idea what half speed is, for example, when expressed this way. I'm sure it's just a matter of living with it until it becomes second-nature, however.

My one real regret? I lose the ship's name box Smivs so thoughtfully provided on his clipper hud. It's not that I'm likely to forget what vessel I'm flying, you understand, but it gives me a warm feeling seeing 'Noomi' at the bottom of the screen. Sad, but it's something I'm prepared to live with to get this superb hud.

Thanks for bringing NumericHUDv3 to my attention!

CommonSenseOTB: in this post (if I'm understanding it correctly) you seem to be saying you're proposing to change NumericHUDv3 to report the ship's true forward speed, taking into account any nett velocity component in that direction. Have I got it right?

If so, I assume that you, as a pilot, consider this the best (i.e. most useful/least ambiguous) method of stating the ship's speed. My own personal preference would be to see the ship's true speed in the direction of motion, irrespective of the direction the ship is currently facing. For much of the time it probably wouldn't matter, as the two would be one and the same. My concern is that, when using military fuel injectors for prolonged periods, the considerable build-up in velocity would lead to some anomalous situations.

The first is where, after giving the mil injectors a sustained burst, I kill the speed and 'coast' to a gradual stop over a period that often exceeds a minute. While coasting, if I spin the ship, I can find myself travelling sideways, backwards, forwards... in fact in all directions. If forward speed is strictly reported, I'll presumably see the speed readout changing, from +300 (say), through 0, to -295, up and down constantly as the velocity decays. Personally, I would much prefer that a speed readout of 0 confirms I'm stationary in space, not scooting sideways at who-knows-what speed.

Another potential situation would arise, I suspect, when the action heats up. I use my (mil) injectors a lot in combat, so presumably I'm carrying considerable amounts of velocity at such times. Combine that with frequent and often violent changes in direction, and I can imagine significant degrees of 'sideslip' developing, again with a detrimental effect on reported (forward) speed. I expect to see the speed readout change when I press 'w', 's' or 'i', but not when I move the joystick: I can't see how that would help me, and in fact it seems likely to prove a distraction.

It's possible I've got this whole thing round my neck and that's not what you're proposing at all. If that's the case, apologies, and I'm happy to be wrong.

You bring up some very good points Albee. While the Q-Charger gives your ship velocity and then takes it away just before reapplying that velocity which allows your ship to turn without skidding, the military fuel injectors apply a velocity and do not remove it or damp it down gradually, which allows you to skid when you turn until your own ship provides its own thrust to eliminate this excess velocity.

As this is not frontiers or pioneer with newtonian engines, there are no gauges suitable to show all components of your velocity and even if I change what the numerichudv3 reads, the best I could do would be to show the total speed as one readout and it won't be 100% accurate after an uncontrolled velocity boost and having your ship turn sideways or a 180 degree turn. I would probably not give just your forward velocity without giving the velocity in the other 2 axis. So a really good set of useable readouts might not be possible until a new version for 1.77 is available as it would be too much effort to modify for 1.76 just for that to add 3 new guages. Even for 1.77, how much use would the player get out of it? Now, if I read your post correctly, you just want one readout of your total speed, and that is probably all I will be able(willing?) to do anyway so I guess you are in luck. But, as I haven't touched this issue yet except to leave myself a note to look at it, no decision has yet been made. But this is how I'm leaning anyway and it's too bad I didn't understand as much 8 months ago as I do now or the speed guage would already have this method to read velocity.

Just a thought, but perhaps Thargoid might wish to modify his oxp to start shedding velocity when the player's forwardVector is over a certain angle relative to the original vector when the velocity boost was applied? That way you would have to keep your ship pretty straight to use that velocity and could still decide you wanted to make a turn and have the velocity dissappear rather quickly. Maybe if you ask him nicely and he has some time he could look at it and see if it's even workable.

Cheers Albee!

CommonSenseOTB wrote:

Just a thought, but perhaps Thargoid might wish to modify his oxp to start shedding velocity when the player's forwardVector is over a certain angle relative to the original vector when the velocity boost was applied? That way you would have to keep your ship pretty straight to use that velocity and could still decide you wanted to make a turn and have the velocity dissappear rather quickly. Maybe if you ask him nicely and he has some time he could look at it and see if it's even workable.

It's do-able, but it would make what is a very simple OXP into probably a rather more complicated one. The key point is that you'd have to apply velocity away from your current heading (to cancel out what is now essentially sideways or backwards velocity, relative to that heading) and it's to know at what point to try and stop cancelling things out.

I'll keep the thought on the back-burner, but I've got other things on the go at the moment taking my time so it probably won't be a near-term job.

Thargoid wrote:

CommonSenseOTB wrote:

Just a thought, but perhaps Thargoid might wish to modify his oxp to start shedding velocity when the player's forwardVector is over a certain angle relative to the original vector when the velocity boost was applied? That way you would have to keep your ship pretty straight to use that velocity and could still decide you wanted to make a turn and have the velocity dissappear rather quickly. Maybe if you ask him nicely and he has some time he could look at it and see if it's even workable.

It's do-able, but it would make what is a very simple OXP into probably a rather more complicated one. The key point is that you'd have to apply velocity away from your current heading (to cancel out what is now essentially sideways or backwards velocity, relative to that heading) and it's to know at what point to try and stop cancelling things out.

I'll keep the thought on the back-burner, but I've got other things on the go at the moment taking my time so it probably won't be a near-term job.

I understand you completely. With a dozen projects currently on the go and currently only a few hours a day to spend on anything oolite related, some will take time to be realized.