Fix or remove the ETA display

[Henrik Heimbuerger]

The ETA would be nice to have, but shows all kinds of problems.

When you're in base, targeting your own base, it shows something like "-3:0-54".

When you're autopiloting your base and closely watch the ETA, it's flashing all kinds of funny values, including "0:010" and something really long (~20 characters) for a split second.

When moving away from a target, the ETA still counts down.

I'm not sure all these are fixable with the current abilities of the MDL and if not, an open mind should be kept regarding removing it entirely.

[Henrik Heimbuerger]

It's also occasionally showing 0:60.

[girlyboy]

I personally think the ETA should be left in even if it does things like count down when you're headed away from a target -- this only happens if you're accelerating quickly enough, and is presumably due to the ETA being based solely on your speed and distance from target, without taking vectors into account. It's still useful though, even in this limited form, and it's easy enough to tell whether you should be paying attention to it or not in any given situation.

I think it would be good to simply remove the ETA from the F3 screen when you're *docked*, though, as it can't possibly have any use while you're in base.

[SVN]

New commit by MrWabbit? (revision [130]):
[Fix for ticket #46] some changes to the way this works.

• changed formula to targetrange/(mySpeed-targetSpeed)
• if < 0, then targetspeed is greater than my speed. readout within parentheses "(5:21)" to indicate both negative value and unreliability.
• if > 1800 then getting there will take you more than 30 minutes (eg when in station) and readout will say "infinite"
• no longer replaces speed indicator.
• moved below range and speed indicators.
• improved display code, so stuff like "-0:-009" doesn't occur anymore (hopefully)

[Henrik Heimbuerger]

Occasionally shows "0:9" on r132. Might be something like 0.94 rounding down to 0.9 in a different way than the leading zero is computed.

[Henrik Heimbuerger]

I'm also wondering if maybe replacing (0:00) with an infinity symbol (image) would be worth the effort.

[MrWabbit]

I've been looking at that too. I was hoping to use the actual character, but i couldn't get a reliable way to print it.

Making it into an image is probably a good thing. But getting it to scale right might turn out to be an issue. For now i figured just printing "infinite" would do the trick as well... :)

leaving opened to investigate "0:9".

[Henrik Heimbuerger]

Also got a TTI of 0:01 while in base.

[SVN]

New commit by MrWabbit? (revision [140]):
[new fix for #46] improved algorithm. Formula now handles positive and negative values of (playerspeed-targetspeed) sensibly. now handles div/0 errors properly. hides TTI when in base.

[MrWabbit]

• Refined the way the leading zeroes are added to the secondstring (condition is now [secondsvalue]<=9.4999 rather than <=9.0000. Ought to be precise enough. (see comment #2 and #10)

the operative math is this (see code for more about how results are handled).

GHTTI_allseconds = Divide(GetRange(Target, OnEveryFrame),Subtract(GetSpeed(Me, OnEveryFrame), GetSpeed(Target, OnEveryFrame)));
GHTTI_allseconds_Abs = Max(Multiply(-1,GHTTI_allseconds),GHTTI_allseconds);
GHTTI_Mod = Mod(GHTTI_allseconds_Abs, 60);
GHTTI_Minutes = Divide(Subtract(GHTTI_allseconds_Abs, GHTTI_Mod),60);
GHTTI_Seconds = Min(GHTTI_Mod, 59);
GHTTI_SecondString = 
	SwitchString(
		Max(9.4999,GHTTI_Seconds),
		ConcatinatedString(":", NumberString(GHTTI_Seconds)),
		[(9.4999, ConcatinatedString(":0", NumberString(GHTTI_Seconds)))]
	);