cfrag

This may help. Look at the "BombersBhere" trigger zone for details. Random Bombers Inbound.miz

Bullet. Tracer Bullet.

Version 2.2.2 - 20240418 - Maintenance Update A few days ago, the DCS community suffered a tremendous loss: mission designer and contributor @Dzsekeb decided to quit the DCS mission design community. For those who don't know him (you shall be pitied), Dzsekeb is the author of the wonderful "Foothold" and "Pretense" line of dynamic missions that are phenomenally popular: they are fun to play and very multiplayer friendly. I'm hopeful that Dzsekeb will find his way back to DCS mission authoring some sunny day. Since that day I have received a number of questions/suggestions: could I perhaps chip in one way or the other to maintain Dzsekeb's legacy. There are multiple responses to this: Heck No: I fully respect, and comply with, Dzsekeb explicit wish that people do not publish work derived from his Pretense and Foothold missions. So I will not mess with his code, nor will I create missions based on his code. Maybe: I'm currently exploring a dynamic mission inspired and based on the spirit of Foothold. The game concept that Foothold and Pretense pioneer is fun. It is with this game concept, and of course a deep, respectful bow to Dzsekeb, that I'm currently looking into creating a mission that builds on Foothold's premise, with similar elements, and some new ones. That is why this DML update may feel a bit strange: many modules have received tweaks, and those tweaks seem random. They are not - they are a result of my tinkering with big-scope scenarios and geared towards further integrating modules into a greater whole. There are a couple of new modules as well that are geared towards larger strategy components. It's very early in the game (huh, a double entendre!), so now is not the time to explain what they are for. Maybe I have something to report in coming weeks or months. If I succeed, maybe there will be a new mission that can do justice to "Foothold" in spirit. But even if I don't, one thing is clear: the amount of work that Dzsekeb put into Foothold and Pretense is phenomenal, so let us be grateful for his contributions to our community and hope that he'll return to contributing great missions. Thanks, man! To the rest of us: Keep our fingers crossed. Changes In Detail Documentation Main - additions to ownedZone - additions cloneZones Quickref - same as above Demos - none Modules - autoCSAR 2.0.1 - small fix for coalition bug - bank 0.0.0-- - new module (experimental) - camp 0.0.0 - new module, experimental - cfxZones 4.3.1 - new QOL methods - cloneZones 2.2.0 - new damaged! output - new health# output - csarManager 3.2.7 - small QoL additions - dcsCommon 3.0.5 - small additions for table/string handling - factoryZone 3.1.2 - fixed verbosity bug - FARPZones 2.0.0 - dmlZones update - groundTroops 2.0.1 - small fix/improvement for pileup resolution - heloTroops 3.0.3 - improved insertion pointInZone check - inccome 0.0.0 - new module (experimental) - milHelo 0.0.0 - new module (experimental) - owned zones 2.3.0 - upgraded logic to inclide airfielfd and FARPZones - zone-local numCap - zone-local numKeep - new title attribute - code clean-up - playerScore 3.2.0 - integration of other modules Enjoy, -ch

