[HOUNDS] CptTrips

Also, I couldn't see from the vid. How many hits did those top guns get? Or I can check if you post the exact miz. I don't want to introduce an accidental error editing anything.

I see your video. It's not what I'm seeing. You aren't running any kind of internal build are you? Here is what I see from your tail gun mission except moved the FW up to be outside of the tail gun. All briefing says it that chin gun eventually shot. (See track and miz below.) Is top gun shooting? If you give me the exact miz you made the film from I'll try it specifically. NOPE.miz NOPE.trk

I'll try it. The one I modified from your tail example didn't even though it flew right over the top of the gunner. (See NopeMiz.miz attached above.) (Chin gunner did shoot. As expected.)

Did you check the debrief to see which guns were shooting? I don't know why this is harder than it should be. If you can just post a "correct" mission with the settings that make the top and belly gunners operate properly. We can then use that to fix our own missions. That would be the easiest wouldn't it rather than arguing? Can anyone?

What I'm asking is, are you seeing the top and belly gunners shooting properly? Show me your own test mission if mine are "incorrect". Can you demonstrate the top and belly guns operating properly with track and miz? ?

I just tried you mission. I moved the FW up closer so the tail gun couldn't shoot and he just passes over the top of the bombers. (See attached.) I saw no top gun shoot at all. Eventually the chin gun shot after I had passed, which isn't surprising since I graded the chin gun as "fine". Can you provide a miz and track of the top and belly guns operating properly? NOPEmiz.miz

Can you post me a track of the top and belly guns shredding up an attacker? Include the miz too so I can confirm. Thanks in advance. What threat setting are you saying fixes the top gunner?

Are you refusing to look at the mission I posted? Really? Seriously? Just flat out refusing to even look?

OK. Tried your mission. You showed the same results I did in my "incorrect" test. Which is why I grade the tail gun as "fine" in the first post I am not sure you read. So now where are we?

HAVE. YOU. TRIED. THE. TOP. AND. BELLY. AND. SIDE. GUN. EXAMPLES. I. POSTED? Please show me the courtesy of looking at what I posted. Then we can discuss further.

I will be glad to, but a couple of points. 1. Passive defense is the b-17 default when placed. I assume that is to tell it to maintain formation and defend with its guns instead of make crazy evasions. 2. I had graded the tail gun as "fine". I also noted he killed the target. Regardless of whether you like them, before responding please try the top, belly and side gun examples I posted and simply tell me if that behavior is correct as-is.

From the top and belly guns? Can you post a track. I've only ever seen the top gun shoot once. It was off by 50 yards on a perfect target. Are you saying that is intended behavior? Have you tried the top and belly gun examples I posted. Regardless of whether you like them. If it's not too much trouble. Just to make sure you understand what I am posting. This thread also has a A-20 example. Demonstrating a similar behavior to the b-17. Is that intended behavior?

You need to look a little deeper. I graded the tail gun as "Fine". Try the top and belly gun examples. Are you telling me that is intended behavior? If so, you might want to tell these guys it's correct as-is.

That's not what I said. The problem isn't that you are not looking at enough issues. I assume you are working at capacity. The issue is when you have looked at them, or are researching them, or have reported them, you are not taking 2 sec to add or update a tag consistently. That costs you more work to have to type responses to this and other queries. I'm not saying you have to type a reply to each issue. What I am suggesting is to avoid you having to respond to someone asking what the status is. Adding or updating a tag takes less time than reaching for your coffee cup. You could have updated the status tag on 20 issues in the time it took for you to explain to me why you haven't been updating updating tags. But when people get frustrated and cynical and think ED doesn't care about fixing bugs, only selling new modules (which I do not believe), to a large extent is self inflicted for want of a tiny improvement in your CRM process. In a vacuum of feedback, they assume they are being ignored or ghosted (which I do not believe). But I think I've explained my point sufficiently. You do what ever you want. $0.02.

BTW, no one is suggesting going back and fixing years worth of posts without useful status and update them. Just take a couple of seconds on the issue you are working on currently and as you work with them, update a status tag. Takes less time than reaching for your coffee cup. And in the future, try and be more disciplined about tagging when you start touching an issue and update it as you go. Communicate back to the community through tags, start to finish. We're talking about seconds here to avoid frustrated customers wondering if they are wasting time just posting issues in to a bit bucket never to be seen again. I don't believe that to be the case, but it is easy to see how that frustration could arise without timely feedback to keep customers informed. If nothing else, it is a really easy and cheep way to buy your team a lot of forgiveness and patience at the cost of a couple of extra seconds. It's a discipline issue not a resource issue.

