rob10

So you talk and put your company into a worse legal position. That would be a brilliant move. Smart companies/people listen to their lawyers when they tell them to clam it. If they don't it usually turns out badly.

Sound folders are encrypted so you likely can't do a lot with it.

Based on experience here, IMHO you're wrong on that. Setting a fixed pagefile has helped MANY users that were running out of memory. Windows can't adjust it fast enough to keep up in DCS if you're on the margins for memory. The one watchout is how full is your drive that your pagefile is on? You need at least 10-15% free space AFTER you deduct the amount you're setting pagefile to or you're going to run into issues with it anyway (and Windows won't use it if you leave it to the system).

Are you going into the MUMI page and pressing the COMM and in a couple of seconds after it's loaded it will box? It's been working (other than setting everything to FM as reported in a different post) for me, but I missed the MUMI step at 1st.

Bump your pagefile. This is one part of the crash error: 2025-04-20 18:47:10.112 INFO EDCORE (12968): 0x0000000000025b2b (edCore): ed::fatal_out_of_memory + 0x3B Germany is very likely going to need more memory and you have your PRELOAD set to 150,000 so it's gobbling up massive amounts of RAM/Pagefile, so drop that to 40,000 or something more reasonable as well. DCS is a different kind of load than other games, so saying other games work fine doesn't mean it's not a hardware issue. DCS may stress a part that isn't used much in a different game. And different maps are going to behave differently due to the fact they are coded differently. And may have more detail that pushes your system as you're seeing here.

As long as you're using a POWERED hub it shouldn't be a problem. Check that your hub is working properly and getting power (i.e. power supply didn't get pulled out a bit so it's not getting full power or something).

Something that could cause that is if you're dropping the points too close together. Zoom out a bit and it should be farther apart and that may solve your problem. Mods are always a good culprit to check too since they can cause weird and unexpected issues at times.

It isn't really obvious, but if you click on the FILE button in the top left it will allow you to IMPORT a DTC if you've made one and exported it already.

@NineLine Here is a track and the associated DTC. 1 x F-18C runway start in Caucasus. Imported the DTC on the "fly" page, then loaded it via the MUMI page. Frequency #'s are correct but they all default to FM. Only Comm 2 presets 10-12 should have been FM (only available modulation for those frequencies). Double checked that Easy Comms is off on my computer and in the mission file. Also, and at least as big of problem, it won't let you change it from FM to AM in the UFC. Haven't checked which it's actually using in game yet (AM or FM). (Sorry Bignewy, meant to ping Nineline, not you 1st time ) F18 DTC forced FM only.trk FA-18C JTF-111 BASE.dtc

A short trackfile of the problem will be much more helpful to figuring out the problem than that picture. It's likely something simple, but without the trackfile it's purely guesses.

If you're seeing flares on landing you need to update. That was removed shortly after it got added.

RB may not hold a "copyright" on the F-15E, but I would be completely shocked if there is not an exclusively clause in their agreements with ED that means no one else can develop a DCS F-15E. In fact, ED moved to announcing "forthcoming" modules sooner because there had been a few cases where 2 different teams were independently working on the early stages of module without realizing the other existed and only one was able to move forward with a module for DCS so the other teams work became worthless and wasted.

In the Hornet, as long as the mission builder places a bullseye in the mission, WP59 will default to it (even if it's also at say WP 4). So it's generally safe to assume that WP59 is always (not quite true but close enough) your bullseye.

Not sure what your actual issue is . Yes, it changes it to 4096 x 1440 because it now includes wherever the MFD's are displayed. They are displayed as part of the "main" screen and then exported onto the external MFD's, so it's completely normal for it to be 4096x1440 and shouldn't cause you any issues in game. Are your MFD's actually working if you change it back? As a sidenote, if it's going to 4096 you likely have the 3 MFD's side by side in your windows setting. You can stack them in whatever configuration results in the smallest total area displayed. At 4096 x 1440 you're pushing 5,898,240 pixels. This likely includes a bunch of black space which is still has to draw. If you can get it to for example 3340 x 1440 you're only drawing 4,809,600 pixels so less load on your computer.

If you include a track file of this happening you're much more likely to get a meaningful response. Without it there are so many possible variables that it's nearly impossible to recreate it exactly. My other question would be what MODS of ANY type to you have installed? They can cause issues with things that seem completely unrelated.

It was legit to bring it up. We don't have good details on the fuses to suggest whether it's correct the way it is or whether the option to select DLY1 is bugged. I might not have noticed except that I never even thought to change it to DLY1 when I dropped it Saturday, so I noticed you did (was watching to make sure you had armed the fuses and that wasn't the issue).

Well there's your problem: you used the AF variant and it didn't like being dropped off a Navy plane . I did use the USN variant but they should in theory be identical. Yes, that was the C+C bunker I dropped on (good to check). So in quick testing it's related to the fact that you set the fusing in the stores page to DLY1. If you set it as INST (with the 0.06 sec set in the re-arm menu or mission editor) it will take them down with a single GBU-31 (naval or AF). I suspect this is it looking for something functionally when you have DLY1 set that doesn't work with that particular fuse (I assume you were using the default FMU-139?) when you have it to DLY1 and isn't triggering at the appropriate timing. I don't have in depth enough knowledge to speak intelligently any deeper than that on it though.

If you a track you might get some useful answers. Trying to diagnose from pictures is very difficult to do reliably.

As the OP discovered, if you run into this specific error check the time on your computer is correct.

100% agree with what MAXsenna said. That's a LOT of IC errors which suggest that the mod was installed into core rather than saved games. It also was showing IC error on Aim-120.lua and Aim-9X.lua near the top of the log so a slow repair to clean it all out and reset things back to base is your 1st step.

Used a single GBU-31 on a command and control bunker on Saturday from the F-18 and took it out no problem. Are you changing the fuzing delay on it in the Hornet? I set it to the maximum (can't remember what it is). Not sure if the F-15 has options for that yet so that may be the difference. And yes, a track file is pretty much a need to do to get a real answer.

It works differently to other datalink stuff. You can't change the frequencies for it and you don't need to have anything in your plane tuned to a specific frequency to use it.

In that case you haven't followed this whole issue in very many places or with much detail. It's been discussed in a number of places including with alleged scans of the legal docs from ED to Razbam. If you do some digging you'll find it. The source code thing was initial speculation when this first happened but it moved on from there.

It's not. ED has alleged that Razbam used ED's intellectual property (IP) on an unrelated project without their permission.

Since ED have said due to contract that they couldn't remove it from sale barring an OFFICIAL request from Razbam or whatever other conditions in the contract might allow them to (meaning if they did remove it on their own they'd be liable for damages for breaking the contract) and now that Razbam has OFFICIALLY requested it's removal (and ED would be liable for damages for NOT removing it) it's pretty easy to understand why ED would agree to it. As for the Razbam side, that's a guess because there doesn't seem to be lot of rationality to most of their actions in this affair.