Bug Fix versus New Release Priority

[xyphic]

The auto-throttle is broken badly. Here's a modern day analogy. You have a car with cruise control. You set it and head down the road. Ahead you see a traffic jam so you cut throttle and apply the brakes, but instead of slowing, your vehicle accelerates to maximum speed and smashes into the others.

It seems that way at first, doesn't it? What's actually happening is that you're being given feedback in an unintuitive way. When in supercruise, the yellow bar doesn't indicate speed, it indicates the proportion of safe maximum speed that you're travelling at. As you approach your target this safe speed decreases, and if you're travelling quickly it will decrease at a faster rate than your actual speed (even if you set your throttle to 0). The audio feedback is tied into this bar, so it also sounds like you're accelerating. The reason this 'bug' doesn't get fixed is that it's by design.

As for bug fixes in general, you need to know a little about software development to understand why the frequency of bug fixes drops off over time. When you have multiple developers all working on the same code, you don't just all pile in and start hacking around. If you work like this, you end up in a complete mess. What actually happens is that Frontier will have one ongoing development stream (usually known as the trunk) and when they start on a bit of work, be it a bug fix or a new feature, a developer will take a snapshot of this development stream known as a branch. Any work they do on the branch has no immediate effect on the trunk. In this way, all developers will be working on their own copy of the code. When a piece of work has been done and tested on the branch, it will be merged to the trunk. You usually get some help from the tools here, but where two developers have touched the same code -- which happens more regularly than you might imagine -- you get what's known as a conflict, and one or both developers have to manually pick apart what each developer did and get it integrated correctly. There are ways to minimise this, but it's an important concept to understand.

So think of this thing like a tree. You have the trunk, which grows ever upward. Off this sprout branches at irregular intervals. Branches may have branches. Eventually the majority of those branches rejoin the trunk, somewhere nearer the top. So, what happens when we do a release? Simple, we take a branch of the trunk (call this a release branch) and this release branch is what we maintain and release with bugfixes.

When a bug is identified and fixed, the developer assigned to it has to work out the root cause, figure out where it came from and fix it. But where should they make that change? It definitely needs to go into trunk, otherwise it'll get forgotten about and future releases will still contain the bug. If you want to do a bugfix release, it also needs to go in the release branch. When the trunk and release branch are fairly near each other, this isn't usually too difficult. But as time goes on, the code can diverge significantly. It may not be possible to make the same fix in both branches. It may be that it's been fixed indirectly in the trunk through some other change, and in either case the developer needs to spend effort effectively implementing the same thing twice, possibly in two different ways. Whichever branch you do the work on, the number of conflicts that arise from the merge will increase over time. So as time goes on you get diminishing returns from bugfixing the release branch; it doesn't mean they've stopped fixing them though. Pushing 1.3 or 1.4 back by a month to get bugfixes implemented into the 1.2 release branch would be a waste of money.

The one thing that Frontier could do better would be to maintain a list of known bugs and their status (e.g. fixed in 1.3, planned for 1.4, etc.).

 

[Mithos09]

You're not accelerating at all, it's a common misconception. Your ship is actually putting full power to reverse thrusters in a futile attempt to stop you overshooting. By the time this happens the only thing that can prevent you from overshooting is you dipping your nose so that you're not heading directly for your destination.

Actually, at least in some cases, it's just the engine sounds, which are wrong in that moment. I remember that the explanation had something to do with the maximum speed the enviroment (near astronomical object) allowed compared to the speed you're going. Said one of the officials, once, as far as I remember.

 

[CMDR MAIN SEQUENCE]

I'd like to but I'm out exploring and keeping my location quiet. I have no way to black out the system info shown. That's why I kept it unlisted.

Ok no worries I'm just interested to see if your "symptoms" are the same as mine. The "75% throttle at 6-8 seconds" method - did it used to work for you but now it does not?

 

[Agarthan]

