Wawar

I removed the tacview folder/files in Savedgames/DCS/Mod/Tech and DCS/Scripts. To confirm that Tacview is uninstalled from DCS, just check if you still have the « Tacview special options » in the DCS settings menu. Sent from my iPhone using Tapatalk

After a few days of testing, I can say that my issue is sovled. It was Tacview. So, my DCS install was not totally "mod free" after all. Without Tacview, the initial loading is 2 or 3 times quicker, and no more random crashes.

I have set the pagefile to 64gb. Same issue, fresh log related to a crash, attached dcs.log

Thanks a lot for the analysis and the suggestions. - SFC/DISM : Already done system files were repaired, no change to the issue - BIOS fully up to date - Core Isolation, double-checked, it’s disabled - Windows memory diagnostic, I ran a test, no errors reported - XMP Enabled, but I’ve had zero instability issues in any other demanding workloads (including memory-bound tasks or games). Not ruling it out, but I'd be surprised if it were the issue. About the pagefile discrepancy: I’ll share a screenshot as requested, but my system is configured with a manually set 8GB pagefile — I assumed it was enough given I have 64GB of RAM. Happy to try a higher or system-managed value if needed. I'll share another screenshot from the windows event viewer, with an error that happens at the moment of the PC Freeze : "Error setting traits on Provider {8444a4fb-d8d3-4f38-84f8-89960a1ef12f}. Error: 0xC0000001"

Hello, I'm experiencing serious issues with DCS that are becoming increasingly frustrating and disruptive. I’m hoping someone from the community or the ED team can help me diagnose or solve this. Symptoms: - Sometimes, when I launch DCS, the loading bar freezes mid-way. DCS becomes unresponsive and never finishes loading. - Shortly after, my entire system starts progressively freezing: Task Manager, File Explorer, Discord, and other apps stop responding one by one. I have to end task DCS.exe to get back the computer. Occasionally, the system completely freezes, forcing me to do a hard reboot. Other times, the freeze happens when trying to join a multiplayer server. DCS gets stuck during the server loading phase and the same cascade of freezing occurs. When DCS hangs, the whole system's responsiveness degrades, not just the game. And when it happens, there is no apparent heavy load on the CPU, SSD or the RAM. The ram is not saturated. I have this problem only with DCS, no issues with other games or softwares. In actual gameplay, DCS runs smoothly once loaded. Here is my specs : - Ultra 7 265K - 64GB DDR5 - RTX 5080 - 2TB NVMe (WD Black PCIe Gen 4, 7000 MB/s read speed). DCS is installed here - Windows 11 fully updated - The DCS install is 1 month old Troubleshooting done so far: - Core Parking disabled - Core Isolation disabled - WIndows Gamemode disabled - DCS clean of any mods - DCS slow repair - Set a fixed pagefile, no pagefile swapping so far - Checked disk health (no issues), updated firmware, and verified full PCIe Gen4 x4 bandwidth - Ran CrystalDiskMark, nominal read/write speeds - Performed full DISM and sfc /scannow repairs - Disabled Windows Defender and Smartscreen entirely to rule out interference. - No signs of thermal issues: both NVMe drives run cool (40–50°C), CPU and GPU temperatures OK. I'm running out of ideas... Logs and DXdiag attached. Thanks in advance. DxDiag.txt dcs.log

Thanks for your answer. So, if the said « standard » can varies between aircraft, it doesn’t really exist. The problem is that people here are used to a certain standard of fidelity, and they consider that if this standard can't be reached with a certain aircraft... They'd rather not see resources allocated to the development of said aircraft, in favor of another aircraft that could reach the desired community standard. Anyway, yeah sure, we’ll always have the wallet vote. But seeing DCS losing it’s edge is not what we wanted.

Hello Nineline. The question is not whether the aircraft meets the DCS standard or not. The question is whether the DCS standard has been lowered to make it possible to create this module. Because that's what the people complaining here don't want: to see the modeling standard lowered. And since the fidelity level between ED modules and third-party modules is already disparate, the -35 announcement is everything but reassuring.

Considering the complexity (A/C moving in 3D, the gimballed gun, the recoil, etc) and the fact that these variables change every fraction of a second, I find that the gun does rather well in terms of grouping, and that on the contrary, the CEP is relatively low. However, the “point of impact” seems to be on the side. The rounds are well grouped, uniformly, but next to the target, not on it. (Clearly visible in the clip I recorded and posted above) Which made me wonder if it was correctly working. (The TSE seems to be compensating correctly, but not in the right spot) So I've got the answer to my question : TSE limitation. Thanks for the details and the quick reply. EDIT : Last question about the gun : In case of FCR gun targeting, is the TSE supposed to work?

