The timer is worse than pointless...

Except for the fact that if you get to 0:06 on approach and just leave it there, your on a really good track to destination without any further throttle adjustments. If you get down to 05 you're probably heading for the loop of shame...
that is forgetting that, according to your approach axis, should you pass next to a planet, you will set the throttle for a specific position to hold the infamous 0:06, then all of a sudden *bam* 20:0 so you have to throttle UP then another *bam* you were at 0:30 and all of a sudden, you overshoot.

there are simply some approach situation where you WILL overshoot no matter what.

i have listed 2 or 3 stations like that, the only workaround is to change your approach vector to avoid the gravitationnal pull, or more exactly, make it inline with your approach so it doesn't matter.

this is rather counter intuitive since, in regular speed, you don't control the throttling but set a speed (which is altered by ship / loadout / pip status), while in SC, you control directly the throtle amount and thus are subject to various gravitationnal effect, which oddly only affect speed but not trajectory.

i am rather used to dea with such things, and the current implementation being half baked is having a really "random" result
 
Not sure how people missed this in my OP: "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. "

I know how to get to my destination as fast as possible. I know how to use the information the timer provides to my advantage. That wasn't my point...

Wouldn't you prefer a timer that provides an accurate estimate of the time to reach your destination? This is easily achievable by taking into account, a) your current velocity and b) the speed changes that the SC mechanism is likely to impose on you because of gravity wells on your current trajectory.

If you change heading or throttle, obviously, the ETA changes. If you are going to fast, it could read "overshoot". The current 0:06 value is arbitrary and meaningless.

No I would not prefer an ETA based on actual time, because it's irrelevant to why that counter is there; it's not a stewardess, it's a velocity indicator measured in time. The current system works easily and understandably. The "time limit" of 6 seconds IS your overshoot warning; get under that except at comparatively low velocities on the final approach, and you'll overshoot. The count reading is not meant to be an accurate gauge of your actual travel time in the least.
 
But... as I mentioned the module would be optional - for those who want to install the system showing these details. If you don't like it, don't purchase or install it. It could also be set as optional in the same way orbit lines are - and, at least IMHO, removing orbit lines only serves to allow for clean screenshots - I'd much rather keep orbit lines in general (and indeed I've never once switched them off) because they're invaluable for me as a guide when approaching my destination.

