cfrag

Ah, I found the issue (I believe): The spawner needs indeed the country attribute set to 2 (USA, blue) to be eligible for helotroops to show up in blue helicopters. The masterowner attribute merely controls the eligibility and of the spawner for helicopters, it does not control the owner of the spawner itself. NOTE THAT THIS IS IN STARK CONTRAST TO HOW CLONERS WORK (and, yes, that is bad API design, my apologies). The idea with spawners' master owner is that they can be made enabled depending on the ownership of a (faraway) zone. So, you did everything correctly, and probably confused a spawner's masterOwner mechanics with the identically named, but very different cloner's masterOwner mechanics. Don't worry, I confuse myself as well.

Yeah, let's tray and get that to work

Thank you! What was the issue @Recluse ran into? (I'm always looking for ways to improve the manual)

Please remove all mods from the mission - I can't open them otherwise.

Well, there's always the possibility that I screwed up. Can you show the zones for the spawner and FARP so that I can have a look at the attributes? If all else fails, I can take a look at the miz itself, but with some luck we can resolve this quickly.

Thank you for the headsup. It seems to work on my setup. smr test.miz

The M4 soldier is an old model with an old run-only animation baked in. Use the Infantry M4 Georgia soldier model instead, that one should have a better walk animation added.

Good news - it appears that the new version is now available at ED's User Files.

Well if the CIV exists in-game you can spawn them via a cloner. AFAIK, there are no civ units except for some cars.

Unfortunately, no. ED's User Files seems badly maintained, and I'm hoping that they get their act together as soon as possible. I regard it as a troubling sign when a company can't afford to keep their highly visible, client-facing content site in order.

Three cheers for ED's User Files ops team! Huzzah!

Version 2.00 - 20250208 FIRE FIGHTING! I've (finally!) added the fire-fighting abilities from "Heroes of Flames" to Caucasus Angels, and patched a number of holes made by recent DCS releases. All changes A LOT Enjoy, -ch

So you basically want free stuff. Understandable, and that's not the way ED make money. They want yours. While I can understand your desire to freeload (so do I); when we become adults we understand TANSTAAFL.

I agree. And I tried to come up with some simple requirements for that so that I can put it into a server script. That is where I'm currently blocked: Do you get one or more pilot(s) per server? If yes, where is it stored? Who owns it? (remember that if the serving machine is located in the EU and the player profile is stored there, the server owner can be liable to GDPR hits from malignant litigants). What if a server owner decides to "kill" your pilot out of spite? Does your profile move with you from server to server? How do you then prevent cheating? I made no progress on these basic questions, and yes, let's hope that these questions do get resolved

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