The timer is worse than pointless...

[LaveLubber]

The timer is a representation of how long it will take to reach the target at your current speed.

Not sure why you don't understand that.


Changing the speed can't be accounted for, because the computer cannot possibly know how you are going to adjust your throttle. If you put your throttle just slightly above the center of the blue "optimal" bar on the indicator, you can practically go AFK and your ship will slow down perfectly.

It is however not as fast as the 75% thing, but if you are terrible at doing that as I am its a surefire way to avoid overshooting. Usually I just turn my attention to netflix during this, paying slight attention to the blue bars.

We all have a way to use the information provided to us as best we can. However, a TIMER is pointless if it doesn't give you the correct time.

Darth Ender highlighted an elegant solution that would be easy to implement. But hey, I guess you are all fine with taking one minute to reach the destination that is "six seconds" away.

I agree that this is not the most game breaking thing, but FD have trained us that to whine on the forums is how to effect change (cf. 5billion credit fiasco).

 

[cschales]

The time-to-reach-destination timer, under your target, is worse than pointless - it is misleading.

We all know this and yet we put up with it. Because of the variable, non-user controllable, speed variation in SC, it renders this timer pointless. We all use it to max out our time to destination at "0:06", but we know we won't get there in six seconds. Even worse, when we are travelling long distances, the timer reads shorter than the amount of time it will actually take you to get to your destination.

How about, instead of a misleading timer, we have a small bar under the Ls counter, which is similar to the blue bar next to the speedo. If you have the ball on this bar in the blue zone, you are optimally approaching your destination. In this sense it would mirror the bar on the speedo, and perhaps not provide any additional info...

I'm sure there is a better way, but as it stands, the timer is bloomin awful... Please FD, add it to the never-ending change log.

You must not know about the 10-second rule. I found this in another thread, can't remember the author but wish I could give him credit for this very powerful information. When you're heading into a system at full SC throttle, just keep an eye on the time index so that when it reaches ten seconds 10), you knock the throttle to 1/2 in the blue zone, or a hair under a half. That will start your deceleration (maybe sooner than you would have done) and give you a perfect vector into safe disengage range without having to fuss with the blue vertical lines. Try it! Works like a champ every time.

 

[LaveLubber]

You must not know about the 10-second rule. I found this in another thread, can't remember the author but wish I could give him credit for this very powerful information. When you're heading into a system at full SC throttle, just keep an eye on the time index so that when it reaches ten seconds 10), you knock the throttle to 1/2 in the blue zone, or a hair under a half. That will start your deceleration (maybe sooner than you would have done) and give you a perfect vector into safe disengage range without having to fuss with the blue vertical lines. Try it! Works like a champ every time.

Thanks. I do know how to reach my destination as quickly as possible. That isn't really what the thread is about though.

 

[Xpats]

Except it obviously isn't. If a timer reads 0:06 for one minute - that's accurate? Nothing to do with many forces at work, but shoddy programming at FD that doesn't take into account the variable speed that they have put into SC.

I am fine with removing it - sick of the sight of the thing - it clutters the target reticule unnecessarily.

Actually, it might be. When the timer says 6seconds, your ship should be slowing down quite rapidly, every time the timer refreshes, it calculates the time taken at your current if it were constant. It does not take into account your rate of deceleration which is variable depending on lots of factors.

- - - - - Additional Content Posted / Auto Merge - - - - -

The timer is a representation of how long it will take to reach the target at your current speed.

Not sure why you don't understand that.


Changing the speed can't be accounted for, because the computer cannot possibly know how you are going to adjust your throttle. If you put your throttle just slightly above the center of the blue "optimal" bar on the indicator, you can practically go AFK and your ship will slow down perfectly.

It is however not as fast as the 75% thing, but if you are terrible at doing that as I am its a surefire way to avoid overshooting. Usually I just turn my attention to netflix during this, paying slight attention to the blue bars.