It seems that way at first, doesn't it? What's actually happening is that you're being given feedback in an unintuitive way. When in supercruise, the yellow bar doesn't indicate speed, it indicates the proportion of safe maximum speed that you're travelling at. As you approach your target this safe speed decreases, and if you're travelling quickly it will decrease at a faster rate than your actual speed (even if you set your throttle to 0). The audio feedback is tied into this bar, so it also sounds like you're accelerating. The reason this 'bug' doesn't get fixed is that it's by design.

As for bug fixes in general, you need to know a little about software development to understand why the frequency of bug fixes drops off over time. When you have multiple developers all working on the same code, you don't just all pile in and start hacking around. If you work like this, you end up in a complete mess. What actually happens is that Frontier will have one ongoing development stream (usually known as the trunk) and when they start on a bit of work, be it a bug fix or a new feature, a developer will take a snapshot of this development stream known as a branch. Any work they do on the branch has no immediate effect on the trunk. In this way, all developers will be working on their own copy of the code. When a piece of work has been done and tested on the branch, it will be merged to the trunk. You usually get some help from the tools here, but where two developers have touched the same code -- which happens more regularly than you might imagine -- you get what's known as a conflict, and one or both developers have to manually pick apart what each developer did and get it integrated correctly. There are ways to minimise this, but it's an important concept to understand.

So think of this thing like a tree. You have the trunk, which grows ever upward. Off this sprout branches at irregular intervals. Branches may have branches. Eventually the majority of those branches rejoin the trunk, somewhere nearer the top. So, what happens when we do a release? Simple, we take a branch of the trunk (call this a release branch) and this release branch is what we maintain and release with bugfixes.

When a bug is identified and fixed, the developer assigned to it has to work out the root cause, figure out where it came from and fix it. But where should they make that change? It definitely needs to go into trunk, otherwise it'll get forgotten about and future releases will still contain the bug. If you want to do a bugfix release, it also needs to go in the release branch. When the trunk and release branch are fairly near each other, this isn't usually too difficult. But as time goes on, the code can diverge significantly. It may not be possible to make the same fix in both branches. It may be that it's been fixed indirectly in the trunk through some other change, and in either case the developer needs to spend effort effectively implementing the same thing twice, possibly in two different ways. Whichever branch you do the work on, the number of conflicts that arise from the merge will increase over time. So as time goes on you get diminishing returns from bugfixing the release branch; it doesn't mean they've stopped fixing them though. Pushing 1.3 or 1.4 back by a month to get bugfixes implemented into the 1.2 release branch would be a waste of money.

The one thing that Frontier could do better would be to maintain a list of known bugs and their status (e.g. fixed in 1.3, planned for 1.4, etc.).

Having to try this hard to explain a poor game mechanic that can be circumvented as easily as 'veer away and veer back'.

 

[Harbinger]

Actually, at least in some cases, it's just the engine sounds, which are wrong in that moment. I remember that the explanation had something to do with the maximum speed the enviroment (near astronomical object) allowed compared to the speed you're going. Said one of the officials, once, as far as I remember.

This quote from Mike Evans certainly backs up what you're saying:

It's just the audio that revs up, you'll still be slowing down the whole time. The audio is based on your current speed within the range of allowed speed. Once you get close to a planet that allowed speed gets very low but your current speed can't slow down quick enough to remain in the range, thus the audio revs higher than normal.

But this coupled with your speed indicator going into the red has the effect of making people believe they are accelerating when the exact opposite is the case.

I personally wouldn't consider it a bug, more that it's badly communicated what is happening in this scenario. Stating "Slow Down" is not particularly helpful as zeroing your throttle (which is what people will do) does nothing to avoid overshooting.

 

[Agarthan]

This quote from Mike Evans certainly backs up what you're saying:



But this coupled with your speed indicator going into the red has the effect of making people believe they are accelerating when the exact opposite is the case.

I personally wouldn't consider it a bug, more that it's badly communicated what is happening in this scenario. Stating "Slow Down" is not particularly helpful as zeroing your throttle (which is what people will do) does nothing to avoid overshooting.

