cfrag

We have helper gates for missions, and they can be real boon for many training purposes. I have written some training missions, and these gates really help people become better at what they are doing. The gates allow for better situational awareness, and since they are optional, are always welcome. I was now asked by some kind people if it wasn't possible to create a multiplayer mission where the players could see those gates. Alas, currently that is impossible because these helper gates are (IIRC) single-player only. So here's my request: please provide a scripting API that allows us to spawn helper gates in multi-player missions at a defined point and height, and facing a defined direction (either 2D or 3D). If possible, please also allow scripts to despawn gates on-demand perfection would be if we could also have an event 'gateTransition' that is triggered when an aircraft (initiator) passes though the gate (target) This could help open up a number of interesting new missions (even outside of pure training: racing, etc). It could also allow implementation of some permanent training servers and the ability to ad-hoc create training gates: for formation flights, plotting an approach on-demand, AAR (yeah, I know, let it rest please), and even carrier approach. Note: I'm not requesting this also be integrated into ME, although I'd be happy if that also happened; I'm merely requesting an API for mission scripters to add and remove gates to MP missions on-demand.

Wait - you married your girlfriend because she told you four times that Razbam isn't continuing work on the Mudhen? The short answer is 'no'. The long is "Caveat Emptor". And that is irrespective of what Raz is going to to in the future. We are all grown ups here and make grown-up purchasing decisions.

This may be of interest: https://www.digitalcombatsimulator.com/en/files/3324851/ Among other things like monitoring and setting flags, It can spawn and remove units/groups. It's not a panacea, and some DCS-native debugging tool along the lines that you mentioned would be great. Man, you're lucky I didn't read that, I'd be so disappointed

A Mod requires that the receiving audience also have that mod installed. I write missions for everyone, and thus avoid mods.