Ok, thought that LMC was a criteria for TSE activation, thanks. So, constant lasing + target correctly stabilized in the scope = TSE is working and good accuracy? George is NOT using LMC, he is using the Autotracker + lasing while shooting. The target LOS is perfectly stable AND and the A/C perfectly stable. This should make the LMC work and put the rounds correctly to the target, without wind, since the TSE should compensate for the A/C movement. Does it seems normal to you, with the conditions described in my previous post, with a perfectly stable LOS and continuous lase (So, TSE in action), that : - target on the LEFT of the A/C : group of impact on the RIGHT of the target - target in the RIGHT of the A/C : group of impact on the LEFT of the target According to Bradmick, it's normal to "compensate" sometime, but I don't understand if we are supposed to compensate for the lack of performance of the TSE itself, or If we should adjust for the external factors like wind, etc. Currently with a perfectly stable A/C, in a sterile environment like DCS can provide (no wind, etc.), the rounds are well grouped, but OFF the target. It is supposed to be?

TADS yes. After verification with Bradmick on Discord it seems to be normal. The system is not « perfect », sometime the gunner has to make correction, even if the targeting is good. Another interesting point : apparently, George AI don’t use the LMC/TSE, so when George is operating the gun, there is not account of A/C movement. Which could explain why it is grouped, but off. Example of George AI grouping : https://streamable.com/okq8ql Sent from my iPhone using Tapatalk

Same issue. @Grennymaster : Like Dog explained, I don’t see a « dispersion » or a CEP issue, it’s just that the group of impacts is OFF target, to the right or the left. If I understand correctly, the TSE should compensate for the A/C movement, within margins. Another test : No wind, A/C height 1000ft AGL, target range 1000-1500m, 40KIAS; lasing a few seconds before the shoot to let the TSE make the calculation and lasing while shooting : - target on the LEFT of the A/C : group of impact on the RIGHT of the target - target in the RIGHT of the A/C : group of impact on the LEFT of the target The impacts are well grouped, good CEP. But the point of impact is OFF the target, left or right relative to the relative bearing of the target.

Hi, Airstart jet, GBU10 loaded on the left CFT. At spawn, the LCFT seems not set up correctly in the pacs. Once the bombs have been manually set in the pacs, ASL for that specific station is bugged. Seems stuck in a corner of the hud, and the state "TREL" never appears. If I switch station, the ASL comes back on target and "TREL" appears on the hud. Track attached. GBU10 LCFT : GBU12 RCFT : ASL LCFT.trk

Thank you for the Klarification. Let’s hope Razbam is working on it, the current behavior makes the ASL not usable under certain wind conditions.

Any news about that ? Thanks. :-) Envoyé de mon iPhone en utilisant Tapatalk

Ok ! Thanks.

In this case of radar designation with AUTO release, shouldn't the radar switch to AGR mode during the last 15 seconds before the release? Like explained in the Baltic Dragon official manual, page 401 :

Hi, airstart jet, designation right on target. Without wind, the ASL is perfectly aligned on the target diamond. But with wind, the ASL is pointing towards the wind. The issue here is the ASL behaviour. The closer I am to the target, the more the ASL moves towards it. It is not "space stabilized". So, If I follow the ASL to the target, the plane will approach in a "curve" profile. Shouldn't the ASL be "fixed" in space, in this case to the right of the target, directly with the correct spacing? Track attached. ASL Drift With Wind.trk

Thank you for your answer. So you confirm that the AG Radar is not linked to any elevation database?

Hi, Airstart jet, patch map designation right on target. Target diamond on the HUD appears to be at the wrong elevation, under the ground. Track attached. null Radar Designate issue.trk

Yes, please. So important for cockpit users. Thanks ! Envoyé de mon iPhone en utilisant Tapatalk

Let's hope it's in priority in the roadmap. Can't wait to use my Strike with the exports.

Hi team, In the recent videos, the DLZ's Rmnvr cues do not seem to follow the same logic as the docs. To my understanding, the Rmnvr should indicate max range against a target executing a 4g turn towards a designed aspect angle. If the current target aspect is less than the designed aspect angle, Rmnvr equals to Rpi. So, in term of kinetic energy, from the farthest to the closest ; Raero, Ropt, Rpi, Rmnvr, Rtr. But in the vids, Rmnvr cue appears before RPI, timeline wise. Thanks.null null

So much. People should be happy to have had a TGP for the past 3 years. Indeed it's a pity to lose the "HD TGP" ability until Sniper, but it's only a matter of time. Capabilities are what they are, pilots must adapt to their systems, not the opposite.

Same issue. Picture and track attached. MT Ghost.trk

@JCTherik : More speed or more AOA, wich results in more depression on the upper wing surface. (Lift formula : coefficient of lift(aoa) x speed² x wing surface x 1/2p) So, due to DLC, for a straight and level flight with a defined speed : to counter the lost of wing surface , AOA must increase. Wich results in the same amount of lift generated by the wings. If you reduce the wing area and don't act on the AOA or the airspeed to counter it, your wing will just generate less lift. So, less wingload, so less wing flex. But, let's say you are in a descent at constant TAS, level flight is no more a factor. So, the AOA increase is no more required. Try this : Descent, constant TAS, DLC activated (so DLC in middle position) : if you extend the DLC more, the wings flex more. But, more the DLC is out, the less depression on the upper wing surface, aka less lift, aka less wing load. I presume that the wings should flex less. Maybe there is a story with the location where the lift is generated on the wing, idk. But something seems off to me. If a dev could clarify this, It would be cool.