cfrag

It should say "+++persistence: mission saved to <location>". It tells you this after it is done saving. The message fades after 30 seconds. Yes? Convoy currently does not support persistence.

Isn't saveNotification = true doing that for you? saveNotification When set to true, each time that the mission is persisted, a text notification is sent to all players. Default is true (notify players when saving)

env isn't initialized inside the Lua context when no mission is running. You can either provide you own stubs if env is nil, or redirect all invocations to env through your own env patch that redefies env and only invokes env methods when a mission is running.

Thank you so much, @Flappie!

It's straightforward, here's script, explanation, demo etc. Result: *) Should say "No index 0" above The script first gets the warehouse inventory for Anapa, and then dumps the table (method t.vardump2str) Note that we have four entries into the array for liquids (side note: IMHO, whoever signed off on the idea to make liquids an array while all other inventories are dictionaries should be sent to bed without supper, and they shouldn't contribute anything to DCS until they get a modicum of design and coding experience. This is amateur stuff, even before the "brilliant" idea of using a 0-index array in Lua) The script then invokes lua2json on the inventory, and dumps the resulting string. Note that the jetfuel index is missing (or rather, one is missing, since the array only holds 3 items. I know it's index 0 because I set the amounts during my testing to different values and was able to identify that index 0 is missing). Here's the (trivial) script: And here's the miz to play aground with. As you can see, the error can be re-produced at will. Cheers, -ch t json.miz

I believe that the following question may lead you to the answer: Q: How do you known that a group died? A: when the last unit from that group dies. And that is the answer to your question: A group does not have a location, it has many units, and each of them has a their own location (in naval groups, they can be miles apart, as can be in aerial groups). So, the condition "when a group dies" could be better written as "when the last unit of a group dies". And that you can catch, by intercepting the unitLost or dead event. Now, be *very* careful when looking at dead events for ground units, because DCS can pull an undocumented fast one on you: it changes a ground unit into a static object that "cooks off". So what's the big deal? Well, a static objects has no group, and your script dies when it tries to access a static's group. So although what you are trying to do would usually be a simple thing, for people who aren't very comfortable in DCS mission scripting, it will become a very frustrating experience. What you need to do is some "threading the needle" stuff: when groups spawn, keep a table that links each unit's name back to it's group name. When you receive a dead or unit lost event, get the group name from the table (not from the object, it could be a static), get the number of remaining units in the group. If it's zero, the last unit died, and you can remove the group from your table, and place the explosion and smoke on the location of the object that just dies. It's going to be a lot of work for a simple thing. But it may be a learning experience, and even fun.

Just did, and thank you for your example miz. Answer: smoke WILL TIME OUT AFTER 5 MINUTES, so you will have to continue re-starting a smoke started with smoke() (obviously this is not required for an effectSmokeBig() ) Here's a demo miz (doesn't require mods) for the frogfoot. requires 5 minutes worth of patience. Thank you @buur again for the info! smokin zonet.miz

Thank you so much! That helps a lot. <blush> Did I miss that somewhere in the docs? Also (will check myself asap), will the smoke still time out after 5 mins when we supply a name?

To me, the big problem is that the 'effect smoke stop' action is (another) API call that's currently not available (AFAIK) from scripting for the smoke that is created with smoke(): we have no ID to reference the smoke to stop. I'll have to investigate if smoke() now returns an ID that can be used, and if it still turns off by itself after 5 minutes. Or many effectSmokeBig now accepts colors? If so, hopefully the known smoke colors, not the smoke generator (smokewinder) colors that are different - and different again from flare colors. What a mess. Methinks the DCS API downslide is accelerating.

Still intentional, I'm debugging the score module. Yeah, no need to add insult to injury. It'll still tell you occasionally, though.

-- we'll see. Enclosed please find a brand new version, for you to kick the tires. It should now correctly reflect ferry flights. In the enclosed demo, take a dynamic flight from Senaki to Kutaisi, park at ramp, then save the game via comms. Restart the miz, and the ferried flight should now be at Kutaisi. Currently set up for a Hog and Hornet at Senaki., you can curtail Senaki for your favorite frame. Requires DCS be de-sanitized. The messages appearing every 10 seconds can be switched off with the 'monitor' attribute. If you update WHpersistence in an existing mission, you should remove the old save data. WHpersistence.lua pay the ferry, man.miz

When you pass an array with a zero ('0') index, that index is not written to json when converting a table with net.lua2json. This can be reproduced at will: take the warehouse inventory from any base, and convert that to json. The liquids are defined as an array, with liquids[0] being jet fuel. Now look at the json result of lua2json conversion and see that liquids never contains array item index 0.

It took me two entire days to track some of this. At the end, I discovered a bug in net.lua2json (it can't correctly save arrays that have a zero (0) index, like for example a warehouse's jpl index), and I discovered that a warehouse's inventory API for weapons and aircraft is so incredibly braindead that it removes entries with a zero item count even if that entry was formerly present. In case you wondered: yeah, that the same as unlimited supply. Or rather, it's not documented how an airfield implements unlimited supply, and airfields with unlimited airframes have no entries, so it is impossible to tell those two apart by code. So, if you have an airfield with 1 Hog, take it and ship it to fly it somewhere , the A-10 item disappears from the originating base, and it is impossible to tell (from a script perspective) if there are no, or unlimited aircraft left for that type by getting the inventory. Whoever signed off on that API seems to be a rather low-rent help to me. Still working on it, just an update. WHpersistence will require a significant update, though.

