[Release] AlmostAlmostDefault HUD 1.1.4

[Wildeblood]

How do I change:

Code: Select all

	this.ostronomicalUnit = system.sun.position.distanceTo(system.mainPlanet);

From sun to witchpoint? I'm gonna try witchPoint replacing sun. If that's wrong, please correct me, thanks!

Well, I'm curious. Did it work?

The distance from the arrival point in the system - the witchpoint - to the main station, expressed as a percentage, seems like a good idea to me at the moment (having given it about 20 seconds thought ).

[Rese249er]

...
Well, I'm curious. Did it work?

Distance from arrival point in system (witchpoint) to the mainStation, expressed as a percentage, seems like a good idea to me at the moment...

Agreed.
Nope, didn't work. Now trying

Code: Select all

	this.ostronomicalUnit = (0,0,0).distanceTo(system.mainPlanet);

EDIT: Success! Edit line 20 from the above posted code to

Code: Select all

	this.ostronomicalUnit = Vector3D(0,0,0).distanceTo(system.mainPlanet);

EDIT2: *grumbles to self* Could you repost Aad-HUDv2.0 again? I can't seem to get the darn thing to refresh the distance unit for each system...

[spara]

How do I change:

Code: Select all

	this.ostronomicalUnit = system.sun.position.distanceTo(system.mainPlanet);

From sun to witchpoint? I'm gonna try witchPoint replacing sun. If that's wrong, please correct me, thanks!

Well, I'm curious. Did it work?

The distance from the arrival point in the system - the witchpoint - to the main station, expressed as a percentage, seems like a good idea to me at the moment (having given it about 20 seconds thought ).

This is interesting. How should one define such measure?

The real AU is the approximate distance between Earth and Sun. So it would seem natural to define the unit in Oolite to be the distance between the main planet and the sun, as I have done. But if the sun is very far from the main planet, then OU distances would be very small. Fractions of 1 to be exact.

If one want's OU distances to be bigger numbers, then Rese249er's idea of wp-planet definition is very reasonable.

Percentages would fit very nicely into the numeric hud, but in different huds I think something would be lost in immersion.

I think that it does not really matter much, as long as there is a number running and it's different enough from any every day real world measurement.

[Rese249er]

A comment/observation on immersion factor: The starting point for the compass in any system is the main planet. The starting position of the player is in the general vicinity of the witchpoint. Therefore, by my personally opinionated reckoning, that number just out of witchspace should be very close to 1.

[Commander McLane]

Now trying

Code: Select all

	this.ostronomicalUnit = (0,0,0).distanceTo(system.mainPlanet);

EDIT: Success! Edit line 20 from the above posted code to

Code: Select all

	this.ostronomicalUnit = Vector3D(0,0,0).distanceTo(system.mainPlanet);

Again, quite overcomplicated.

As you already have observed, the witchpoint is the origin of the system. Thus, the distance from it to the planet is quite simply the same as the position of the planet:

Code: Select all

	this.ostronomicalUnit = system.mainPlanet.position;

Voilà.

[Rese249er]

EDIT: That's a coordinate, not a measure of distance. Gave me a display of "NaN WPU."

[Commander McLane]

EDIT: That's a coordinate, not a measure of distance. Gave me a display of "NaN WPU."

Yep, I have to facepalm as well.

I was a little to quick. You need either the length (= magnitude) of that vector, or—because the planet always sits on the z-axis, and the other components are 0—it's z-component. Thus, either

Code: Select all

	this.ostronomicalUnit = system.mainPlanet.position.magnitude();

or

Code: Select all

	this.ostronomicalUnit = system.mainPlanet.position.z;

will do.

Apologies for the oversight.

[spara]

A comment/observation on immersion factor: The starting point for the compass in any system is the main planet. The starting position of the player is in the general vicinity of the witchpoint. Therefore, by my personally opinionated reckoning, that number just out of witchspace should be very close to 1.

I understand that this is your personal opinion , but I just have to reply. According to the wiki:

The main planet is placed on the Z-axis at a distance of about 10 to 14 times the main planet radius from the origin. (This is roughly at 300 000 to 900 000 meters from the origin)

So if wp-planet distance is used as a basis of a measure, it can be very different in different systems. That in my opinion is bad for the immersion as the same distance in OUs could take double the time in a different system.

I would at least advice to use the latest version (0.4) of the oxp, as in that OU is defined exactly once, so that in later sessions it is constant and not system dependent.

[Smivs]

Just a thought, but I do agree one OU should be a consistant measure of distance. Today we use a figure based on the distance between the sun and Earth.
Perhaps a logical adaptation of this for use in the Ooniverse would be to take the distance from Lave to its sun, then use that distance as the OU everywhere.

[spara]

Just a thought, but I do agree one OU should be a consistant measure of distance. Today we use a figure based on the distance between the sun and Earth.
Perhaps a logical adaptation of this for use in the Ooniverse would be to take the distance from Lave to its sun, then use that distance as the OU everywhere.

That's exactly what happens, when you start a new game with this oxp installed. OU is defined to be the distance between Lave and its sun and that value is saved to a mission variable. I didn't want to hardcode anything to the script as people may be using sun farthening oxps.

[Rese249er]

Regarding standardized units and ETA... How far does a ship travel in one or ten seconds under Torus Drive?

[cim]

Regarding standardized units and ETA... How far does a ship travel in one or ten seconds under Torus Drive?

Torus drive is 32 times as fast as maximum speed regular flight.
1.0LM = 1.0kOometre/s

[spara]

Nice features. (I like the big clock) Would it also be possible to giva an ETA (Estimated Time of Arival) based (calculated) on current speed (and vector). Although this would be very difficult to program.

There's something satisfying about vector calculus . Here is a new version that calculates an ETA from velocity vector by projecting it to ship-target vector.

I'm not absolutely sure that this is an improvement in terms of usability, as this makes the hud a bit more cluttered. I'll have to experiment and test fly a bit more. So let it be a beta release for the time being. I'm also greatful of all feedback. As always. . It would also be trivial to calculate time to target estimate if that would be better.



Donwload (v0.5): https://www.box.com/s/8xt3lnyq2nqousvm7kgz

_EDIT_

After quite a few experiments the one with time remaining ETA feels the best. Here's an image and download.



Download (v0.5.1): https://www.box.com/s/ozpukjoqig45502jertd

[Switeck]

What's that in the bottom left corner of your 2nd picture?
Some sort of alternate main station?

[Tricky]

What's that in the bottom left corner of your 2nd picture?
Some sort of alternate main station?

It's the fabled Griff Industries Icosahedron Station - available from the ZGrOovy spaceyard.