The handling of bug reports - more updates, more communication, more managing

[FalcoGer]

It would be nice to have something come from bug reports. I don't mind bugs and problems in early access, that's to be expected. What I do mind is being treated that way when I take the time out of my day, and the days of other people who help me make those multiplayer related bug reports, reproducing them and posting them here with detailed steps on how to reproduce them and uploading tracks. And after all that, nothing is done, no acknowledgement is given, no communication, no updates, just nothing at all.

Those people I do those bug reports with feel increasingly frustrated and more unwilling to do it, because they get the feeling that nothing comes of it. And if they get that feeling then something is wrong because either

a) Really nothing comes of it, or
b) That something comes of it, but it isn't communicated properly

and both of those things are issues that should be fixed. I don't know which it is, so I will assume the latter to give the benefit of the doubt.

I have posted well over at least 50 bug reports, some recent, some a long time ago, and recently just a single reply from the forum- or DCS staff. I have paid a lot of money, I am taking my time to report bugs, because I want the module to be as good as it can be, and I get ignored. I feel like I'm wasting my time, working for you, for free. I admit that a good portion of those are minor details, not important or often used, but as a big fan I want every detail to be accurate and working. Other bugs are indeed more concerning and relevant to major elements of the aircraft. Some are duplicates, but that can't be helped if a forum is used to keep track of bugs and people using different words to describe things so it can't always be found via search.

Furthermore, once a thread had been looked over and marked as "Needs track replay", "needs more information", or "Investigating", it seems like no one every checks on it after a track or more information has been provided ever again. No updates are being made from "reported", if it ever gets to that, to "fixed", except for a select few, very major bugs.

On one occasion I was reporting a bug, with video evidence of it, showing it and giving detailed steps on how to reproduce that bug. I have since talked to at least 5 other people who experience that very same bug while no one I asked claim that they did not have that same bug. For me and every one of them the bug comes about by literally pressing 2 buttons in the cockpit and nothing else. Yet claims are made that this can't be reproduced. I did not have a track file at the time but it was requested. The thread was marked as "Investigating". 3 days later the track was provided, showing the bug. In 6 months since then, not a single download of those track files has been made, nor was there any further comment, and nor was the bug actually fixed since then.

I don't know if I'm crazy or something, but to me it seems that asking for something, then being given the thing and then ignoring it for half a year seems just a little absolutely rude to me. Since this had been "investigated", this bug is still present half a year later. Granted it's a small inconvenience, and nothing game breaking, but all the same it's disappointing and most of all I feel like I'm being treated like a moron, and as a result, of course I get a little grumpy and frustrated at times and less faithful that my bug reports actually are taken seriously at all.

I don't think that's how you should treat your customers who, mind you, are paying for your product. The least you could do is show some appreciation.

I feel this should be addressed and improved.

To improve the situation I would like bug reports to

• be updated once their status changes, not just on the initial reading of the report
• more efforts be made to merge the reports of the same bugs
• A notification be given if a report has been read and/or confirmed/reproduced
• A list of known bugs be published and kept up to date, such that the list be easily checked before posting a report, possibly with status updates such as "fixed for next release", until a proper bug tracker is implemented
• Be revisited once more information/tracks are provided
• Be acknowledged again once said information/track was provided
• Be appreciated more

I understand that DCS is a large project and that the forums are big and several bug reports for all different modules come in and that not everything can be taken care of right away, that certain things need to take priority over others. But on the other hand, asking for a track and then no downloads or replies in 6 months, or no comments after several weeks is just not explainable by that. There are several people that are paid to manage the forum. And If i can take my evening to look through the bug report sections of a few aircraft and check for new posts, then so can they.

Keeping track of bugs with a forum is generally just horrendously inefficient. Personally, I think a new, streamlined bug tracker system should be put in place to link bug reports and software development closer together, such that when the team finishes working on a bug, the bug tracker is updated for everyone to see, including your customers, allowing the simple merging of reports. There are plenty of good, open source bug trackers out there that will do the job just fine. Integrating them of course would take a week or two, but version control and a good bug tracker will make development a lot easier and more streamlined.

Taking issues seriously and being appreciative of the community creates a better environment for everybody involved. People feeling like "Writing bug reports is pointless because they're ignored anyway", and that is a quote from some people I asked before to help me report bugs, must be a red flag. The very fact that they think this way lies in how they perceive the efforts being made here. This must be addressed if you want your community to stay engaged with the product you are trying to sell. We're all enthusiasts in a niece hobby, we're passionate about military aircraft and we're passionate about details. Neglecting those that raise issues with either the product itself or with how things are handled generally will create a toxic environment where everybody is frustrated. I don't want that. What I want is an open discourse with an open company that can be both proud of it's achievements while also admitting to it's faults and failures and that is open to suggestions to improve and criticism.

