LastRifleRound

That says it drifts less, not that fixes are working

Was it fixed recently? Wasn't mentioned in any notes. It was not doing that before.

The bigger problem here is why isn't FIX and cursor slew working correctly? No matter how large or small the drift is supposed to be, it cannot currently be corrected. This is a pretty big problem and certainly not intended. MOVING THE CURSOR should update the whole flight plan in an F16. That's why Cursor Zero is so important to understand in the Viper. FIX just resets the cursor zero point to the cursor's current position (be it radar, HUD, TGP, etc), but slewing the cursor is what moves the flight plan. The current Viper does not do this despite the fact that this behavior is well-documented in the dash manual.

I guess anyone interested should have reviewed the tracks the months ago when they were posted. I think we'll just discuss them unless someone wants to pay us for our work. We'll keep letting people know this stuff doesn't work. If ED wants to confirm it they can re-create the tests. If they think that's too much work, fine. Out of my hands. It's too much work for me, too.

There are 4 tracks in the thread linked above, and posts indicating hours of work @Nealius put in to demonstrate this. Other users also posted videos and images demonstrating it. Anyone else replicating this work would do nothing but confuse the issue and that thread dead-ended back in November with no real official response. I see no reason to re-create the hours of work that would take if the initial input wasn't taken seriously to begin with.

It's pretty sad this thread dead-ended because no one wanted to directly address the primary questions at hand. 1. Is 240m of drift within 1/2 hour of normal (no extreme maneuvers) flight with GPS on acceptable? It is undoubtedly happening, the evidence posted in this thread and the work @Nealius put in demonstrate this clearly. 2. Why does FIX not update subsequent waypoints, with our without GPS on? You guys need to go with preponderance of evidence. This clearly isn't right. Either you shouldn't have made videos telling people to use FIX, or FIX isn't working properly, and I'd bet my house FIX isn't working properly. There is no way on God's green earth that FIX only updates the single waypoint you use it on. There is no way the Kalman filter filters out fixes because it weighs LITERALLY every single INS data point the same. It doesn't. There is no way the Kallman filter rejects nav fixes because they don't exceed 300m, but doesn't reject also the INS data that induces drift under 300m. The logic itself is incoherent. Out of curiosity @Nealius have you tried using ACCAL for your first fix with GPS off?

Nope, referenced right from the Hornet TACMAN. That's how it's supposed to work. EDIT: Also, what I described is not how the F16 offset behavior works.

That's because it isn't fully implemented for the Viper or the JF17. It is in the Hornet. I can see why, as the Viper docs don't really say what happens when you FTT other than it tracks a return. FTT looks for the point of greatest return in the cone and tracks it, which HOPEFULLY (but often isn't) is your target. For large buildings, ships, and other large return, isolated objects it can add precision as it's not relying on your interpretation of the radar imagery. However, the radar will lock the greatest return, regardless of whether or not it's your target. If you have the Hornet you can test this. Put several static objects relatively close to each other, slew the radar over them then SCS to initiate FTT. You'll see the lock doesn't necessarily pick your target. Often, you can keep re-initializing the FTT and will pick different targets each time. FTT really is typically used for ships, otherwise the AG radar is used more as cueing for sensors or eyes, particularly with the help of offsets.

Of course not

Easy comms was disabled. It may not be a bug, but the comm trigger point seems to be either too far past the airfield or mis-firing somehow. I noticed the gear fault earlier than I was "supposed" to. Since the fix is scripted, the manual was no help and following the real world procedure does nothing until you trigger the dialogue. I was in the air 5nm from H4 for 15 minutes fiddling with it before the radio dialogue triggered. At about minute 10 is when I paused the sim to ask the forum.

Nevermind. Comms bug in campaign. Was supposed to happen but trigger didn't trigger.

Playing the first actual mission in the Gamblers campaign. Fly all that time, it's time to land, I hit the gear lever and it immediately bounces back up. Try it on my hotas, hitting the g key, clearing all keys then doing it, playing with the yellow knob below it, nothing works, gear lever goes down half second then bounces up. I'm at 200kts, 5000ft. I don't understand what's happening.

Well my replies keep getting deleted, so I guess you win? Your testing is flawless, and no one should use the forums to critique the handling of anything from ED. You absolutely can and should ask for tracks as many times as you want for the smallest and easiest explained items, and you absolutely should not under any circumstance worry about anything in your software unless some random paying customer has jumped through at least 4 hoops for it. I concur completely and yield the floor to you.

