scommander2

Thanks for updating.

okay, thanks.

Ya. I heard about it to integrate (link) all maps together. I can image that we need a big SSD to store data... It is a gigantic development effort and like to see it happened soon.... Thanks for posting it.

Perhaps, we should close this thread since majority people are in another thread, or this issue has a workaround solution now.

"Resistance is futile..." To get F-14 in air is up-to the user decision to do the exception rule for meanwhile or not

Agree. But, there is no way to prevent a DLL file generated has the false-positive virus signature. PS: As a developer, I do not think that I run AV scan files after I compile a binary code, *.so and *.dll because I know that I do not create virus/trojan.

FYI: 2025-03-20 13:15:08.303 WARNING EDCORE (Main): CPU HAS PARKED LOGICAL CORES (this can be source of stuttering and reduced performance especially on hybrid CPUs with P/E-cores)

Added "D:\SteamLibrary\steamapps\common\DCSWorld" in the AV exception for the directory to solve the issue immediately.

I guess that more users on the server will generate the kind of the load to slow down but also affect to the user sides (FPS)?!

I am used to report the filename (false-positive) that gets captured by AV, and its signatures back to the AV vender so that the AV vender will add the filename into a whitelist to avoid for the next AV database up. However, I can only do my AV vendor only.

Cool, good to know... Thanks!!

Similar one?

It is not a preventable, and it is not practice. Put the file into the exception list and move forward since it is a false-positive report.

No offensive: how can the code get compiled with the binary code contains the identical signature in the AV database? If yes, should the code to be written again?

Is the file ""F14-HeatblurCommon.dll" still under ..../F-14/bin folder after the fresh installation?

The repair had performed?

My win 11 does the core parking enabled, so I had disabled it. And, I did not find the warning message of the core parking in your dcs.log. Is it okay so far?

How about the following thread?

What happened if without PL: 2025-03-15 02:26:09.324 WARNING APP (Main): ProcessLasso is running And, manually set process affinity by using Task Manager->Details (looking dcs.exe), right mouse button click for "set affinity" for selecting all P-Cores (0, 1, 6, 9, 7, 8, 18, 19). A good sign is that no CPU core parking is shown in dcs.log

For 265K, P-Cores are not sequential likes 12/13/14th gen by checking the 200s "Compute tile Floorplan". The following is not sure: 2025-03-15 02:26:06.669 INFO EDCORE (Main): common cores: {7, 8, 18, 19} 2025-03-15 02:26:06.669 INFO EDCORE (Main): render cores: {1, 9, 0, 6} 2025-03-15 02:26:06.669 INFO EDCORE (Main): IO cores: {2, 3, 4, 5, 10, 11, 12, 13, 14, 15, 16, 17} according to dcs.log. All P-Cores are used in either common/render cores...

Please check the following thread:

I will say that the file "F14-HeatblurCommon.dll" was compiled with the code contains the identical signature in the antivirus/defender virus/trojan database. Maybe "F14-HeatblurCommon.dll" will be updated/compiled in the future contains no antivirus/defender "possible" signature. I think that it is the exclusive rule about because the antivirus venders can't guarantee the files get catched are 100% virus/trojan for sure, and it is relied on the user to determine the file is false-positive or positive-positive. Not offensive: It is very impossible to re-code/re-compile the file to meet all antivirus requirements, and it is not practice.

Should Windows defender do the same exclusive rule:

Cool, thanks.

- [ADDED]F-14A/B Afteburner Effect Desync {https://forum.dcs.world/topic/356998-bug-f-14ab-afteburner-effect-desync/} added the known issue into the fix section.