Sorry for the rant.

[[DE] T-Bone]

I have to agree with FalcoGer. It is very frustrating to spend time and energy finding bugs and then find that they are not followed up and reported appropriately.

Two examples:

https://forum.dcs.world/topic/304743-eufd-warning-util-hyd-level-low-when-unlocking-tail-wheel-on-any-carrier/#comment-5059668

or

https://forum.dcs.world/topic/306016-gun-shakes-on-movement-while-lasing/#comment-5054968

Unanswered for half a year. Not even a statement that the matter is under investigation or anything like that.... This is very frustrating for your customers who are trying to let you know that something is wrong. 

I would also like to see better communication and quality in bug reports. We're happy to help with more track files or videos or give you log files, but we need active feedback from you.

And I would appreciate ED commenting on how they feel about it and what actions they will take.

Introducing a bugtracker would be very helpful.

Edited January 24, 2023 by [Eule-22] T-Bone

[Raptor9]

First off, let me begin by saying that I am not a community manager, so I don't speak for them as individuals or for their department. However, their job is far beyond simply "looking at a few bug reports for a few aircraft." They monitor, moderate and manage the entire forum to ensure individuals are not abusing the rules, attacking each other, or posting slander, restricted information, or forbidden topics. On top of all of that on the forum, they also do the same for the other social media channels: Discord, Youtube, Facebook, and interact with the community in other ways like on Reddit. Of course, the community managers are not the only ones checking bug reports or interacting with the community. You also have ED internal testers that do the same, as well as other ED employees that do as well; to include translators, manual writers, and I'm sure some dev members. Admittedly, I'm still a newcomer so I'm not familiar with the forum screenames of all the ED team members, this is just from what I've observed.

Switching gears, another thing that can be seen is that whenever a feature is announced for one product, the players that use other products that are subject to contemporary features often immediately demand to know when their favorite module is getting the same treatment. When it was mentioned the F-18's radar was being re-factored, the F-16 players wanted to know when the F-16 would get it, despite already announced it would be. When it was mentioned the F-16's DTC was in progress, the F-18 players wanted to know when the F-18 would get it, despite already announced they would be. Despite the fact that it was announced multiple times that each of these respective aircraft would get these features, everyone wants the features in their preferred aircraft first and as soon as possible above any others. Following that, if any newsletter does not talk about an upcoming feature for a specific module, there is often times the inevitable thread that starts where players assume the feature might have been cancelled, shelved, or delayed, even if a previous newsletter mentioned it as still being worked on. This starts a long cycle of debate back and forth until the community managers are forced to lock a thread and assure everyone that nothing has changed, there just isn't news to share.

