(NEW RELEASE) NumericHUDv3.oxp

[JensAyton]

With altitude, if it's an actual altitude that the bar graph shows, numerical would be more useful.

I have to say, I’m strongly against a numerical altitude display simply because we don’t have any meaningful units of altitude in Oolite. This is an obvious consequence of planets and ships being at completely different scales.

[Ganelon]

I'm not sure I understand the concept of meaningful units in this case. Would it matter if they were meters or cubits or fractions of a planetary radius, so long as when they hit zero it is a collision? Players wouldn't have to make calculations based on the altitude, so any discrepancies wouldn't likely to be noticed. I think of it as basically eye-candy, and not needing to be more meaningful than green-yellow-red.

[Eldon]

Rather than measuring in meters, could you measure as a proportion of planetary radius? Cutting off somewhere between 1.1-1.5 radii above ground (2.1-2.5 from planetary centre). That would give you some idea how close you are to being mass locked by the planet. As an added bonus it helps keep the scale mis-mash somewhat hidden while giving nice solid values for those who like them.

All the best,
Eldon

[Eric Walch]

I'm not sure I understand the concept of meaningful units in this case.

One problem would be that the values that are used in calculation for planet diameters are 100 times smaller that the planet radius on the F7 screen. And that is the value a player sees.

[Commander McLane]

I'm not sure I understand the concept of meaningful units in this case. Would it matter if they were meters or cubits or fractions of a planetary radius, so long as when they hit zero it is a collision?

The best—and completely unit-independent—indicator for hitting zero would be a shrinking bar that would reach length zero on collision, wouldn't it?

[Ganelon]

The best—and completely unit-independent—indicator for hitting zero would be a shrinking bar that would reach length zero on collision, wouldn't it?

If that's what you like, I suppose. But the units are still there, whether represented by numerals or the length of a bar graph. It wouldn't affect gameplay or how long it takes to do anything, so to my way of thinking there is no "better", much less a "best" other than in personal aesthetics.

But you know what? I don't write the code. I just play the game and write a little fiction now and then. The only really pertinent parts of my comments on anything relating to the game are generally found in words like "fun", "nifty", "cool", etc. I don't understand why some things are the way they are, and I certainly don't presume to know how they "should" be. I just play the game.

So, lest I be perceived as arguing with people who *do* write the game and understand such things, I withdraw from the discussion. I feel I owe that to the people who actually do the work to write the game, whether it be core code or OXPs.

Sorry.

[CommonSenseOTB]

You might want to add a check and bail-out for interstellar space, or at least a check that there is a planetary body found in the scan (as I guess some OXPs like Achenar will add planets in IS) or else it'll cough up log errors if called after a misjump.

Good point!

Here's the amended code:

Code: Select all

this.$altitudeOverClosestCelestialBody = function()
{
    function $isCelestialBody(entity)
    {
        return entity.isSun || entity.isPlanet
    }
     var closestCelestialBody = system.filteredEntities(this, $isCelestialBody, player.ship)[0];
     if (!closestCelestialBody) return undefined;
     var altitude = player.ship.position.distanceTo(closestCelestialBody) - closestCelestialBody.radius;
     return altitude
}

Now the result of the function will be undefined if there is no sun or planet. You can check for this case with

Code: Select all

if(!this.$altitudeOverClosestCelestialBody())

Thankyou Commander McLane and Thargoid. This is exactly what I will need for altitude. This would probably make a good example for the javascript reference in the wiki as well. I will let you know if I have any problems with it when I do the final assembly of the numeric hud.

[CommonSenseOTB]

Ganelon, you have some good and interesting ideas for displays/gauges. Your inspiration has made me think of a way to represent the roll portion of a combined RPY indicator as an actual banking line. Does anyone know if there is JS for rpy and what it is or if there is a workaround for this as well? This will be for later however as it is more relevant to the needle(analogue) or animated gauges that I will be working on after this. The 6 pack type indicator you talk about from aircraft does have some relevance for numeric gauges and a similar/relevant version could be made as an addon for fighter/atmospheric type craft. Damage indicators are doable but would be in the style of crude icons until condition"equipment_required" is available in the legends just like it is in dials of the hud.plist. This would allow text and images to be used instead.

