cfrag

It does... except you may have also noticed that it does not show the original foothold mission. Why can't we simply look for all missions that contain the name foothold, and indulge ourselves, discovering new stuff, have fun? That's how I would design User File's main interface (I'd also integrate it into the "Missions" part of the main DCS app, but that's just wishful thinking, I'm afraid). It unfortunately also presupposes a lot of information that a neophyte user does not have nor should be forced to have: "Multiplayer", "Caucasus", "Downloads". You obviously know what to look for. But you are a power-user, anything but a neophyte. For those, I think it's bad UX design that easily turns into a bad experience. My point isn't so much that it is impossible to find something, it's that inexperienced users have a terrible experience that can easily turn them away. And you definitely must know what you are looking for in order to find it - that's not discovery to me, that is merely retrieval. I would want neophyte users to enjoy what they see, to make them hunger for more, to become addicted to DCS. Currently, I think that we are at the 'scare them off' level of UX. That being said, I thank @Actium for a great solution! Normal DCS users are borked, sure. That's ED's problem.

I believe that this is the sad and salient point. We both know that few people, if any, work at your level of expertise, @Actium. What makes me sad is that ED seemingly invests so little into their customer experience. If "Joe Simpilot" comes to DCS, he takes a look, is unimpressed. Maybe he hears about "Foothold" or "Pretense", the two missions that almost single-handedly saved multiplayer for a couple of years. Someone tells him that he should download it, and DCS will look much more interesting. Problem is: even if you can get Joe to go to UserFiles, searching for "Foothold" gives him this: Joe neither knows nor cares that there is a great mission available, hidden somewhere. He's just been given the finger by User Files, knows a good-bye when he hears it -- and DCS has lost a potential customer - simply because other games handle their customers a lot better. That is heart-breaking. I believe that ED should invest more into their DCS user experience. The current experience has a lot of room to improve. But this is only half of the tragedy: imagine Joe miraculously receives a link to Foothold, and downloads it. As @Kang pointed out: Now what? What does he do with that mysterious .miz file? I believe that a game should shield their users from silly minutiae like this. And I find it supremely disquieting when the company that wants to sell you 'quality software' seemingly can't even get a simple SQL query right on their main user site. It makes them look bad, and it reflects badly on their reputation. @Actium that was a clever, and to me exceedingly helpful post - thank you! What pains me is the fact that it is necessary at all, and that for most DCS neophytes, their visit to User Files is going to a one-time experience. They shrug and then they are gone. Most players aren't looking for a challenge to get their sim to run. They are looking for a good time. I think that ED can and should do better.

Dear ED, I'm an avid fan of DCS, having purchased all modules, tech and maps that you offer, and I have contributed the odd mission and other titbit to the DCS community. I want DCS to thrive, and that is why I am taking time and effort to try and improve the "DCS experience". I believe that good content is what will make or break DCS in the future, especially good user-created content. In the past months I've been troubled by - what I think - ED's failure to put their best foot forward when it comes to presenting (or accessibility) of user-created content on their "User Files" repository. I like that ED provide a repository for users to share their work - that is excellent! While I believe that the process for users to share their work can benefit from your immediate attention (I recommend that ED build sharing, and updating, missions into Mission Editor), I believe that discovering content may be in even more urgent need of improvement. I believe that integrating mission discovery into DCS's main could also be a significant step into the right direction, yet that is not my focus here. Let's assume that a user has found their way to ED's User files (I maintain that today this is a hurdle far too few people are willing to overcome and should be addressed). From my experience, finding content, even for people who know where to look, is disquietingly unintuitive. Please allow me to give an example: In the past I created two "Tourist Map" missions and shared them at user files (here and here). The goal of these maps is for players to explore points of interest on their map. For "Sinai Tourist", the kind folk at OnReTech provided me with location info for those POI, for "Hamburg Tourist" I knew them from when I grew up there. Now, for both I created an easily re-usable script so people can re-create similar tourist maps for "their" cities, and people have asked me if they can use these scripts. Of course they can -- I want more great tourist missions, I'm looking forward to seeing these contributions. So, occasionally, I search ED user files for new "Tourist" maps, and I find that ED user file's search function to be less than intuitive to use. For example: I enter 'tourist' into the search box, and press return. I get the following: Please note the distinct absence of any relevant "tourist" missions, it seems the search term isn't applied at all. "Very well", I thought, so maybe I'm not sorting by the correct term. I open up the "sort by" dop-down - which posts more questions that it answers. "Relevance" didn't do anything - what does it mean? And "Ratings"? I believe is has been a couple of years since you (thankfully) removed that troll-attracting attribute. Are there still ratings being kept, and if so, how are they managed? If not, I recommend that this is removed from the 'sort by' drop-down. So, it seems, today I am too stupid to figure out how to get a list of all missions that contain the word "tourist". What am I doing wrong? How can I get a list of missions that contain a keyword in their title? And while I'm at it - there now seems to be a mysterious "vote" link at a mission. Whatever is this for? What am I voting for if I click on it? What are the consequences? Will this perhaps provide some algorithm with data so I am served similar missions in the future (that's what I'm hoping). Put differently: Why is there a vote link? What does it do? Why would I want to click it? I strongly recommend that ED improve the User Files interface to be more user-friendly, obvious, and self-explanatory so stupid people like I can better navigate its content. I believe User Content can drive DCS's popularity, and I believe ED's User Files can contribute more if the interface improves.

