Harley

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.

typical video of someone departing Baghdad. It looks like it really pushes the hardware pretty hard with the framerate seen here. Maybe it is just something not optimized yet, and we're all working on something that isn't going to work yet.

Welp, I've tried several things, all with no real improvement, although I saw some differences. Un-installed AMD adrenaline software. For you Nvidia users, likely no surprise that it didn't help. Installed instead, the last pro version, first driver only, and then the whole feature set. With the driver only, I did get further into Baghdad than before, but crashed. Almost certainly a driver issue. Still using the pro version, because the blue accents are a welcome difference, although the driver itself is supposed to be more stable/reliable, it also makes me feel I can trust it more. I think I will try just the standard driver only option next. Un-installed ReShade, just incase the "structured buffer" issue and ReShade created some sort of conflict. Nothing. Low altitude, high altitude, still a CTD over Baghdad. If anyone is having any success navigating through Baghdad, I would love to know their hardware specs. I did see the GPU finally load up past 10GB of used memory, which was pretty neat for me. I've not had a GPU with more than 8GB in many years. This map will use some hefty amounts of VRAM, so expect stutters if your particular GPU has less than 12. Surely this map is going to use plenty of resources. I wonder if it is working for anyone. I've looked some, but still not seen much for videos of Baghdad city being explored in detail, which begs the question: I wonder if many folks are able to yet. There could be missing files/textures/something that the GPU is being called to do and just isn't available or finished yet. I don't know a lot about programming language or what else to conclude at this point. It seems that this region is in need of optimizations or something else that just hasn't been addressed yet, although the errors some of us get are fairly common, historically. Interesting if nothing else. Any input? Ideas?

Ok. There are crash log entries, and this thread seems to be alive with the sound of music. Maybe someone can sift through these and tell me what area I need to look at. It appears that in one of those files, it shows an entry wawnting to reprocess the f-18 texture or something like that? I am not sure that is it, but it appears to be the last thing it tried to do before a stack of the very nearly same error message flooded the file. Can someone make sense of these? It always opens an AMD error reporting window about a driver timeout, and some folks have also showed a work-around to increase the timeout duration, and if someone sees that this is possibly where I should look, I'll try that. I get a little nervous about using regedit, because it's not really intuitive, and I'm not sure if I'll be able to undo some of the things that an impatient person can do there. I wanna drop some bombs, man! dcs.20250201-040316.crash dcs.20250201-040316.dmp dcs.20250201-040316.log dcs.20250201-040316.trk dxdiag.txt hash

I'm going to hunt down the crash log and post it in here to see if someone can decipher this Rosetta Stone. I see so many entries on it that looks like some driver timeout, but not an answer for why. The last thing of any importance is something about reworking the F-18 texture or something of that nature. dcs.20250201-040316.crash dcs.20250201-040316.dmp dcs.20250201-040316.log dcs.20250201-040316.trk dxdiag.txt hash

There already multiple threads about this topic. I'm looking for more information from people that also have this issue.

Having similar CTD, and reviving this old thread to use these tweaks. It's still an issue, or has resurfaced recently.

I think perhaps setting the clock manually within the driver, or if there's a preset, set it to the power saving option. It's going to be a try and test hassle to me at this point, unless someone can decode exactly what some of the error codes mean, but it does look like we're already off to a good start. Nothing like going into debt to upgrade hardware that otherwise seems to work just fine, eh?

I downloaded the latest chipset drivers and all AMD utilities available for my setup. I will test again later. Seems to be a driver issue for sure. It's always the same errors. I don't think it's hardware anymore.

I tried this on the ground to correlate what I was feeling with something I could see. From outside, the speedbrake deploy causes the pitch trim to nose down, perhaps to cancel the nose up that should result from the speedbrake. Then, as soon as I release the speedbrake button, the pitch trim is what changes the pitch, even while the speedbrake is still deployed. I think it's that causing the issue, not the speedbrake. Pitch trim on the elevons increases as soon as I release the button. Maybe this is proper, maybe not. I can't tell now. There's so much going on.

Progress. Someone that can decode this stuff. Thank you!

There are multiple threads about this. Is it solved for you? Maybe they should be merged into one topic...

Well, it's confirmed. Installing a GPU with more VRAM did not stop the CTD issue. This is my post in a different thread over what I saw.

Perhaps with these maps being developed exclusively (a presumption) on NVidia cards, I wonder if there is a driver conflict between AMD users, like me, and Nvidia card users. Ray tracing? Other exclusive driver issues? Because I also have an error reporting log for AMD, as if the driver knows that it also stopped responding. However, if others are having CTD issues on Nvidia equipped machines, then that argument is null. Just a thought.

