cfrag

Indeed, and that is only a problem from a UX perspective (the player FF Fulcrum now is the only unit that does not follow the route in sequential order, the semantics of waypoints in a route have changed for FF Fulcrums of skill Player or Client). The semantics for a 'correct' (as I understand it) flight set up for a FF Fulcrum group's route is RoutePoint 1 --> AeroDromepoint 1, RP 2 --> AD 2, RP 3 --> AD3 (i.e. the first three route points as assigned in Mission Editor go to AD points 1-3). The FOURTH route point (as assigned in ME) is the first 'mission waypoint', i.e. the route point that you are heading for in an engagement: RP 4 -> MWP 1, RP 5 -> MWP2, RP 6 -> MWP3 (I'm using non-standard terms 'route point' RP, 'aerodrome point' AD, 'mission waypoint' MWP for clarity only) HOWEVER: In Wag's Video, the first AD (airodromepoint) [02:00 in the video: "The first three points that I'm going to lay down are going to be the aerodromes corresponding to the switch in the AD position"] is Shindand then Farah (first divert) and the last AD is Qala. At 02:39 Wags then proceeds to add three more route points: "Next will be the three waypoints which correspond to the switch being in the WP position", and then proceeds to place three points enroute from Herat to Shindant, which all happen to be collinear with a route directly from Herat to Shindant. The last bit is important to recall in your analysis. Imagine that there was a known SAM location between Herat and Shindant that we want to avoid so we move route points 4 to 6 to the West. The waypoints 1-3 (route points 4 to 6) are no longer in line with the straight route from Herat to Shindant. Add an AI wingman, fly the route and see what happens: Your wingman will fly directly from Herat to Shindant - because it takes Route Point 1 (= AP 1 Shindant) as its first destination. It will fly directly into the SAM site. AI wingmen DO NOT follow the "first three route points are aerodromes" semantic of the route, they simply fly from from route points 1-6: Herat (spawn)-Shindant-Farah-Qata-routepoint 4-routepoint 5-routepoint 6, and then land at the closest faction-owned airfield. This is VERY different from what you want it to do: Fly from Herat to Shindant while avoiding the SAM site and following the player. So the only reason why it looks as if AI is doing what you want is because route points 4 - 6 are (by coincidence) in line with the route from Herat to Shindant. You should have known that something was amiss when you tested the scenario and found that instead of landing at Shindant, your wingman would go on to Farah. If you arrange your tests against your expectations, you will quickly see that your desired scenario falls apart, that AI wingmen do not follow a player FF Fulcrum's route point semantic. Below please find a demo mission with a Roland SAM site that kills the AI Fulcrum because it does not follow the player's route. fulcrum me tests2.miz

In "Navigation And Landing", Wags tells us that when setting up a route for the Fulcrum in Mission Editor, the first three Waypoints are divert airfields, and WP number 4 (silly as it may seem) is the first "real" route point. Currently, AI FF Fulcrums do NOT interpret the first three WP as Divert Airfields. Worse, if you set up a group for you and an AI wingman, and follow Wag's instructions, your Wingman will happily fly to the first route point (your first divert Airfield), abandoning you while you fly to WP 4. Here's a simple demo. Enter the airborne group, and see your wingmen fly off to Kobuleti, while your first mission WP is Sukumi. fulcrum me tests.miz