Nonsense. It takes mere seconds to add a tag. I'm not talking about fixing the bug. I'm talking about consistently adding and updating a tag as they work with issues. If you already have it open to review, just add the tag while you are there. "Queued." 2 sec If you select that issue to research, bump the tag to "Investigating" . 2 sec When you've reported the issue, just bump the tag to "Reported". 2 sec. Compared to the amount of time investigating a bug, updating a status tag would be a trivial percentage. As opposed having to stop and type an answer different peoples questions about a thousand different issues in process. Have to type out an answer one query would take longer than updating 100 tags. Are you a programmer? Ever work with a bug tracking system? A bug report has a status field for a reason. You keep updating the field as the issue moves through the process so that anyone can open the issue and check the current status without having to come to your office and beg for information. I assure you it is a much better approach. There is no issue here of time or resources. It's simply taking a little more care to keep status updated in a consistent and disciplined manner. The cost is mere seconds. It will save them more time than it costs and leads to a better customer experience working with support.

Cool. Maybe the innovation is the idea of actually using them in a consistent, disciplined manner? I just scrolled through 20 or so pages of bugs. I didn't see any marked "Investigating" . Does that mean none of those issues not marked "Solved" are being looked at? How would anyone know? I would like to see one before "Investigating". Something like "Queued" so I know ED is aware of the post even if they do not yet have time to "investigate" (as apparently it can take quite a while until they can get to look at it). The guys in this thread have been begging for two months to even get acknowledgement the report has been seen. Has it? Has it already been reported? How would they know? I posted a similar bug June 13. Has it been seen? Has it already been reported? Is it not really a bug? How would I know?

This is my third attempt at this note. LoL. I keep scrapping it telling myself I’ll only create problems for myself. There is always a probability of being misunderstood and also every community has white-knights that love to ride in and defend against any criticism no matter how well intended. Oh well. In my former life I was a UI programmer. The one cardinal rule of UI is above all else give the user immediate and continual feedback. Apple is super hyper about this. If I click of a button, it has to visible show me it recognized the click (depressed state, audible click) if it is then going to do a longer process, it should inform me. If that process takes more than 3 sec (that was a rule at my last company) it must have a progress bar that moved so the user realized something is occurring. Otherwise customers can get really impatient, really fast, especially when they don’t know what’s going on. Did it recognize my click? Is it doing something? Is permission denied? Is the software hung? It’s amazing how much more leeway they will give you as long as you are acknowledging their command immediately, and letting them know where they are in the processing from start to completion. Studies have even shown the users PERCEPTION of he delay is less when they are kept informed of progress in the UI. With immediate feedback and a progress bar a user might perceive the delay as being 20 sec or so, without that they will say it was hung for minutes. In reality, in both cases, it may have been 30 sec. I mention that just so you understand what I am referring to. I’ve noticed that there is a real lack of consistency in how users bug reports are tagged and timely feedback returned to the bug reporter. I had a bug I thought I had well documented and explained so that it wouldn’t be misunderstood. I then waited. And waited. Had anyone at ED seen it yet? How would I know? Was the post clear enough for ED to understand the concern and did it have all the info needed for analysis? How would I know? Had anyone at ED reproduced it it yet? Do they agree it is a defect and not just something I misunderstood? How would I know? I finally had to start asking and apparently it had been seen, it had been reproduced, they agreed it was a defect, and it had been escalated to development. How was I supposed to know that? Only after I had poked with a stick did the “Reported” tag finally get put on. Meanwhile I had been drumming my fingers couple weeks awaiting to at least have my existence acknowledged when in reality it had already gone through the system. Don’t make people poke you with a stick. I had made a joke about problems with the B-17 gunners and Nineline acted like he had no idea what I was talking about. That worried me because I had recently submitted a bug report a week or so before, and doing research found another very similar (I suspect same root cause) issue reported for the A-20 in the WWII asset pack bugs section from a month before that. And from that thread, it seemed like lots of people know about this type of issue. So I would have assumed it would have been something the support team is aware of. But neither mine, nor the A-20 thread has had any feed back from ED. Are we misunderstanding something? Is there a magic setting we don’t know about? Is it currently being reviewed? Has it already been reported? How would we know? I’m not trying to bust your chops. I’m trying to explain the PERCEPTION of the process from a customers point of view. I understand you have your tails on fire with MT threading now and that is all hands on deck and obviously show be the to priority. I understand the difficulty. I’ve done MT threading. It scares me. I’ve seen whole products fail from it being done badly. MT bugs are the worst bugs to fight because they can be horrifically hard to reproduce. Which means it is hard to prove you fixed something or if the nearly random thread interaction just hasn’t happened again yet. Oooof. Good luck with that. MT is always best carefully designed in from day one, like localization. It's a pain to duct tape on later. I’m not demanding my bug be fixed immediately. Once it is escalated to development, it is out of your and our hands. We’ve done our part then. What I am suggesting is a more consistent, timely communication of where a reported issue stands in the first level support process. I think that would benefit the customer and your team. Even if things don’t get fixed any faster, the feedback alters the PERCEPTION of the process for the customer (like UI feedback). I don’t know what tags you currently have to use, but I would suggest a fine granularity and encourage their timely and consistent use. I’d like to see the following tags used liberally: “Queued for Level1” Someone at ED has seen your post. They acknowledge your existence. You are not being ghosted. Should reach this stage within a couple of days of submission. Just show me the ball is rolling! “Level1 Review” A first line support guys is actively reviewing what you wrote. “Need More Info” A first line support guy has looked at it but need more explanation, logs, miz, trks. “Correct as-is” (Add a link to users manual or something to explain.) “Duplicate Report” (Add a link to original.) “Reported” Let the freakin customer know! That tells them Level1 has reproduced it and agrees. It tells the customer that all the needed info is there and the issue has been escalated to development. That’s all I hold you guys accountable for. “Solved” Note the version number that contains the fix if it was a code fix. I've seen some of those used...sometimes. Some of those I think you should add. I think you should use them more and consistently. I shouldn’t see years old bug posts with no tags. How did that end up? Was it ever reported? What it just a misunderstanding? Something that was fixed? What version? The guys in the A-20 thread were commenting for weeks that they couldn’t get any feedback from ED. Has anyone seen their thread? If not why not provide feedback. The people in that thread feel like they are being ignored. Do people have to start a sht storm to get attention? Without feedback, why should people assume the worst possible scenario; that they are being ignored. Please take this in the way it is intended. I think a more refined and consistent feedback of the support process would take a lot of heat out of the experience and buy you a lot more patience with very little extra effort. It’s just basic CRM best practices. I could be full of it, but that is my impression as one customer. I think the current approach leads to unnecessary frustration for the customer and additional avoidable pain for you guys when customers get bitter and believe there is no point in trying to help find and isolate bugs. You don't want people to start feeling like there is no point in working with support, "They will only ignore you." even when that is not the case. $0.02.