That, basically.

 

[Roybe]

The timer works..just like this....patiently wait for the off ramp bit...:

https://www.youtube.com/watch?v=sCzgdF_WjOg#t=243

 

[LaveLubber]

Actually, it might be.
That, basically.

As Darth Ender said (better than I could), it reflects your instantaneous velocity.

Since your speed is NEVER constant in SC, it never reflects an accurate time - an accurate time being the time it will take you to reach your destination.

I guess I just haven't drank enough Cool Aid.

 

[Skip Intro]

A long time ago, a guy from Microsoft told me that the internal timer to do things in Windows essentially makes a guess, then refines that as it goes, which is why the 'progress' bar used to scream up to 99% then hang for minutes. I'm guessing the timer in your ship is also loaded from Windows 3.1 floppies.

 

[Twelvefield]

I love the timer! I use the James Bond Rule, which is simple: make the timer read 007. When it does that, you'll make the optimal approach at the fastest speed possible (apologies to the 010 guy above, but 007 is not just cooler but also a shade faster!) 006 works as well, but you do risk an overshoot.

I find the numbers much easier to read than the gauges. The gauge lines are not very precise, and there's no numbered scale anyways. The gauges are great for at-a-glance situational awareness, but not good at precision and efficiency.

 

[Elzean]

Haven't been bother by the timer, but now that i think about it, it should work the same way GPS in car do no ? I Mean don't they calculate the time to destination using the optimal / legal speed for each section of the road?

 

[Dogthinker]

I agree with the OP. The timer is profoundly misleading. It's not even capable of being correct. The problem is that it assumes space is flat, but in SC it's not. Throttle to 100%, it says x seconds. It's a lie, the gravity well WILL decelerate you no matter what you do. In my opinion it should show a time adjusted for the gravity well. Sure, It's useful in its current state (the 0:07 method), but it's not really presenting it's information in the right way.

Time to arrival, assuming throttle % unchanged. A separate indicator indicating expected velocity at arrival time would work nicely with this (better than the 'slow down' warning that usually appears a second or so too late to actually be helpful.)

Alternatively, simply translate the existing value into some value indicating over/under speed. (0:07 would be rescaled to 0.0. 0:06 or below would be values > 0 (overspeed), 0:08 or above would be values < 0 (underspeed).)

 

[Gavski]

All I know is that software progress bars/timers et al, have been lying to us for ever. Microsoft are experts at giving and taking-away minutes, seconds...hours.

So I chill and don't get worked-up about it.

 

[SquidgyB]

Ok, an alternative solution to the OP - stop calling it a timer.

As soon as you accept that it is not a real timer and just represents the time of arrival at your current speed then you can relax.

As mentioned already, a timer which accurately shows the actual time of arrival would be skitting all over the place - worse than a microsoft timer. As soon as you change your speed, approach angle, overshoot etc - the timer will show even more spurious results.

Stop expecting it to be a timer and accept it for what it is - an arbitrary countdown that can help the pilot to minimise their time spent approaching their destination.

 

[CMDR i Tetsuo]

Sorry OP but the timer works as intended and accurately and I use it exclusively to judge my approach, if it was removed I'd end up flying past my destination, thus it must work!
-
You cannot have what you think it should display because you are constantly changing speed, even if it went ahead and figured out the exact time to destination with deceleration taken into account what's to stop me speeding up or slowing down after the calculation was made which would make the originally accurate reading inaccurate?

 

[sic]

Speed:

100 mph took 1 hour to reach 100 miles
10 mph took 1 hour to reach 10 miles
5 mph took 1 hour to reach 5 miles
2 mph took 1 hour to reach 2 miles
1 mph took 1 hour to reach 1 mile

ALWAYS 1 H??? Timer why u no point?????
RAGE!!!!!!!!

*sorry caps

 

[SquidgyB]

Having thought about this for... 10 minutes, this is something that I think I'd like to see implemented;

