Special K

He? I don't think you're understanding the change mate. I told people to NOT open up everything but to create a file which works for their solution. I provided one which opens the minimum for server owners, mission and server, which in fact is very secure and not the issue for the casual user anyway. The problem lies at a different place. But if you know it better, I'm all ears how you would go with the scripts that use net.dostring_in() now.

Just put it in Saved Games, that should do it.

You don't need to fix anything in your scripts. People that use it just need to amend their autoexec.cfg like people need to amend MissionScripting.lua since ages already. As said I have provided one in here, costs you 2 mins to share it.

Would need to see the script to tell. Would wonder why any slot blocker needs that. Mine does not. Look a bit up, I posted a sample that should work for 99% of all cases. Goes into Saves Games\DCS\Config

This is what the closed beta is. If it would not be easily accessible and servers would not show up, who should run that and who should play on it?

I am using exactly that in my bot, which is running on some 550 servers these days. And there is no issue at all in doing it, people just need to add the 2 lines. If your server is either using my bot or running on one of the big hosters like Fox3 or MasterArm, you are good already also. So it will affect self-hosted servers, yes, but again, just add 2 small lines and you are happy.autoexec.cfg There would be the need to do it at 2 places, because you need to either do it in the GUI for clients or in the WebGUI for servers. And yes, that is an option. We do not have this option for anything in MissionScripting.lua also since ever (which does not make it better, but just as a reference). The majority of people will just not need it at all.

No issues with MIST and Moose AFAIK. I don't know the EW script but as long as it's not passing information between Hooks and the mission, then it will not be affected. LotAtc is, DSMC, DATIS and from the looks of it DML. I'm still in contact with the Tacview guys about it, can't tell there yet.

Understood. Yeah, I fear you need to add that autoexec.cfg to the mission downloads now. At least that would be the most convenient way for people. I did my best to tell the support guys what to do if they see these errors also, they have a sample autoexec.cfg in place if a user reports it.

Yes, it puts the burden on those who developed the scripts to tell people how to run them / what to do to run them. I agree that this is not great but it is how it is now. My message was meant to the guy who seemed to be a starter in regards of DCS scripting.

So you mean you're using net.dostring_in in all possible contexts with all possible scopes? I doubt that. Unfortunately, the documentation is a thing. There's not "the" source and what we get from ED is very limited. I am on vacation rn, so I can not write up an essay about it. If you just started scripting it is quite unlikely that you need this specific API. You can use it for instance to call a function from your Hooks environment inside of the running mission. Or you can now read values from your mission from the Hooks. That can be useful for persistency frameworks, statistics etc.

But that's the same argument you could have for MissionScripting.lua. People do not just blatantly open up all gates, just because some mod might need it. It's like always, we need to get used to it. And we will.

I understand your frustration but the reality is different. It's not to add any more security for mission builders or scripters or to make the world of server admins more difficult. It's to add security to the casual DCS user that does not need any of that but that loads a mission from anywhere and runs it. These people need to be protected and that's the obligation of ED which they took responsibility of here.

Not sure how a change that adds security ruins whatever you had done as you don't even have access to where these changes were made. AFAIK you guys use my bot? At least you did in the past. If you do, all you need is make sure you're using the latest version. If you don't know what they do, you probably don't need them. For the guys that are building mods and script stuff it should be very obvious what is what. Any mod that needs to pass information between the different secure zones.

Done. This feature was a long asked question from the community. Mod makers are licking their fingers after it. But it comes with a cost. It opens up options that can be critical for the users of DCS World, so ED had to do something. Sure, there are better ways of doing it. But the enhanced security was indeed needed. It is 2 lines you add to your autoexec.cfg, so I am pretty sure one can survive that. And no, I am not going into detail what potential this call has, for reasons.

No it gets added to the pool on startup but might get parked before polled. So when it's needed it might not be in the state is should be causing the stutter until it's unparked again. See it as a database pool where the connections time out after a while but the pool doesn't know about their state. When you're unlucky enough to grab that connection from the pool, the database takes a bit longer to open that connection again as it would on an already open connection.

That's not 100% correct. DCS creates core pools and schedules the tasks in these pools. With that, DCS decides what will be on which core groups at least.

Only because you see the same result does not necessarily mean you have the same root cause. Can you please provide the following: - a recent dcs.log from a gameplay where you had the issue - a dxdiag.txt which you can create by running a Windows tool named dxdiag and press save everything at the bottom. Not sure if I have asked that yet, but you do not start your DCS as admin by chance? If yes, don't do that please. For rebar, yes your DCS will most likely benefit from it. I am not a big fan of staying behind on BIOS updates, as the changes they made usually are fixes to issues they encountered. If they upped some voltage, they probably did that to stabilize something, most likely memory (e.g. better 4 stick support) or the like.

Ok, so additional things. Your BIOS is very (!) old. Please update it to the latest version. Update your chipset drivers also. Some game crashing because of a fixed pagefile is more or less impossible unless the pagefile is not large enough. You need to see "why" it crashes. Second thing I see in your dxdiag is that you run all these ASUS stuff like Armory Crate and DtsApo. If you do not absolutely (!) need them, get rid of them. They are all known to cause a ton of issues. Your last 10 reported system crashes are all in these ASUS programs and probably much more likely the reason for any crashing besides the pagefile (I see not a single sign of such a crash). As BN mentioned already - and sorry for having read the whole convo only now - you want to update to Windows 11. For your settings, please disable hot plugging (in your control options) and disable SSAO. SSAO is known to eat performance. Delete Saved Games\DCS\fxo and metashader2 and run your test again. If it still stutters, send a file named Saved Games\DCS\Scrips\Export.lua (if you have that).

@iceman06 Without having looked at your log yet (which I will do as soon as possible), you are using MSI Afterburner, which is known to be a performance issue on its own. Can you please reconfirm that the issue is still happening, if AB is uninstalled? EDIT: sorry, just saw that you tested without already- I am at work rn, will report back later. In the meantime, please create a FIXED pagefile on your FASTEST NVMe SSD of at least 32 GB in size and retry.

Your system is hard crashing with bluescreens. The DCS crash is a stack issue, which points to a memory issue. Check if there are BIOS / chipset driver updates available for that mainboard. If yes, update. If no or if the update does not help, reduce your memory speed (e.g. disable XMP).

Core parking usually is a cause of stutters, not of crashes.

DCS can use up to 3 threadpools: - Render Pool => your rendering - Common Pool => everything else but IO tasks (probably file and network operations) - IO Pool => probably file and network operations I am not an ED developer, so these are somewhat guesses. Not sure if I asked that already, but do you run DCS as Administrator by chance? Or use the Nvidia overlay?

The first picture is ok, that is expected. The P-cores are being used for the render pool (the ones with the higher scheduling class if available, ED named that performance class for whatever reason) and for the common pool. The E-cores are used for the IO-pool, if there are any. Otherwise, the IO-pool is empty and IO tasks will be handled by the common-pool also. That is then shown in the 2nd picture, where the IO tasks will be spread also over the P-cores and the E-cores will not be used (that dcs.log would probably have shown an empty IO pool).

This is how it looks like (that's my CPU, but it looks similar).

Taskmanager always shows you logical cores. Your CPU has 8 P-cores (each P-core has 2 logical cores) and 16 E-cores, which only have one core. So you have 8 + 16 = 24 physical cores but 8x2 = 16 + 16 = 32 logical cores (aka threads, which is in all fairness wrong but nevermind) So, when you see the first 8 cores loaded, that means that 4 of your P-cores are fully loaded and nothing else. If you can replicate that somehow, I would really love to look at a DCS log for that case.