For better or worse, a good deal of this probably has to do with the fact that documentation around all things DCS mission API has room to grow. Now, what may be confusing you are two related functions that return things that look very similar, sound very similar, and used radically different. This is further made difficult by the way that they are implemented in Lua, as Lua is a very clever programming language that can lead people like me to believe that they themselves are clever. Let us start with the vec3 that you mention. Now, if you have done any vector algebra, the common use case for a vec3 is that of a 3D vector. If your eyes just glazed, here is a more detailed explanation. A "vector" in math is a construct that has a size (called "magnitude") and a direction. One very common representation of a vector we use is one that has 'coordinate offsets'. If you, for example, play Chess, you will notice that there are numbers from 1 through 8 and letters a through h along the side, allowing you to identify each and every field on the board uniquely by their position (offset from the origin). So the field in the bottom left corner would be identified as "a1", and the one in the upper right corner as "h8". Math takes this concept and makes it a bit more general, and uses number for every 'axis', so position "a1" becomes co-ordinates [1,1] and "h8" becomes [8,8]. When used with maps, we use the same principle, and can identify each position on the map as an offset to the 'origin' of the map - the point who has the co-ordinates [0,0]. Since we are talking about math, they love abstraction, and we can apply this principle not only to 2D maps, but also to more "dimensions", for example by adding height to a map, and suddenly every position is identified by the point on the map and the height it has - by three coordinates. And what points to this point from the origin of this system is the vector. One form of presentation is the vector that contains the offset for East/West, one for North/South, and one for Height. Which part of these co-ordinates is used for what is up to you (or the one who defines it, here ED and DCS) DCS can be a bit difficult here because it uses a non-standard description for points in the world, and to make matters worse, it uses two different ways to represent this. One for points on a 2D map, where we use 2 coordinates, one called "x" (used in DCS for North/South) and one called "y" used only for maps to indicate East/West. That is often represented in the "vec2" data type. So we often have a vec2 implemented in Lua as {x = 123, y = 456}. (See Lua notes, below) When we talk about points in the game (not just map), we need 3 coordinates, and DCS often uses the representation {x = 123, y = 456, z = 789}. Now, be aware that the context for y and z has changed: y now is height above ground, and z is the offset east/west So, for most intents and purposes, when you deal with a variable "myVec" that is of type vec3 in DCS Lua, you are dealing with a table that has at least three attributes: myVec.x, myVec.y, myVec.z. Now, since this is Lua there are a number of important caveats: a table if type vec3 can have more attributes than just x, y, and z the type of the attributes x, y, and z should be a number, but it can be many different things, for example another table (as we see later) or string. So, when we look at a standard Lua method to get a unit's 3D position while the mission is running, we invoke myPoint = myUnit:getPoint() and that returns a vec3 into myPoint with myPoint.x, myPoint.y and myPoint.z containing Northing, Height, and Easting, respectively. This is mostly standard, except for the Lua caveats, and the somewhat funky assignments for x, y and z. Now, you are surprised that sometimes you get something different. I know of one place where you may get thrown by this, and that is if you invoke the confusingly named "Unit:getPosition()" method. Although the name implies that you would be receiving the position of a unit in the game, a very close inspection of the description of the method shows you that you do not receive a vec3 as return value, but a construct called "position3". Now, to be absolutely frank: there are few worse ways imaginable to name both, because: getPosition() does not return a position position3 does not have 3 but 4 attributes three of the components confusingly are named "x", "y" and "z" but they are not numbers but vectors themselves. The thing to take home here is that getPosition() DOES NOT RETURN A vec3. It returns a position3 type: a vector comprised of 4 (not 3) NON-NUMBER elements. The position3 "vector" us used to describe a very important element in physics, it describes a state: where something is (a vec 3 describing a point), and how it is oriented there (the directions of its "up", "left" and "forward" in the "world"). Few people ever use the orientation values. You can use part of it to derive a unit's heading and velocity vector. The 'where' part is what you are looking for - it is the same vec3 that you would get if you invoked Unit:getPoint() So, your confusion is probably caused by some very unfortunate naming from ED/DCS, and a severe lack of good documentation. In a nutshell: a vec3 is a Lua table that usually contains the 3D offset of something from the local origin (the location [0, 0, 0] in its "x", "y" and "z" attributes. The getPosition() method DOES NOT RETURN A POSITION and does not return a vec3. Don't use this method unless you absolutely know what you are doing, and are aware of the fact that it does not return a vec3. Hope this helps a bit clearing this up. You have been misled

... which really is a bummer for many other possible tutorial scenarios that I would love to write that involve formation flight or anything team based. Yeah, and I would love to be able to control those helper gates in MP as well. There's a lot of room to grow for DCS API I guess

That's where an event loop can come in -- you'd simply subscribe to user cockpit events, or trap them in a more rustic event loop. Hey, it's even doable with today's architecture. Imagine an event id 'cockpitInteraction' with initiator the unit of the player who flicked a switch or changed a setting, and a control id for which control changes, and a newVal that tells us to what it changed. Not great (because that controlid is going to be headache central unless truly engineered to work the same across all units that players can inhabit, present and future), but reasonably doable.

Although it could indeed be, it could also be a nightmare. Looking at the entire "X" action tree (and many others) it seems all too apparent to me that very little engineering has gone into API design, with most functions seemingly being added or retro-fitted ad-hoc The "X" actions are often model (plane)-individual, and can only work in single player (which is exacerbated because there is no "I" or "me" for clients). trigger.misc's branch is used to get flag values, yet the trigger.action branch to set them? For a fun experience, set a flag to a string... textOutToUnit and soundOutForUnit do exist, but there is no missionCommand.addCommandForUnit to mirror it. Oh, and there is a trigger.action.addOtherCommand which seems to be an instanced, limited version of missionCommands.addCommand(). This IMHO does not bear the hallmarks of design. I'm hoping that there will be a complete overhaul of the Lua API in the future, with real accessors and setters (how about: unit:setFuelAmount() - I'm dreaming, I know), and an event handler designed for that purpose (that also allows us to post events). And here's a radical thought: maybe give us an event loop - you know, like applications started having in the early 90s of the last century.

If you assemble a complex group of ground units (for example set up a SAM site) that contains different Categories (for example 'Unarmed' for the resupply trucks and "Air Defence" for the Launchers and Radar), changing the Country (say, from "Combined Joint Task Forces Red" to "Combined Joint Task Forces Blue") will incorrectly change the group so that ALL UNITS NOW ARE FORCED TO THE CATEGORY OF THE FIRST UNIT. This will, for example, result in changing the resupply truck (cat Unarmed) to a FLAK 8.8 cm (cat Air Defence) if the first unit in the group is an Air Defence unit. People unaware of this, and who are changing the country of large, complex groups will often not see this change, and can ruin a lot of effort with a single click that should not result in these highly impactful changes. It is 100% reproducible.

Two things can be true at the same time: people could know that using mods would offer them a much better experience, and they still can be unwilling to install them. And you are preaching the choir, dear Elphaba. All of is here know phenomenal mods that are available and how much better our missions could be if we used them. And we all know the hard truth: using any mod in our mission reduces the number of people who play them. It's heartbreaking, but undeniable fact. We, as mission designers want our missions to be played, so we cater to our audience and do not include them. Your frustration is palpable, my friend. Your arguments are well received, mostly agreed, and we all dream of the day we could use mods. Today, unfortunately, is not that day. In my experience, trying to force other people to see the light seldom brings the desired results. So my recommendation for you is to perhaps relent a little in this regard, lest it breaks your enjoyment of DCS. Because that is why we are here.

My experience is that if you need logic or reason to convince someone on a convenience issue, you probably have already lost. While you may have all the logic arguments on your side, many people simply don't care if that means even the tiniest amount of effort on their side. For an outside perspective, look at cars. While many car enthusiasts will tell you that (at least until a few years ago), gear shift cars were superior in control to automatic (and they were objectively right), that made little to no impression on those who prefer automatic. That's because automatic drivers look for different things in cars than enthusiast. DCS is the same. Many people who install mods look for something in particular, something that those who do not simply couldn't care less about.

As soon as you use a third party configuration organizer/tool I think that you have crossed into 'specialized, hardcore' player area. It's definitely no more 'Joe Normy' country. Look at it this way: which other apps (outside a Linux/*ix distro) require that you install separate, third-party file organizer just so that you can use it? And what does that say about the app that requires it? So yes, my observation (based on an admittedly tiny cross-section of personal feedback) is that having to use OVGME or similar is a major disincentive to run a mission. Most people want 'simple' and eschew anything else. YMMV.

While I believe that I've read somewhere that Masada will eventually be coming to this map, there is a geological peculiarity of that region that runs up against DCS's terrain engine. Masada, as you probably know is is an ancient fortification in southern Israel, situated on top of an isolated rock plateau and rife with some heroic history (and no happy endings). The problem here: although Masada is atop of a mountain plateau, that plateau is only 60 meters (180 feet) above sea level. The entire surrounding area (dead sea and land) is 400m below sea level. DCS currently can't correctly model terrain below seal level - it shows those areas as water. So Sinai currently puts the surrounding terrain at close to (but still above) sea level, and the Masada mesa currently is more of a Masada molehill. Hopefully, ED's terrain engine will eventually be updated to account for terrain below sea level, and then we can have a Masada in-game that correctly reflects its forbidding, brooding real-world presence. And allows us to properly explore the dead sea's Jordan Rift Valley.

If it were an abstract map of an inexistent place, perhaps. Still, we'd want some recognizable landmarks there to orient ourselves, and unique buildings serve that purpose. I remember way back when I was playing an FPS game called "Unreal Tournament" that had custom maps. One was called "Deck 16". Great map, synthetic. There was another map, called "Louvre". It was based on the real place, and it was fun to battle between re-enactments of the exhibits and through the corridors of a maze built upon the real place. For better or worse, these 'reality based landmarks' make me enjoy a map more. Since Sinai is a real place, having landmarks based on, and located at, their real-world objects adds some je ne sais quoi to the map, makes it more enjoyable to me. Now, when you are in a whirlybird (and I often am), it also makes VFR navigation around those landmarks much, much easier. Yeah, but in that game I can't get jumped by some Insurgents in need of forceful persuasion. And have you looked at the quality of what may be coming soon? Breathtaking. Now, let's all hope that the fine people at @OnReTech heed the Jobsian proverb: "real artists ship". I'm really looking forward to the next update and am happy that ORT found the time to post a sign of life here.

At first I didn’t. Got it when it came to steam, didn’t like it. It simply didn’t click with me, and many things I couldn't get to work for me (I felt that ME in particular, was actively resisting my efforts to get anything done). Then I got my first module. Yeah, the Hawk. That didn’t help either. i tried again a year later or so with FC3. That made me delete and ignore DCS for another year or more. i only got into DCS again because of its superior VR support. Then it grew on me.

IMHO I think that is - especially for DCS neophytes - the main stumbling block. Out of the box, DCS's user experience simply can't be called "good" nor "modern". For a new user, nearly everything in DCS becomes a fight. Imagine that you download DCS, install it, and start it for the first time. ... and then? Nothing tells you what to do, no guide, nothing. "Fresh" DCS comes with the T-Frogfoot and T-51. Neither of which you can fly out of the box - unless someone tells you how. Well, maybe you can get into an Instant Mission, and then you run into the wall of setting up your gear. Fine, that's expected. There's no flight sim worth its salt where you don't have to set up your gear. DCS's way, however, is, uh, an acquired taste, I guess. It definitely can be improved. No matter. We are in-game, and our gear is set up. Now what? Hey, that plane's avionics talk Russian to me. So there are a billion ways that DCS can be improved, and missions (e.g. tutorial missions) are one way that mission creators can help. And that's where we hit the next wall: no integrated way to discover missions, even though we upload them to ED's servers. Another billion great opportunities sadly wasted. So if new DCS users are brave enough to download some files from a Russian-registered server to their PC, and find the correct way to install them so that DCS can find them, these users should be encouraged. If my mission doesn't run because it requires a mod, that would only frustrate them, and they would not play the mission I wrote. That's why I try to keep it simple: no mod, no more problems (and not to disparage the incredible work other contributors have made) some mods are difficult to install. That's mainly ED's fault, and the early 1990 architecture of how DCS organizes its assets. But for a new user it's another frustrating minefield to cross. And incredibly helpful utilities like OVGME? Lets me quote the Readme: "Sadly the original developer Sedenion is no longer developing this extremely useful tool". This is not stuff first-time players want to read, it all makes a really, really bad first impression. Now, some of my missions are geared towards servers/multiplayers. With those missions I will occasionally include a mod, but only very sparingly, and usually only those that I know very well and trust that they will be maintained - that point of introducing dependencies is very well made. So, no mods in my missions for normal players, minimal mod support for server missions. Server admins usually have the knowledge (or access to people who have it) so that they can add support for their favorite mods. Now, if DCS came with built-in mod support, mod discovery and integrated mission loading from their servers, I'd reverse that in a heartbeat (and maybe even try some of these mods myself ).

It would seem that this has nothing to do with DML. Comments by ED point at changes that they made for the "Link Unit" features with carriers. As a precaution we should not use Mission Editor's "Link Unit" feature with carriers until this is fixed. There's a hotfix for servers scheduled for today, so with some luck, this can be resolved quickly.

Here's a mission that, once per SECOND (pls ignore the silly misleading name) destroys (if they exist) and then allocates 7 groups of 17 ground vehicles. This will exhaust the storage after a while (some 580 seconds until RegMapStorage runs out, which can only store 4094 entries). After a while, another table (with 65534 limit) runs out. ERROR EDOBJECTS (Main): RegMapStorage has no more IDs (4094 max) in <viColumn> and EDOBJECTS (Main): RegMapStorage has no more IDs (65534 max) in <viWorldHeavyObject> Here's the miz that reliably re-creates the issue on local server: clone once a minute.miz

Thank you so much for taking it upon yourself to answer this, @BIGNEWY. Can I trouble you to relay my opinion that many people here would love it if @OnReTech also took the time to communicate with us. They made such an encouraging start with this roadmap, only to disappoint many who thought OTR to be exemplary.

Doesn't this thread's title literally suggest the opposite?

Thank you for this very interesting and detailed analysis - it confirms what I have speculated about (and is the reason why I tend to have missions save and then re-start. I'm hoping that a mission re-start frees the memory occupied by units). I'm looking forward to ED handling this quite serious bug (a massive memory leak). For the life of me I can't figure out why you filed this important bug as a Mission Editor bug - it doesn't affect ME but, much more importantly, the game core engine itself. Great work, thank you, and hopefully this is going to be tackeld soon.

The last line is a definite hint: you are running stopGap STANDALONE, a no-no with DML as it overwrites many libraries. Please use the standard DML 'stopGap' and all should be well.

Hey, @Eeroth, that error looks very strange, and may be pointing to some scripts not being loaded. When the mission starts up, it should put out a number of lines that helps you to divine if the various modules load correctly. Do you get any error messages (you may want to check "Message History" when the mission runs by pressing 'ESC'). Also, are you sure that you have included all the dependent modules for cloner in the correct order. I'm sure we can get this sorted quickly.

It still is. Let's enjoy Dz's phenomenal contributions as long as we can. All the best from me to Dz, and a big, heartfelt THANK YOU. You made a difference, and we'll hopefully see you again!

This is a wish list, and you have come to the right place. Unfortunately, this topic "AAR Helper" is know to be irresistible for some of the, uh, more outspoken "git gud" crowd, with motivations I try not to speculate too much about. In case you haven't yet used it, there is a very helpful function available to you that can make this entire discussion (albeit not AAR) a lot more palpable: the 'Ignore' function that can tune out those whom you deem not worth your while. I use it sparingly, yet I notice that I only see half of all the messages in this thread. Go figure. So is an AAR helper a legitimate wish? Yes. Why? Because you wish it.

Strange. No issues on my end (I did replace persistence with the newest version). Then again, I do have an old version (there are multiple errors due to not including groundTroops etc, there is a second, slighty differently spelled persistence config with data for root etc, that's not being loaded.). Perhaps send me your latest version and I can investigate further. And man - that mission is Epic!