cfrag

Dear all, my inclination to contribute to DCS has reached an inflection point, and I have decided to withdraw from public contribution for the time being. I thank you all for your kind encouragement and friendship in the past decade, and wish you only the best for the future. -ch

Dear all, my inclination to contribute to DCS has reached an inflection point, and I have decided to withdraw from public contribution for the time being. I thank you all for your kind encouragement and friendship in the past decade, and wish you only the best for the future. -ch

Dear all, my inclination to contribute to DCS has reached an inflection point, and I have decided to withdraw from public contribution for the time being. I thank you all for your kind encouragement and friendship in the past decade, and wish you only the best for the future. -ch

To run any mission that uses a script with dostring_in(). If they do not enable it, the formerly running mission stops with an error. Try this: Won't run on a fresh, secure DCS install. It did so until yesterday.

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.

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. crash my clients.miz

That is true. And it requires that anyone who does this knows what they are doing. 99% of them do not, and do not care. They will copy/past someone's solution, and that one is virtually guaranteed to unlock all environments, if it's not a maliciously crafted script itself. Any solution that requires a user to know some arcanae is a bad solution. Any solution that relies on detailed user know-how in coding is sensationally bad. This solution requires both: that a user feels comfortable editing a code file, and know what the terms inside like 'gui' and 'mission' mean. You just lost 99.99% of all ED customers. Most have the ability, yes. But they can't be bothered. They will copy/paste.

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.

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.

DML has completely gone South, and today I do not feel charitable. Any mission using a recent version of DML, Olympus, SSB, or slotblock (i.e. anything Foothold or similar) will no longer work without you changing your DCS install. Expansion, most of the missions I released to UserFiles in the last year, and many interesting missions created by others in the last 24 months are affected. They continue to run, but you must install that godawful "autexec.cfg" <shudder> in the correct location(s). And yeah, that includes your servers. Good luck figuring out which context name corresponds to "scripting" - you may have to rewrite your server scripts. If you can. Fun. If this continues, I foresee that - out of simplicity/convenience - 90% of all DCS installs are set to execute insecure code, completely ruining security - the exact opposite of what the kind people at ED set out to do. Maybe they should have asked someone...

