Harley

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.

Well, after some homework and testing was done, and even posted the crash log into the help room and the crash log analyzer in the DCS discord server, some direction was made, although ineffective overall. If I fly over Baghdad, especially leaving from the airport in Baghdad, DCS crashes. Sometimes also over Cairo on the Sinai map, but that's not even consistent enough to test for yet. I think that the solution lies with making Baghdad a success, the rest of these issues go away also. So, I manually throttled back on the memory and core overclock that the AMD driver automatically adjusts within the driver, disabled/Un-installed ReShade, ran the slow repair on DCS, deleted unnecessary files with it, and added the tweak to the windows registry that another forum post said may work, and all net no change. So, I flew over Afghanistan, released at a similar time, for testing, and I can fly over Khandahar all day. Difference is all the buildings, developed areas, and perhaps some other properties and differences that I don't know about. The F-18 flew over the air base in a circle until it ran out of fuel and augered in. So, it's not the developer of the map, but maybe some of the populated areas that are using some textures or something else that DX11 handles poorly with this GPU. Interesting bit: the discord help tells me that the critical error causing the crash is DX11 related, that it's constantly removing the GPU. So, I don't know what to make of that. It seems that there is no real consistency as of yet. Users from either GPU camp seem to be having these issues, and apparently, it's popular enough that a quick Google search has many posts about this "dreaded" issue, and there are no answers as of yet. I'll post the part showing what someone pointed out is the critical issue. ``` 2025-02-11 20:39:34.800 ERROR DX11BACKEND (14108): DX device removed. Reason: 0x887A0006 2025-02-11 20:39:34.815 ERROR DX11BACKEND (14108): Can't map structured buffer. 2025-02-11 20:39:34.815 ERROR DX11BACKEND (14108): Failed assert `0` ```

Ok. That confirms for me that I will wait to download and install the newest update. Nobody wants these issues.

I tried that the other day. I'm not familiar enough with the discord interface to figure everything out. Working on that. I was having issues logging in and what not. My password didn't work, and I was frustrated with that. Seems like I found the right area to do that, and something else didn't work right. Thanks again.

Thank you for looking into that. The top gun mod is a loading screen image set, and music. Likely not the cause, but I will remove it for testing. Also, this was happening with a different GPU and a newer one I just installed. They are both similar in age, but it almost seems to be a driver issue. I will remove all AMD drivers and retest. Thank you for your help. It's definitely a challenge to figure out what is happening here.

That is a great way to say that. I concur. I think the way it should work is that the pitch should not try to retrim until the board begins to travel during the stow cycle. The net effect should be as close to zero as possible with this function. It likely would be if the trim were programmed to function against the board position instead of the switch position.