Eldon, your idea for representation in planetary radii is a good one. I will look at this closely. Might make a good percentage or ration readout and hide the scale/units problem.

Ahruman and Eric Walch, I am also concerned to display gauges that properly reflect the need for clarity while maintaining the immersion and hiding any unit/scale problems. What is the value displayed at the altitude bar gauge and how is it arrived at? Maybe I can use that same display method/formula to portray a similar relative reading on the numeric gauge. We have whatever time is needed to come to an acceptable solution to what should be displayed on gauges that have scale issues. Eldon's idea sounds worth looking at. If I can't figure a solution for this units issue I will simply leave the gauge out for this version 1 of the numeric hud. Four gauges plus a couple of extra(special) readouts combined with a few traditional bar type gauges might be as much eye candy as one could stand anyway.

I have some more progress to report. The script for the numeric gauge now has user selectable/definable color(2), color change point and color cycling point as well as a remove left zeroes option. Still looking at more options and tweaking the code(not much left to tweak however ).Size will be limited to a bit larger than I would like but I might have 2 sizes of number for use. When this is done the hud arrangement of the gauges will begin(the easy part).

All your posts have been of tremendous help whether directly or inspiration.Keep those comments coming and put your 2 cents worth into the pile while it is still early.

[Eric Walch]

Ahruman and Eric Walch, I am also concerned to display gauges that properly reflect the need for clarity while maintaining the immersion and hiding any unit/scale problems. What is the value displayed at the altitude bar gauge and how is it arrived at?

For a hud readout you need to update regularly. For efficiency I would not constantly use a scanning over all entities. Very inefficiently, certainly because planets in a system are hardly changing and there is already a 'system.planets' that contains an array with all planets (excluding the sun)

A problem you will have is the planet radius. When you have a moon and planet around the distance to the core is different than the distance to the surface. More efficient would probably to hook on oolites own planet monitoring by just using the shipEnteredPlanetaryVicinity() handler. It transfers the nearest planet for you. Just remember that planet until you receive a new shipEnteredPlanetaryVicinity() event (in case an other planet becomes closer) or the shipExitedPlanetaryVicinity().

[Commander McLane]

Ahruman and Eric Walch, I am also concerned to display gauges that properly reflect the need for clarity while maintaining the immersion and hiding any unit/scale problems. What is the value displayed at the altitude bar gauge and how is it arrived at?

Why don't you check it out yourself? Just stop exactly at the point where the bar begins to shrink and establish your distance to the planet at that moment. Now you know what the "maximum" altitude is.

How do you establish your distance to the planet? You only need to type a slight variation of the above code into the JS-console:

Code: Select all

player.ship.position.distanceTo(system.mainPlanet)-system.mainPlanet.radius

[CommonSenseOTB]

Thanx Eric Walch that's an excellent suggestion. I don't want to bog the hud down.

Commander McLane I do know that my numerical readout of altitude says that at 35km the bar selector for altitude starts to drop. What I'm looking for is what the bar selector has for a value when it starts to drop. If the 2 are the same then things are fine. If not I would like to know so I can make a conversion to the same units the bar selector uses. This will be done before displaying as numerical units. If this all looks practical as I mentioned before I will display altitude as numerical units. If not I won't until it is sorted out to be more (presentable?) as to not break immersion due to problems of scale.

[Commander McLane]