I don't have comparative logs, but I noticed the same delay all of the sudden. three things have changed recently. 1. The latest patch. 2. I started using the MT steam version. 3. Just recently installed the Oculus software.

ED has to make money, but fleshing out WWII could make them money. I just bought the asset pack and Normandy 2.0. If they would flesh out the asset pack with missing items (even just AI), and fixed certain things like the buff gunner issues, then I would even buy a WWII asset pack 2.0 as long as there was an upgrade path. WWII has the advantage of not having to dance around classification issues and it has no shortage of documentation and the platforms are a lot less complex than the highly computerized modern stuff. It would also make a very good on-ramp to the DCS ecosystem. Players who are not quite ready to bite off the systems complexity of a F-15 could get started with good old stick and rudder WWII action. Broadens the net casted for new customers. Hopefully after they put out the MT fires, WWII could get some more love. $0.02.

Soooo, Two Weeks?

Sorry for the spam but I want to give you as many data points as I can for debugging. Not sure what the difference on this one was. I was piddleing around with the alt and suddenly the top gunner woke up and shot some rounds. Of course they were horribly mis-aimed, but at least he pulled the trigger. Maybe debugging these different miz will reveal what is going on. Miss. Miss. Miss. (See attached miz.) TestBuffGunners_top_didshoot.miz

If he would shoot.... Effective range 600 yd (1800 ft) except high rate of closure targets then effective out to 1000yd.

The ball turret is the worst gun position to lose effectiveness on. It was the most fear by LW pilots. (I would have said the tail gun, but what idiot would approach from dead 6 I guess. Maybe in RL the sun glare was more of a problem for top rather than belly gunner.) The ball turret may have had up to 57% kill effectiveness of engaged targets. Gunners would start shooting out to 600 yd (1800 ft vs 800ft in DCS). Especially if the fighter is closing on them. If a fighter is diving on you, if you pull the trigger at 600 yd the target will be at 400 yd by the time the bullets connect. I fear the top turret as much for my normal pass. If he would pull the freakin trigger, the top turret is shooting at me at the start of my dive before I've built up max speed. The ball turret would be shooting me on egress after I have converted the dive into max speed. But gunners should be shooting out to 600 yd and should be achieving reasonably good hit percentage in their prime kill zone.

Some gunners won't shoot at all. Some gunners fail to shoot at ranges they should. Gunners that shoot, seem unable to calculate proper deflection lead and fail to correct their mistake. (Probably why the chin and tail gunners seem better, because velocity vectors are mostly aligned and little to no deflection is needed.)