Harley

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!

Ok. Difficult to set this up. Carrying the LITENING TGP, WPDSG, scan for targets, find one, SCS R 2x to lock pod, then SCS L, then uncage MAV-E, and sensor can be WAY off where the TGP is looking. Recage, uncaged, still points to same possible WAY off location, not scanning L to R, but locking onto empty area nowhere near where the TGP is aiming. SCS R back to TGP MFD (that's where I select it to display) and the TGP goes off of the locked target, to some unrelated area, and have to scan for the same target again, and usually by that time, you're too close to find it again, and need to make another pass, usually exposing you to enemy fire. The TGP and the RIFLE are not communicating well for me. Is it just me?

I figured it out, and it did involve replacing the GPU. Not because it was faulty, but because the way the Radeon VII measures temps at the junction. It was getting too hot under the demand of some of the newer scenery and throttling, causing the driver timeout. I'm on a 7800XT now, and it's rocking Baghdad amazingly. I even turned up many of the settings that were causing performance issues on my prior card. Thank you for trying! The GPU is still fine, it just can't do SAM, and perhaps some of the other newer things theyre doing now, and I think we're going to be required to enable that and/or resize BAR in BIOS from here on out. This card is definitely a leap in improvement from 7 years ago. I've been testing and tuning some of the settings, and it seems the generational gap is much more apparent than I had initially thought. It has been a while since I've upgraded the GPU, and much has happened since the Radeon vii. The 7000 series really is doing some pretty powerful things as compared to the generation I've been using. I still consider myself pretty fortunate to not have needed to upgrade the Vega 64/vii for some years. Those were great cards. I hope this one does as well. It would be good to have finally found a sweet spot and can settle in for a while.

Welp, It's somewhat bittersweet to report that after installing that new 7800xt, that Iraq now flies remarkably well. A smooth and steady 60FPS, likely more if I turn off the cap. Apparently, it was the junction temp limit throttling the ol radeon vii, causing the driver timeout. I bombed a couple things in Baghdad last night, because why not? Still need to tweak and optimize the driver because surely I can turn some settings up a little, and then I can also likely turn some DCS settings up higher, too. My guess with anybody experiencing CTD in Baghdad: enable SAM in the Adrenalin driver, or whatever the NVidia equivalent is. Mine enabled by default. I can only assume that it will need this enabled as it seems far more detailed than other maps, and the autogen is crazy. Also, apparently GDDR6 and whatever else these newer GPUs have can handle whatever is being asked of them more than the previous generations can. This was the answer that worked for me. I will need to do more optimizing and testing, but it works now. Oh Radeon vii we hardly knew ye.

If the legacy is such a.good seller, it seems that it would be counter productive to offer the superior version, expecting sales to continue for the C model. Unless it were an expansion that required the legacy hornet. *BAM* Make it an expansion to the C model. I'd buy it. I already have the C. I want the extra pylons.

Got lucky on Monday night. I've not run anything that isn't Asus for some time, but I managed to scoop up a fresh sapphire 7800xt on the ol newegg. They are now gone. Will be delivered Friday night. Then the testing will begin. I imagine Baghdad will pose fewer problems then.

Man, the scalpers getting ahold of all the newer generation GPUs should be a dang crime. Can't get ahold of anything short of +50% or more of MSRP, if at all. I'm ready for a new GPU, like a 7900xt, or even a 7800xt, but nothing available anywhere. Frustrating. 4 figures for a GPU is intolerable.

That's what I would figure, honestly. Seems like that wouldn't be difficult to change.

Yes, if I am understanding what you're asking. Any position of the speedbrake, partial or full, I think should result in a countering FCLS retrim, based on the panel position. Full deploy should full retrim, and a portion should retrim proportionally. The switch position is what does it now, where holding the switch in the deploy keeps the flight controls in the retrimmed position. But that switch position is a momentary function, and will spring back to the center "hold" position, and will improperly retrim the elevator function back to the same position as if the speedbrake were stowed upon release of the switch. The airplanes I work on do this with the flaps as well, and retrim the horizontal stabilizer position based on flap position. I know the super hornet does a net zero function when deploying speedbrakes to keep the nose at the same position, and it works really smooth, although that really is a very different bird. But I still think that the retrim function should be encoded against speedbrake panel position, not the switch position. Just to note, it's not a deal breaker, and I love the legacy hornet enough to be building a dedicated sim pit with it, but that part I think is not correct, and changes the nose angle during a strafing run. Hard to compensate for.

I will try this next. I suppose it's just a matter of throttling settings for this particular map if I want to bomb the garbage out of Baghdad.

Ok. Did some work this morning. Set settings to the default "low" preset, and had the AMD adrenaline monitor open under the performance>tuning tab. Started DCS, set at the runway at the airport in Baghdad (don't remember the name) and saw in the temp monitoring that the GPU Hotspot temperature was at 95° while sitting on the runway. Took off and flew around Baghdad for the first time, but it was very bare. But that was after taking the ol radeon vii apart this morning and cleaning/reapplying new compound to the contact areas. That's likely the issue. Throttling while it's running the sim, and timing out as reported by the driver. It's definitely hot, even though the design specs do say that this temp can get to over 105°, but there's surely not much headroom before it hits that, and changing the fan settings definitely rival the sound of the jet when set to the outside view. It's working really hard trying to do something. I will focus my attention there, although it may only end up with me taking out a 2nd mortgage to buy a new GPU. The price point is definitely out of control. So, who's trying to watercool a radeon vii in 2025? This guy.

Looks great! Just for clarification, that wasn't my video. It was one I found that helped me understand that there's something going on. I get very smooth performance everywhere, even in in the areas around Baghdad, but I can Not takeoff from there, nor can I fly over the city. I will throttle settings and see if that affects anything. Maybe I am just pushing the detail too hard over Baghdad.

I don't mind upgrades, it just seems that either 1 or 2 conditions exist: I don't understand the game engine or their more recent developments, or that their more recent developments require something that my components just can't do, or aren't being allowed to do. I am only lacking the South America and KOLA maps. Otherwise, only Baghdad and sometimes Cairo give me problems. It handles all other areas I have without issue. Steady and smooth 60fps all the time. Scenery up at decent levels, also. It just doesn't seem logical, even if it is the case that upgrades are in order. Why only those 2 cities, and only one consistently? The whole rest of the Iraq map seems to play nice, and not draining resources. But, Baghdad reliably crashes as soon as I go wheels up, or fly over it. No drops in fps, nothing. Not the slightest indicator that a problem is coming, just a crash.

Perhaps someone else can chime in if they are seeing the same or very similar issues. I'm not sure if it's because Iraq and Sinai are supposedly still in an "early release" phase of development, and if optimizations will be made, but many videos over Baghdad show heavy demand on resources and low frame rates. It seems there may be some more work done, but no word yet.