Yes. A killed unit is no longer tracked by persistence, hence will not be reallocated.

Alright! I'm busy trying to replicate this, thanks!

Units cloned with a cloner, irrespective of their template are tracked by unit persistence They are dropped from tracking after they are destroyed, individually (I hope) After spawning from persistence, the units spawn at full health and munitions

Ah, that is interesting, thank you! I'll try to see if I can replicate that and replicate the mechanics, and see if I can detect the change in the warehouses, if and when planes get added (do players have to leave their aircraft, or are planes ferried my AI)? Are there any special conditions that I need to observe to make a flight count as a ferry flight (I assume that you need to use a dynamically spawned slot from A and fly it the B and then have the plane added to B after you exit the plane)? Is there any in-game messaging that confirms that the plane was added to the WH inventory? I can't seem to find good documentation on these mechanics.

What is your issue in detail? Also, what is your issue with team (faction?) score? Currently, there is an issue in DCS (i.e. the issue was created by a change from ED) that makes is very difficult to tie map object kills back to player. The most recent change to PlayerScore may make this work again, but I haven't yet checked yet. What issue have you run into doing that? I'm, sure we can resolve that quickly. What issues have you run into there, or put differently, how are you currently trying to score them. I believe that since PS now supports wildcard naming, scoring spawned destruction should be easy. Let's see your approach and hopefully it's just a little tweak.

I don't know, do you think it should? I don't think that it's fully documented yet, but if warehouses also keep stock of aircraft, adding WHpersistence to your mission should (may?) resolve this. The warehouse API is one of the (many) low points in DCS, and I haven't yet had the nerve to create a mission that relies on that. It'll come, I'm sure, and I'm happy to pass off the role of Guinea Pig to you on this one The important question here (since I don't know how this works) is: do aircrafts show up as available on the new airfield after you ferry them over and exit there? If now, that may be something that I can try and add as a module. What are DCS's current capabilities with this (does it already support some form of ferrying), and how would you imaginne that this works?

I believe that I corrected this (along with squashing some remaining little critters in the code). Does this work for you correctly now? playerScore.lua

Although I strongly support your wish, I even more strongly want to encourage you to not resort to 'click-baity' thread names. I only read this thread because of someone else's response. I think it's best if we make our point in the headline to help people decide if they want to participate in a thread. So, "yay!" to @currenthill's work and inclusion into DCS (although the murky ownership of IP is going to make that highly unlikely), and "boo hiss!" to this thread's subject line.

Can't find any new civ trucks either, so I'd be happy for any pointers. It think it would really help if ED could include the typeName (e.g. "MAZ-6303") for us silly mission creators to make our obviously all-to-easy life even easier. /sarcasm

Since we currently cannot influence AI or AI units in a meaningful way (except through drastic ways just like the ones that you suggested), your approach seems to be workable. Setting zero fuel should get most AI planes to have the pilots bail out and the plane plummet to ground - if that was possible (spoiler: it's not). The good old explosion(unit:getPoint(), 30) should also do it, albeit a bit more visceral. Ah, then an explosion seems fitting I think (and that does not mean a lot) that current implementation of unit AI only kicks in with that event when the unit runs out of fuel (? undocumented) or damage (somewhat documented). So, re-top up regularly so they don't run dry. The spanner in the works is of course that we currently cannot set a unit's fuel nor life. A colossal oversight for a military sim scripting engine, but that's DCS for you. It won't fail in MP. The script runs on the server, and all clients sync to the server eventually. If the server thinks that a unit is dead, it is dead and removed from all clients). It will work in MP. IMHO, the most reliable way to remove a unit is destroy(), but 'setting them up the bomb' by explosion() is a lot more satisfying, and you can probably forego the destroy() yourself (schedule a timed destroy() two minutes in the future just in case) There is the kludge approach: in the event handler that detects the unit aborting, set a named flag (I use the unit's name plus "_k" to keep this part short). Then create a trigger rule for every (messy, messy, messy!) unit that triggers on that named flag (e.g. FLAG TRUE "aerial-1-1_k") to execute the trigger for the actions (unit set life, explode). So, if you have 20 units that can abandon the mission, you'll have to create 20 separate trigger rules, one per unit. Very kludgy, very messy, extremely difficult to maintain, and wholly depressing from a scripting perspective. It really is a shame that DCS's mission scripting environment is in such a bad, amateurish state.

That's some very bad UX on my side, and I'll try and change that in the next update. You should see a warning when the miz starts up that the range for the pulser is illegal, and that it defaults to 1. Long story short: if you want infinite pulses, please delete the 'pulses' attribute to have DML default that value to -1

Thank you, I'll have a look. When you were taking out a large number of units, were you flying or in a CA vehicle?