So, the answer is YES (ME has become worse), AND ED screwed up Fulcrum Navigation setup from ME. Disappointingly it's the first thing that I posit ANYONE would have tested after reading the specs. After all, these questions came up immediately when I watched Wag's tutorial. In short: you can no longer mix AI and player FF Fulcrums in the same group if you set up navigation correctly (as recommended by Wag's video). Here's an easy test case (took me 3 minutes to set up): Setup AI first: AI FF Flanker, placed in Air over Senaki. Set Divert airfields (WP 1-3) to Kutaisi, Kobuleti, Batumi, and set a 4th Waypoint (mission destination) to Sukumi. That way, you can easily determine AI behaviour: if the plane goes south, you know it is heading for the Alts, if it goes North, it heads to the mission target. Start the mission. The AI FF Flanker heads to Kutaisi (i.e. the first divert). This is NOT the mission target. So setting the Fulcrum navigationally correct, up as recommended by Wags, does not produce the correct result. If you want an AI FF Flanker to go somewhere, you must not set up divert locations. That's bad enough, but let's proceed. Setup Player FF Fulcrum: Now add a player unit to the group (still route setup as Kutaisi, Kobuleti, Batumi, Sukumi). Jump into cockpit. Checking the AP and WP settings in-game is exactly as described by Wags: Kutaisi, Kobuleti and Batumi are divert airfields; and Sukumi is mission target. Turn to your mission target (Sukumi). Problem: your wingman is going to Kobuleti. F*ç%!!!!! So yeah, FF Fulcrum's nav in the game is screwed up; you no longer can use its nav system as designed with AI wingmen, and player aircraft route setup in ME now is nonstandard. These are two hard knocks against the FF Fulcrum, and one knock against ME. Demo mission enclosed. I would have hoped that this was obvious during testing and was removed prior to release. Alas, no. fulcrum me tests.miz

A fantastic new video from Wags (see here) shows us how the (as of now upcoming) Mig-29A is set up in Mission Editor for navigation. From what I've seen (my interpretation, I can be wildly wrong), setting up a player-controlled Fulcrum's route is non-standard, and breaks compatibility with all other units. RIGHT NOW when we assign routes to units in ME, the procedure is simple and universally applied to all units (air, ground, naval): add waypoints, and it is understood that a unit follows all waypoints in sequential order. WITH THE FF FULCRUM it seems that - probably only for Fulcrums with Skill of Player or Client - this changes significantly: the first three waypoints placed in ME are now fed into the Nav System's "AD" store (AeroDromes, e.g. for diverts) while all other waypoints added are going to be accessible with the swith in "WP" position. The result is that a (player?) Fulcrum's route now always has to be set up with three divert AD points, and only then adds the "real" waypoints. [EDIT: to be more precise, I do understand what Wags says at the 02:57 mark: "if you wanted to have six geographic waypoints you could set those aerodromes as geographic points not assigned to specific aerodromes, rather any geographic location. Just need to make sure that you have the switch in the AD position to access those". I'm at a loss to interpret what that means, and I think that this means that waypoints 1-3 as set in Mission Editor can be accessed as Waypoints as well, depending on the setting of the AD/WP switch - but it is not clear to me how this duality of WP interpretation works in what context, especially with AI aircraft. For the sake of this discussion I'm assuming (dangerous, I know) that WP 1-3 by default are treated as AD points, and WP 4-6 as waypoints for navigation. So if you want to navigate to WP 1 as assigned in ME, you'd switch to AD, then select '1'. Ugly enough. How does this apply to AI aircraft? If the waypoints 1-3 are stored as diverts, will an AI aircraft then directly fly from spawn-point to WP4, or do AI aircraft interpret waypoints differently?] THIS IS INCREDIBLY POOR DESIGN Why? A couple of points it breaks established procedure that a unit follows a route from first to last waypoint. Now, some units (Fulcrums) follow the route like this: from initial point they go to the FOURTH waypoint. It's not made clear in the tutorial, and I assume that this only holds true for player-controlled Fulcrums, not AI-controlled if there is a difference between how AI-controlled Fulcrums handle a route and player controlled do (player Fulcrums ignore waypoints 1-3), this further breaks usability, as the value of an attribute (Skill) changes route behavior. it makes it more difficult for content creators to visually understand a mission. Remember that in ME all waypoints for all units are drawn and connected. If there are multiple player Fulcrums they all now show the divert points, with the routes criss-crossing the map. it requires that mission creators remember that the FF Fulrcum have non-standard route assignments, and they must know how to handle the "(player) FF Fulcrum case" (the first three waypoints are special). If AI and player units handle routes differently, creators must also remember this correctly. it works against (and destroys) established practice from experienced content creators when they create complex, multiplayer missions that provide slots for multiple player types. Let's look at "Foothold" or "Pretense" as exampls: established procedure is to first place a player aircraft, set up the route, and then copy-paste unit with route. Then, we change the pasted unit's type to a new aircraft. The new units inherits the old route and all is well. This breaks for FF Fulcrums, requiring additional steps - if the content creator remembers that Fulcrums behave differently route scripts that process a unit's route for any purpose (there are lots of them: visualizing a unit's path, automatically providing info about the route, automatically placing units along the route etc.) now could break functionality for FF Fulcrums breaking the sequential logic of a linear route depending on a units/skill is incredibly bad design, as it requires additional coding and is not backward compatible DCS's own 'save state' (which, admittedly, is still nowhere) will have to compensate for this design flaw, and the code will have to check for type and skill, and provide extra code to preserve the AP states it can be a source for errors. AP points can be anything, there is no validation built into ME that the first three points in a FF Fulcrum are airfields. A BETTER DESIGN, more in line with established ME procedures would be: If a mission creator edits a FF Fulcrum, they can enter AD info from the "Aircraft Additional Properties" tab. This FF Fulcrum specific tab can hold three AD locations AD1, AD2 and AD 3 which can be set to any airfield in the map by means of selecting that airfield from a drop-down. [Edit: if it is important that AP can also be assigned as any geographical point, this ability could be added via trigger zones: An optional secondary drop-down menu allows mission creators to choose any existing trigger zone's center as geo point. I regard such an approach as klutzily and still at LOT better UX-wise than re-purposing ME waypoints.] Perhaps something like this: All route waypoints now are treated just like route waypoints created for any other unit, WP1-3 are no longer dual-purpose in ME. I think that the current design smacks of a "let's be low-effort and re-purpose existing data, and to hell with possible consequences for users" attitude that reflects poorly on ED's dev team. The current design creates more problems for everyone else down the line and is one of the main reasons why I'm so worried about DCS's future; why I no longer feel encouraged to contribute. What we have here is a brand new, for-profit module that reveals significant integration design flaws. That to me shows that too little thought has gone into game integration. This is not a good trend, and further confirms my unease about DCS's future.