It's really not hard (actually, it's trivial) to patch net.doStringIn() so that a security layer inspects the context and allows or disallows it depending on the mission file that is running, from ission to mission, in the 'mission' environment. The same goes for any other environment. I respectfully contradict your kind message and assert: anyone with access to the interpreter level and a modicum of Lua knowledge can make net.dostringIn() safe depending on the mission that is running. If we have a set of missions that we want to allow unsafe invocations, all we need is a list of their file names. And users could manage that easily, heck even (if you can't be bothered to give that to your customers) have them put in a folder '/unsafe' inside your '/Missions' folder. It's exceedingly easy to manage this, and it looks like no thought has gone into this at all. That's why I'm so disappointed.

Yup, The new release from ED introduces a new, braindead 'security' scheme that prevents scripts in missions from invoking net.dostringIn() unless you create some arcane "autoconfig.cfg" text file in a similarly arcane location. It is simply crap design, and I'm at a loss of words seeing how ED simply did this without bothering to ask the community. The results are far ranging: slotblock (if you play foothold), ssb (another popular slot block), stopGap for multiplayer, twn, radio, ... all require the new 'security' BS. IMHO, the result will be that everyone who wants to play a modern, good mission will have to allow unsafe invocations, and this results in LESS security for DCS than before. What an ill-thought out, idiotic, crude approach to security. Goodness. And ED rammed this atrocity down everyone's throat without ever announcing it or soliciting ideas. Because it is trivial to come up with better solutions, solutions that could help DCS become a modern, player-friendly SECURE app and could ditch the silly 'unsanitize' approach of today. But no, we now have 1980's style "autoconfig.cfg" files. If it wasn't so sad, I would laugh. This is bad. And completely unworthy of ED.

It was. It is used to invoke some code in other environments and pass back data. Regard this snippet: local command = 't = loadfile("' .. path .. '"); if t then t(); return net.lua2json(towns); else return nil end' local json = net.dostring_in("gui", command) if json then towns = {} traw = net.json2lua(json) end Above (plus correct path info of course) reads all towns with their location from any map, and allows scripts to determine where something is, provide better locations, and even determine if a location if worth an attack (it is required because "towns" isn't otherwise accessible in MSE. And it simply worked. Same for radio frequencies, getting the name of the currently running mission (for easy restarts because the trigger version saves a string which buggers versioning). And of course, the venerable SSB (simple slot block) used it to pass slot blocking info. All gone to this 'improvement'

This is atrocious -- I am severely disappointed and aghast. I feel that you (ED and their community managers) could have announced this change more than 24 hours in advance (6 months would have been a better time frame), and perhaps solicited feedback from the community -- because the way that you (ED) chose to implement this sandbox protection scheme is a 1980's design. "autexec.cfg" - are you frigging kidding me? Doesn't anyone at ED understand modern UX and or UI design? Why use such an obsolete and user hostile one-size-fits-all scheme when it would be so much better to build a "sandbox on/off" switch into DCS proper, and then add a simple UI that allow users to add folders to an 'allow unsafe' box that automatically allows unsafe invocations for any mission inside? Users could drag folders/directories and/or missions into the box and - boom! - they allow unsafe invocations. Designing this is (or should be to your talent) near-trivial (I did interface stuff like that in 2 hours -- 2002, on a Mac in XCode!), and a so much better approach for users who grew up with a Mouse. I feel that this new 'design' of yours is unworthy of you, and it feels like such a blatant slap into all of your content creators' face that I am deeply saddened to see how you simply (and callously) implement a far-reaching change like this without ever feeling the need to consult your community and contributors. Are we that worthless to you? That new 'feature' of yours kills any mission that uses net.dostringIn(). You do realise that mission scripters resort to doscript_in because DCS's mission scripting environment requires this to circumvent a bad flaw in MSE's design, do you? This means that any mission today that is sufficiently advanced will stop to work and require that unsafe patch, which will probably result in most DCS installs being unsafe. The exact opposite of security - likely a complete failure of what you set out to do. Why, why, why did you not try to sound out this change with those who spent lots of time creating missions for your product? I would have expected more from you, ED. For the record, can I request that you. or someone from ED, elaborate if you agree that this is merely a coarse stop-gap and that you do have a real, user-accessible and well thought-out future version waiting in the wings? Because this? This is bad design. Will we get a real 'sandbox' security interface for DCS? I don's feel like updating the 50 (?) missions I put on Userfiles, so maybe they run, maybe not. 9 out of the last 10 missions I published there no longer work and now require unsafe invocations. So be it. I cannot be bothered to care if you, dear ED, can't be bothered to engage with your community either. What a mess. I hope that you will fix it soon. Will you, ED?

Update 20250720 - better dynamic traffic Now there's some local traffic on both your departure and destination airfields. Enjoy, -ch

Unless I've already invested heavily into modules, and have been a loyal DCS customer for more than 10 years. I want DCS to survive much longer, and it pains me to see DCS moving in that direction. I purchased the YAK when it came out in EA, and it's still not done today. That hurts, and it hurts ED's reputation, which is IMHO worse. Writing off the Hawk, Mudhen, Farmer, Harrier and Mig hurts. The question is: what am I learning from this? And I was looking at the 'what if' thought experiment of only purchasing non-EA modules produced by ED only. That was IMHO not a pretty sight, and IMHO shows what it would mean if ED's EA and Third Party policies deteriorate further. We could argue about the methodology, sure, but that's 'angels on the head of a pin'. ED's EA policies seem to try and misuse the Early Access term simply as a meaningless marketing gimmick: to make potential customers believe a module is 'new' when it's in fact many years old and no longer in active development - Yak, Viggen, Jeff etc. - something that I deem a bit unsavoury if not seedy. "EA" in DCS is to me a meaningless term. "Active Development" would be a more relevant term, and of those there are only a few modules in the catalogue. Receiving the odd maintenance update in my book does not qualify 'active development'. That's just 'on life support' so it can still run with the current version of DCS. My apologies for being obscure. The relative module age was part of the 'what if' thought experiment, underlining the extreme dependence of ED's business model on new EA one-off sales and no sustained income otherwise. If a module remains in "EA" for too long with no discernible development, the "EA" moniker loses meaning, and may serve to alienate customers. With regards to DCS's core, it has slowly evolved, and since parts of it harken back to pre-2000 time, it's legacy and creakingly-old old core is apparent to me every time when I create a mission, every time I use at the Mission API. And the underlying core is ancient: it caps at 65535 object allocations - that's a 16 bit integer from 1990, a relic from libraries used at that time. Garbage collection is similarly old and dysfunctional, the reason why a dedicated DCS server (of which I run two) needs daily reboots. So, yes, DCS core is very, very old and in dire need of update. I've been with DCS for more than a decade, and around the block once or twice, just like you. I'm happy it still runs, and I'm hoping that ED manage to keep it together for much longer.

That is good to know - thank you for the update. Then again, the treatment of Falklands wasn't my central worry; I was more focused on what remains of DCS without EA and third party modules.

That is an interesting and IMHO intensely valid point: ED's current situation seemingly burns bridges left and right: at one hand we can no longer trust that they can control their subcontractors (I've now been burned multiple times: Hawk, Mudhen, Harrier, Farmer, Mirage, Falklands), and on the other hand their EA program can't be trusted (almost a decade in, my YAK still has no damage model, it likely never will have one). So, if we disregard all non-ED modules (for risk of losing support over night), and disregard all EA modules, what is left as of today, July 2025? (maybe next week: ) F-16, a six years old module FA-18 , a seven years old module A-10C, a 14 (!!!) years old module F-5E, 9 years old F-86, 11 years old L-39, 10 years old Mig-15bis, 10 years old Flaming Cliffs, 13 years old And on the rotor-wing side we have Black Shark, 17 years old (old enough to drink where I live) Mi-8 Hip, 12 years old UH-1 Huey, 12 years old Maps: Nevada, 8 years old Persia, 7 years old (plus a couple of warbirds that I own but never fly. And I did not mention CA out of kindness.) So we can get a couple of badly aging modules (the Hip and Huey are great models, they desperately need updates, the Huey still can't be used in multicrew correctly). The reason that the older modules are in such a crappy condition? Probably financial - since there is no steady revenue stream to support older modules, they languish in 'maintenance hell' and get little to no development, just enough to keep them afloat. But that's a different story. Without EA and their contractor modules, DCS IMHO is not really interesting, with a hand full of aging (9+ years on average), barely maintained modules on offer, and a core that seemingly approaches obsolescence due to bugs and age. The ever-tightening one-off sales structure that heavily relies on EA is likely to steepen the curve, making it worse. Let's hope that ED find a way to mitigate the RZ disaster and can avoid a repetition of the Hawk and keep customers buying modules from their contractors.

