cfrag

There are also "hoverAlt" (maximum altitude for hovering, 40 meters) and "hoverDuration" how long to hover inside the radius and alt for a winch rescue) to play with.

Can you perhaps post a screenshot of the entire csarManager definition bar (right-hand side) so I can take a look? Wait... what do you mean by 'pick-up' radius? The radius where you hover and winch? Yes, that's a different attribute indeed: It's called "hoverRadius", no quotes, and again you specify the radius in meters

I found that DCS is quite terrible at loading (I'm assuming you are running the MT preview for VR). Meaning: you'll need to keep it running for some 2-3 minutes after you start the mission until it becomes stable. You can try and offload some of the work to other threads by starting the game as multiplayer even if you fly solo. But yeah, having the server handle the strain (especially for the Sinai and Syria versions) takes some of the performance issues away from your machine. It's one of the reasons I'm now renting a dedicated server (from the kind folk over at Fox3) for most of my DCS playing. And I'm about to throw in the towel and upgrade my GPU - in DCS, once you go VR you can never go back - and that is especially true for rotor heads, so we are doubly afflicted and affected

"Logistics" as in the form of warehouse data? Not yet - the persistence framework can do it easily enough, but I have not yet started work on DCS's warehouse API integration, as it looks like a (terribly bad) joke in its current form to me. I'm sure the fine people at ED will release something resembling a real API and that contains some real engineering in the future, now that we have some meaningful cargo modules ready to go (and others coming).

Usually, when this happens, there is s slight misspelling in the flag names that you are using to trigger the saves, or you are missing the "?" and "!" in the attribute names (you should get a warning on mission startup in the latter case). After you checked for typos and still can't get it to work, simply post screenshots of the config zones for persistence, unitPersistence and radioMenus.

My apologies for being obtuse. I developed this mission so you can run it yourself (as single-player) or host it (local or dedicated) so you can play it with your friends any time that you like. You can freely download the mission (in its Caucasus, Syria and Sinai flavors) from ED's user files (just follow the link in the OP). That being said, you can occasionally find the mission hosted on my development server ("cfrag's DML Testbed") if and when I'm performing maintenance or feeling like taking a spin myself (I really like these missions myself, even if I authored and tested them to death). Usually, though, that server hosts some other mission I'm stress-testing (Expansion, COIN, Firestarter etc.) for release to public later. Some tests are open to all, some are closed. So, should you feel the urge to rescue some souls, download the mission, and run it. If you have downloaded the mission, all you need to do is open it in mission editor and: click on the trigger zone "csarManagerConfig" (you may need to show all trigger zones first). It's color-coded yellow You will find a sort of spreadsheet list of 'attributes' with their values (eg "addPrefix" -- "no"). Click on the ADD button below the list. A new line will appear with a name "PROPERTY_?" and an empty value. Change the "PROPERTY_?" (with ? being some number) to "rescueRadius" (without quotes) and enter a number like "5" (no quotes) as value. The value is in meters (we don't do silly units in DML ) That's it. You now set the radius in which your helicopter's center of gravity must land in relation to the evacuee to perform a pickup to 5 meters. You may find that a bit too close for comfort (I believe in Angels it's currently set to the default 70 meters), so experiment a bit.

Having LOS in DML isn't very exact; it takes the unit's location ("center of gravity", but the 3D model's origin in reality), and plots a line to the zone's center point. If that view is unobstructed (a DCS API test as provided by MSE via land.isVisible() ), you are good to go and call in the strike. Since trees, houses and objects are not taken in consideration for these tests (per documentation), it should work for the Kiowa. Since I suspect that the AI can see you through trees and houses as well, that good feeling may be short-lived, though.

Unfortunately, DCS is very inconsistent with this, so I'll try to be more clear about this: When you place units on the ground, that defines their first waypoint. It is also sometimes called "Initial Point", waypoint 0, or (since Lua starts counting with "1") waypoint 1. This will cause confusion. I call the initial waypoint "Waypoint 1" because I look at groups from a scripting perspective, and it is always designated Waypoint One in the miz itself (for the simple reason that Lua starts counting indices at 1, not 0). So, the Initial Point, the point where a group poofs into existence is "Waypoint 1" to me. In ME, it will be called "0", which is really, really unfortunate as we'll see. If you then add a waypoint to tell the group to go somewhere, you add a point to the Initial Waypoint. Unfortunately, in ME this new point, being the last in the route, is unhelpfully called "Waypoint 1 of 2". On the Map they are numbered "0" and "1". Witness a masterclass in bad UX: Normal people start counting with 1, not 0 -- starting with 0 is a typical coder thing, especially C coders; forcing your customers to adopt your way of seeing the world is a classic Ux blunder that was common in the mid-70s to early 90s of the last century. More baffling is that Lua (which starts counting with 1) also internally numbers waypoints starting with 1. Here is the route of two waypoints as it is written inside the miz: ["points"] = { [1] = { ["y"] = 644480.31803998, ["x"] = -282677.0446673, ... }, -- end of [1] [2] = { ["y"] = 645178.98325343, ["x"] = -282234.55669878, ... }, -- end of [2] }, -- end of ["points"] So, it's a complete mess, and I'm not helping. When I say "Waypoint 2" I mean the second point in the list, which is the first point that you added after putting down the group, and that is called "waypoint 1 of 2" if there are only two waypoints in the list. The point after the initial point. The point called "2" in the Miz.

Thank you so much for the headsup. There's a lot I'd like to know, and any clues that you might be able to provide can help. So here goes: What do you mean by "crash"? I know that this sounds silly, but it makes a difference. Does the mission throw up a dialog with a stop sign and some text? If so, I'd love to have a screenshot. That would be the single best clue I can have to locate the culprit. So, if the error can be forced in single-player, make it surface, and take a screenshot. If the mission simply becomes unresponsive, the issue becomes less clear-cut to identify An obvious question: did you in any way modify/adapt the mission to your needs: add units, objects etc.? If so, can I trouble you to try again with a vanilla copy of Expansion? Also: are you running any mods with DCS? For example Blackhawk, A4 etc.? Olympus or some other helpers perhaps? Do you have server extensions running (obviously, I expect you answer with "yes, dummy, I'm running stopGapGUI on the server."). Please remove all but the recommended Before you run a test, please remove the saved data file and folder, so we can start fresh, with a defined, common starting point Thanks for any help you can give me in this

Ha! I knew there was something off in the docs. Thanks, I will try and make that passage more clear In theory, yes. In DCS, however, persistence is a far cry from that, and you need to design the entire mission around that 'sorta-like persistence' concept that DML is struggling to offer: Ground vehicles reset to the spot that they were persisted, but immediately ruin into issues if they have more than 2 waypoints - because the are heading to the second waypoint (that's the way DCS works, no way around it). Late activated units - well, you must make sure that you preserve the flags that trigger them, or use cloners instead. Aircraft - well, let's just say that there are reasons why I used such a peculiar phrasing in the docs: if you persist ME-placed aircraft, after loading a persisted unit, remember that time is reset to zero (no way for scripts to change that), and that aircraft start at their initial point, so DML persistence isn't helping much here - it's a crutch that may help a liiiitle bit to tide us over. That being said, I have very little faith in ED's ability in bringing us "true" persistence where you can save a mission at one point, and continue it later like in other games. If they do (and I sincerely hope that they do), I find it highly unlikely that these missions will be backward compatible with what we have now. But I digress. Unfortunately, you need to design your mission with DML's persistence limitations in mind, and if you do that, you can enjoy a modicum of continuity after you save and restart the mission. Those missions still can be fun because - DCS

This is awfully complex, I believe you are overthinking this. Is there perhaps a simpler way to describe what you are trying to achieve? It sounds as if what you are trying to do is pick a random flight based on from where a player unit originates. Using a Valet zone can probably take care of that, right when the player slots in, triggering an RND to choose from a list of enemy flights. Methinks that can be simplified to a single RND per airfield, activated by the valet. What do you want persisted? To me it feels as if I do not fully understand what you try to achieve with this mission. What is the central thread or essence of the mission? What defines it, allows you to tell at a glance where it has progressed to? I think things will become much easier once that we have worked that out.

That is correct: SSB on the server implements the slot blocking, but only for multiplayer because it is server-bound. Slotty implements it (by kicking you an instant after sitting down in the cockpit) even in single-player, and also multiplayer if SSB isn't present on the server. Slotty and SSB (server) like each other and compliment each other. ssbClient provides the required logic that tells ssb and slotty whom and whom not to block. This only happens if you have another module added to the mix. By DCS standard rules, an airfield stays with the last faction even if all units leave and no other faction units are near.

Thank you for asking - it looks like I really have to rework some passages of the manual. Here's the excerpt from the relevant chapter in the manual: 5.4.10.1 Description ssbClient provides automatic slot blocking for aircraft that have their starting location on an airfield/FARP that currently belongs to the enemy (optionally neutral as well). This is a dynamic feature, and when an airfield is captured, the aircrafts based there change availability (free or blocked) are on an airfield that is “closed”. ssbClient provides DML watchflags/Zones (and a script API) to open/close airfields (optionally) aircraft that have crashed (a ‘single-use’ feature to prevent crashed aircraft to be re-used). This option provides a “re-use after” feature to allow access to the crashed aircraft slot after some time (to simulate replacement). Note that the module ssbSingleUse provides a better, more flexible support for this. Note that a mission that enables the “single use” feature requires that the host first disables SSB’s automatic “kickReset” option. Any player group that you wish to be blocked from spawning until the airfield belongs to the correct side must have the group's first player unit placed on the ground (i.e. "Take off" with one the following: "From Runway", "From Parking Area", "From Parking Area Hot", "From Ground Area", "From Ground Area Hot") within 3000m of the airfield's/FARP's center. For this reason, I recommend that you only use single-unit groups with player (client) planes. Automatic Slot-Blocking /-Enabling on Capture Slot blocking and enabling is fully automatic. ssbClient manages all airfields and FARPs by their owning faction. If an aircraft originates from an airfield/FARP, the slot is blocked if the airfield does not belong to the same faction enabled if the airfield belongs to the same faction you can allow neutral fields to count as allied to both sides (using the allowNeutralFields attribute in the config zone). In that case all aircraft on neutral airfields are enabled. If a neutral airfield is captured by either side, the other side loses access to that airfield If a slot is blocked, a player can no longer use that slot from the change role dialog. I'll see if I can phrase that better in the next release.

Why would you want to do that? If the airfield is taken by the other faction, ssbClient handles it transparently, without having to be told. If an airfield has blue slots and red takes the field, the blue slots get blocked. That's the module's main job. There is no need to tell ssbClient anything. It just works (well, DCS tells ssbClient that the airfield was captured with an event, but I like to keep some mysique in my modules ) Whoa. That will only happen if there are also blue ground units inside the zone. So, the miz starts up, with red owning the airfield as set by ME. All blue slots are blocked by ssbClient. By what I understand you narrate, there are red and blue units inside the airfields capture zone (2km radius). The ownership stays with what it was set to in ME (red), and although it is contested (red and blue units inside cap radius), it remains with red. Now that you move the last red unit outside the cap radius, DCS (not DML) gives the airfield to blue, and ssbClient module notices: red slots get blocked, blue slots are opened. Now that would be a bug. Can you send me a short miz so I can re-produce that and remove the bug.

There is a big difference between "late activated" units and "dynamically spawned" units. Late activated units are units that are placed with ME and therefore the mission knows about when the mission starts up, and are contained within the 'miz' file. Dynamically spawned units are units that are spawned by scripts. Persisting late activated units isn't required because they will be allocated when the mission starts up. The unitPersistence module will then proceed to remove those units that it knows were destroyed when the mission was persisted. That's quite easy. What may cause your mission headache is the fact that late activated units need to be activated, and DML does not know if a late activated group ever was activated. So a persisted late activated group may end up 'present, but inactive/invisible'. To take care of that, ensure that you also save the state of the flags that you used to activate units. It would seem that I completely failed you to properly convey what persistence and unitPersistence do, my apologies. Can you point to the relevant parts of the docs so I can revisit them and be clearer about that? Thank you so much. I'm lazy. Expansion uses 100% DML persistence, nothing else.

I believe that your current approach may be slightly over-engineered. To accomplish 2. and 3. you'd use ssbClient in its default state. It automatically blocks aircraft from being started from airfields that do not belong to the slotting pilot. If the airfield is captured by another faction, all slot stati are automatically re-calculated upon capture. Since old-school SSB requires multiplayer, you'd also add 'slotty' to enforce this for single-player. Slotty and server-based SSB cooperate nicely, To accomplish 1 you'd probably want to use persistence and unitpersistence. You may want to allow 10 seconds to pass in mission time when the mission starts up from a save to make sure all slot blocks are in place and are enforced.

I've only taken a cursory look at the miz, and not yet found the time to test. Just out of curiosity: what are you trying to achieve by both SSB closing an airfield and using an airfield zone? If red caps an airfield, blue won't be able to use it, why do you also close it? I'm sure that there is some deeper idea behind this (prevent dynamic player spawns from that airfield?). The issue here may be that synchronizing the events can become difficult and lead to a race condition (blue capture before opening blue leaves that planes on the ground locked), and I'm not sure that the modules trigger correctly on all capture events, which may requires some sequencing (events that happen one second after each other using the sequencer module or similar). Also, I think that having that owned zone that triggers the events inside the airfields own capture radius is asking for trouble - we now have multiple sources for cature contest with each other. Can you move the triggering owned zone outside of the airfield's 2km capture radius? So before I go into deeper analysis: what are you trying to achieve with this construct?

No, it hasn't, but I have not yet found the time to look into it. I will, over the week-end at latest.

Understood. You can't "call flags", though. Flags are merely memory locations that contain a number value. There is no method that gets implicitly invoked if/when a flag's value changes, you have to poll flag values yourself.

Unfortunately, due to the fact that you are using DoScriptFile instead of "DoScript" it is impossible for me to trace the bug to its origin, While I'm absolutely prepared to believe that ODD is the culprit, there is no line 150 in ODD that invokes getName(). I've hardened on your suspicion ODD against the Jul-11 and Jul-22 DCS bugs (see below). Does this new version make a difference? Cheers, -ch objectDestructDetector.lua

Currently all Owned zones in the theater are considered, and the units are made to go to the nearest enemy owned zone, even if they have to cross the map for it.

I think the best approach would be to walk through the code and explain why you would expect it to invoked more than once -- that usually helps me. Below I've taken your code, slightly simplified and formatted it for my legibility -- do removed local function GlonassWP1(Argument) -- Arguments are not into code, only info! local path ='W:\\DCS\\1. Mission Editor\\Su-25A\\SYRIA RUSSIA V00\\HDG_COURSE_WP1.lua' assert(loadfile(path))() trigger.misc.getUserFlag(GlonassWP1) -- <-- what do you believe that this line does? if trigger.misc.getUserFlag(flagNameWP) == 1 then -- <--where is flagNameWP defined and set? timer.scheduleFunction(GlonassWP1, {1}, timer.getTime() + 0.5) -- Reschedule the function to run again after 0.5 sec end end timer.scheduleFunction(GlonassWP1, {}, timer.getTime() + 1) -- Loop will start at start condition +1 secs --(missing 'end' to conclude do here, leading 'do' removed) Frankly, I'm slightly surprised that above executed even once, there's a missing 'end' to 'do' that I think Lua glosses over by not enforcing it for do..end. So, you invoke a timed GlonassWP1 once, one second in the future. It runs, and then terminates, just like the code suggests it does. There are two questions: trigger.misc.getUserFlag(GlonassWP1) What is your intended behavior with this? It immediately reads the value of the flag that has the same designation as the address of the table entry for the local function GlonassWP1 that you defined above, returning the number 0. It does not invoke the function. trigger.misc.getUserFlag(flagNameWP) Where do you set the value for global "flagNameWP" that is read? If it is undefined, the value that is returned is the number 0

That is unfortunately a result of DCS's internal runway handling and the reason that I had to add the ungainly 'left^' and 'right' attributes to a TDZ. You may have to experiment with them and create two TDZ for the same RWY, one left and one right. One of them will be 'wrong' (inverted).

My apologies for being unclear about this. I'll try to make this easier to understand - in my defense, I'm not a native English speaker, I tend to speak in riddles . Here's the relevant passage from 5.3.29.1 - Description in the "Shock Block" under DESIGNATING OBJECTS/UNITS AS DELICATES This implicitly means that even if the zone moves after mission startup, it will not add new units/objects to the set that was determined at startup.

I have plans to bring expansion to other maps as well (most probably Syria). I'll wait a little bit longer to allow all your kind feedback to settle, and balance the mission. Once I feel comfortable that Expansion has matured to be fun, I'll start the process of bringing it to other maps as well. Expansion currently represents the high watermark of my mission creation abilities. I did not get there in a single step, ED's user files are littered with less ambitious and (probably) much easier, smaller-scope attempts of mine at this concept. "CnK" is one of them, and before that came 'Pushback' (of which only "Pushback Caucasus" and CnK are current, the other -- Syria and SOH -- require updates to work around the past three unsavory DCS patches).