cfrag

I was thinking about a successful landing at a FARP triggering restore. We’ll have to see.

It would seem that goldfish-brain I kind of forgot about that. It should regen them regularly, but I then forgot to put the code in. I may be able to put this into the update following tomorrow's.

Indeed, and it is way too generous awarding score. This will be fixed with the upcoming release It's probably debugging code that I erroneously left in, and I'm working on that. Some messages do use pointed brackets "<>" to better delineate between a name and the rest of the text, though.

If ownedZones 'fastEval' flag is true (it is by default), only the first unit of each group is checked for zone entry for performance reasons, and the rest of the group is assumed to be close by, and all units are counted. If you are driving any other unit than the groups first unit, ownedZones will not register your unit entering the ownedZone. So please try again driving unit 1 from the group, or turn off fastEval.

You are using one "command" (or flag), and they are all listening to that same command. So you only need to save it once. Think of it like a tape recorder in a room that records what was yelled. You only need one recording, even if there are 5 listeners. Yeah, the metaphor is being stretched to breaking point, agreed ... but each listener need their own "=1" instructions...

Looks wonky to me... If above doesn't work, try local Flag = net.dostring_in('server', " return trigger.misc.getUserFlag(\"HP\"); ")

Here's how I made it work with your example: null You will need to remove the previous save file

They are. I tried this with the mission that you kindly included and found that when I spawn the units, kill them (I conveniently placed a Leo close to them so I can pick them off once stared), save the mission and restart them, the trucks do NOT come back. Now, if you again choose "start ground units" from the menu, the radioMenu sends the "goMissionStart" command, which goes into the cloner's clone? input and it clones a new set of enemies. This is expected behavior, as cloners will always react to signals on their clone inputs. You can easily try this yourself by starting a mission fresh, start the ground units, kill them all, and then, without saving or restarting the mission, issue the "start ground mission" command again. New trucks appear. The issue isn't the cloner, the issue is that you aren't guarding against multiple ground mission starts. What you probably want is that the cloner remembers that it has spawned, by using the information encoded into the "goMissionStart" signal, and only clone when the underlying flag's signal is exactly 1. To do that, you'd set the triggerMethod to "=1" (this will prevent multiple starts in the same session) AND save the flag "goMissionStart" state with persistence via the "saveFlags" attribute (this prevents across saved missions). That way, persistence saves "goMissionStart"s state and loads it. To make this a bit simpler, I'll see if I can add a new 'maxClone' attribute (that is automatically persisted) that limits a cloner to n clone cycles. You could then set it to 1, and only one clone cycle is run on that cloner, no matter how many times you bang on the input.

That could be possible, and it would incur a performance hit, much like owned zones will (they each need to check against all units in the mission if they are inside, and check that once every second or whatever you set ups to). That is the reason that I did not do this for FARPs, as they have their own event when they are captured, and I can conveniently (with no performance hit) tap into that. That should be possible, and I don't understand why I haven't done this yet Maybe I can can shoehorn that into the next update (scheduled for Thursday)

This appears to be similar to the seminal "simple slot block" idea ("SSB"), of which there is a good implementation available. It's your idea generalized - which is a good thing because your script changes the semantics of all missions running on your server when it comes to players and the flag named "HP" in missions. Scripts in Hooks can indeed execute trigger.misc.getUserFlag() in another context and retrieve the value (and set it is well, but nothing more) using net.doString(). @Kanelbolle was already kind enough to quote the relevant passages from SSB, here's the line to focus on: local _status,_error = net.dostring_in('server', " return trigger.misc.getUserFlag(\"".._flag.."\"); ") The 'server' bit is non-discoverable, you simply must know that it has to be 'server'. Three cheers for DCS's documentation team. Also, remember that after changing a server script, you must fully, entirely restart DCS for any changes to occur (server scripts are only read when the app starts up)

Yes and no. Helotroops can currently load anything "ground" into helicopters, but will disregard the weight. Therefore, HeloTroops checks the things on the ground that for their type, and currenlty restricts all units to infantry. This can be overridden. So: transport - yes. Realism or visual slinging - no.

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