What does all of this have to do with how bug reports are managed? Well, nothing; at least in itself. The reason I am typing out this short novel is to articulate not only how busy the community managers are in trying to keep fires from starting or putting out existing fires across the various channels (some of which continuously progress in real-time, like Discord), but that communication itself between the community and the ED team members can be a significant challenge. To many players, they only see their little slice of the forums, whether it be their wishlist or bug report, or they only see what is (or isn't) happening for their favorite DCS module. But to the community managers and other ED employees, it is everything, all the time. What the vast majority of the player-base sees is only the tip of the iceberg of the amount of effort that it takes to manage the interactions with the community, or the development time that is being spent to produce such complex aircraft and environments.

I myself am taking a good slice out of my workflow today to read this thread, consider the appropriate response, compose this message, and then proof-read it several times to ensure that it is a measured and appropriate response. I do this in a methodical way because, as an ED team member, I do not have the luxury of posting whatever I please whenever I want, or respond in a half-cocked manner. It is my responsibility to ensure that what I say is accurate, level-headed and not driven by an emotional response, and does not reveal or state anything that has not been approved for public consumption.

Forum members are under no such obligations outside of the forum rules and guidelines. Regarding bug reports, they could post anything that could be caused by interference from user-mods, hardware input issues, user error, a misconception to how something should work, or any number of reasons why something "doesn't seem right". If it seems like some bug reports are missed, some in fact are. Some get missed, some get overlooked, some sound very similar to the one that was looked at last week, etc. We are human, with much more work tasked to us each work day than many realize. Many of us work more hours than we are required, to include the weekends. We do this because, like you, we are passionate about DCS World and we want it to not just succeed and grow, but we want it to be fun as well.

Unfortunately, quite often the absolute worst case is assumed; that ED team members or our 3rd party dev team partners are lazy, evasive, incompetent, don't know what we are doing, only care about sales, don't respect the community, blame players for issues, don't like to communicate with the community, ignore bugs because we don't want to fix them, etc. When these statements are repeated endlessly on the forum and other channels, even though it is borne of false hyperbole, kneejerk reactions to announcements, or community members with an ax to grind, this is not just disheartening to ED team members, it also creates discontent among the community itself and makes it very difficult to consider how we should communicate in the future. Everything we do is met with both positive and negative reactions, but more often than not the negative reactions are the loudest and most promulgated statements on these community channels.

Even when information is provided in a very honest and facts-based manner, it may still be met with a negative reaction or blowback from other players. This could be because they do not get the answer they expected, there may be a cultural or language difference, or because they don't like it because they don't like it. Again, we are all human, and I'm pretty sure we all want the same thing, which is to have a fun and engaging form of entertainment that caters to our fascination of high-performance aircraft and their place in history. But please keep in mind, to use an analogy a second time, only the very tip of the iceberg is seen. I cannot stop anyone from basing their opinions on limited knowledge of what is happening behind the scenes, but we purposely avoid posting information that we do not know to be accurate, that does not reflect a known solution to an issue or bug, or is not a future development plan that is both set in stone and already publicly announced. We are not always perfect at this, but if a change occurs, we always let the community know; even when it may result in backlash. Honesty is important, but is only useful if it is based in facts, not speculation or assumption. But speaking honesty based on fact is a two-way street, just as respect is a two-way street.

Bug-reporting standards are there to ensure efficiency in handling of such reports, it is not there to serve as a "gateway" criteria before a bug is considered, nor does it serve as a "guarantee" that a bug can be reproduced, reported, or fixed. If a bug report is provided with a simple paragraph with no track file but still marked as "reported", this does not constitute a break in the bug-reporting standards. It may have been seen by a member of the volunteer closed beta testers or another ED team member, and is already known and reported. If a bug report is still marked as "investigating" for months, the bug may have simply been moved to a back burner due to higher priorities. Yes, I can see how this might support the idea of a public bug tracker, but as already mentioned in the above paragraphs, or in the post below, the manpower requirements in maintaining this would be astronomically high, much more than many realize.

It is very easy to cast stones when, due to lack of information, there is nothing to contradict or refute personal biases or assumptions. If a player sees a lack of communication as disrespect, neglect, or lack of appreciation for their bug-reporting efforts, that is certainly not our intent nor is that what is happening. We cannot, and will not, simply mark every single public bug report with a blanket cookie-cutter tag to make it look like every bug report has been utilized in the development of DCS products, but we also have no control over what any player tells themselves or the community to fill a vacuum of information.

[FalcoGer]

Regarding a bug tracker

I can't agree with all of that. bug trackers are invented to reduce the workload of managing the reports of bugs, classifying them, prioritizing them, keeping their status up to date, collecting relevant facts, for example where such issues might arise, and consolidating evidence and potential approaches to fixing them. Putting an effort into creating or setting up such an environment would actually reduce the workload of sifting through the forums, which are ill suited for the task, both for those people that look for bugs and those that fix them.

It is far more work to do that in a forum, which is designed to share opinions and facts and which is not suited to search for bugs or keeping their status up to date. Many bugs on the forum are not labeled or labeled as reported or investigated when they are in fact fixed. Some bugs are regressions that were reintroduced but are then labeled as fixed already. It makes it hard for people to keep track of what's real and what's simply not been updated. Furthermore when looking at the bug report forum, it's obvious that the amount of threads can only really grow. There will be 10, 20, 50 pages of bug reports, and some will slip through the cracks simply because the bugs on pages 2-30 are fixed, but the bugs on page 31 are never seen ever again. In a bug tracker you simply filter out the stuff that has been fixed and you are left with a list of known bugs or alleged/unconfirmed bugs, drastically reducing the chances of a bug not being looked at.

There is also no need for a "second tracker". One should be plenty enough. Any internal comments could stay internal, no one is asking you to share your source code or reveal how "personal conversations" on the bug tracker can even happen. I implemented a version control system for my company while another member of our team implemented a bug tracker. Took me a few days to set everything up for everyone and him a week or two before something reasonable was working well enough for use. It really just comes down to designing the database and a user interface and the queries that are done between the two.

Regarding the frustrations of people

The fact that people are frustrated and may think that nothing is done, that the team is incompetent, etc, points to a miscommunication. That is the whole problem I'm trying to address here. Of course other projects have some trolls on their forum, other projects have people discontent. But when I look at DCS specifically, it seems way worse. Personally I feel way more frustrated than with other projects I have posted bug reports for, both production software and games.

Blaming people for posting

3 hours ago, Raptor9 said:

anything that could be caused by interference from user-mods, hardware input issues, user error, a misconception to how something should work, or any number of reasons why something "doesn't seem right".

is fair, but that doesn't mean you can just ignore their posts. They still need to be classified and disregarded, and for the right reasons. Take yourself for example. I asked that Air Fire and Arty datalink would be implemented. I read the TM, it outlines the procedure step by step, it shows drawings of what the MFD screens look like each step of the way. You come along and say "That's not how it works, it's a misconception", "Won't be implemented". Despite it being part of the aircraft IRL. I understand that it was never used because radio exists, but in DCS it would tie in nicely. No further information was given on why it was "a misconception". I'm fairly confident that the team uses the very same TM to model the aircraft (while simultaneously forbidding any mention of it on the forum). I understand that it won't be implemented tomorrow or next week, but it would be nice to have in 2 years. My understanding of a simulator is, if the real aircraft can do it, and if it's public knowledge on how it looks, what the procedures are and what the end result is, then the simulator should simulate it, even if the implementation details aren't known (the format of the data link packages, package sizes, frequencies, encryption schemes, etc).

It also doesn't help that some bugs have been around for decades and that people have fixed them by changing a single number in a lua file, yet this is not officially done, thus breaking IC, for instance. I'm not sure if that is true, but it would point to some deeper problems with the whole process. Of course people form their opinions on lacking information because there is no information. When I see certain things, I can only assume how they came to be from what I am provided, and what I am provided is the multitude of problems and my own experience working on software projects, though of course much smaller in scale than DCS.

For instance a Mig 29 locking somone up 45° off bore and you being 45° on the other side still gives you a spike despite being nowhere near the line of sight line, you being 300 miles away and sitting in an aircraft shelter. This has been around for many years now and still not addressed. How can this be? Especially since it's such an obvious issue. Put a single Mig29 in a mission and basically the whole server gets spiked. And that's not even one of those tiny little details, like a single obscure aircraft function not working correctly when certain, specific conditions are met, like the windshield wiper knob not being able to be turned to high without generator power, which was fixed.

Another example is when I see the problems in synchronization in the apache between the seats. I conclude from the dozens of bugs that I observe and the way they happen and from experience, that synchronization works by sending which button is pressed and then separately keeping track of what should happen with the aircraft, and not by sharing the aircraft state. Initial synchronization of some states is done when the second person joins, creating the possibility to forget or mis-synchronize them (for example C AUX tank status, APU status, etc). If I had to come up with a system, I'd write the class for each aircraft system and then transmit that state when the other client asked for it, for example to display it on some interface in the aircraft. Instead it seems like cockpit button presses are synchronized instead. Since DCS uses UDP, some packages might get dropped and then you get one off bugs that can't be reproduced. For example just yesterday my CPG was setting up a route and suddenly the COM->MAN->VHF Tone got turned on for me, but not for him, some time earlier some FMC channels just turned off when my CPG was doing something completely unrelated. It's impossible to recreate, if I were to report this bug, it would be "can't reproduce, no track", never to be seen again and that's why I didn't bother. And when I point out that the whole approach is wrong, I get told "you don't have enough information to even know what the approach is", which is true, but on the other hand I can not get the information either. So either I ignore the problem or I must assume what the problem is through what evidence I'm given.

Of course seeing stuff like this is frustrating. And I'm not the only one to feel that way.

[Raptor9]

 

30 minutes ago, FalcoGer said:

Take yourself for example. I asked that Air Fire and Arty datalink would be implemented. I read the TM, it outlines the procedure step by step, it shows drawings of what the MFD screens look like each step of the way. You come along and say "That's not how it works, it's a misconception", "Won't be implemented". Despite it being part of the aircraft IRL.

I will respond to this one instance alone, for the sake of making a broader point. Just because someone reads a document, does not mean they understand the real-world context. This happens quite often, and it is a prime example of why so many debates happen on these forums, discord channels, or elsewhere. The Fire Support protocol was intended to be used with the EPLRS system. However, the EPLRS was removed in the avionics version that is being simulated in DCS AH-64D. Therefore, what you think should exist in it was actually removed and replaced by a different system altogether, rendering the Fire Support protocol defunct and not usable in the aircraft, despite what you read. Reading about something on the internet does not equate to inherent knowledge on the topic.

The reason such topics are often avoided, and the reason I gave such a pithy response on the matter, is because these things can easily go down the slippery slope of touching on sensitive information about such systems and their evolution in these aircraft, which I will not do. However, inevitably, someone else might decide to post something on the forums about it to move the conversation along. Then that can lead to forum members posting excerpts from restricted documents on the matter (which you yourself have done on multiple occasions, despite multiple warnings not to). Then the thread needs to be moderated and cleaned because people are distributing documents in violation of the forum rules, which are there to protect not just ED but the community as well. This is just a video game.

I am not going to debate the validity of these rules or policies, because they are there for a good reason. Some may not agree with them or even like them, but that doesn't change the fact they are necessary.

[NineLine]

So I am going to jump in the front seat for Raptor as his gunner, I am sure we will be shot down in a ball of flames in no time

Bug Tracking

A long time ago Kate mentioned the idea of a public track, we looked at it, we examined it and we decided against it. When she first talked about it I thought, well that could be a good thing. No more bug reports on the forum, all of them entered into the bug track directly... Then I look at the forum, and for every good report there are two incomplete reports. The devs are even more critical about how a bug is reported than we are. Me, Scott, Raptor and others take a lot of reports and make the work for the dev team. 

Then I thought, well ok, we still report them, but users can see them. Well no, some bugs are deemed lo priority, some take longer to fix, some take discussion before being addressed some take research to be done. Would that help or hurt to see all the communication. Some would love it, some would hate it. 

Well then, maybe they just see the bug reported and status... Well sure, that works for bugs that are fixed right away, for other, well... its just another thing to be frustrated about when it sits there for a long period of time without action. 

Well what does that leave us. The forums. So we try and do better and mark things fixed when they get fixed. Internally we are marking things as user reports and a link to the thread in hopes to help this, but its still far from perfect. We are trying. 

A tracker just doesn't make sense for us right now, we do not have the manpower to support it, we it would just be another source of aggravation for those waiting for a fix important to them. Maybe one day it will make more sense or we will be staffed to be able to support it, right now no. The forums makes the most sense, and me and the team doing a better job to update posts as well. 

Not an answer most will want or accept, but it is the answer now. Opinions aside, that is how it will be for now.

People Frustrations

I would love one day to come on the forums or Discord or wherever and have 0 people frustrated. As you pointed out, other games have the same issues, or similar. I do not agree that DCS World is worse, maybe you do not see us as better, but I do not see us as worse, for whatever that is worth. 

As far as ignoring posts, we really do not go out of our way to ignore posts. We may triage the bug forums trying to tackle the most critical and important that we feel need addressed right away, and because of this some may slip through the cracks. We do not ignore reports though even if it takes us time to get back to them we generally try and get back to them. If people make reports missing info, incomplete reports, etc, those might be skipped over with a simple missing info tag and reply. 

I randomly picked one of yours and I can see how you might be frustrated:

Playing devils advocate had you included a track with your initial report it might not have slipped through the cracks as it seemingly has now. This is not an excuse for us to have not gotten back to it, but I want to show you that making a proper report can get things looked at faster. As a side note about a bug tracker that users were involved in, this could be the same issue there.

So in conclusion, yes we can do better relating information back to the forums about fixes and the status of bugs. You also have to consider the size of the task, and how you may be focused on a handful of bugs, we are juggling hundreds each personally, and then the Devs and management are making a plan based on that. If you think DCS is worse than other games, its the sheer complexity of the game that probably makes these seemingly simple tasks seem so slow and unresponsive. 

 

[FalcoGer]

Well even if people provide tracks, data, graphs, evidence and logic, then a lot of bugs are not followed up properly.

HARMs not using INS. With evidence from tacview data graphs (a lot of them) of track files (a lot of them) and the logic of 1G means they're not guiding to anything, as well as actual INS guidance (EOM mode) looking different (not 1G) and they actually hit somewhere near the target. Verdict: Correct as is, topic locked.

Objects not being cleaned up properly. Destroys long running servers' performance. High impact bug. Result: "Can not reproduce" for half a year. Then Flappie got to it, reproducing the issue from the data provided in short order. Actual communication taking place with that hero. He asks for stuff, he gets the stuff to find the root cause. People are in fact willing to help and go the extra lengths.

One of mine. FPS issues when using TV mode and looking into the woods (FLIR works perfectly fine). Maybe just me, not sure. Provided track with the first post. Labeled "can not reproduce". Provided video evidence, no further communication. No asking for information, no follow ups, just silence.

Then there is stuff like the recent patch. "Added: IAT now syncronized". Then I'm flying for 5 minutes and IAT desyncs when using LMC. Surely one couldn't blame me for coming to the conclusion that testing wasn't done thoroughly enough, especially since this was the big new thing and the patch was in development for over a month now, granted with a christmas break in between. I submitted a bug report, but it certainly doesn't scream competence when "Fixed bug" in patch notes and 5 minutes afterwards the same bug is found when I'm not even specifically testing the feature with all the variations like it should've been done after implementing it. Again, it's EA, one expects bugs, that's fine. But I'm sure you can at least see where I'm coming from here.

This one has been here for 5+ YEARS. Mig-29 locks anything STT, whole server gets spiked. Not 5 months, 5 years. Are you kidding me? And that's not one of those "windscreen wiper knob doesn't turn to HI without generator power." RWR is a major feature in DCS for all aircraft that have it, it's very visible and obvious, it's been reported many many times now. Why is this still a thing? Sure it doesn't blue screen the computer, but it affects basically everyone. How can this be?

  

On 6/25/2022 at 10:46 PM, Flappie said:

To my knowledge, all aircraft are affected by this issue. See here:

 

 

I can understand most things, but those are just incomprehensible to me. And that's just a tiny sample of the things that have been going on. I could go on for pages. I'm sure everyone is working hard, but maybe the methods are wrong. Or you just need more people.

Edited January 27, 2023 by FalcoGer

[Floyd1212]

If employing a real bug-tracking solution is off the table, perhaps using the "forum tracking" method more effectively could help?

Create a sub-forum for bug reporting, and move the posts to another sub-forum when they have been accepted by the devs, then move them to another sub-forum when they have been resolved.  This means there are shorter lists of posts in the reported and accepted forums for users to look through and understand what has already been reported and being worked on.

Don't let just anyone post a bug report.  You've got a nice readme pinned to the top of the forum, but apparently not very many people are reading it.  Allow users to submit their reports for a moderator to approve before being posted.  If it doesn't contain a comprehensive screenshot, a video, or a track file, don't accept the post.

Ask the community to help confirm the bug by reproducing the bug with the included track file on their hardware before moving it on to the devs to look at.

This is all just brainstorming for 5 minutes while I write this, but you get the idea.  The bug reporting system in place right now is not working for the community, and probably not working very well for the devs, either.

If nothing else, realize that you have community members that are taking the time to create concise bug reports with steps for reproducing the issue, and including the requested track files.  At a minimum, come up with a reliable method for seeing them, downloading and viewing the track files, and processing the reports that are generated.

[NineLine]

16 hours ago, FalcoGer said:

Well even if people provide tracks, data, graphs, evidence and logic, then a lot of bugs are not followed up properly.

HARMs not using INS. With evidence from tacview data graphs (a lot of them) of track files (a lot of them) and the logic of 1G means they're not guiding to anything, as well as actual INS guidance (EOM mode) looking different (not 1G) and they actually hit somewhere near the target. Verdict: Correct as is, topic locked.

Objects not being cleaned up properly. Destroys long running servers' performance. High impact bug. Result: "Can not reproduce" for half a year. Then Flappie got to it, reproducing the issue from the data provided in short order. Actual communication taking place with that hero. He asks for stuff, he gets the stuff to find the root cause. People are in fact willing to help and go the extra lengths.

One of mine. FPS issues when using TV mode and looking into the woods (FLIR works perfectly fine). Maybe just me, not sure. Provided track with the first post. Labeled "can not reproduce". Provided video evidence, no further communication. No asking for information, no follow ups, just silence.

Then there is stuff like the recent patch. "Added: IAT now syncronized". Then I'm flying for 5 minutes and IAT desyncs when using LMC. Surely one couldn't blame me for coming to the conclusion that testing wasn't done thoroughly enough, especially since this was the big new thing and the patch was in development for over a month now, granted with a christmas break in between. I submitted a bug report, but it certainly doesn't scream competence when "Fixed bug" in patch notes and 5 minutes afterwards the same bug is found when I'm not even specifically testing the feature with all the variations like it should've been done after implementing it. Again, it's EA, one expects bugs, that's fine. But I'm sure you can at least see where I'm coming from here.

This one has been here for 5+ YEARS. Mig-29 locks anything STT, whole server gets spiked. Not 5 months, 5 years. Are you kidding me? And that's not one of those "windscreen wiper knob doesn't turn to HI without generator power." RWR is a major feature in DCS for all aircraft that have it, it's very visible and obvious, it's been reported many many times now. Why is this still a thing? Sure it doesn't blue screen the computer, but it affects basically everyone. How can this be?

  

 

I can understand most things, but those are just incomprehensible to me. And that's just a tiny sample of the things that have been going on. I could go on for pages. I'm sure everyone is working hard, but maybe the methods are wrong. Or you just need more people.

 

I mean here we go right. So we are not perfect, never claimed to be. Are we better that 5 years ago, heck yes. Will we be better 5 years from now, I would hope so.

Can you pick out all the bug reports that have not been solved yet, or where not solved to your liking and show them off as we are doing a horrible job? I guess so. I mean I could do the same with bad reports etc but would get us no where.

So the first one. I unlocked it, I do not agree it should have been locked if some still feel there is an issue beyond what BN explained, but the info need to be real evidence and and legally usable by us. Weapons bugs are always going to be tricky, why? DO you think these militaries want every secret perfectly modeled in a video game so that everyone can see and use it? If you have public info on what you think it should do, then share it. If you do not and we cannot change it, please use logical thinking why we may not be able to model it. If me or BN or anyone else locks a thread and you have more to add, DM us, we will unlock if needed or get your info checked. A lock doesnt mean the end of the discussion for ever, it only means we believe the issue is done and no further action or discussion is required.

The next one. It was unfortunate it was not caught right away, I will say this happens all the time even for myself trying to reproduce issues and it not happening for whatever reason. This is why these stay open, Flappie who is a great tester came in and got it pinpointed and its now fixed.  Its easy after its fixed to critic how it got there but its not always as easy as it looks just based on the thread. 

The Forrest one. We are right on the cusp of Multithreading and core improvements. Many of these performance bugs will need to be re-looked at when that releases and address after that if still needing. As well we are doing a game wide review of how LODs are created, utilized and handled, all this will impact all of that. So while you might not get a timely reply or response you want that doesnt always equal us not caring or not wanting to deal with it. Also if you are only experiencing this in the AH-64 it could simply be WIP/EA work. If its not just the AH-64 then its in the wrong section. 

Sticking with that one a little longer, a tester, which is what they volunteer to do, is trying to help you along with another user. When we come through and triage reports we see  this and may leave it with them. Of if the tester cannot reproduce, just mark it as such. If many more people reported the same issue in that thread it might get a deeper look. 

The IAT synchro, so I see you just reported it. Great, I see you are unhappy that you had to report it. Well I am sorry and I apologize for the test team if they missed it or more likely reported it and it didnt get fixed in time. Again this goes back to what you are expecting. I mean the easy answer here is to not fly EA access aircraft, I know that isnt what you want to hear but these things are going to happen, especially an EA aircraft in Open Beta. I dont know what to say about this. No matter how many testers we have, no matter how many QA, no matter how many checks, no matter how much we want to be perfect, some things will slip through or rather some things need a larger test sample to catch. 

I am sure this will be seen as another excuse but I dont what to leave out anything that I think might be important on the topic. We are heading towards a MAJOR change in how DCS runs. Multithreading is a huge undertaking, its very invasive and it causes a lot of issues we have been working hard to fix before it comes out. It was close, then pulled back. It could have very easily caused some unforeseen issues just doing that. The point is a lot of the team are focused on the integration of that, and all the other teams are trying to make sure everything continues to work as expected as it comes in as well as add new features and fix existing issues. 

SO after all this what is the conclusion?

Probably best just to copy and past my last conclusion because it hasnt changed:

Quote

So in conclusion, yes we can do better relating information back to the forums about fixes and the status of bugs. You also have to consider the size of the task, and how you may be focused on a handful of bugs, we are juggling hundreds each personally, and then the Devs and management are making a plan based on that. If you think DCS is worse than other games, its the sheer complexity of the game that probably makes these seemingly simple tasks seem so slow and unresponsive. 

PS, send me a link on the MiG-29 STT issues, I will make sure its reported somewhere and that the MP test teams check it out. 

[FalcoGer]

1 hour ago, NineLine said:

PS, send me a link on the MiG-29 STT issues, I will make sure its reported somewhere and that the MP test teams check it out. 

It's not strictly a multiplayer issue. It happens in single player as well. AI locks up another AI, the player (or all players in front of that AI in an MP setting) gets the spike.

1 hour ago, NineLine said:

but the info need to be real evidence and and legally usable by us.

The issue is that there is no INS guidance after the target radar was shut off. It is public knowledge that the missile ought to guide to the last known position using INS. BN marked it as correct as is, perhaps due to a misunderstanding. EOM mode uses INS guidance, CEP is a few tens of meters, clearly showing that the missile was guiding. But with the radar shutting off, suddenly the CEP is a few miles. The evidence was presented that the missile doesn't guide, the evidence being the 1G turn, massively different from actual INS guidance of the very same missile in DCS, and instead goes ballistic. It's real info, and physics is not under the protection of some secret document.

I'm not asking you to defend yourself because I am not trying to attack you. I'm asking for better communication, because ultimately that's where I think everything breaks down.

 

I don't think I can add any more of value to this topic.

[Ogma]

1 hour ago, NineLine said:

So in conclusion, yes we can do better relating information back to the forums about fixes and the status of bugs. You also have to consider the size of the task, and how you may be focused on a handful of bugs, we are juggling hundreds each personally, and then the Devs and management are making a plan based on that. If you think DCS is worse than other games, its the sheer complexity of the game that probably makes these seemingly simple tasks seem so slow and unresponsive. 

I get that; there is a lot of bugs given the complexity of the game and you cannot keep everyone updated.

But it gets really frustrating when the only feedback we get when we look at a nine year old bug is "Yes, we know about it" and that's it.

For example, here is a bug introduced in 1.2.7; it is reproducible in 30 sec in the loadout section of the ME (model viewer). It does affect the game-play since it removes the reticule. All we know about this one that you have been notified about it by new threads being opened regularly in the past nine years because new people stubble on the bug without any fix to be seen.

Or this one, that has been first reported five years ago, also reproducible in 30 sec in the ME; fixed by a wonderful community member three years ago, never implemented. And here again, new threads are created on a regular basis because new people stumble on it since it affects every single Huey livery. And here again no news beside the occasional "we bumped up the report".

This creates a feeling that the bug reports are ultimately useless; which I know to not be true.  But it would be interesting to think about a solution so the community is aware that these bugs are acknowledged and will be worked on at some point; especially for the long lasting bugs. It would be even more interesting to know which bugs are being worked on and how you prioritise them; but I know I am asking a lot.

 

 

[NineLine]

On 1/27/2023 at 3:36 PM, FalcoGer said:

It's not strictly a multiplayer issue. It happens in single player as well. AI locks up another AI, the player (or all players in front of that AI in an MP setting) gets the spike.

The issue is that there is no INS guidance after the target radar was shut off. It is public knowledge that the missile ought to guide to the last known position using INS. BN marked it as correct as is, perhaps due to a misunderstanding. EOM mode uses INS guidance, CEP is a few tens of meters, clearly showing that the missile was guiding. But with the radar shutting off, suddenly the CEP is a few miles. The evidence was presented that the missile doesn't guide, the evidence being the 1G turn, massively different from actual INS guidance of the very same missile in DCS, and instead goes ballistic. It's real info, and physics is not under the protection of some secret document.

I'm not asking you to defend yourself because I am not trying to attack you. I'm asking for better communication, because ultimately that's where I think everything breaks down.

 

I don't think I can add any more of value to this topic.

Thanks, I will see if the MiG one is testable by our MP teams.

As for the INS guidance, its possible that will come later. I dont want to say too much without being familiar with the issue but it might require the new missile API to support such flights. I will ask around. I will add that the public knowing and there being enough info to properly model it can be two vastly different things as well. 

[NineLine]

On 1/27/2023 at 4:16 PM, Ogma said:

I get that; there is a lot of bugs given the complexity of the game and you cannot keep everyone updated.

But it gets really frustrating when the only feedback we get when we look at a nine year old bug is "Yes, we know about it" and that's it.

For example, here is a bug introduced in 1.2.7; it is reproducible in 30 sec in the loadout section of the ME (model viewer). It does affect the game-play since it removes the reticule. All we know about this one that you have been notified about it by new threads being opened regularly in the past nine years because new people stubble on the bug without any fix to be seen.

Or this one, that has been first reported five years ago, also reproducible in 30 sec in the ME; fixed by a wonderful community member three years ago, never implemented. And here again, new threads are created on a regular basis because new people stumble on it since it affects every single Huey livery. And here again no news beside the occasional "we bumped up the report".

This creates a feeling that the bug reports are ultimately useless; which I know to not be true.  But it would be interesting to think about a solution so the community is aware that these bugs are acknowledged and will be worked on at some point; especially for the long lasting bugs. It would be even more interesting to know which bugs are being worked on and how you prioritise them; but I know I am asking a lot.

 

 

Yeah I mean that is the point of my responses, the fact that we need to do a better job tracking and replying to these, I appreciate each and every report we get, even the incomplete ones I appreciate anyone making any effort. I never want anyone going from the forums thinking we dont care or we dont appreciate those efforts.