This is not true, just go test it yourself, the odometer and the distance begins to accelerate, it's not anywhere near the speed that it appears to be but it's definitely accelerating, may be this statement was true at the time they said it, but it's not now.

 

[Aewarin Jameson]

Here's a vid showing the issue.

The "wandering" that you see with the lasers, unless mistaken, is intentional.

A very long time ago, during Alpha/Beta, everyone was using gimballed weapons as they had a very high lock on rate which trivialized combat - they added an amount of drift to them* (tuned and tweaked over time) which causes the effect you see. Gimballed weapons are better against larger ships but against small ships you need to be close to register hits.


*I think the idea was: Auto lock on weapons - lower powered and drift; Manual lock weapons - higher powered but harder to aim with.

 

[Harbinger]

This is not true, just go test it yourself, the odometer and the distance begins to accelerate, it's not anywhere near the speed that it appears to be but it's definitely accelerating, may be this statement was true at the time they said it, but it's not now.

Nope it's still true, you're merely misinterpreting the data you're being presented.

Also the quoted dev post is from 3 weeks ago, nothing has changed in the last 3 weeks. 1.2.07 was released over a month ago now.

 

[Brakespear]

Leaving the debating of specific bugs, I have to agree with the sentiments of the OP.

There are far too many small, but very annoying glitches that should have been fixed a long time ago. At this (relatively) early stage of the game's life, we should be seeing regular updates purely for bug fixes.

This is especially noticeable given the recent Steam release; with the influx of new players, you would expect them to have made more of an effort to be *seen* to be patching the game. But no. There are bugs that were introduced just before the Steam release that still haven't been addressed, along with a variety of performance and stability issues.

 

[xyphic]

Leaving the debating of specific bugs, I have to agree with the sentiments of the OP.

There are far too many small, but very annoying glitches that should have been fixed a long time ago. At this (relatively) early stage of the game's life, we should be seeing regular updates purely for bug fixes.

This is especially noticeable given the recent Steam release; with the influx of new players, you would expect them to have made more of an effort to be *seen* to be patching the game. But no. There are bugs that were introduced just before the Steam release that still haven't been addressed, along with a variety of performance and stability issues.

There are good reasons why we don't have regular bugfixes (see above). It's only when Frontier stop adding features to the game that they'll be in a position to have a regular bugfix cycle. There'll be a shedload of fixes in the 1.3 release.

- - - Updated - - -

Having to try this hard to explain a poor game mechanic that can be circumvented as easily as 'veer away and veer back'.

The first paragraph explains why this isn't a bug. The rest explains why bug fixes in general drop off over time.

I'd agree though that the "bug" in question isn't particularly intuitive, and that the "slow down" warning is pointless as all it tells you is that you're bound to overshoot.

 

[Agarthan]

The first paragraph explains why this isn't a bug. The rest explains why bug fixes in general drop off over time.

I'd agree though that the "bug" in question isn't particularly intuitive, and that the "slow down" warning is pointless as all it tells you is that you're bound to overshoot.

Wouldn't it make more sense that a 32nd century computer would just adjust your speed down accordingly, especially when you've let go of the throttle and let it completely take over? I get the "This is supposed to keep you paying attention to flying really long distances" argument, but there has to be a better way to do than than a finicky autopilot that constantly causes you to overshoot the target if you are just a little bit off. BTW for those who are wondering, I almost never over shoot and now that I figured out the veer away technique it never happens, ever.

- - - Updated - - -

Nope it's still true, you're merely misinterpreting the data you're being presented.

Also the quoted dev post is from 3 weeks ago, nothing has changed in the last 3 weeks. 1.2.07 was released over a month ago now.

I'm going to have to go test this myself to see, I guess it could just be an illusion that you are going faster, but that's not how the ship feels, as you move towards the target if your ship is careening it is far harder to keep it lined up, though if you can you can still safe jump. The farther away you start to careen the harder it is to line it up, the more wildly your ship acts. If it isn't speeding up and it's actually the flight computer just screwing with your maneuverability that makes the mechanic even more ridiculous.