Harley

Seems the communication breakdown is about "can" vs "should". NATOPS is not a reference of design, but operation. Just because it's not in the book doesn't mean that mechanically these settings "lock out" or otherwise disable other functions. NATOPS is how the navy and the builder expect the pilot to handle their airplane. It is not a book that causes mechanical limitations in design or function. It's an abstract I think he's trying to point out. Just because it's not in the book doesn't mean it's locked out or just can't be done. Blue Angels takeoff with no flaps. Or at least the videos I have of them show it like that. It is very possible to do. I think it's the difference between "you can't cross the double yellow line" and "you can cross the double yellow line, you just get in trouble for it." And that may also be where the challenge is for DCS, is that the book is all they have to go on. So, they're somewhat reverse engineering the flight mechanics from the book written after the plane was already built, and retired from our military, really.

Something broke with the last update. I've noticed this also. Even in manual mode, it's behaving strangely. Using the throttle quadrant, the dispense button should be simple. In manual mode, whatever program you set. The fwd button is supposed to dispense only one if the item, and aft is the other. I'm not in front of the game now, but the settings page still confirms the intent. Fwd on the thumb switch should dispense whatever the selected program is set to dispense for qty and type. For example, if the program on page 5 is selected, and it's set to 1 each, then the switch should pop one of the commanded, be it chaff or flare, depending on which way the pilot pushes that switch. Right now, it is fwd to run program, which doesn't seem to correlate to the settings programmed, and aft to stop program. It's all messed up.

It seems to be getting worse every time they touch it. It's raised the debate for me to even report some of these things or not. But, at least it's being worked on. I'm sure that the "bobble" they refer to is a very slight but noteworthy behavior, needed for precision. I love the posts you've made up there about this. I have questions. 1. The engineers ad McD/D definitely tried to minimize the forces exerted with the speedbrake's force by integrating an FCS counter. I think you've made the argument pretty clear with your attachments up there. I need to look again, but it looks like a force can be calculated with the area of the speedbrake panel, airspeed, angle of deflection, ambient air density, and then the total expected FCS counter/retrim, and the only thing that needs to be inserted into the equation is the time to deploy for both. Can that be assigned with the model as it is? Also, if that has been done already, because DCS devs are pretty thorough, is it unrealistic to ask to minimize the effect if all is correct as is? Something tells me it's not. Can you imagine how badly this will mess with a precision approach when trying to correct for overspeed on final? I need to try that. Even ACLS may have issues with that. I dunno. I suppose I'm not as in depth with the numbers as others, but it seems intuitive enough that the attempt to counter the speedbrake nose up input has been made, but the implementation hasn't been good yet. It seems that if the system was integrated, then it should work little better than current.

Understood. Nobody wants to be blamed for disseminating potentially classified information. Those kinds of consequences are definitely unwanted. For clarity, the book is out there, am I allowed to reference the chapter? Meaning where to find the info, or is assuming that someone else also has this info still too close to "sharing"? Nobody wants problems, and I don't want to be that guy. Honestly, and I think it's pretty clear, I'm only trying to help, and I'm not a "beta tester", nor am I seeking that, but I do log plenty of flight time in the sim, and think I can contribute helpful info. That's all. Sorry to cause any issues.

I didn't know that was a problem. I downloaded that whole manual for free online. It's definitely widespread, easily accessible. Who knew? Sorry about that. But the point still remains.

Wow. You know, it's always a precarious situation to report things or not. We never know what the result will look like. But honestly, the effect is even more pronounced now. I was around 300 kts on base earlier, and deploying the speed brake in that regime is way more dramatic now. I'm going to see if there is a definition in the NATOPS for the correlated degrees of travel that the pitch correction input from the elevons is supposed to be. It seems that the jet will perform a pitch correction, but AOA changes significantly more now. A "bobble" is a rebounding effect, normally a momentary motion while transitioning. Maybe it's just me, and I'm ok with that analysis, but it seems far more dramatic than a ground attack role would prefer. Doing some homework...

If that's the case, then it seems that even McDonnell Douglas got it only close, also. I see what you're talking about in Chapter 11.1.6 of the NATOPS. I suppose this is as good as it gets, based on that. Ok then.

Addressed, but it still doesn't seem quite right. I think the elevators are supposed to compensate for the speed brake deploy and stow, meaning the force generated is countered, with a net effect "close to zero" as possible. The stow cycle still takes longer than it does for the elevons to retrim, meaning there is a pitch change. As far as accuracy is concerned, I think the rate that the elevons counter the speedbrake force is too quick during speed brake stow, and the airplane still pitches. It's supposed to be a smooth transition, and not noticeable to the pilot. If it takes 4 seconds from speed brake stowed to deploy, then the elevators should take the same time travelling to counter. The gains from stow to deploy begin to decrease with more travel, so just maintaining a constant amount of degrees/second between the two systems is likely sufficient. They will be dissimilar because the surfaces are different sizes, meaning the force applied per degree will be the same, but the travel between the two systems will be different, but as long as the force ratio is the same, the effects should cancel, and it still doesn't behave that way. It looks like there's still some work to do, to me at least. That said, I'm glad to see that it was addressed. It seems like a fairly minor issue, but when in A/G mode, the gun pipper can change dramatically if deploying speed brakes in a nose dive, still.

I tried it again last night, and it seemed to be working ok for me, also. It seems to have been a fluke, and I can't duplicate it now either. So, maybe it was a server issue. I don't know. I'll call it good until I see it again. The trk file was over 100mb, and wouldn't upload, so I couldn't attach it here, but I still have it incase I see it again, then I'll have 2.

The one attached up there is one where everything worked.

Good info to have. That is a great idea. That said, perhaps I can find the one from last night and upload it! One thing I like about this sim is how much there is to learn. Ok. I started my own MP server to test this. My normal use for MAV-E works in SP and my own server without fail. All I've ever needed to do is SCS-R 2x for PTRK mode, and the MAV-E will automatically slew to target. Last night's fiasco was just that. The mav was all over the place. Also, just to clarify this as a possibility, I know there's an issue with the pod rotating when the longitudinal axis crosses zero in either direction up or down. Really annoying, but perhaps keep the aircraft in the correct attitude, and that won't happen. Looking for the TRK files from tonight's test and from last night's problematic flight. server-20250228-204610.trk well, this one won't upload, larger than 50 MB. Yikes, that does fill up fast! All these files are huge! Man, now what? Dang.

Will do. I hope it captures it correctly. I will be doing some more testing tonight. Wait: multi-player is where I'm having this issue. Can I capture a track file on a MP server?

Well, that confirms a problem for me. A/G mode, R MFD selected with SCS fir FLIR, scanning for my target, then SCS R 2x, first for ATRK, 2nd for PTRK mode, and 2 vertical bars box in the selected target. SCS L, uncaged MAV, and sensor pans down to the PTRK selected target. Single player works, MP not so much, as above.

I'm going to try a few other things. Today I was using the WPDSG because TDC depress hasn't been working as before either.

The guy is probably just trying to notice a difference, and feels that he's being brushed off. That said, we know you all do a lot of work with these systems and all. I fly the bug exclusively, and I can confirm that it seems no changes have been observed. Perhaps it's my technique, and maybe other variables, or maybe the sheet metal of the hornet is just really thin, and missiles kill it easy. The only frustrating part is usually that it takes a while to set everything up, and getting killed by an AIM-9 seems inappropriate, and frequent. Maybe it is more genuine now, but no less frustrating. I get both sides, and I still want the Development team to know I appreciate your work, even if we don't always see it!