Muchocracker

Broke how. Post tracks and describe the problem.

Only thing you can really do is put on the 904E4 on the nose and set it up for inst impact fusing. Pretty much answerd it yourself, we can't set the FMU-139 properly at all because they made it EITHER low drag or HIGH drag faceplate selectable based on the bomb you put it in. All we can do is make our case and make noise about it then hope ED puts significant resources into correcting.

To clarify the actual issue here. When the helmet is facing forward within the HUD "angle limit" BACQ should always take priority of HACQ (even with blank off). It looks like when HACQ gets activated it's disabling BACQ entirely and not being re-activated when moving your head back to the HUD. Forcing you to change ACM modes and reselect BORESIGHT to get it to come back. Reported.

i don't believe this was this in the patch notes

Talk to the server admins and have them check the STN's in the hornet DS template.

@OUO@Yuma So we've done some investigation and found that letters are getting inserted into STN's of dynamic templates that were created before the latest patch. For those 4YA server we found had them they were corrected. There is still the secondary problem of every aircraft spawned using a DS template having duplicate STN's. That one can't be fixed and we're gonna have to wait for ED. So you'll still be prohibited from adding members and donors with those slots. You'll get SURV donations tho.

What server is this by chance. Try setting up a dynamic spawn in a clean mission and see if it sets things up right. Could be something about the server running a miz before the patch.

Will look into it.

Hornet and harrier are gonna be different cases.

I've reviewed some of your test cases and the things you pointed out as unexpected behavior and here's some of my notes. Couple of things to note with the ARM function. As you correctly pointed out it's basically non-functional in DCS as of right now. But there's some confusion that's gonna be caused if we don't narrow down which function the ARM option is serving depending on the initiator that's being loaded. When the MK-112 initiator switch is loaded, the ARM button is in "FFCS" mode. Which gives 5 and 10 second arming delay times. More importantly the option selected here does change the arming delay on the bomb, as it's connected to the jet with a COAX cable. This makes the FMU-139 show up with EFUZ in the SMS The 6/7/10/14/20 second arming delay is for the "FZU" mode of the ARM button when the bomb is loaded with the FZU-48 initiator. Contrasted with the 122 the ARM option does not change anything on the bomb and is only for matching the faceplate with the SMS so the DUD cues are proper. The FZU is a mechanical switch that is energized by a turbine after release. This makes the FMU-139 show up with MFUZ/TAIL in the SMS It's hard to know which one ED is basing all of their avionics functions on as there's some things that are using the mk-122 functionality in the avionics. But with the bomb fusing settings themselves they would be set up for the FZU-48. Case in point; If the bombs were set up for the Mk-122 we would have no arming delay setting as the SMS would automatically override any setting used in on the low drag faceplate. And any highdrag deliveries would cause the arming delay to be overriden to 2.6 seconds. Idk man, for ED to fix this issue it's gonna be complicated as they have to maintain compatibility across all modules that potentially use different fuses as well as initiators (mk-122 is navy specific). Whether than means they make the system module specific so they can do this or they add initiators to the fusing menu depends on them. i've not found any evidence to suggest that the JPF page goes away if the JDAM is not loaded with the FMU-152. So unless you have some then i wouldn't consider this relevant nor any of the information it provides as it's not connected to anything. This one i have reported before as well interally, but i forgot that this FPP document directly calls it out the DLY1 is replaced with VT1. Will add to that report. Honestly, it should just default to the newest available one that there are detailed documents of.

Yeah that's gonna be a side effect of the old miz file using the old bomb config and it screws with the hornet avionics. In my previous tests they were hitting fine providing you had new bombs and matched the height setting on the bomb in your SMS. I'll watch the track you post and see what's up.

-Are you making a fresh mission or using an existing one? There is a current bug relating to old missions before the fusing update. -Are selecting VT1 or VT2 in MFUZ. VT1 uses HOF and VT2 uses the secondary TOF option. The order was corrected in subsequent patches after this report was made -Are you touching EFUZ? It's a bug that it's there with the CBU-99 and should not be there. If you don't leave it off it'll dud your bombs The arming time is also lying to right now as you'd think it was for the VT2 time option but it's not working as such. It's acting like an arming delay, which shouldn't exist as the FMU-140 does not have one. So VT2 is locked to 1.2 seconds.

