cfrag

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

This may be a silly question, but considering that the pyramids are solid (not hollow), made from some 5 million tons of limestones and some 5000+ tons of Granite, why would some puny 2k iron bombs even put a dent into them? Those things were built to last. 3K+ years of humans couldn't put a dent in them... So even if ORT put some collision detection and damage modelling into them, I don't think that realistically, mere bombs that are dropped from above could damage them all that much.

Does it matter? Neither is very accurate, and you can only fly one map at the time. So if your mission is on one map, it doesn't matter what the other map looks like. From my personal (cursory) inspection, The Haifa region has more 'realistic' landmarks in Syria, Tel Aviv more realistic landmarks in Sinai. neither are very accurate, and I find both regions (the two with realistic landmarks on different maps) worthy of a local helicopter rescue mission. Otherwise, the remainder of the map (the stuff without landmakrs) dictates to me what to choose. That, and the fact that Syria simply is much more popular than Sinai (the bad rep that ORT got for the one-year gap between releases may have contributed strongly to this) on MP servers.

Huh. Spoken words are certainly a bold choice - even if the theme evokes strong echoes of Frankie's "War" and "Two Tribes". It's still too jarring and distracting for me. I'm sure others will love it.

Some good wine there, I guess

Version 2.3.6 -- 20241107 -- Feature Update Recently, while assisting a fellow mission designer, I ran into a communications challenge: I tried to convey how modules talk to each other and realized just how inadequate all explanations that involve flags and methods and whatnot were. I needed a new, better approach that allows non-technical people to easier grasp how this works. As I so often do, I kicked the issue up to a bright friend of mine, who also happens to be an artist. It took us more than a bottle of wine, and some of her free-associative thinking, but we came up with what I now call the "Yeller Model". It's become part of the documentation, and I hope that it may help many aspiring mission designers to grasp more easily how modules interact, and it allows most of them to craft great missions without ever using the word flag. Please see the documentation. Other than that, this release also sees a major new feature for one of DML's prime modules: heloTroops. Based on a request I added 'dropZones' that can kick up heloTroops' functionality a notch, while (of course) staying completely backwards compatible. It comes with its own new demo 'Inferno at sea', which is basically an endless extraction mission for helicopters, put together in a few minutes. Also, The Debugger has received a feature update which will bring great relief to a tiny goup of mission designers who actually use it: it now sports a feature to identify misspelled flag names ("commands" in "yeller" parlance). If you build a mission and for reasons unknown two modules seem to have problems talking to each other, a misspelled input or output is often the root cause. The Debugger's new "-x !" command (appropriately cryptic, don't you think?) lists all outputs that do not connect with an input (and vice versa), making it very likely, that one of the names was misspelled. Oh, and finally - which has unfortunately been par for the course in the past few months - a new DCS update came with game-breaking changes: this time on the Syria map. For reasons unknown, that map breaks one of DCS's cardinal rule that no two objects may have the same name. In Syria, well over 100 airfields now have the same name "H", which can break any existing script that accesses airports by name. I hardened DML's modules, and I am sure that there will be lingering issues until the kind folk at ED/Ugra correct this breathtakingly obvious blunder. All Changes in Detail Documentation Main Yeller Model (new) HeloTroops Debugger cunconnected in-/output detection Yeller Model demo (new) Inferno at Sea demo (new) Quick Ref Yeller Model HeloTroops Demos Inferno at sea: dropZones (new) Yeller Model (new) heloCargo (update) Modules cargoReceiver 2.1.0 new noBounce Attribute cfxZones 4.4.3 additional hardening of property processing civAir 3.1.0 hardening for Syria's 100+ airfields known as "H" convoy 2.1.0 new convoyTriggerMethod heloTroops 4.0.0 new dropZone new enforceDropZones playerScore 4.0.0 improved event handling suppress landing event after player spawn theDebugger 3.1.0 new detect unconnected inputs/outputs tool Enjoy, -ch

Yes and no. DML is not designed to be code-modified. It's not intended for code heads at all, it is designed to be used as is, from people who do NOT want to modify, or dabble in, code So if all you need is some script that plays some sound file, and you feel sure enough about mission scripting, you can take DML's modules as some source of inspiration how to go about that. Bomb Range could be such an inspiration, Guardian Angel another. Your scrip would center on an event handler that traps 'shot', lhen looks at who shoots, analyses the weapon that was shot, and if all matches as desired, you play the sound file. On your way, you'll probably discover some of DCS's idiosyncrasies. To quote Calvin's Father: "they build character". I do not discuss code in this thread, though. For code discussions, I recommend that you open a separate thread or PM me.

Or you could tell players to log off, e.g. via chat. You can if you know how to create and maintain server-side script modules. It would be net.get_player_list() - but that is not something that you can invoke from inside a mission, it must run inside the server context.

Ah, perhaps. But even if so, that's no excuse for DML to work that way. I thought I added code to remove leading and training whitespace, and I hope to have it in place for toworrow's (planned) update Good thinking - but as of version 3 of raise flag, persistence is supported for raiseFlag and it knows if and when to fire on reload - so you only need one version.

This is a truly odd one. There is a trailing blank at the airfield's "ownedBy#" attribute. It seems that this is something that some attributes don't like, and therefore do not register as an output. If you remove the trailing blank, it works. I'll try and see if I can guard against this in the foundation itself so that this silly oversight will no longer matter.

That is true. I can't check before the mission starts. If you want a convoy to start at mission start, I think that the best way to do that is use a raiseFlag that runs 0.5 sec after mission start. Indeed. That is default module behavior. It seems you want to exploit a particular implicit setup that may result in a flag change at mission start-up, but does not. I strongly recommend that you always make these things explicit - for example by using raiseFlag.

I did indeed - thank you. I did not see a question to answer. Always remember that I'm not a native English speaker, so a direct approach using small words helps silly me to better understand. And according to the most important person in my life, I "don't understand obvious hints to do things", I'm just a silly male.