Gliders... good analogy, but again, you can buy upgrades which (while not showing you *where* the thermals are) will give you much more information than just how high you are. A good glider pilot (well technically I'm thinking RC, but the same concepts apply) may or may not use variometers to give them feedback not only on the current height of the model, but sudden changes in height. They'll be looking at the wing tips to check for any slight movement - and you're right, in that a good pilot will know his craft so well that he'll "feel" when he's in a thermal.

But there's also technology to help... some people have even considered placing sensitive thermal sensors on different points of the aircraft to try and visualise or at least notify of the existence of thermals in the vicinity. It's quite the "acoustic vs amped" or "old school vs new tech" argument, it's true - but I don't see the inherent downside of having these options and ideas available, especially if they're implemented in a non compulsory way.

Aside from the underlying knowledge and experiance, much of gliding is feeling, RC is great dont get me wrong, and the same principles apply, but scale and sense of environment play a massive part in it and make it a much different beast. Much of the fun in gliding is not knowing for sure but finding out if you are right, to the point you start to get a real 6th sense going on. Relying on tech, while still taking you to the same places, removes a large part of the experiance, as it then becomes the gadgets finding the sweet spots and not you, that kinda makes you more a passenger and less a pilot. Those orbit lines, while just being used as visual queus by many, are actually important in terms knowing where things are that can effect you, seeing where the bodies are on those orbits, understanding the commultative effect of crossing orbits etc. the actual slowing down and speeding up isnt random as some would suggest, they are the result of those forces being applied, much in the same way as feeling a thermal. Aside from the speed changes we get in those instances, we get a visual response from it in game too (moving forward or back in the cockpit) there is a lot of information being given to us in game, its only a matter of understading what it means, how it applies and fitting it into the mental map we use. But you know, if they want to implement a selective system, thats cool, i'll stick to the current setup though.. i'm old, stubborn and Scottish, but i do genuinly like the way it plays too. Besides, I do think there are better things they could be spending their time on.

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

that is forgetting that, according to your approach axis, should you pass next to a planet, you will set the throttle for a specific position to hold the infamous 0:06, then all of a sudden *bam* 20:0 so you have to throttle UP then another *bam* you were at 0:30 and all of a sudden, you overshoot.

there are simply some approach situation where you WILL overshoot no matter what.

i have listed 2 or 3 stations like that, the only workaround is to change your approach vector to avoid the gravitationnal pull, or more exactly, make it inline with your approach so it doesn't matter.

this is rather counter intuitive since, in regular speed, you don't control the throttling but set a speed (which is altered by ship / loadout / pip status), while in SC, you control directly the throtle amount and thus are subject to various gravitationnal effect, which oddly only affect speed but not trajectory.

i am rather used to dea with such things, and the current implementation being half baked is having a really "random" result

it isnt a random result, it is cause and effect.. you said it yourself
 
I can't believe how defensive all these kickstarter people get when you bring up obvious problems with the game. The timer doesn't work. It's simple.

I can't believe that people don't understand it after clear explanation and believe that said understanding is based around the level of someone's supposed backing. I'm not a kickstarter and I know how it works. It's simple.
 
Indeed - it's not at all that it doesn't work - it works perfectly as intended. It just seems that some people are (wilfully?) ignoring the explanations of how it works, and rather focussing on the fact that it doesn't work the way they want it to...

e: one thing that I would like to see if they were just to keep the countdown - add one or two decimal points; I'd like to see the detail behind it, not just the integer.
 
Last edited:
My solution uses the knowledge that your velocity in the optimal zone will change a known amount (barring environment issues) proportional to the distance to your destination and this equation can be used to give you a much more truer time to destination.
You're looking at a differential equation which is hard to solve. It also doesn't take into account that, depending on your course, you will run by planets/moons/suns that will force a slowdown/speedup.

Currently I find the timer useful. While you can set the throttle to 'blue' you can also set it to maxium and set it back to 'blue' at an appropriate time (depending on how far away your destination was initially - i.e. how high your maximum cruise speed is - somewhere between 30 and 10 seconds left on the clock). That saves you a few seconds.
 

ciger

Banned
I can't believe how defensive all these kickstarter people get when you bring up obvious problems with the game. The timer doesn't work. It's simple.

what exactly does not work? i use it quite perfectly for adjusting speed and/or approach vector. 4s and below means i will most likely overshoot unless i use the nearby planet to slow me down, 5-6s and i know i can head straight for the station, anything above 6s means i can throttle up.

it simply gives you a ETA based on your current speed.
 
I can't believe how defensive all these kickstarter people get when you bring up obvious problems with the game. The timer doesn't work. It's simple.

Sorry, I am not a kickstarter and I believe that the timer is working the way it should. It reacts to changes in velocity as I would expect. I guess you could try switching off flight assist and then the throttle would not auto adjust and the time should work out correct.
 
I can't believe how defensive all these kickstarter people get when you bring up obvious problems with the game. The timer doesn't work. It's simple.

I concur that it doesn't work, but I'm a Day 1 Kickstarter backer at significantly more than £5. I don't feel any sense of entitlement, but as someone who works as a programmer in a lab with all sorts of real physical processes, I know how trivial it would be to add an ETA clock as well as a "you'll never get there in 0:06" clock. The t=d/s bit is clearly providing something useful, although it's bogus in its own way due to the way that the speed is kept proportional to the remaining distance. What the 0:06 actually tells you is how long it will take for the distance to half, which is interesting in itself. If the drop-out distance to the destination was 0.5Mm it would take another 6 seconds. If it was 0.25Mm it would take another 6 seconds. If it was 0.125Mm...
 
That's a bit complicated, Urk, for me.

MAX throttle, wait until you hear the 007 music, hit key bound to 75% throttle, wait for blue bars, drop out of SC.

Yeah true!
In practice it is usually:

MAX
8 down
7 steady / down
…exit

The main overshoot danger these days is that I get so bored in SC I tune out of Elite in favour of some paint drying on the wall and forget I am flying a spaceship really realy fast! :D so the extra thinking bit can be usefull to keep me focussed...

Maybe if we didn’t think of it as an ETA? I agree that as an ETA it is…. at the very least misleading!, and not that helpfull.

Try treating each number lower than 10 as a safety measurement…

10 - wake up!
9 – safe, tad slow if anything
8 - safe
7 - safe / fast
6 - risky / fast
5 – danger, you will overshoot,
4 - too late, loop of shame!
 
Last edited:
Wow. This thread escalated quickly. When I read the OP this morning I expected this thread would get lost in the dephts of the forum rather quickly.

For those who still don't understand how ETA works:

If you jump in your car and select a destination 100 km away, your navigation system will tell you how long the trip will take according to your speed. If you drive with 100 kph, the trip will take 1 hour. If you drive with 50 kph the trip will take 2 hours. If you start with 100 kph, but continuously deaccelerate to 1 kph, the ETA will start at 1 hour and stop counting downwards at a certain point. This is what happens with the 7 second timer in ED.

This is not broken. It actually works like it would in the real world. If someone doesn't understand something that simple, he is not in the position to say something is broken. You actually need to understand basic mathematics first.
 
I can't believe how defensive all these kickstarter people get when you bring up obvious problems with the game. The timer doesn't work. It's simple.

Please, consider your comment. The timer does work precisely based off what it is designed to do. It displays the ETA to target based off current velocity. It is simple.

The argument here is that people would like either the option to change this (or seems like some people would like to change the default) so that it displays a real ETA based off the changing values.

Some people have pointed out this would be a technical challenge (not insurmountable, as i recall Frontier's ETA counter actually took this into account).

Its quite simply a design decision on the part of FD to make it like it is. Will they change it? Who knows? They might stand by their decision, or they might decide to change it. Its their call.
 
4 - too late, loop of shame!

Lol yeah difference is with my T-9 I swear I usually overshoot soooo bad I end up practically in the next system.......And it's not like you can correct it by throttling back oh no sireee no. Hit that 5 and it's tickets, game over right there. It's almost as if an invisible hand grabs you and slingshots you straight by the station at double-speed even though your throttle is in full reverse-thrust since long ago......Yep, some programmer had a wicked sense of humour as far as the T-9 is concerned.

Oh yes, forgot to add: The timer works 100% correctly. Any errors can be attributed to P.E.B.K.A.C. or a short-circuit in the S.T.S.I. module.
 
Last edited:
Aside from the underlying knowledge and experiance, much of gliding is feeling, RC is great dont get me wrong, and the same principles apply, but scale and sense of environment play a massive part in it and make it a much different beast. Much of the fun in gliding is not knowing for sure but finding out if you are right, to the point you start to get a real 6th sense going on. Relying on tech, while still taking you to the same places, removes a large part of the experiance, as it then becomes the gadgets finding the sweet spots and not you, that kinda makes you more a passenger and less a pilot. Those orbit lines, while just being used as visual queus by many, are actually important in terms knowing where things are that can effect you, seeing where the bodies are on those orbits, understanding the commultative effect of crossing orbits etc. the actual slowing down and speeding up isnt random as some would suggest, they are the result of those forces being applied, much in the same way as feeling a thermal. Aside from the speed changes we get in those instances, we get a visual response from it in game too (moving forward or back in the cockpit) there is a lot of information being given to us in game, its only a matter of understading what it means, how it applies and fitting it into the mental map we use. But you know, if they want to implement a selective system, thats cool, i'll stick to the current setup though.. i'm old, stubborn and Scottish, but i do genuinly like the way it plays too. Besides, I do think there are better things they could be spending their time on.

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



it isnt a random result, it is cause and effect.. you said it yourself

read again

this is a gravitationnal pull, but the "amount" of pull is not constant.

i did a few a<->b trade run this morning between 2 system (one jump)

one station is a problematic one, and i didn't had twice a consistent slow down, the amount of gravitationnal pull is random, not the effect itself despite my vector being the same every time.

a gravitationnal slowdown should be the result of your velocity/mass vs distance/mass from the planet, the issue here is that while my ship remains at roughly the same speed, with the same mass, being at the same distance from the planet, who's mass doesn't change, i do have very different slowdown effect.

this shouldn't be
 
Wow. This thread escalated quickly. When I read the OP this morning I expected this thread would get lost in the dephts of the forum rather quickly.

For those who still don't understand how ETA works:

If you jump in your car and select a destination 100 km away, your navigation system will tell you how long the trip will take according to your speed. If you drive with 100 kph, the trip will take 1 hour. If you drive with 50 kph the trip will take 2 hours. If you start with 100 kph, but continuously deaccelerate to 1 kph, the ETA will start at 1 hour and stop counting downwards at a certain point. This is what happens with the 7 second timer in ED.

This is not broken. It actually works like it would in the real world. If someone doesn't understand something that simple, he is not in the position to say something is broken. You actually need to understand basic mathematics first.
No. MY navigation system and pretty much any MODERN navigation system will give an estimation on the time of arrival based on the various speed limits during the trip and then amount of current traffic.

A navigation system which bases its estimate only on the current velocity is outdated and probably from before the turn of the millenium.

Which means that an ETA system in Elite should be based on the acceleration/deceleration curves. It's not rocket science, it's just lazyness on the developer's part.
 
Last edited:
Please, consider your comment. The timer does work precisely based off what it is designed to do. It displays the ETA to target based off current velocity. It is simple.

The argument here is that people would like either the option to change this (or seems like some people would like to change the default) so that it displays a real ETA based off the changing values.

Some people have pointed out this would be a technical challenge (not insurmountable, as i recall Frontier's ETA counter actually took this into account).

Its quite simply a design decision on the part of FD to make it like it is. Will they change it? Who knows? They might stand by their decision, or they might decide to change it. Its their call.

the issue as you state is not the timer, the issue lays in the speed management in SC.

currently the grav. effect cannot be predicted, thus resulting in really bad experience when approaching station (which are for obvious reason orbiting planet / moon)

what could help is that the onboard computer compensate said effect in order to maintain the "landing time", after all we are supposedely in the future and as of now, that is something one can rather easily do irl, so i've trouble understanding how such thing wouldn't be standard in a far future where you travel accross the galaxy like i go to work everyday....
 
No. MY navigation system and pretty much any MODERN navigation system will give an estimation on the time of arrival based on the various speed limits during the trip and then amount of current traffic.

A navigation system which bases its estimate only on the current velocity is outdated and probably from before the turn of the millenium.

Well there are no speed limits in space.

PS

To make it clear: I understand how navigation systems work, I just applied the rules used in ED to a real world navigation system. The outcome is the same, so it is definetely not broken.
 
Last edited:
despite my vector being the same every time

Was it though? (genuine question, not trying to trip you up)

If the body you are approaching is orbiting another body (and that body another!), then it’s position will have changed since your last visit, so although you think you are doing exactly the same thing in the same place, your position to the target and yours and it’s position relating to other bodies will not be exactly the same, and there will be different gravity effects to your last visit.

Does that sound feasible?
 
Back
Top Bottom