Do you understand that I am telling you that following the instructions in the JDAM training mission DOES, in fact, guarantee the same failure case every time? If you fly that mission and follow it as intended, you WILL get dud bombs. Do you understand that I DID describe the failure. It is a dud bomb. Do you know what that is? I think you do, so I'm not sure what other detail I could provide. It's rather elementary already, isn't it? It's not a CBU and has no tail fuse. It's an air start training mission, so no ME access, and rearming isn't possible. Either setting the e-fuze to INST makes it go boom or it does not. Why won't you fly the mission? Why leave it for customers to waste their time wondering if they did something wrong? Why is it ok for you to ask me to fly the 15 minute thing AGAIN just to record what I already explained here, but it's NOT ok for me to ask you to fly it? You're on the testing team, are you not? Do you only test things users bring to you, or do you do proactive testing? If you do proactive testing, what is the difference between you testing this mission sans track with no one asking and you flying it now? Do you just assume after major changes all the training missions work without actually checking them? I did nothing but follow the instructions (some bombs get e-fuze to instant, others get delay 1). That 100% leads to a dud bomb. I'll pay you $200 if you go in that mission (public release, not your test build), fly that mission as instructed, and DON'T get a dud. That's $200 for 15 minutes of work. If you're so sure I'm wrong without a track that's a great deal. But I think we both know I'm right and you'll probably just be wasting your 15 minutes, just like I would be.

You do not have to do A SINGLE THING THAT I SAY. Just fire up the FA18 JDAM training mission that COMES WITH THE GAME. Follow the instructions THAT YOU PROGRAMMED INTO IT. Report back your results. Good luck!!

THE BOMBS DUD IN THE JDAM TRAINING MISSION WHILE FOLLOWING THE INSTRUCTIONS. WHICH PART OF THAT SENTENCE CONFUSES YOU? WHICH PART DO YOU REQUIRE TO SEE IN REPEATABLE VIDEO FORMAT? The second half of my post even told you what the issue was and what ED needs to do to fix. You are literally not necessary. No one needed you for anything. Well, we did, before the update, but now I think we're good.

Buddy, an ad hominem is when you attack someone instead of their argument. If I'm being charitable I think you meant strawman, but either way, my argument is that tracks should not be necessary for ordinary course-of-action items, because those are the sorts of things that should be well tested BEFORE updates release. Your argument is that I'm wrong because sometimes the user gets it wrong. I countered that sure, that's true, but when it's something like a training mission that's a bit of a stretch, as that sort of thing should have been tested before the update anyway. You side-stepped that and instead called what I said a rant, and quoted some unrelated prattle about CBU's, that has nothing to do with JDAM training missions. I then re-simplified the argument by trying to see if we can find some common ground. I find it hard to believe that you would actually think that every single bug whatsoever must have a track or it's just not reasonable to expect a fix. If I could get you to agree with that, then we agree in principle then it's a matter of degree. Instead, you label that re-simplification an ad-hominem (it isn't, that'd be if I called you lazy or said you were a crappy tester or something like that, none of which I did) and here we are. The funny thing is the bug was actually already reported in the bug section. I'm just pushing back on the way ED has been doing things lately because frankly, it's rubbing a lot of people the wrong way. So ED has these bug reports on things they know are broken, but make us post tracks of them anyway? On top of that, they're aware that training missions are broken but just don't bother saying anything, leaving it for the users to find and jump hoops for? That's actually worse.

Is it your position that unless a user provides a track you find it literally impossible to find and correct a bug? If it isn't, then what the hell are you arguing with me for?

Because I've done it a 1000 times. Here's what happens 95% of the time: 1. Forum users post immediately and ignore your track, telling you how its definitely your fault anyway, often quoting a useless irrelevant truism from their favorite SME like "not that accurate" 2. If you do not jump on it and argue with people in step 1, thread will be marked "correct as is" without anyone bothering to look at your track. Start over at step 1 3. Congratulations! You made it past step 2. You're told someone will look into it 4. It has been 3 months, nothing has happened, you mention it again 5. "Post a track" 6. Link 3 month old thread 7. Start over at step 2 Also, I could turn this around on you. What's so hard about just trying the basic functionality yourself? In fact, what's so hard about testing the training missions BEFORE a major update? Why is it my job to make sure ED's training missions work?

