I'm genuinely curious as to the process FD use for patching bugs, more so just why it's so slow. As it stands, both minor and severe bugs are often left for weeks, and on occasion months without being dealt with. Is this by design? Lack of resource? Or the limitations of the patching process? The fact that missing and broken audio got through the beta process for 2.3.10 is a little more than surprising, - those broken and missing features, even the small ones, don't leave the best impression for those who have joined recently. Is there a better way to do this? Perhaps interim hot-fixes? Or is this just not something that is worthy of concern by FD?
Patching Process
- Thread starter Canoe
- Start date
Voice added to OP's.
All good questions which deserve an answer.
And I will add that if you're not a DEV or an INSIDER that you either just add a +1 to the OP's query or remain silent because you don't know the answer.
All good questions which deserve an answer.
And I will add that if you're not a DEV or an INSIDER that you either just add a +1 to the OP's query or remain silent because you don't know the answer.
Yes, I'm sure that will work splendidly...
While I agree it would be nice to know these things, it's also the case that FDev are in no way shape or form obligated to answer these sorts of questions. So, don't hold your breath, basically.
I know the answer because I listened to FDEV when they talked about it earlier. Since I am not a developer I will not tell you though.
BTW
How about YOU remain silent because you clearly didn't understand the concept of a discussion forum?
Last edited:
Absolutely true. They're not and this one at least will not be holding his breath waiting for FD to respond. But it'd be great if they did.
Stopped reading there.
Unless you work for Frontier, such as a developer, or managerial position; you don't get to decide what is minor, and what is severe. Only Frontier can make that call. What may seem severe to us, could actually be considered important but not severe to them.
Last edited:
I also know, but I am not affiliated with FD in anyway, so I cannot reveal the secret ... shame ... but Rules are rules.
Quite clearly you didn't stop reading. Personally, I wish you had. So rather than engaging in finger-wagging, why not request some clarity on how the process works, and why sometimes deeply obvious and glaring bugs get through weeks of testing untouched or unresolved.
They hate us or technical reasons.
Combat logging has been around now for over two years and they still haven't fixed this. I can truly understand the OP. Besides that, I still get instancing desynchs/crashes and connection errors. Additionally NPCs block my assigned landing pad and thermal cascade is still bugged. On top of that multicrew is not working properly with alot of issues of all kind. Lastly, outfitting crashes when transferring modules or switching them with 100% frequency until I restart the game.
I already know why glaring bugs get through, I know why they don't get fixed immediately, I know how the software industry works and in particular how a development team works.
There is the SDLC/STLC to take into account; as well as the fact that FD might be using an agile development process; which means they work in sprints (usually 2 weeks sometimes longer) during which time a new set of development is planned, whilst the other is on-going and no interruptions or changes will be entertained; now unless a bug is game-breaking, it gets put into a pile with all the rest and addressed in time when the team has a chance to get to it.
There's a plethora of other factors that get taken into account as well; for example, a bug might remain because it has a massive impact on something else, or it breaks something else, or they want to change the way the program handles that particular area of code and thus, instead of fixing the bug, they leave it until the sprint comes along that contains the changes to that particular part of the code.
Or, the most common one, it's simply not as important as you (the customer) think it is.
Welcome to software development. ¯\_(ツ)_/¯
Any game developer who doesn't at least listen to what their players are telling them about the impact of a particular bug on gameplay and factor that into their decision making is either very brave or not altogether wise. Or both.
Obviously any effort to fix bugs has to begin with some kind of prioritisation exercise; the template used for bug reports obviously informs that with its questions about frequency and severity. Equally obviously that won't be the only factor; if they're currently working on a particular aspect of the game it may make more sense from a resource allocation point of view to fix three or four relatively simple issues that can be dealt with as part of that process even if they aren't currently creating critical gameplay problems.
There could also be issues which seem relatively minor to us as players but which are affecting the underlying architecture of the game in such a way that they do present major problems to the developers, especially if they involve routines that are called on by more than one in-game process. Things like that can be a blocker to a huge amount of future work until they're fixed, tested and implemented.
The fact you jumped on three words of the OP's post (minor and severe) and went off on one about what he does and doesn't have the right to do smacks of white knighting though and believe me, I'm the last person to accuse someone of doing that; usually I'm the one pointing out to people that what they are describing as white knighting is actually just someone expressing a different opinion about an aspect of the game.
I had a similar reaction from someone myself yesterday when I had the audacity to make a post asking how the missing materials from the mission board rewards have managed to get removed again in the most recent patch and why/how it keeps happening without being picked up by QC during internal testing.
My own post was actually a direct question to Dom who had been reading the thread in which I posted it, although the fact that he's chosen to continue the discussion today in a second thread that some one made about the same issue means that it's unlikely to see an answer. In both cases, my post and the OP's here were reasonable, politely worded and not in any way ranting and raving or attacking FDev - it seems that both of us just have some genuine curiosity about the processes in place and in this case the OP seems to be trying to promp a constructive discussion about the issue.
So within the context of the OP's post do you think your post going off on a tangent about what is a major or minor bug added anything to the constructive discussion he was seeking?
It might have had if OP had asked 'Hey FDev, why do you keep fixing minor bugs and leaving the major ones' because obviously there the issue could be that OP's perception of the importance of fixing a particular bug was skewed. But he didn't ask that did he? In fact he did the exact opposite, his question was about the length of the patching process in general regardless of the priority of the specific bugs being addressed.
TL;DR - put your armour away and stop polishing your lance. (Not a euphemism. Well OK, maybe a little.)
As with any post directed at FDev it will either be answered or it won't (it probably won't just because the amount of time the developers can spend browsing the forums is limited if we actually want them to get some work done too) but either way I'm absolutely certain that they don't need people coming out to defend them when they aren't even being attacked. It's a bit weird. And no, I don't need to work for FDev to make that determination.
Last edited:
Software dev here, I can't speak for FDev but here's how it works in my company. Fixing bugs carries risk, because when fixing bug it's very easy to introduce another. For that reason bugs aren't fixed adhoc (unless they're very severe) but are instead fixed in batches so that all the bugs can be tested together with a proper period of testing before a release.
The more bugs are fixed, the greater the risk and some bugs have much riskier fixes than others. For this reason, bugs are usually "triaged" which means than the various senior leaders get together and risk assess each fix to figure out the cost/value of making the change. Some bugs will be put into a forthcoming release but others may be deemed too risky or it may be that they'll be fixed later by a design change instead. It may also be that the bug doesn't impact enough users and there are workarounds available etc. This is why some bugs can last a long time.
The sad reality is that no major piece of software ever has 100% of bugs fixed. To do so would be to hold up development greatly.
Last edited:
Since you were nice enough to paragraph it, I'll number according to your paragraphs.
1. QC gets the bug; they investigate it. If they are sure, they mark the severity and the priority and they shove it off to development. If they are unsure, they will speak to a manager, or to a developer if they have access to one; and they will then mark the severity and the priority. Part of this process is making a determination if the bug is game-breaking or not; this is further complicated by the condition of "how many people are affected by the bug" - if only a few people are affected, the priority might be lower; pushing it further down the queue. A developer doesn't need to listen to a client on how it affects them because in the majority of cases, we (developers) don't need to; we already know what kind of impact it will have. Testers are usually as clued up as, if not more so than, developers. A developer must always listen to the feedback provided by the client; but they shouldn't allow it to interfere with the SDLC/STLC of the product, for one simple reason: customers aren't objective. A dev-team will make an educated, and subjective decision as to the priority and severity of the bug.
2. Whilst I don't disagree, unfortunately, the reality is that allocating resources to fix "three or four" relatively simple issues is a risky. What if, for example, one of those bugs has a much deeper issue; where fixing it, breaks something else? That relatively simple bug fix, suddenly becomes a much bigger bug - a bug that extends past the allocated time for those "three or four" relatively simple bugs ( to compound the issue, the other bugs haven't even been addressed yet. ) This could ultimately lead to creep; something most development houses actively tried to avoid.
Excluding all of that, however, allocating resources to fix those "three or four" bugs, doesn't actually make the company any money.
3. The reason I jumped on those two words is because they are extremely important in the SDLC/STLC process. Without it, you get endless testing cycles, you get scope creep, you get resource allocations that don't bring in any money for the company; if developers listened to all their customers about how important a bug is, every single bug would be severe and important.
I'm not saying OP's feelings on the matter aren't genuine and should be dismissed; I'm saying that opening a thread that relies entirely on the assumption that their severe bug is Frontiers' severe bug is pointless; it's an argument with no basis to support it.
4. You mean how does [Object A] that is missing from the loot-table, get re-added to the loot-table but then get removed again in another path? Oh, pretty normal fair in development; especially if you're just quickly fixing "three or four" relatively simple issues.
- In all seriousness, that happens. It's not unusual for something missing to be re-added but then accidentally removed again; it's difficult to explain how it happens, but it does,5. Granted, however, I take issue with someone who genuinely wants to know something, but then takes on an accusatory tone after making assumptions ( ala bug severity/priority ).
6. I consider pointing out fundamental flaws in an argument, or questions based on those flaws to be constructive; even if others do not.
7. Leave my lance out of this.
Good post, fair comment.