I don't know how HUDs work, but I don't think that the bar selector uses any unit at all. In my tests in two different systems with both planet and sun it was full at about 40000 meters and half at about 20000 meters. So I'd say that's about it. A full bar means 40000 meters above ground. What other value or unit should the bar use? I mean, what other units for distance do you know except meters (game-meters, to be precise, referring to Oolite's coordinate system)? Perhaps internally the full range (0-40000) is translated into a real number from 0-1, so that 0 corresponds with 0, and 1 corresponds with a full bar or 40000 meters. But as I said, I know nothing about the inner workings of the HUD code.

[Ganelon]

Keep those comments coming and put your 2 cents worth into the pile while it is still early.

All I was saying is that since I don't understand much of how the game works or why it was made to work the way it does, I'm out of my league arguing with the people who actually write it or parts of it so far as telling them how it should or shouldn't be.

However, I do write some fiction, and one of the "jobs" of fiction writing is to make an idea at least seem to make reasonable sense to a reader.

And you and Commander McLane are holding a really nice number.! So ok, I'm going to chime in even though I said I was going to be out of this discussion.

40,000 is a really nice number. If we consider it's units to be "tens of meters" it'd be 400,000 meters. 400 KM just happens to be about the altitude of the high points of the International Space Station's orbit. That would give a scale that could feel meaningful to any player that is aware of such things. That would give you a scale that would "make sense" from a player point of view, since it would put the stations in Oolite at somewhere near the altitude of actual real space stations.

Here's a handy chart for thinking about distances in real orbital space.

http://www.spacetoday.org/SolSys/Earth/ ... Chart.html

It's in miles, but if you convert to meters, 400 KM is about 249 miles, which as I said is approximately the altitude of the higher point of the ISS orbit.

Now, Eric Walch mentioned that planets are about 100 times smaller than the radius reported on the F7 screen. In gameplay, that doesn't really matter, since they're still really big when you're close to them. In most cases a player would never notice the discrepancy (obviously at least most never have), so that isn't an immersion breaker. So if planets are 100 times smaller then reported, making the distance within the altimeter's range (I'll call that "orbital scale") 10 times smaller would give us a compromise between "planet scale" and "ship scale".

It's a tantalisingly simple solution, so long as you can get the altimeter readout to give the numbers like you and Commander McLane are discussing as seeing as the distances for the top range of the altimeter. Just add a zero to it (multiply by 10) and it becomes a fairly realistic distance.

A workable altimeter can also open up potentials for more missions/OXPs, since logically quite a lot goes on in that range between the planet and the station..

"Commander, a work shuttle doing routine maintenance on navigation satellites developed a fuel leak. They are somewhere near surface to station lane and are currently at a 120 KM orbit, but that orbit is decaying rapidly. We need you to find them and refill their tank from yours so they can get home safely. Please hurry, Commander.. They don't have much time."

An unidentified satellite was reported by a trader in a low orbit of 160 KM, near the Sun to planet spacelane. The photos taken indicate that the object may be of alien origin. It should be presumed to be armed and dangerous. You will be rewarded for locating and destroying it, but a more substantial reward could be given if you can disable it and deliver it to the station more or less intact. Good hunting, Commander.

Obviously, Oolite hasn't previously had missions like those, but it could. A working altimeter would be helpful for missions/OXPs within orbital ranges. It could be "fun". It might be "nifty".

[Eric Walch]

In my tests in two different systems with both planet and sun it was full at about 40000 meters

Not about, but exactly 40000:

Code: Select all

#define PLAYER_DIAL_MAX_ALTITUDE		40000.0

Meters, miles, km, just select the unit you like

[CommonSenseOTB]

Thanx for all the info. I think Eldon's planetary radii idea looks better from the keeping immersion point of view. I will have to research this fully but I could translate 1 to 40000 into a ratio of percent of planetary radii possibly modified by the actual planets' stated radii to make bigger planets look like they have more altitude or something similar with still a lot of precision from a numeric gauge. Will have to think about this. Lots of different possibilities here. May have to wait for version 2.

More progress. The numeric gauges that will be available in the first numeric hud have all had the variables and control formulas/equations encoded. These are Forward and Aft Shields, Energy, Speed, Fuel, Destination Fuel Required and Range to Target. Altitude is not certain to be a numeric gauge for version 1. Others will be bar gauges. Will now begin the actual assembly and will determine if the current number size will fit properly in the space available. May have to make a smaller number set if needed. Add a little polish and wiki page and should be done within a week or so.

Any other ideas about anything related to numeric hud design are welcome here.

Also I will now start up a new thread for the Needle(analogue) style huds and would encourage all ideas, thoughts and comments on needle gauges to be posted there. Thanx.