cfrag

Have you tried it?

Until ED restore the expected functionality of the KILL event I see no other way, yes. I have filed a bug report in the relevant forum, so let us hope that someone sees it and reacts.

Thank you for sticking with this issue. A few more questions and comments: What do you mean by 'commented out the two lines'? Did you remove the DOACTION for persistence and unitPersistence? That will indeed remove persistence from the mission entirely. I followed your kind advice and re-created this. I was unable to observe any crashes. That is about what is to be expected, DML (the foundation the Expansion is built upon) works that way. It will automatically also shut down the 'income' and 'camp' modules. Net result should be that your side starts without funds, and no longer can work with any funds. Just like you state, it leads to an error dialog from the xpStrat module at start. The main mission script shuts down, and no AI is scheduled (you'll receive no objectives, no enemies are launched, no allies launch). Expansion has become a shell, no units are spawned by the mission. While I can't 100% rule out a bug in bank nor income, I'm currently leaning against that hypothesis after extensive testing. The persistence modules have no open issues, and neither do 'bank' nor 'income'. A stress test over the week-end I conducted cannot reproduce the issue that you kindly reported. To try and make this issue go away, can I ask you to ensure that you have removed all mods run a full repair on DCS The pattern and symptoms of the issue that you are describing (isolated nature of occurrence, crash to desktop instead of an error dialog) IMHO points to a cause outside of the mission's scripting. It can't be ruled out, but I have been unable to re-produce your issues. After a full repair of your DCS installation, and removing all mods, what do you observe?

The servers are back! At least they were today. And if you head over to my "cfrag's DML Testbed" (dedicated server hosted by the kind people at Fox3) you can help stress-test a firefighting (alas, not bambi-bucket) miz -- my own imagination of helicopter firefighting.

It seems that some static objects, when killed DO receive a KILL event (that allows tying a unit to an object's kill), while other objects, on being killed only receive a DEAD and UNIT LOST event, but no kill event. Worse, there is no usable HIT event that would allow a script to connect a DEAD/LOST event to the launching unit because the HIT event does not carry the relevant information. From what I can gather, this seems to be connected to the category of the killed object: Ground Vehicles seem to receive a KILL event, while at least some structures and warehouses do NOT receive a kill event. Not being able to trace a kill to a unit is a severe impediment for creating many interesting missions. In the attached demo, destroying the static vehicle on the runways does create a kill event, while destroying the other three structures/warehouses does not. All hit events return nil targets (why?) object scoring test plain.miz

It looks as if there is no way that you can tie SOME kills back to the aircraft that originated the weapon because inexplicably, for some objects there is no 'KILL' event when they are killed. Worse, even though the API documentation CLAIMS that you should be able to tie a hit of an object to a unit via the HIT event, unfortunately that is not true. If it did, I could try to thread the needle and tie a weapons hit back to whoever dropped the weapon. So it looks like for the time being, destroying SOME objects with bombs cannot be tied back to who killed them - the KILL event isn't invoked for SOME objects (it is invoked for others, very strange -- it may depend on the killed object's category: ground vehicles seemingly receive a kill event, structures and warehouses seemingly do not). We get two generic 'DEAD' and 'UNIT LOST' events for those objects that do not carry the required data to tie a kill to the killing unit. Very disappointing; very, very inexplicable why ED would overlook something as fundamental as that. Here's to hoping that ED can arrest DCS's API quality decline soon.

You mean that the displayed text is too large in VR? I think (but I'm not sure) that this can be set in your options screen. This is not something that a mission can change.

My apologies, there must be something lost in translation. I do not understand the question.

Either disable stopGap in the miz, or run 'stopGapGUI' on the server (need only be run on the server). The exploding and dropping aircraft are a result from a DCS synchronization bug.

I'm afraid that you'll have to be more specific than that - this is a great topic, and very, very broad: Kill count - for players only, or also count AI kills, count kills per side, per (aircraft) type (flown and killed), do killed ground units count as well, pvp only, pve only? Persistence - Should the count be saved to disk so that next time that you run the mission the past kills are loaded and then amended Display - what do you display, and what do you aggregate? Scoring/Weighting: Does killing a Su-27 with a Kiowa count more than killing a Huey with an Eagle? If so, by how much? Balancing: In a similar vein to above, does killing an ace (with many kills to their name) count more than killing a noob? Does killing an aircraft that's still on the ground count (thereby incentivising airfield camping)? Does the weapon used for killing make a difference? Gun kills vs. Missile? Does it matter if there are many more blue players vs only few red, and if so, how? Cross-mission - Should the kill count extend past a running mission to other missions? Other considerations that may be good to clear up - how do you count fratricide? - what if a player changes sides? Oh - and finally: be advised that no matter how you implement your score board, there will be others who don't like it

Agreed. So it was just an inflationary use of words to replace 'nice'.

Apologies, but I can find nothing wrong with how it works. When I kill the static car on the runway cross, I get 100 points just as intended. object scoring test.miz

While I agree that it would be a nice gimmick that I'd probably use once, maybe even twice, I'd like to know what makes a nice-to-have side show such as walking to your aircraft prior to a flight an "extremely awesome epic thing". It's not that we would find something wrong with the plane. It's not essential for the simulation. IMHO it is likely going to be something that most (99.9% of all casual pilots who start hot) will skip after they did it a couple of times. I get into the plane to fly it, not to spend a couple of minutes to walk to it. Sure, wish list and all, and I will support the idea, the more the merrier. But when I think of "extremely awesome epic things" that are perhaps ornamental, I'm thinking along the lines of tarmac/ground/tower/ATC control, smart AI ground and airfield traffic etc.

ED have changed a lot stuff surrounding the "dead" event. I'll see if I can track this down, thank you!

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.