Special K
-
Posts
801 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by Special K
-
-
vor 8 Stunden schrieb scommander2:
Hi @Special K, what is "exclusiveMainRenderCore" for? Thanks.
I don't know where that chap got that from. I would not recommend tampering with mt.lua.
It is an internal file, which is subject to change and not meant to be set by users unless advised differently by support. I can not even tell if it is a thing at all anymore.vor 14 Stunden schrieb Papamiraculi:I sometimes get 100% on a single core too. Not Always, and I haven't found a reason why it's not always the case. I suspect DCS just puts too much stuff on the main thread. Running 9800x3d.
But I will definitely try this. Thanks for bringing this up.
An observation when looking at your screens: it looks like both are actually maxing out a core. Core 9 seems rather maxed out here in this screenshot with your mod engaged, very similar to your second screenshot, which maxes out core 0 with the mod disengaged.
Are you sure it doesn't just move the main thread from core 0 to another core? This is what happens if I deactivate the maxed out core while DCS is running. The main thread will just move to a different core and max out that one.
Windows seems to agressively enter eco mode on AMD for whatever reason.
You can try and launch your DCS.exe with --disable-features=UseEcoQoSForBackgroundProcess and see if that fixes it. -
vor 18 Stunden schrieb Tippis:
Your solution is unsafe and does the exact opposite of what this change is meant to accomplish.
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.
-
vor 6 Stunden schrieb AvgeekJoe:
I've got a few fixes going like making the 2nd Growler a jammer also.
But mainly putting the attachment @Special K made into \Saved Games\DCS.openbeta\Config AND Program Files\Eagle Dynamics\DCS World OpenBeta\Config makes it go again.
Should work with any MIST-based script, IMHO. Your utility may vary.
Just put it in Saved Games, that should do it.
-
1
-
-
vor 28 Minuten schrieb MARLAN_:
My Dynamic Weather script for DCS is now broken and I don't have the time to fix it in an instant with zero warning, so support for that tool is going to be dropped too. Oh well.
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.
-
vor 2 Stunden schrieb PeeJott17:
@Special K Do you happen to know what needs to go into the autoexec.cfg to get the slot-blocker-script to run normally? The cfg-lines you provided fixed the progression-save-script but not the slot-blocker. I know, I'm disturbing your holiday, but if you happen to find the time between sunbathing and lunch, may-be you could just punch-in a few characters via your phone
Cheers,
PeeJott.
Would need to see the script to tell.
Would wonder why any slot blocker needs that. Mine does not.
vor 1 Minute schrieb Spartan111sqn:where shall be located the autoexec file?, is as simple as put that file in a folder of the server and that's it?, for example in foothold or pretense do we have an issue?, at the moment I tested it and they run normally
Look a bit up, I posted a sample that should work for 99% of all cases.
Goes into Saves Games\DCS\Config
-
1
-
-
vor 3 Stunden schrieb Dangerzone:
I've previously suggested what I believe is a better solution: a true Open Beta—(implemented differently to before). Make it accessible only via command line, so only those with the tech knowledge of how to execute command lines, and also know the OB version number can install it. That way, it’s not used on production servers, and Open Beta versions don’t appear in the public server list—IP connect only. This would make it a genuine testing platform, not a general gameplay environment, and give us the time we need to adapt and see the upcoming changes and try them out. Sure - there will be some that push and opt to use it as a stable release, but it would be the minority. The previous OB didn't work because the majority used it as a stable release (and even ED recommended people use it for production in MP).
I really feel we need a proper Open Beta for everyone’s sake. Far too many issues are being discovered in these new so called stable releases within hours, forcing hotfixes. That’s bad for both ED developers, who get blindsided and must scramble to patch, and for us, who have to react to breaking changes without warning. Let alone the image that it's putting out there of ED's quality. Let an Open Beta run for a couple of weeks—(1) to give content creators time to adapt, and (2) to apply necessary hotfixes—before pushing a public stable.
Just a pity that ED seems to disagree that there's issues for the community by working this way and believe everything is fine as is. Nothing needs changing, with "no plans to consider...". While all along I see what I feared when open beta disappeared. That the new and improved stable release would eventually degenerate to being what Open Beta was all along - with no real practical alternatives for public server content creators (that aren't in the CB team anyway) to be proactive, and just have to be reactive and rush about to deal with bugs, problems, or breaking changes at the last minute.
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?
-
vor 3 Stunden schrieb Buta:
Thank you very much for using your precious vacation time to answer questions!
Last week, I tried and found that net.dostring_in('mission',... ) can be used to call functions that are not available in Mission scripting in the mission environment, such as trigger functions in ME (those 'a_*' series of functions).
For example, if I want to "dynamically" show pictures to several player units, I can use the following method:-- assume I have defined 'imgPath', 'unitID' local cmdString = string.format('a_out_picture_u(%d, "%s", %d, %s, %d, "%d", "%d", %d, "%d")',unitID, imgPath,1,'false',0,1,1,30,0) net.dostring_in('mission',cmdString)
If used in this way, there will indeed be a large number of net.dostring_in() in the script. So sad that this has been changed just after I found them out XD.
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
vor 35 Minuten schrieb eekz:By the way, why wouldnt you just add a checkbox in DCS menu that would do the same thing as autoexec?
The problem is that it seems nobody accounting the fact that majority of users won't bother going to cfg files and editing them.
Want an automatic spawn? go donwload and install the script, want a mission to work? - edit .cfg.. etc.
Users are not coders, and have better things to do thant editing files in order to try something new.
Give some love to UX please, that's what DCS needs for years. Despite being probably on of the best products outhere in terms of APIs, scripting, it severely lacks in UX/UIThere 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.
-
1
-
-
vor einer Stunde schrieb AvgeekJoe:
Simple questions as an end user:
1) Is this going to mess up MIST or MOOSE?
2) Is this going to mess up the EW script?
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.
-
2
-
-
Gerade eben schrieb cfrag:
My apologies for being obscure. I use doString_in all missions (it's a framework I use, DML, and its 'common' bedrock that provides all services uses dostring_in(), it uses at least one context. The number of contexts used is immaterial. A user who does not know the origins of the error, and who did not open their DCS install, will suddenly receive an error. Because by default, invoking doString_in, no matter which context, produces a nil error.
Someone who until yesterday could happily play all these missions and who did not set up an autoconfig file will today have the mission stop with an error.
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.
Gerade eben schrieb Special K: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.
-
1
-
-
vor 55 Minuten schrieb cfrag:
That is an incredibly dangerous assumption. Run the below mission on a secured DCS install. It will throw an error. Any of the missions I have put up on User Files (and that enjoy moderate popularity) in the past 12 months will immediately stop at mission start, throwing that error. Perhaps try this one:
Error on start.
"Joe User" who downloads such a mission will not know what to do, and they now need to know what to do to run a simple mission. This is bad.
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.
-
vor 2 Stunden schrieb cfrag:
It seems a likely outcome. I put up some 50 missions on ED's user files, and they (guesstimate) clock in at some 30'000 downloads. Half of them will no longer work today unless the entire DCS install is unlocked.
So you mean you're using net.dostring_in in all possible contexts with all possible scopes? I doubt that.
vor einer Stunde schrieb Buta:If a beginner wants to get started with DCS mission scripting, how should they learn it?
I've used the APIs mentioned at https://www.digitalcombatsimulator.com/en/support/faq/scripting_engine/ and created several missions like dynamic helicopter logistics and custom dynamic campaigns for MP servers. I don't have any other "teachers" currently.
Now I want to learn about "net", especially the "net.dostring_in()", but I find it very difficult to find relevant documents. I’ve checked Hoggit’s documentation (which has been incredibly helpful!), but noticed the "net" section hasn’t been updated in some time.
Guessing or testing trial-and-error has slowed my progress, and I’d really value concrete guidance. Thanks for your help.
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.
-
1
-
-
vor 1 Minute schrieb Veltro3:
Personally I have only worked on server-side mods and I have little experience in mission scripting. I think the changes ED have introduced can be very interesting for server-side mods, intended for more advanced users. However, now knowing that missions also leverage dostring_in and have now been blocked, I do agree with @cfrag's point that soon someone will just make a post somewhere saying to simply copy these lines in autoexec.cfg and enable absolutely everything. I think the idea behind the change is good and needed but the approach may require some tuning.
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.
-
1
-
-
vor 18 Minuten schrieb cfrag:
No discussion here. DCS needs good, scalable and easy to maintain security. In the past, I have recommended a couple of approaches in these forums how, for example, DCS could easily sandbox (better: sidestep) the lfs 'sanitize' issue by allowing a controlled, sandboxed 'writeString()' method that saves a string to a mission without having to 'de-sanitize' DCS (and compromise security). It was never followed up on. Pity. Instead we got the 'save mission' system that simply doesn't work, solves no problem at all, lfs still needs to be de-sanitized using a really, really bad 'unlock this for everyone' approach, just like this approach for dostring_in(). And to truly underscore how bad things are, the two approaches to resolving related issues (security) aren't harmonized. To me this is indicative of deeper troubling issues at ED than merely a bad IT security design team.
The problem is that this new 'enhanced security' is, as implemented now, utter garbage; an inept, heavy-handed approach that will lead to LESS security. Why? Because soon (if they haven't already) videos and article will appear that tell you how to 'fix DCS' when all these "attempt to call field dostring_in" errors pop up in-mission. Invariably they will tell you to 'simply place this autoexec.cfg here, and you are done'. Because of the hare-brained one-size-fits-all approach, now the entirety of DCS is open, for every mission (not to mention providing a new attack vector through a malicious autoexec.cfg that is provided by the attacker in the video). Anyone with merely passing working experience in security can tell you: this approach is bad, much worse than not doing anything.
So my opinion: this 'security' design is utterly inept, and it results in REDUCING security because everyone will bypass this 'security' for their comfort. Its like putting a fantastically complicated lock on your front door. Because it inconveniences everyone, they just keep it unlocked, opening the door for anyone. Is that improved security?
A better design would allow per-mission sandboxing. There a billions of possible approaches: put the mission in a folder /insecure, and if it is in there, use the settings screen in DCS to regulate what is allowed (and yeah, lfs and io should be in there too). Better yet: have a GUI for that allows players to drag missions/directories into. Any mission in there is allowed risky stuff (configured by the GUI). Simple, and it does not take a lot of talent to implement. I'm not saying that above is good security design. Far from it. I'm merely saying that it's better by orders of magnitude than the current, inept design. What deeply troubles me is the fact that something this badly designed has made it past the design stage. What angers me is that it made made it into production. ED - you have a serious quality issue. Cheap, badly thought out code like this should never make it to the customer.
This is really, really bad, ED. Please fix it. And please, if you don't have the talent, I'm sure there is ample talent in the community to help you out. Just ask.
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.
-
1
-
-
vor 3 Stunden schrieb 392198523:
Yep, that's a 2 lines change which totally ruins our newly introduced enhanced security.
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.
vor 5 Stunden schrieb MarcosR:Can someone confirm is working? I can't make it work in rotorheads..
Can execute, but cant receive any data.
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.
vor 2 Stunden schrieb Buta:How can I know what those "server", "mission", "scripting", "gui", "export", "config", "zone" mean and what they can do? I hope the answer won't be "guessing", "trying" and "testing". Is there a doc to explain this api?
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.
vor 47 Minuten schrieb Mr.Jazzy:If mod makers are licking fingers after this feature, what kind of mods are we talking about?
Any mod that needs to pass information between the different secure zones.
-
1
-
-
vor 2 Stunden schrieb Asphelite:
Hello
Can confirm whilst fixing HBCW, "server" is indeed a valid field and does need to be allowed in the dostring_in table in the autoexec.cfg
If possible, Id like to see the example list (posted by BN) to be updated
Cheers!
Done.
vor 4 Stunden schrieb Karlos:This is crazy. My server and almost all the servers I've visited use SSB and DML. So, the work of people who dedicate secure and free scripting to the ED community is not good? Are we crazy? I'll shut down my servers. For ED, are we just numbers? Probably.
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.
-
2
-
-
Am 18.7.2025 um 08:32 schrieb scommander2:
Thank @Special K.
If one parked core becomes the unparked state later while DCS has ran a while, it is too late for DCS to put this core into the core pool so DCS won't schedule a task on it. Is it correct?
Thanks.
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.
-
1
-
-
Am 4.7.2025 um 14:58 schrieb sleighzy:
No reason not to (not sure if you can individually state which should be parked and which shouldn’t). DCS doesn’t “require” it per se. However, DCS doesn’t ask an individual core to do work. It requests the OS (CPU) to do work and the OS will schedule that task onto a core, which may be currently parked in which case it needs to “wake up”.
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.
-
1
-
-
Am 28.6.2025 um 05:47 schrieb Astralox65:
I must say that I made my DCS forum profile just to coment here about this issue and I have the same exact problem with F16 as you have for god knows how long. And I dont know how ED can’t reproduce it.
It happens to me while I play on my flat scren monitor on 75fps cap, or 140 cap it doesnt matter. Doesn’t matter the settings I put or whatever in game it is always the same stutter result when I roll the plane and it is always while rolling aggressively or suddenly. It doesn’t happen while flying straight.
I am glad that I found this topic here and as soon as I turned off radar altimeter the heavy stutter that annoyed me for a long time was gone instantly.
I thought my pc was the problem but even though I upgraded to ryzen 7 5700X3D and 64gb ram with my rtx 3080ti. It still was happening. And at that point I became suspicious that maybe it wasn’t my rig after all.
No other module of mine has a stutter of any sort except my F16 which is also my most flown module. To the point I thought it was the most hardware intensive module since my Phantom flies perfectly and smoothly both on flat screen and VR.
I must thank Iceman06 for figuring out it was radar altimeter. So now I strictly fly F16 with radar alt turned off and I have no issues whatsoever VR or flat screen. Finaly I can roll the F16 without a very nasty stutter at least!
I really don’t know what the problem could be at this point but hopefully it can be solved. I am just surprised not many people share the same experience and even more suprised that ED cannot reproduce it?
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.Am 26.6.2025 um 19:20 schrieb iceman06:@Special K Thank you for posting your help here, I will answer you step by step.
-First point ; Msi AB, I only use it when I want to analyze certain data, I haven't uninstalled it but it is programmed to activate only when I ask it rather than at session startup by default. Can uninstalling it make a difference when it is not active in my tasks?
-Second point; the pagefiles. Indeed, having tested a few manipulations recently, this one was by default when the last Dcs.log was sent, you will be able to see that I have now set it to 32GB, unfortunately I don't see any difference.-Third point; Regarding the BIOS update. After trying a few updates a few years ago, I decided to go back to the original 0707 version since the later versions exerted abnormally high voltages and caused temperatures that I found unnecessarily high without any benefit. The only problem is that this version restricts me since it doesn't allow me to use ReziseBar, which is why I wanted to try version 1003, which is also old but one of the most stable according to Asus users. Do you think the Rezisebar is an advantage in DCS? No one has really been able to tell me if the game supports it.-Fourth point: The armory crates and DtsApo programs. Armourycrate is a real pain in the neck. Unfortunately is useful for my Rog Spatha mouse profile and all my LED lighting, which is the only reason it's there, DTS has been disabled. I've determined the circumstances of these application crashes, and they only occur when closing sessions when I turn off my computer. No problem,so I even disabled them at startup for a test, and it makes no difference to my Viper problem in DCS.
-Concerning Windows 11, a touchy subject but on which I know that I will have no choice but to end up giving in, I also know that the clean and complete reinstallation of my PC will take time, which is why I want to do this calmly when time allows me.-Final points;
Hotplug is already disabled, SSAO or any other settings make no difference to my problem, I've tried everything possible on that side I think.
Fxo / Metashaders 2 cleaned several times with nvidia shaderds cache and direct x as well
DCS repair/uninstallation/reinstallation performed with no effect either. I don't have this file in saved game Scrips\Export.luaThis problem is quite frustrating and occurs when my alt radar is activated only unfortunately I do not understand how this is possible but it is nevertheless linked to my problem on my PC.. unfortunately you have to see it to believe it, What is even more frustrating is to see that no one can reproduce this on their configuration, making my problem even less solvable.
I'm attaching another DCS.log as well as a DXdiag again.. ignore the DTS crashes they are not problems at all.dcs.log 79.09 kB · 2 Downloads DxDiag.txt 100.11 kB · 1 Download
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.
-
1
-
-
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.
-
Am 12.6.2025 um 01:25 schrieb SharpeXB:
Well spoke too soon. The mouse polling problem is gone now. But DCS quit to the desktop.
Events250611-1.evtx 68 kB · 3 Downloads dcs.log 226.91 kB · 5 Downloads DxDiag.txt 114.23 kB · 5 Downloads
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). -
Am 12.6.2025 um 15:37 schrieb SharpeXB:
PS is core parking related to performance or stability? Even with core parking enabled (looks like it is) the game runs smoothly with no stutters or anything at 80-120FPS.
Were parked cores the cause of the crash?Core parking usually is a cause of stutters, not of crashes.
-
vor 5 Minuten schrieb Schlomo1933:
@scommander2 yes this was in flight.
@Special K what u mean with io-pool . Do you mean Input Devices ?
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 operationsI am not an ED developer, so these are somewhat guesses.
vor 6 Minuten schrieb Schlomo1933:but why just one core for the graphic ?
And why so high ?
Not sure if I asked that already, but do you run DCS as Administrator by chance? Or use the Nvidia overlay?
-
1
-
-
vor 3 Minuten schrieb scommander2:
Hi @Special K, according to @Schlomo1933 CPU usage:
with his dcs.log:
common cores: {8, 9, 10, 11, 12, 13, 14, 15} render cores: {0, 1, 2, 3, 4, 5, 6, 7} IO cores: {16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31} unavailable cores: {}It seems that his system uses E-Cores in the most time rather than P-Cores (hope the CPU usage was taken when he was in the flight).
However, he set affinity by Task Manager fordcs.exe with all P-Cores 0-15 (with hyper-threading which matched to dcs.log common/render cores), then:
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).
-
1
-
One or more cores reaching 100%
in Game Performance Bugs
Posted
It is an internal file that you do not have in your installation but that goes into Saved Games. At least that was the case.
When MT was new, one could fine-tune stuff in there, but that was for the developers, not for the general public. Now, MT is much more advanced and stable than it was in the beginning.