I don't think i've ever had this happen before. Can you post a track demonstrating the TGP slaving to the wrong waypoint?

wait, so was the issue occuring when using dynamic spawn, or slot spawn? Your original wording was normal slot spawn.

Recreate the issue and post a track, there is something else going on that i don't have the context to see. I don't have this problem on 4YA

You're gonna have to give more details chief. What is your STN showing on the TGT DATA, is it your mission file or somewhere else like a public server, was your buddy a hornet or another aircraft? If he wasnt showing up on the SA page then one of your TNDL's was turned off, that or STN's are not set up correctly.

jesus....That's gonna cause so many more issues. I'll add this to what's already been reported.

it's a known issue. If you look in your DL pages you'll see your STN box is empty or X'd out. Dynamic Spawns doesnt seem to be automatically assigning them.

Nothing should be rendering outside of that small box. So any element that is would be a bug.

There are a million different causes for any issue. You did not provide sufficient detail of your failure case to give an answer of what is causing it. So i asked for a track showing the issue happening to do that. To give you the right answer of what the issue is and what do do about it. None of that has anything to do with me playing the mission (which does not guarantee that i get the failure case in the same exact way you did), none of that has to do with confirming does or does not exist. Do you understand that?

There are a million different causes for any issue. You did not provide sufficient detail of your failure case to give an answer of what is causing it. So i asked for a track showing the issue happening to do that. To give you the right answer of what the issue is and what do do about it. None of that has anything to do with me playing the mission (which does not guarantee that i get the failure case in the same exact way you did), none of that has to do with confirming does or does not exist. Do you understand that?

I'm just going to repeat myself until you understand my words. There are a million different causes for any issue. You did not provide sufficient detail of your failure case to give an answer of what is causing it. So i asked for a track showing the issue happening to do that. To give you the right answer of what the issue is and what do do about it. None of that has anything to do with me playing the mission (which does not guarantee that i get the failure case in the same exact way you did), none of that has to do with confirming does or does not exist. Do you understand that?

How mother of god bro how many times do i have to keep repeating this. Your initial post did not give me enough information to give the right answer to what's causing your bombs to DUD because there are many causes for it. I asked for a track to do that. What is so hard to understand about this? None of this has absolutely anything to do with whether the bug is repeatable or not, nor does it have anything to do with if it's tested before a patch release or not. It was to give you the right answer, not to confirm or deny the bug existed of which it was already reported and i was one of the first to confirm it was a known issue.

Nice ad hom. Where did i say that they had to post a track? I said it makes it easier, espeically when there is no further detail of the failure mode. you should look at yourself and ask that question. You went on an angry rant about a completely irrelevant topic screaming at ED when all i prompted was for you to post a track producing the issue so i could give you the proper explanation of what is causing it in that case and the workaround. How do you know what is reported and not reported in testing before an update release?

Not a single other thing in your pointless ramble about being asked to provide a track was relevant. Of course i'm not going to address it. You really must be a miserable person to be around if you can't possibly fathom that something you're doing is wrong and it's everything else. Idek what you're talking about anymore, this is all entirely irrelevant to this post and my request for a track to diagnose the root cause of the issue through your playing of the mission. Your report on the A/G radar designation is reporting that the bug even exists. Do you not understand that those are 2 different things? And it was acknowledged by ED that it's reported at that, if the bug is acknowledged and reported there's no reason to need to post more tracks. You just raise the issue to get it pushed to be fixed. Completely irrelevant whether it's an ED made mission, or your own, or a 3rd party campaign. What matters is the process of how the unintended behavior happens, that is why tracks are asked for. So the process of how the bug is produced can be observed and determine the root cause. Even just one example tells you why; A player has an issue with CBU-99's not dispensing the submuntions. Not other detail is given except they used VT1. There are a number of reasons that it may be happening; -They loaded another pylon of CBU-99's with the mk-339 and caused an MC LOAD fault -they chose VT1 2 instead of VT1 because of a prior issue where the settings were reversed and they dropped the bomb inside of the DUD envelope making the munition impact the ground before the timed function delay was reached -the jet was an air start and so it had the old bomb config -the jet was a ground start and used an old saved loadout which causes the same thing to happen. Different causes for the same effect. And that can multiply when you go outside of this scope and look at other weapons and systems. Every single detail matters matters when doing diagnosis, and tracks make that easier for everyone. For me, for other people trying to help, and for the developers.