My apologies, that was not intentional.

It would be near trivial to write a script for that. And it would be near-trivial for a player to designate any point and have arty pound it, which is why I so far did not implement it, it’s simply too easy (for an approximation, install theDebugger in a mission, and use the boom command. That would be very similar). And if we can hash out a good, fun way how this feature could work, I’m happy to create a script for that…

Version 20250719 - update Update to defend against new DCS bugs. This update also includes a new module for better civ fixed-wing traffic at Batumi. Enjoy, -ch

The "size" of a conflagration is determined by the number of fires - DCS isn't really good at simulating fires, and you may have noticed that fires really are 2D 'billboards' with low-resolution artwork pained on. Trying to make this a better experience by controlling the size of fires proved not to be worth the effort, so what I call 'size' is really number of burning cells. Hitting the fire is a combination of velocity and altitude (of course). Simplistic though it may be, the fire-fighting module simulates dropping the fire correctly (if near-instantaneous) using simple vector algebra. So your best bet would be flying slow, and release directly above the flames. Since (again) fire in DCS is (sadly) a purely visual effect, you can fly into the flames without being affected by heat nor updraft.

Let's disregard the particulars of this situation and look at a purely hypothetical one: Imagine I hire you to create a marble statue for 1000 USD. You deliver, I owe you 1000 USD. Now I claim that one day you parked your vehicle on my lawn, and that that has caused me damage, and that therefore I withhold that payment of 1000 to you. Most courts in the world would tell me that I can't combine things that aren't contractually connected, and they will order me to first pay the 1000 USD to you (settling the 'marble statue' issue), and only then, in a separate procedure they will settle the damages that you owe me for parking on my lawn. I cannot unilaterally impose sanctions upon you simply because I feel it to be just nor adequate. Separate things must stay separate. So it may well be that RZ impinged, or broke some contract(s). If ED have a contract schedule to pay RZ for services rendered, they would be well advised to pay those fees under the contract, and sue separately for damages for the broken contracts else they open themselves up for litigation. Now, we don't know the facts of what happened here, except that there was a lot of unnecessary, unhelpful and probably self-serving public exposure (highly inappropriate and unprofessional). So let's not speculate nor believe any public missive that was put into public view - they are irrelevant to the proceedings. As a customer of ED who owns all modules that currently are under dispute, I'm not interested in learning who was at fault. I'm interested to learn that my modules will be kept up to date and the Early Access promises are going to be kept. I don't care how this is accomplished, and I hold ED accountable for looking out for their customers - especially after they broke their promise to me in the Hawk debacle, and I decided to give ED the benefit of doubt with the Harrier, Mudhen, Mirage, Farmer and Falklands.

Whenever one side in (legal) proceedings uses public channels to 'contact' the other side -- instead of using the very, very defined channels set out for legal proceedings, they are behaving unprofessional: they are deviating from the protocol laid out by law), and it is likely that such communication has other intents as trying to resolve the dispute between the two parties. If they really want to contact the other side, they contact the other side's legal representation, or, failing that, file with the legally appointed arbiter/court. There is no way that either side does not know this, so a post on a public forum is an immediate red flag. So, to answer your question: if RZ want to contact ED there are ample proper and defined ways to do so. A public forum or "social app" is usually not among them. I find it inconceivable that the post from RZ was out of desperation because they could not reach ED. There are likely other reasons to go the public way, and I can think of no good, innocent ones. We - the customers and general public - have no say in this dispute, and we will not be consulted for the resolution. We might after. This is how legal proceedings work. They are eating the shoes! They are eating the socks! Oh my...

To quote George Carlin (to who's wisdom I still regularly bow) who remarked in 1998 that And yes, it definitely only takes one to make an idiot out of oneself. I've proven that many times over.