Deleted member 38366
D
-- Deleted --
Last edited by a moderator:
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.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...
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.
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.
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
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.
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.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.
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 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 how defensive all these kickstarter people get when you bring up obvious problems with the game. The timer doesn't work. It's simple.
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.
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.
4 - too late, loop of shame!
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
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.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.
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.
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.
despite my vector being the same every time