No - I never thought that would be something desirable

Both are entirely different calls. They occur in the sequence that Lua encounters them in the script. Semantically you may think those statements to be similar, but in some very important cases they can be quite different -- so lets' see what they actually do This statement is pseudo-OOP, generated for the benefit of people writing code. It assumes quite a lot, and that may become a pitfall to those who do not regularly code. "myAIGroup:getSize()" does the following: it takes the contents of the variable myAIGroup, assumes that it is a reference to a table, accesses it's value as a table reference if the reference is stale (which can happen if the group is dead and was garbage-collected after you obtained the reference!), it is undefined what happens in Lua. If it is nil, Lua generates an error looks for a member named "getSize" in this table. If there is no such member, Lua generates an error assumes the member is of type function. If not, Lua generates an error executes the contents of member "getSize" as a function and returns the result. Contrast this to This code accesses the variable myAIGroup and uses Lua's internals to interpret myAIGroup as a variable of type boolean. If myAIGroup is not of type boolean then, if it is nil, this returns FALSE. In all other cases it returns TRUE (if myAIGroup is not of type Boolean and also not nil), or, if myAIGroup is of type boolean, it returns the boolean value. Semantically, above code wants to take advantage of Lua's duality for references - a nil reference means 'not defined' and everything else means 'is defined' - you are performing an implied nilcheck. The problem here - again - are stale handles. If you obtain myAIGroup immediately before you do the implied nilcheck 'if mygroup then', all is fine. However, if you obtain the reference earlier, and the group has died in the interim and was removed from memory ("garbage-collected"), you are in trouble. Lua does NOT garbage-collect external references (anything received from DCS API is external C code, definitely NOT Lua-integrated), so the memory location pointed to by myAIGroup has undefined values and may have been overwritten/repurposed. Your reference (pointer) to the table is stale, and your code is likely to take a dive off the deep end. You seem to assume that a group's reference is set to nil when a group dies. It is, but this does not propagate to the variable that you store a reference to that group in if you obtained the reference to a group while it was alive, and you retain that reference for use later. As a result, both your examples may contain serious bugs: you should obtain the reference to the group immediately before you dereference (i.e. access) it. If you do that, your code can be explicit or implicit, whatever floats your boat. I recommend you amend your code as follows: local myAIGroup = Group.getByName("myAIGroups cool name") -- get reference NOW! if not myAIGroup then return end -- nil reference, group does not exist any more, prob'ly dead or not yet spawned if myAIGroup:getsize() < 1 then -- group still exists but dead return end -- if we get here, myAIGroup is alive Now, if you want to detect that a group has died, use above code to detect if it is alive, and when it is alive, set a global variable/flag to remember that fact. And every time that the checks for dead fail, test if it was alive before, and only then you know that it once was alive and now is dead (i.e. transitioned from alive to dead -> died). Reset the alive flag, so this won't be flagged on subsequent passes or so that you can re-spawn. (Just passing through - hi all)

yes Of course, even some vids.

The mission runs the DML version of Stop Gaps. It's a bit more refined, and requires the three other scripts to run (they are DML's foundation scripts - they don't have any abilities by themselves and provide services for any DML script that may need them. Stop Gaps needs them ). There currently is no 131 for standalone, and it will probably stay that way for some time.

That seems odd. Here's a quick demo miz that does work fine for me. If the Frogfoot is cold, remember to turn on electricity (right shift-L) before talking to Ground. (still on hiatus, just passed by) SG with Su25T.miz

So the semantics for routes in Mission Editor is different between AI and player for Fulcrums. It's now the only unit in DCS that uses route points different based on skill. I do not think that this is good design, but at least we have cleared up that it's not a bug but a new 'feature' for the Fulcrum. Because re-purposing Mission Editor Routepoints 1-3 for a player fulcrum allows your team to skip implementing a good, dedicated UX to designate AD points - for example like in the mock-up I showed above. You are sacrificing some usability fidelity for all your customers in return for saving a small amount of effort building the experience. I've been in software development long enough (30+ years) to recognize when designs or implementations cut corners. All that is immaterial, you build your software as you see fit. I would have preferred better design, but that's just me.

If you change both Fulcrums to AI Skill, they will fly into the SAM, and not follow the route that was set up exactly as Wags recommended, meaning that routes for AI and players now follow different semantics. If what you say is how it works in the game now (and I have no reason to doubt you) then as a result it now also becomes relevant which number in a group the player is, and I surmise that the only reason that the AI unit follows the leader (player) is that it would always follow leader, and not the route as marked in ME. This means that any group set up with an AI will not follow the route setup as shown by wags, and if a player follows an AI unit, the setup for AP and WP can't be used as shown by Wags. I believe that this only comes up because assigning these AD points via re-purposed route points is terrible design (it would have been much better if this was set up in an plane-specific panel, but I believe I've already written as much in a different post where I enumerate the reasons why re-purposing route points in ME is a bad idea). For the record, below could be an implementation of AD assignments if it was integrated into ME using basic integration- and UX skills. A pity that the team chose a different approach. The fact that AI Fulcrums do not follow the semantics as shown by Wags seems like a bug to me. Re-purposing route points for Fulcrum IMHO is bad design that feels cheap. Re-purposing them just for Fulcrums with Skill "Player" or "Client" makes a bad design decision worse. I strongly recommend that the team drops the 'repurpose' approach and spends the effort to correctly integrate this into ME.

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

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...