Rather than the simple timer, could we have an, er, approach vector display (if that's the right description)?

What I'm thinking is along the lines of the classic Aliens landing sequence "we're in the pipe, five by five" - very much like what's shown below:



So the two main things - your angle of deviation from the destination, and your speed, both can be more elaborately detailed in the rectangular path than with just numbers (plus it looks much prettier and more... "technical").

The rectangular path would show if you have the capability to change the craft orientation in time to reach the destination - heading straight to the target destination you would be in the middle fo the path. Veering off from the straight path would send you further towards the edge of the rectangular path - moving out of the path signifies that your craft does not have the turning speed at the current rate of deceleration to be able to pull back into line - so you must slow down or risk overshooting.

Speed (or more accurately your rate of deceleration) could be signified by rectangle colour, or distance apart - either way, a bold reference to your speed and whether you're over or under the optimal speed would be useful up on the main HUD screen as well as being down on your throttle near the scanner/radar.

The question then arises as to whether this could take into account gravitational forces from planets etc, and how easy it would be to implement given the framework that's already been set by FD.

It could also help with docking, giving the same kind of vector approach, warning if your current rate of acceleration is goign to throw you out of the "pipe" and smack into the station walls.

Maybe as an upgrade module, class 1 or 2, like the discovery scanner - not to take control of the ship like the docking computer, but to give guidelines which can help people dock more quickly and efficiently...?

e: granted the pic shown is of a planetary descent, but the vector approach would work equally as well for a station in orbit - or any other destination while n SC.

 

[Master-Windoo]

Except it obviously isn't. If a timer reads 0:06 for one minute - that's accurate? Nothing to do with many forces at work, but shoddy programming at FD that doesn't take into account the variable speed that they have put into SC.

I am fine with removing it - sick of the sight of the thing - it clutters the target reticule unnecessarily.

You are neglecting acceleration and deceleration.

 

[Pete]

The timer is fine once you understand what it's actually telling you.

But what bothers me more than the timer is all the other marker's / texts overlaying / obscuring each other
Your current target should, IMO, be the only thing visible.. the other markers should only show when no active target is selected.

Argh - no, no no no no!

This is so very very useful for explorers in the current implementation, we can drift our aim a little to see one (or multiple) target(s) beyond our current one, and see the distance to start planning our next planet to visit without unlocking (and losing the built-up scan) our current target.

If this changes, then it will break exploration even more than it is already is.
Just because you don't use it, it doesn't mean that it's not an exceptionally important feature to other people!

-- Pete.

 

[Master-Windoo]

Like i mentioned in my previous post. The timer can use a simple equation to arrive at a avg time that is much more useful than what it currently uses. It would be the time if you were flying at the optimal throttle point regardless of your throttle at any given distance. This provides much more useful information than the current ETA timer and much more pertinent info. Trying to arrive at an ETA dependent on whatever your current velocity is would result in noisy ETA times, or nonsensical ones since it would result in a destination speed that may not be realistic.

But if the average time is used then it would be inaccurate which is what you want, but it is accurate which is what you want! Are you female?

- - - - - Additional Content Posted / Auto Merge - - - - -

Fair call but perhaps the hud display can be turned on and off.

 

[Dogthinker]

Having thought about this for... 10 minutes, this is something that I think I'd like to see implemented;

This is pretty much how it worked in Elite 2 / 3. While I'd love that, it wouldn't be quite as interesting in this version, as our approach vectors are usually just straight lines, since gravity doesn't exert a force on us directly.

IMO, the problem with the timer is that it's either the wrong metric to use, or it's not correctly implemented - we fly in curved space due to effect of most object's mass on SC, but the timer assumes completely flat space. The timer really should either be improved to show 'time to destination at current throttle', or be replaced some other metric.

 

[Master-Windoo]

The difference in acceleration and deceleration in light years is vastly different to miles.