This is why I hate tracks. You didn't even fully read my post. Look at my post history. You'll find loads and loads of reports with tracks and detailed analysis that hasn't amounted to much. Hows the AG radar designation being inversely affected by aircraft movement coming along? Lemme guess, need another track? I mean it's only 4 years old. It's ED's own Hornet JDAM mission. It's an air start. For people trying to learn the game. Just test it as is. You know, the thing that's supposed to happen before major updates release. I honestly can't wrap my head around launching a big feature like bomb fuses, and then simply not testing the largest entry point for new users, training missions. I'm not hating on you but the users don't work for you. You're supposed to deliver a functioning product whether we leave tracks or not. There is no more open beta, and the Hornet is not in EA, so there are no excuses. The bombs dud in the training missions. Simple as. It's your (ED) fault because you didn't check them and update the armaments, and you need to fix them. You should do this whether we can provide a notarized bill passed by congress or not.

Track? My dude your own training missions dud all their bombs. Just fly the JDAM one and tell me how your BDA goes. Bet you don't pass. Tracks should be for bugs that are hard to recreate or dubious. For bugs that happen in the normal course of use and run headlong from a foot ball field away and superbowl punt kick you right in the face like a mountain of cocaine to al pacino's nose, I think the whole "track or it didn't happen" thing is a bit overwrought. @PawlaczGMD is right, every mission you have to re-load the bombs, either by re-arming on the ramp, or just changing the loadout in the ME (if you can get at it). Just pull the bombs off and re-add them, and they should work again. I'm guessing instead of supplying default fuses on missions (my own custom missions had the same issue), they just supply bombs that can't accept fuses at all (and therefore I suppose have none).

I had the idea that maybe with the new ARC 210, that channel 34.3 should be entered on the 210 instead of the dedicated FM radio, so I flew again with that set. Everything went fine until, once again, enemy infantry attacks across the river. The gun does nothing to them. Additionally, they appear to spawn/despawn oddly, so making one pass will never kill all of them or even most of them. You MUST use rockets to score hits. I popped full labels on so I could closely monitor what was happening with the enemy and, at one point, I thought everyone was dead, though Axeman didn't say anything. All of a sudden, more infantry appeared literally out of thin air and started attacking again. Unfortunately, while this is effective at killing the enemy infantry it will take many passes, and you almost CERTAINLY will end up with a blue on blue, as when the infantry "respawned" they were on the other side of the tree line crossing the river. I accidentally blue-on-blued one Georgian ranger (identified in the debrief as #3). Is this guy Axeman? There were radio calls after that one of "don't how much longer" etc. Once I killed all the enemy infantry, but never heard anything from anyone ever again after flying an additional 10 minutes with 0 activity. I think this part needs to be cut out or the trigger has to be added that firing the gun in the correct area will automatically thwart the attack, as it is obvious the DCS engine cannot handle an engagement of this type in anything approaching a reasonable manner.

The trees are messing up the shots for sure. It was on easy comms after the update. I fixed it, but it happened again. I sometimes hear nothing but static through the FM radio. Is it possible the radio update ED psuhed requiring LOS messed with this? I'm high up and over the valley most of the time, but if axeman is next to a building or something maybe it's killing comms

I reported a bug in offsets a few months ago. The real problem with offsets is designating anything overwrites the offset, killing the purpose for them in the first place. Let's say INS has drifted. There is a target a known distance and bearing from a radio tower. This radio tower is a waypoint, and we've added the offset data to it. I designate the OAP which should be a large radio tower. I can see in the TPOD the designation is off, so I SCS then slew the TPOD onto it, and hit designate. I then hit offset. Expected behavior: I am now looking at the target. Actual behavior: Nothing changes. The offset is now the designation point. The offset data has been changed to reflect the designation. The tail is effectively wagging the dog. There is nothing in any documentation that suggests slewing a designation on a designated OAP should overwrite it's attendant offset data but that is exactly what it does. This feature cannot be used for its intended purpose until this is fixed.

The biggest reason for misses using DT is not being wings level when first hitting pickle. If you're not wings level when pickling, you'll "throw" the bombs crooked if you maintain that attitude through the release. If you are not wings level when first hitting pickle, then roll wings level as you pull up, you'll put the bombs in a straight line beside the target. Easiest way to get hits is largely ignore parameters (they're not really needed), make sure your dive angle is 30 degrees or greater (makes radar lock faster and the reticle move slower relative to the ground), and make sure wings are level just before pickling then all the way through.