It would be great if this was made possible in vanilla DCS. In the meantime, you can use scripts like this: Try this as a demo (it's based on DML so you can easily see how you can create water-based CSAR as well: https://www.digitalcombatsimulator.com/en/files/3335652/

That rather depends on what you are trying to do. In general, many (if not most) DML modules look for certain events. Since DML does this transparently for mission designers, that will probably not help you. DML currently does not have modules to do that. I know that people have requested that and similar features (track min, max or minmax altitude, distance, speed, heading. change in altitude, change in speed, change in bearing, change in distance), and while it would not be that difficult to create a module for each one of these, they quickly add up, and people would want to combine one with the other (e.g. trigger when a player's planer is inside altitude range and inside speed range). Combine this with a good way to choose which planes to monitor, and we are looking at UX hell. I could not come up with a good interface for such a combined module. Yes, by trapping those events in a script. In the context of DML, which tries to provide fully-fledged solutions, not so much, I'm afraid. DML excels at placing ready made solutions on the map, and placing 'sensors' that can trigger solutions when certain conditions are met. DML is not (or rather: no longer) a tool for mission scripting. It's self-contained and does no longer have any serviceable parts inside nor provide an API for scripting.

No, I really don't -- you have already made your purchases, and I suspect that you, like me, are way ahead on the curve in terms of purchases per average users. Technically, we are already written off as low potential buyers. New users -- now they are the ones that bring in cash because they are bushy-tailed hot-shots, not old, disillusioned and bitter types like you and I New users want the hot stuff - Maverick's Hornet, an Eagle or Hog. Maybe later they'd get a Cat. And they hardly give a flying *&%! about a non-weaponized tandem seater with a single prop that you can't even (for lack of a damage model) use to ram other planes. They are Hotel Sierra pilots, and we are just sad downers that obsess about old stuff. Might as well sign up for Facebook or something. The world's harsh. I fly DCS because it still helps me make it a bit brighter.

That's been solved.

Again, excellent news! While we are at it - can we please have some teensy, tiny csar-specifc units/statics with it? Like a person in an inflated life west (for sea-sar) a person on a stretcher (even better if we also can get a civilian) access to the pilot model that is present in DCS but walled off to scripts so we can place a pilot rather than the GRG M4 guy a modern ambulance. Blinking lights? Icing on the cake, let's not get greedy

I think that those people most interested in a Linux distro would be the server farmers who provide us with a great service (I'm renting a Fox3 server). If they can knock off a few dollars off their monthly fee for using Linux instead of Win, I'm sure they would appreciate it. The rest of us probably hold their nose and run Win.

I believe they do. No opportunity cost, ripple effect or churn rate will ever account for the disparity TODAY in unit sales of, say the Hornet or Viper versus the Yak-52. Let's be gracious and say the Hornet outsells the '52 by 10:1 (it's probably closer to 100:1 or worse). So any cent invested in the Yak has to overcome that 10x (or 100x) leverage to be financially viable. That is why investment in low-selling modules is so sparingly: ED must know that it's worth their investment. Those "feature complete" and "not game-breaking" references were spot-on an not random: they allow ED to focus on other modules that better 'earn their keep' (remember: all DCS sales are one-off, no steady income stream other than that). To have some 'neglected near-orphans' in your line-up (e.g. Yak-52) isn't as reputation-killing as people might think -- if enough other pieces in your line-up pick up the slack (Hornet, Viper, Apache, Hog). Just look at CA (shudder). Oh, yeah, and I own the Hawk too - and I'm still an ED/DCS fan (and slow learner / glutton for punishment?). We know that low-selling modules take longer to receive fixes, and we understand why. And yeah, I'll still get the 'Nook even though my Huey really needs some fixing. Oh, and I don't have a problem, I can quit DCS any time

Version 2.2.1 - 20240404: Maintenance Update I've spent the past weeks putting finishing touches on some (DML-based) SAR and CSAR missions, and DML reflects those changes: the CSAR-centric modules have received tweaks: there are few better ways to stress-test a framework than having a moderately popular mission, and many of you have chipped in to test - and provide feedback - on these mission, so thank you so much! Over Easter week-end (and, admittedly, a couple of very good bottles that shipped from the Ribera Del Duero region) during a greatly meandering discourse, a good friend of mine (who regularly flies missions with me, especially those that I write) bought up the idea of a COIN missions. That idea struck; yet I have nothing to announce in this regards, except to announce that I may announce some support for this kind of missions later. But those who let their curiosity get the better of them and delve deeper into DML will find that there are now multiple 'mystery' modules that eventually, when they are sufficiently tested and documented, find their way into 'official' DML. At this point, however, I'm still grappling with the concept. So, if a module isn't documented in the 'Shock Block', it's entirely your risk. Changes in Detail: Manual Main - csarManager new 'inBuiltup' opion - various corrections Quick Ref - various correction Demos - boom boom: Update (flares with explosion) Modules - cfxZones 4.3.1 - QOL additions - clients (experimental, undocumented) - commander 1.1.4 - low level bug fixing for rare issues - csarManager 3.2.6 - inBuiltUp option to place units in cities - dcsCommon 3.0.5 - low-level hardening of code - new QOL functions - groundExplosion 1.1.0 - new ability to also launch flares with an explosion to better mimic real explosions - groundTroops 2.0.0 - jtac callbacks, prep work for later - jtacGrpGUI 2.0.0 (undocumented) - milHelo (experimental, undocumented) - unGrief 2.0.0 - better handling of griefers, still not good enough. Enjoy, -ch

The parts of DML can easily be re-arranged, just like LEGO blocks can be to build something bigger. So, if we take your example from above and split it along functionality, we can arrive at this: Q: Can a Factory be made to stop and start production on demand (say, a signal)? A: yes, that is what the "pause?" and "activate?" inputs are for. Q: Can DML (or, in a broader sense, DCS) detect if a static object was destroyed and send a signal? A: Yes. DML can even detect if a map object is destroyed and generate a signal Taking both abilities together you can "wire up" a factory that stops production (is paused by sending a signal into "pause?") when a building is destroyed. A little bit of work will go into adding the ability of resuming work when something is 'repaired', but as soon as you work out what that repair constitutes (often a cloner cloning something), you already know what to wire into "activate?" In whole, what you'd probably do is clone the static at mission start, and start production. Then, when the clone is destroyed, the cloner sends its 'empty!' output which stops the factory, and starts a timer. When the timer runs down, it clones a new building and resumes the factory. Easy as that

Now this is excellent news, and makes the wait for the 'Nook even more distressing - really looking forward to both.

I believe that the issue aren't the particulars of some bugs by themselves, but the perception that bugs, after being reported, aren't responded to adequately. As a fellow Yak-52 owner (I own all modules, and am a strong supporter of ED and all things DCS) I'm sure I'm not the only one who read your January 26, 2020 statement that said Now, we may differ on the definition of "feature complete" but I think we can agree that the '52 still has some way to go. But again, the specifics aren't as important as the perception that too many things in DCS are moving slow, and ED's focus seemingly is on creating new modules rather than finishing existing. Since DCS's income stream is based on one-off sales of modules, that makes complete business sense: money spent on an obscure, released module like the '52 can generate only a tiny fraction of the expected return if it was invested in a new module with much greater mass appeal; 99% of all Yak-52 sales have likely already been made. That's heartbreaking to me, but understood. "Caveat Emptor" applies to anyone who enters the "Early Access Lottery" and I knew what I was getting into. What I do find a bit irritating is what appears to be some attempts at gaslighting: claiming that everything is fine, and all that needs to be done is to report bugs in the proper forums and things will be perfect. I own, fly and love all DCS modules. Many of them have issues, and the time it takes to fix them does seem to greatly correlate with their module's popularity, meaning that known issues can linger for years in modules that aren't top sellers. I now see that ED have changed from a 4-week to a 6-week (currently it looks more like a 7 week) cycle. That's fine with me. I'm sure that ED understand that with longer cycles their customer's expectation rise as well. And people do get frustrated when, after eagerly browsing the change log, their pet peeve wasn't addressed again, and the next fix is at least 6 weeks away. That's bad. But it's worse when we hear from the perspective of ED that everything is actually fine, and all we need to do is merely report bugs in the forum and they will be addressed. Many aren't and unfortunately, too few are commented on by someone in authority at ED (and by "commented" I mean "acknowledged, reproduced, scheduled for fix"). That is what I feel chafes at people's minds (I'm speaking for myself, and reading the comments I think I am not alone). Mind you, I'm not accusing ED of being lazy (far from it), it's that many of us feel too little of the effort that ED pours into the modules that we bought. We'd love to hear more, and more frank, updates. Tell us if fixing a bug has low priority for ED. I would understand and manage my expectation accordingly. I think we can handle the truth (admittedly, also browsing the comments, that's not a universal trait exhibited here).

Sorry, I still don't get it. Let's assume you can fail your aircraft as intended (this is a single-player mission, right? I'm not sure that you can target and fail aircraft in MP), and the player ejects. And then? Most players would re-slot at this moment, or re-start the mission. Say you simply wait as player and you float down to ground (can take a few minutes). You can get the pilot's location by script by trapping the relevant event (31) and getting the location of the initiator. That's the easy part. You can then spawn and send a helo there. Now comes that part that I don't understand: you (the player) just stand there and wait for the helo to arrive, right? That would mean that after waiting a couple of minutes watching the earth come closer; wait to float down from say angels-10, you then sit around and wait another couple of minutes (say the helo is within 20 miles, so you wait 10 minutes for it to arrive), only to be force-de-spawned when the helo, getting close, despawns your pilot unit to replace it with a normal soldier unit, and you (the player) are sent to look at the slot board, never seeing the (now AI) units being "picked up" and brought home. Wouldn't it be more fun to watch paint dry? Not to knock doing that, I have some crazy paint. But still, I have the feeling that something in this scenario is escaping my addled brain. Should lay off the paint, I guess.

It allows you to save additional flags that you are using outside of DML, yes. Those modules that use persistence usually save their input and output states. If a flag gives you trouble saving, though, please let me know and I'll investigate. My Goldfish Brain may have forgotten something.

I'm probably a bit slow on the uptakes (happens after a sensational Easter meal ) - so what is the players role in this mission? They get downed, wait for the Helo, and then get carried back to base? I don't think picking up players is currently supported in DCS.

I honestly never thought about that. To me, sending an AI helicopter to rescue an AI unit leaves no element for the player, so it never crossed my mind to write such a mission. In case you want to set up an escort mission I think you can get that much easier by creating sich a mission directly, it would not require DML. But I'm likely missing something. How would an AI/AI csar mission look from a player's perspective? What would they do in such a mission?

Huh. I appreciate @BIGNEWY taking the initiative on this - and it does worry me a bit that apparently, even inside ED information on the status of Sinai is difficult to come by. I would have hoped that, after the greatly appreciated and inspiring roadmap that @OnReTech published a couple of moons ago, we would be close to an update (on April 3 or 4). Now, I can live with ORT not making that release date, but IMHO I think that they are unnecessarily burning goodwill with all their customers by not communicating where they are right now. Software is notoriously difficult to deliver, we all know that. So communication is important. ORT did a great job when they published their roadmap. I feel it'd be heartbreaking if a company that shone that brightly fumbles so badly when we know that they can do much better. Here's to hoping to either get an update soon (unlikely if ED don't know the status of Sinai - to be part of the upcoming update next week, it would have had to be inhouse for a couple of days already; this doesn't look promising to me), or some official update from ORT that they are still alive, well, and hard at work delivering on the great promise that the Sinai Map currently represents. We don't need much, and we love Sinai - all it takes is a sign of life to keep our fires burning.

There are often multiple contributors. Pretense hits hard with the number of units, although Pretense Caucasus isn't nearly as susceptible as Pretense Syria - so the mission's units count AND the map have an impact. You mission, as great as it looks, runs on Sinai - another great map that is untested wrt memory demand, but I'd be surprised if it hit less hard than Syria.

Well, those two statements seem contradictory to me. In any event, it seems that you are describing symptoms of an app undergoing pagination (swapping in and out memory from virtual memory space). It's exceedingly unlikely that those issues are DML-related; DML is a collection of lightweight invocations with little to no memory demands and no central process of its own; the symptoms you describe seem to point to a process buckling under load, perhaps a memory issue or non-returning tasks (DCS's unit pathing has a spotty reputation in this regard). This may be acerbated by the fact that DCS server isn't multi-threaded (yet). Unfortunately (among many other things missing) DCS has no means to profile its processes or we could track this issue quickly.

This is usually a sign that your server is running out of memory (too many units, etc.). It seems a common issue with large missions like Pretense. If it happens on your Fox3 server, perhaps ask Luck if he can give you some server diagnostics, I seem to recall that they have installed a memory watchdog on most servers.

[Update: @Chad Vader's issue sorted out by the "Eye of Sauron" effect. The mission is great, it merely needed me looking at it to make it work ]

This would indicate that something else, much bigger, is amiss. It would seem that none of your imported scripts work from what you are saying. With some luck it's the way that you import them.