So, I've installed that new-to-me Radeon VII card. For a while there, it was a smooth 60 FPS, and it seems like part of the reason that there are stutters in the game at all is because of a lack of available VRAM. It was smooth as buttered pancakes for maybe 15 minutes. Then, en route to Baghdad, it crashed while only using 5.500+GB or so of available 15.600+GB VRAM. I read the crash log, and after what looks like a somewhat comon loading sequence, I see this message, and it repeats for pages and pages. A stack of these repeats for a while, then a stack with a different number in the parenthesis, but has the same 'DX device removed reason" code. Can anyone make any sense of this? Crash report sent through DCS error reporting, and perhaps it is a map optimization issue. I copied/pasted from a somewhat arbitrary place, a little before the error stack piles on like the amount of parmesan we want on our spaghetti. It just keeps aflowin. In parenthesis, there is that 4 digit number, and there are others. One is a (2888), there is a (13624). Whatever associations there may be for this, the answer is in there somewhere. It's likely something simple, and is a matter of an update, but I don't know, and that's why I posted that here. 2025-01-29 22:21:42.172 WARNING BACKENDCOMMON (3348): Need to reprocess [DDS] image '/textures/F18C_1_DIFF_STAY_nm.dds'. Reason: Conversion requires - expanded pixel size, setting alpha to known value. Source is an 8:8:8 (24bpp) format 2025-01-29 22:21:45.315 WARNING LOG (11148): 1 duplicate message(s) skipped. 2025-01-29 22:21:45.315 INFO VISUALIZER (Main): Preload() finished 2025-01-29 22:21:45.399 INFO Dispatcher (Main): precache units resources in slots 2025-01-29 22:21:45.611 INFO EDCORE (Main): Created game pool: h:2 n:5 l:2 2025-01-29 22:21:45.611 INFO Dispatcher (Main): loadMission Done: Control passed to the player 2025-01-29 22:21:50.836 INFO WWT (Main): FA-18C_hornet 2025-01-29 22:25:47.723 WARNING WORLD (Main): ModelTimeQuantizer: SAME MODEL TIME 2025-01-29 22:28:18.625 WARNING WORLD (Main): ModelTimeQuantizer: ANTIFREEZE ENABLED 2025-01-29 22:28:20.662 WARNING LOG (11148): 1 duplicate message(s) skipped. 2025-01-29 22:28:20.662 ERROR DX11BACKEND (5876): DX device removed. Reason: 0x887A0006 2025-01-29 22:28:20.664 ERROR DX11BACKEND (5876): Can't map structured buffer. 2025-01-29 22:28:20.664 ERROR DX11BACKEND (5876): Failed assert `0` 2025-01-29 22:28:20.667 ERROR DX11BACKEND (5876): DX device removed. Reason: 0x887A0006 2025-01-29 22:28:20.668 WARNING WORLD (Main): ModelTimeQuantizer: ANTIFREEZE ENABLED 2025-01-29 22:28:20.680 ERROR DX11BACKEND (5876): Can't map structured buffer. 2025-01-29 22:28:20.680 ERROR DX11BACKEND (5876): Failed assert `0`

I will check, but I don't think it's that. If it were, then it should try to cancel the downforce upon deployment. The super hornet does that, but the legacy hornet doesn't, best I understand it.

It's definitely only reacting to the switch position. It's something that would be difficult to video, but I can definitely tell it's not right. As soon as I let go of the switch, the nose slowly returns, as if the speedbrake is retracting, but switching to the external view, the speedbrake can still be extended and it's confirmed by the SPD BRK annunciator. It's not a dealbreaker, it's an accuracy issue I noticed right away, and never really brought it up. It's something you can tell isn't right. For what it's worth, I don't know if everyone is using an associated keybind on the keyboard, or a button on a joystick, but on this winwing taurus, it has a fairly accurate 3-position switch, and the extend is momentary, and it automatically returns to the center "hold" position. If the speedbrake is fully eployed, it can stay deployed, depending on flight condition. It doesn't always auto-stow, excepting maybe if the gear is down, or whatever other condition may cause the auto stow to operate, but it doesn't always auto stow, so it shouldn't always produce the AOA decreasing effect unless the speedbrake stows, not just because I release the switch.

Not sure how to word the title, but I'll explain: When deploying the speedbrake on the F/A-18C, when it starts to deploy, and with full deployment, there is a resulting slight nose-up condition. That is expected, but on a 3 position switch, being stow, hold, and momentary deploy, there is something not correlated properly. The deploy switch is momentary and in some conditions, will hold even at a partial deploy, but as soon as the switch is released, even if the speedbrake is still deployed, the resulting and expected nose-up force input seems to be modeled to decrease, meaning the force should still be there, meaning the nose should still be being forced up until the speedbrake is stowed, not just when the switch is released. It seems that the downforce on the tail causing the nose-up condition seems to be modeled against the switch position, not the actual speedbrake position. It's noticeable in the cockpit. The nose begins to come back down, even with the green SPDBRK annunciator on. Speed should likely have an effect on how much downforce is applied, but the AOA increase should be correlated with speedbrake position, not switch position, and it seems that's how it is now. I hope that reads clearly. Still loving this F/A-18C, though. Flying every night.