Agreed, and I think that AI and scripting support in DCS has become decidedly subpar. DCS's future will live and die by good content: what people can do after they master a module. What's problematic here: IMHO DCS today is hell for content creators. Content creation tools (Mission Editor, QAG) are abysmal, support for content creators is non-existent, community content integration into DCS is not even planned (how do players discover community content from within DCS? They don't - it's not integrated, even though ED host 'user files'. Publish/update a mission to ED's User Files for content creators from Mission Editor? Nope - even though the creators are logged in. Have these been suggested to ED? Oh, yes. Any response from our 'community managers'? You must be new here). Support for better API (cargo management, events, unit tasking, multiplayer, persistence, security/sandboxing)? Community suggestions are ignored, and as the last 'dostring_in()' brouhaha in July showed, ED's is long on ignoring the community, and seemingly quite short on good talent. The constant stream of exceedingly low-quality additions to DCS Core (save state, QAG, warehouse API, cargo UX), combined with a consistent lack of central improvements (AI, ATC, Mission Scripting API, UX) after more than a decade of feedback has cooled my enthusiasm for DCS significantly - to a point where I no longer can be bothered to contribute (I have occasionally contributed in the past). The tools are terrible, DCS core seems to deteriorate, and the community managers simply aren't. Hopefully the fine people at ED can turn DCS around, and re-kindle our love.

This sounds suspiciously like a mission that I made, so I'll try a stab at it. If you choose communications->Other->Formation/Intercept & Escort, you get a menu that allows you multiple choices, for example "Team: OH58D". While you can choose any option, you must be at 300 AGL for the choice to have any effect, else you get a notice and your choice is ignored. So, I recommend that you take off, get above 500 AGL and then try again. A Kiowa should appear in front of you, flying your current heading, to allow you practicing formation flight with it.

I believe that the decline in DCS's quality is quite obvious, and the reason why ED can't prioritize fixing what's wrong is equally obvious: they must sell new stuff, they have no time to finish stuff that they sold yesterday. ED have actively decided against a steady-revenue-stream model (a.k.a. "subscription"). That (a subscription model) could allow ED to fix many of their current shortcomings, and - yes - it would alienate many of their existing customers. TBH, ED offends those anyway with their current neglect. And that is of little consequence, because existing customers are only relevant for a company to keep happy should these customers subscribe. We currently don't, and aren't kept happy. Because we don't matter. IMHO DCS' quality is in freefall for all but the cash cows. ED seem to have adopted the "Kodak strategy": "we've been successful for so long, so we must know what we are doing". Then, Digital Photography killed Kodak. Let's not forget, Steve Sasson, a Kodak Engineer, invented the digital camera. So Kodak was uniquely positioned to grow BIG. They thought they knew better. Kodak went bankrupt in 2012, after more than 120 years of phenomenal success. Kodak's Ektachrome is *still* the best film I ever used. That didn't save them. DCS is still one of the best FS around. I don't think that alone will save ED. DCS must also become a good *game*. ED know how to make a good FS. IMHO, they have no idea how to create a good, engaging game. Look at their content, content creation tools, look at how they engage with us, their *fans*. "Bleak" is what comes to my mind. So, subscriptions to help finance fixing the core, and re-tooling DCS to become engaging: now that's a monumentally tall order. Low product quality and lack of engagement are the main reasons that I'm withdrawing from contributing to DCS. It pains me to witness DCS' current state, and I hope that I'm not watching a re-run of "The Kodak Story", the story about a great company unable to change. Change is hard. Hopefully not too hard for the developers of my favourite FS.

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

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.