cfrag

Here you go. The new attribute for the spawner is named "drivable" and if you set it to true (default is false), any spawned vehicle is drivable if Combined Arms supports it. Below please find the modified scripts that will be part of the next DML release, and a demo miz. Only the vehicle spawned by "my ride" can be commanded spawnZones.lua cfxZones.lua catch a ride.miz

Yes. Except that there is a 1/999 chance that the new value is the same as before (in DCS, that's basically certain to fail in the worst possible moment), and no change registers for that reason. It would be better if you used the 'increment flag" action, which is guaranteed every time to be recognized as a change in value.

Ah, huzzah, the cargo API. It seems to work very different from sling-loading, and I'll (against my better instincts) try and have a look at it. Just out of curiosity, what are your steps to load cargo into (i.e. NOT slinging) the Hook? Rearm/refuel, then the cargo abomination to get get that cargo into the chopper, fly to receiver, and use the abominable interface to push it onto the tarmac into the receiver, correct? When you say 'second time', what do you mean exactly? Do you load two pieces of cargo in a single go, and unload two in one go, or do you load, deliver, return, load, deliver? Maybe I can work something out...

... yet -- it simply never occured to me to use a spawner that way, it's blindly obvious now -- I think that I can come up with reasonable patch within the next couple of days.

Expansion only allows spawning from airfields that are owned by blue. Try a fesh start (delete the data folder) and select a slot from Nalchik (a flight starting with "Nal"). That should work.

Yes, issue still there, NO SLMOD running on dedicated server, using Apache null

Apologies if I sound silly (I'm not native English): Can I paraphrase your question as: do people in (dedicated) server that do not have SLMOD running see the issue of disappearing menus? I'll check anyways Can you be slightly more specific for me? What do you mean by that -- you cannot order support flights while you still have funds, or does the "Admiral AI" does not create flights any more?

Yeah, DCS's API strikes again. Here's a list of the cargo objects: https://github.com/mrSkortch/DCS-miscScripts/tree/master/ObjectDB/Cargos uh1h_cargo is the one that you are looking for, and the type name is "uh1h_cargo" How can you discover that on your own? You can't.

Mission Editor automatically removes any resources that arent referenced by trigger rules during 'file save housekeeping' to keep the files small. This can cause grief to anyone who (like you) attempts to include additional files. In order to include your sound file, and ave it in the correct location, add a new trigger rule (ONCE, any name, I call it 'Load Audio), add a Condition "Time Later Than" and make it a large number, e.g. 999999999 so it will never be executed, and then add actions "Sound to all" with your audio files. This makes sure that the miz references the sound files at least once, never plays them in-mission (realistically) itself, and (most importantly) they are accessible to DML and other scripts that try to play them.

i believe that indeed, your change logs are a testament to your and your colleagues continued hard work on DCS. Few here (at least not I) doubt that you are diligently at work, furthering DCS, shaping the future - and I thank you for that: not just in words, but by purchasing modules, and investing >100 USD a month to host two DCS dedicated servers, and creating missions that I share with others. What can give people pause is not so much the amount of effort that ED invests into bettering DCS, but the focus. It's sometimes difficult to put reason to rhyme when we read that people are working on removable pilot patches and another new map when many of the aircraft I own (yes, I own all of them) are still in EA six years after I purchase them. It's ED's focus of work that becomes an irritant. Shining a light on why (ED is a business) helps to understand; my personal view is that some of your customer's irritation stems from the fact that we don't see what your (ED's) focus is and why. Much of the official communication IMHO doesn't help, and often (for me) exacerbates the issue. There's (for me) too much non-committal, if self-gratulatory talk about features like save-game and dynamic campaigns that, when looked at rationally, would already have arrived a long time ago if it was a focus of ED's aspirations. IMHO, the people at ED are working hard, and like so many people here I show my appreciation by staying a loyal customer. Criticism comes with the territory, and please do not confuse my being critical of your efforts with thinking that you are lazy. I appreciate what you are doing - even if I wish that your efforts were directed more into the direction of fulfilling promises made: I regard each and every EA module that I own as a promise that you made to me to complete, and I intend to hold you to it because I think that you are good for it. Currently, I prefer that you keep your many promises made rather than selling us new, unfulfilled ones. After all, even the greatest of all people can only do so much, and I have many, many products of yours that require ED's fine people's attention. So, thank you for your hard work, and please remember the promises you made.

The fact that DC has been talked up for over a decade now and hasn't seen the light of day pretty much puts that hypothesis to rest. Sad truth: there's next to no money in DC. Put another way: if there was an indication that DC would *significantly* increase module sales (sheer player numbers don't count. Player retention doesn't either. ED needs daily module sales), we'd have it by now. DC is viewed by ED as an edge case for a small, albeit vocal, slice of the pie. There may be the occasional investment into DC, and it is definitely going to be talked about -- in glowing terms. Talk's cheap. Delivery is hard. Businesswise, DC won't swim: Take a napkin, jot down an earnest guess how many additional modules ED would sell if DC became part of the DCS package. That's the marginal business value, before subtracting dev cost. Compare that to the number of sales the next hot module will bring (say, a Tornado or Typhoon or other iconic craft), and assume that both share the same dev cost. Nope, dynamic campaigns don't have a chance in hell to get financed. That sad, perhaps ironic, thing is that ED know their Achilles heel, and they said as much in a 2023 interview: DCS suffers from a lack of gaming content, a lack of player engagement. Missions are sterile, there's really nothing for pilots to do beyond training and getting better. A Dynamic Campaign could be giving players something to do, give them purpose. The immense success of quasi-dynamic missions like "Foothold" and "Pretense", where players have some agency and purpose in the overall engagement spotlights the tremendous potential. Yet, although a seismic shift already, that alone won't move the needle far enough -- ED would need to better engage the community, actively support mission creators, server hosts, provide much, much better creation tools, infrastructure, and push the 'story/purpose' mode of DCS. Given ED's IMHO exceedingly low-skilled communication credentials, though, it for me indeed makes more sense to bet on stamping out new, half-baked modules, tech and maps for as long as possible.

(blush) well, yes. Remember that I'm a bit brain-damaged from years of mission design without DML: Never needed it since, though.

Yeah, English is not my first language, so this is bound to happen. What this text means to convey that the input "spawnObjects?" looks at whatever flag name that you write into the value field, and then reacts (spawns new objects) whenever that flag's value changes. In "Yeller Model" terms, the module listens over the "spawnObjects?" input and waits for whatever command you write into the value column. It's really hard for me to convey this abstract concept, so I invested almost two whole bottles of wine with a good friend of mine to come up with an analogy that may be better understood. It won't magically make the existing docs better, if I have the time, I may go through the docs and update them to also include the Yeller stuff. The spawner module is so old, they even predate the "Watchflag" terminology that I came up before (it seemingly did not help much).

I seem to have solved it by running the launcher, fiddling with some settings, saving and then restarting DCS without the launcher. The "F11 Free Camera" option seems to do the trick: when unchecked, it limits the camera's zoom on F2 and all the others as well. Strange.

IMHO that was the only important and strategically relevant point in the entire interview. ED is a business, and their goal is to make money. Since they stick to an one-off (single charge per model versus other income streams) they must sell modules. Which modules sell well? New ones. So ED regularly pumps out new new modules to generate revenue. In the past years, they have more and more shifted to selling their modules at the earliest possible time, well before the product is finished, as "Early Access". Since sales are highest when a module is 'fresh', their sales revenue slumps shortly (some 6 months) after release. Investment into that EA module is withdrawn and invested into the next candidate for high return on investment. Hence the many half-finished modules in ED's catalogue that IMHO slowly start to tarnish their reputation as a quality outfit. If you own a map or module or tech that is still "EA" then there's a high likelihood that it won't improve much 6 months after initial release. Everything else we heard in that 'interview' was irrelevant to me. ED need to make money to pay their investors. Everything else is window dressing. There is no business-related "commitment to product quality" (see half-finished modules still languishing in EA after 6 years), but there is a commitment to profit for their investors, there is commitment to return on investment. That's how businesses are run. ED don't overestimate their development backlog. It's irrelevant for developing the next module, and that is their focus. Look at Afghanistan's schedule slipping while Iraq is being pushed to sales. Don't ask, so ED don't have to be economical with the truth. We all know what is happening, and it is expected as much as predictable. A "fixed price per module" revenue stream tells you all that you need to know. To me, the rest of the interview may well have been titled "please tell me some comforting lies". Yes there are tons of interesting things that could happen. But they won't unless there is a cold, hard business case to support it. And finishing modules, completing maps, improving technology or developing infrastructure (ATC, dynamic campaigns, better ground AI, you name it) simply don't have the numbers. So don't ask Nick to lie to you. We all are old enough to read a business case. So let us be clear-eyed about this: Unless ED change their business model, there's no need for another interview. "Hard questions?" There currently are none. We already know all the answers. We may not like them - but we know all that there is to know.

Uh. No. Why would it? Put differently, what makes you think it would? Can I trouble you to perhaps read the brand spanking new chapter "The Yeller Model" in DML's docs, and apply it to your setup. Try and forget everything that you know about flags and other under-the-hood workings of DCS. In the yeller model, the LZ screams "landedAtZone1" when a player lands. That's all it does, and other zones who are waiting for that "command" react accordingly. The LZ doesn't "unscream" when a player takes off.

No scripts run when the server is paused, so a paused server does not do anything DML-related. Also, DML scripts must run before they can become active, so an "AT START" trigger is best to use. This isn't DML-specific, it applies to all mission scripts. Set your server to run on client connect, and you may make many issues disappear. All that being said, from a mission's perspective, there is very little difference between a single- and multi-player mission. There are truckloads of DCS bugs in multiplayer, yes (sound not playing, menus not appearing etc), but that is not tied to DML, it's merely a disappointing manifestation of some lamentable state of QC on ED's side. TBH, this is probably an issue with the mission (or DML's code) itself, and not related to the number of players or server context. I'll be happy to sort this out, as it may make DML better, so let's try and trace this bug. If you can please PM the miz to me, with a description how I can force the issue in MP that works in SP, and I'm sure that we can get to the bottom of this quickly.

That's a really cool project, and I think that it is manageable - although you do run the risk of becoming addicted to mission scripting like I have. So, think twice, and if you are sure that you want to roll the dice on that devilish stuff, read on Now before I pontificate on some minute details, I'll take a step back because I think that for later projects, it may help to fully develop an idea before you put the effort into it to implement it. In this case, we'll just power on because it's a great challenge, and no matter what the outcome, your mission scripting skills will have become so much better. That being said, some initial thoughts/questions - what are you trying to achieve? It seems to me that you are implementing a solution in search of a problem. Now, putting down smoke at the player's current location, triggered by a communications command is a good challenge. And having a unit spawn and attack an arbitrarily defined point is another, separate challenge. Together, though, in DCS mission terms they do not fit well. So a player puts down a smoke signal at their position to allow other units to attack that location. Fine, let's say we did that. How does this look in-game? A player would have to fly over some enemy-infested location to mark that spot. Overflying enemies is a no-no unless you are suicidal. So even if you fully develop the entire thing (mark spot, spawn AI and engage spot) the game mechanics won't be fun. Implementing it, on the other hand, will be fun so, let's proceed. Getting the player's position This can be done, and you already seem to have a good idea of this, by using the communications menu and retrieving the group that issued the command. Note here that for this to work (because DCS currently does not provide better API) you need single-unit player groups. But it is entirely doable. Retrieve the unit from the single-unit player group, get the unit's location, and you know where the smoke is to be dropped. Dropping smoke Since you have the location where to put the smoke from the player unit (its x, y, and z coordinates), use the x and z to position the smoke on the map (yeah, a 3D point uses X and Z for map locations. Bad API, but that's DCS for you). To place the smoke, invoke the appropriate API method trigger.action.smoke() -- however, there will be a problem if you directly pass the player unit's location: the smoke erupts at the same altitude as the player unit, so you'll first need to get the height of the map at that location. Use land.getHeight() for this (and get the x, y, and z issues in DCS hammered home in the progress of solving this) So we now can mark a player's current location using communications. Now you want to spawn an aircraft in the vicinity and attack that point. Again, before we go down that route, a brief reflection: why do you want to do that? What is the objective? If you simply want to code this challenge, A-OK, we'll do that. If all you want is rain down destruction on and near the point that the player marked, there are much better ways to do that: simply simulate artillery shells impacting some time later by blowing stuff up at random locations around the smoke using multiple trigger.action.explosion() that will damage anything that's sitting there. So no need to spawn aircraft and whatnot. But let's return to spawning units and have them attack a location Spawning AI Welcome to one of the most tedious tasks in mission scripting. First order of business: determine where. Since we want to keep it simple, we simply use the player's location and move the spawn location 20km (= 20'000 units) up - the spawn location is the player units location as retrieved, and we subtract 20000 from the z coordinate. In a game environment, you'd do some cooler stuff, for example picking a random spot on a 20km circle around the player's location. I'll skip trivial math here. So we have the spawn location. Now, to spawn a unit, you invoke coalition.addGroup() -- you always add groups, not single units. Most of the params are simple. And then there is that groupData monster. If you think that you know tedious, you haven't met the groupData table. You can spent your entire hair trying to figure out how that works. Don't - unless you want to end up looking like me. There's a simpler way: use mission editor to place a flight like the one that you are looking for, and equip it with the weapons, and make it attack a point on the ground. Save the mission, open it with zip, then load the mission file. Note that the mission file is also Lua. Spend a couple of hours to absorb how a mission is structured, then find the definition for the single flight that you built. There's some more tediousness involved, but what all this boils down to is that you simply copy the group definition, and paste it into your script. Yeah, stupid as that, and it works and saves you oodles of time. Then, from your script, you simply modify the spawn location, and target location (= player's smoke location). Which brings me to the last point: how do you tell an AI aircraft where to attack and with what? If you take the copy/past approach from a working mission made with Mission Editor, you kill two birds with one stone. Telling units what to do involves one of the worst thought-out and most user-hating schemes that you'll come across in a long time: DCS's task data. It's even worse than groupData, and if you add a task at spawning, it becomes part of the spawning groupData (hence I prefer ripping the data straight from the mission). If you inspect the crazy data structure from a group, look at the route data. It contains the task. Shortly after your brain starts melting, you'll recognize that the locations in one of the task can be adapted to match the target location, and that all you need to do is to change the route and target points to the spawn target location (provided that the route only has two points: spawn and attack). So all you need to know is take the entire data block that you copy/pasted from your 'code research' mission, and change some "X=" and "Z=", and you are done. Anti-climatic, I know, but "the journey is the reward" After you implement all this, you find that a) it's a great feeling to have DCS bow to your mission scripting prowess and b) that this particular mission mechanic is crap for players. So you immediately have a great new challenge: build onto this to make it fun. Your mission creation skills will soar, as will having fun with DCS. Below please find a mission where I faced a similar challenge. I whimped out going the 'ground explosion' route instead of calling in AI. And I found my own way of marking the ground with smoke other than overflying it (players need to check in with arty first, and then shoot a WP round into the ground near the targets, then call in to arty command to shell the smoke location. Works, but no splashy AI flights) Good luck and have fun coding! demo - Willie Nillie.miz

This may sound silly, but… have you made sure that the server unpauses when you join?

Version 1.80 -- New Rescue Metropolis: Tel Aviv -- 20241108 Full Change Log: slightly moved Adana West hospital smoke NEW Rescue Area: Tel Aviv Code hardening Enjoy, -ch

TBH, if you see something like this [Quote] We do not have time to read through a 30 post thread of two people arguing why something is bad, in fact most times we will just read the first post for the idea and move on from there [End Quote] in the byline for a wish/suggestions forum you know that there's something deeply wrong with how that company views their customers. At least they are honest (or callous) enough to admit that they mainly are annoyed if customer presume to propose, or discuss, ideas. It seems that they cannot be bothered to look at what their customers take time to write. From that I derive that at this juncture ED seemingly have little intention (or need) to mine ideas nor gauge feedback. Methinks experience shows that it's also one of the hallmarks of a company with dysfunctional communication skills. The good news is that ED have a lot of headroom here should they want to improve.

While this is true, methinks that enforcing ATC would be throwing out the baby with the bathwater. ATC should remain wholly optional, and if people abuse it in any way on an MP server, there's always the option to talk to them. I'm not a friend of automatic enforcement. Yes, griefers exist, and they should die a slow, painful death. Everyone else solves problems through talking. So optional, cooperative ATC would be my preference.

What I find so disappointing is that we have the infrastructure in place, the technology in place. Static objects can have, and support, "Paint Schemes". So methinks that adding "sand", "ice", and "stone" paint schemes to FAPS would be a matter of adding a texture map and a settings (text) file. Let us hope that ED find it in their hearts to invest into this request. Maybe the 5th year after acknowledging this will be the charm?

I believe that in an interview with ED (which I can't seem to find, so a suspect source) a spokesperson mentioned that MP makes up a sliver of some 10%-12% of the installed base. Let's turn this around: if DCS was primarily an MP game, it would look very, very different today, with MP-supporting features taking precedence over SP eye candy. If MP really was important, I think that there'd be much better support for MP, because business requires it (if you run a server or try scripting a server, you know what I mean). Currently it seems obvious to me that - due to ED's one-off sales model - selling (new) modules to SP is ED's business imperative; we get half-finished new stuff regularly, and infrastructure upgrades only when absolutely necessary. There is no way to directly monetize ATC (at least when contrasted to publishing a new module or map), so it won't receive much funding - if at all. Talking about it is cheap, so we'll likely receive the occasional "status update". But the one-off sales model seems to serve ED well, and until that changes there's little impetus to upgrade the infrastructure. I sincerely doubt that we'll see passable ATC unless ED's business model changes. ED may talk about it, sure. Just like they talk about a "Dynamic Campaign" or a damage model for the Yak (published as EA in 2018, still EA today, still a bad joke). Yeah, pull the other one. What really adds insult to injury is that all of these come as well-defined, well documented FSM, and the only challenge in putting them into a game are some possible edge-case state transitions that can easily be overcome by state resets. It's not a difficult proposal at all, merely something that requires work. Work, however, that can't well be monetized. Nobody plays DCS for the great ATC experience (and I wager the same holds true for the other FS). Everyone plays DCS for their modules (be it Hornet, Tomcat, Hog or any of the other great stuff). So ATC gets the shaft. Sad, but something I'm trying to live with. Currently, I'd even advocate that ED remove "ATC" altogether, it's in such an abysmal state that it would be better not to put a lantern on it. So, realistically, the sad truth is that we won't see ATC in DCS anytime soon. I play DCS for the fun it gives me now, not for the hopes I have what it may bring me in the future. And since this is a wish list item, yeah, ATC is very high on it for me. And my goddaughter is wishing for pony this xmas...

Perhaps you are overthinking this. Put differently, why do you think that you must clear a flag, what are you trying to achieve? When all you need is one DML module talk to another one to have it do something, DML takes care of lol that for you. In that case I also recommend that you look at the brand new chapter “Yeller Model” that may help you take a much simpler approach to combine modules.