cfrag

I've modified cargoReceiver in a way that should work according to your needs: Below please find a pre-release version that still needs regression testing, and I award you the honor of being part of that Here's the updated dox - it's backward compatible and I still recommend that you use the new (shorter) cargoReceiver! semantic. Note the new noBounce attribute that defaults to TRUE: Name Description cargoReceiver! Output flag to bang! when the cargo object is delivered onto the ground inside the zone. Marks this zone as a cargo receiver zone. MANDATORY cargoReceiver deprecated Marks this zone as a cargo receiver zone. Value is ignored deprecated autoRemove Delete (despawn and remove from game) a cargo object <removeDelay> seconds after it was successfully delivered. This is helpful for most ObjectSpawnZones set-ups to trigger their spawn cycle Defaults to false silent Set to true to turn off this zone’s directions. Defaults to false (zone will talk to pilots) method cargoMethod DML Method for output Defaults to “inc” f! cargoReceived! deprecated The flag to bang! when the object is destroyed. Use only one synonym per zone. removeDelay The delay (in seconds) after which after a successful delivery of a cargo object is removed. Requires that autoRemove be set to true. Defaults to 1 (second), Minimum is 1 noBounce Prevents multiple deliveries of the same cargo object to the same zone are counted multiple times (e.g. bounces). When set to true, each cargo can only be delivered once per receiver zone. Defaults to true (one delivery per zone) And the new module, I welcome your feedback cargoReceiver.lua

Isn't that expected behavior (unless autoRemove is set)? The receive would register each time that the cargo is on the ground and lifted again, provided that this happens less often than once per second and ups is set to 1. If autoRemove is active, the cargo should disappear (and no longer be able to land inside the receiver). And I think I understand what you may be getting at: once put on the ground, the cargo should be removed from cargoManager's inventory. Currently, it's not set up that way so that you can pick up cargos that you have lost, and transfer cargo after you have dropped it into a receiver. What is your intended use case? Maybe I can figure out something for that.

Here's the updated cicAir that works with buggy Syria. And, wow, Ben Gurion! Note that CivAir is currently still a bit chatty, make sure to disable verbosity. The next DML release will probably have a verbally slightly more restrained version. The text you see now is to help in diagnosing other odd stuff Syria/ECS might throw at us. civAir.lua

Please revisit 4.1.6 "That text in the upper right corner" of the manual to get some step for step instructions. If modules constantly display information, there are two possibilities: I goofed up and forgot to remove some diagnostic code. In that case, please provide me with a screenshot so I can try and correct it. Otherwise, that module's (or a zone under its control) 'verbose' attribute is enabled. In that case, set that attribute to 'no' or remove it entirely.

I think a simple approach would be to insert a delayFlag module between a cloner's "empty!" output and "clone?" input and set the timeDelay to 300 (5*60 seconds).

I looked at the mission, and HO BOY did I get a nasty surprise. I discovered a slight edge case issue that your mission forces and that was easy for me to fix. And then there was a big surprise: the last update of the Syria map BREAKS CARDINAL DCS RULES: it has 120+ airfields that all have the same name (a fundamental no-no in scripting, the map should not even load in DCS nor Mission Editor): "H". No objects in a mission may ever have the same name at the same time. In Syria, there are now more than 120 such items of strategic value that infract on one of DCS's most fundamental principles. This will cause a lot of strance behavior and abends. These "H" airfields aren't airfields: they have no runways. They are helicopter bases, and identify as airbase - another violation of DCS ground rules. This will cause bugs with scripts that look at runways or assume an airfield has an runway. So what happens is that civAir randomly picks an airbase. There's an 80% likelihood that it's one of the "H". Accessing that airfield will yield a nonsense airfield, and trying to get a parking position for a civ flight to start from results in one of the parking slots that you have seen, where the planes then start stacking up. I'm patching civAir now to work with Syria, and I'm very unhappy that ED's QC even allowed this to pass to us customers. This will break a lot of scripts that deal with airfields (and since warehouses are linked to airfields, most scripts that deal with airfields by name). This is a TRULY BAD DCS bug. I'm at a loss to explain how ED have let something of this magnitude slip by - that's troubling to me. Thank you for alerting me to this.

Thank you for the quick response, BN!

It seems that one of the last releases of Syria added a bunch (over 100?) of helipads. That is great! Unfortunately, though, they all have the same name: "H". While seemingly the game itself and ME do not protest, this violates one of SME's strictest rules: Objects must have unique names. In Syria, that is no longer true, making scripts that manage airfields by name unfit for this map: stupid null, cheap tools, ED! The result is that if you now invoke Airbase.getByName("H") you only get one airbase, and the remaining 100+ airbases remain inaccessible. This renders many scripts that access airfields (heli pads) by name inoperable. Was this done unintentionally? If not, what is the recommended work-around? Thank you for any pointers.

Please see below. Docs: convoyMethod DML method that is sent to the output. Defaults to “inc” convoyTriggerMethod DML method that triggers the input. Defaults to “change” convoy.lua

Trap one of the mark events (e.g. S_EVENT_MARK_ADDED), get the pos field for the position, spawn the group there. Your logical next step would be to analyze the mark text and use that to allow you to specify what kind of units to spawn Next thing you know, you have built yourself an interactive debugger. Great exercise, incredibly powerful tool for your missions.

Well, as someone who does have some understanding in this area I can tell you that any software development that takes longer than 18-24 month in the entertainment arena has a 99% chance of failure - simply because the rate of change is so great that whatever was implemented is now based on outdated specs and concepts, so whatever ED are developing, let's hope that they discard anything that's been longer than 2 years in the making. A cursory glance at DCS's 'new' cargo/warehouse architecture/API IMHO demonstrates vividly what happens if you don't, and should serve as a warning to us all. A dynamic Campaign may or may not arrive some day. Let's hope for the best, and reserve judgement for the day if/when it arrives.

Will do, certainly. I should be able to have it added by tomorrow, you can then test it

That module is very old, one of the first DML modules when DML wasn't really DML. I'll have a look to see when the output is banged. If autoRemove is enabled, it may be possible that the output fires erroneously, but I have never tested for that. Do you have reason to assume that this is happening?

Yes - It's trivial to add for me to add if the need arises. Yes.

Now that's an interesting (for me, annoying for you I guess ) issue that I'd like to get to the bottom of. Before I go too deep into what may be happening to you, please allow me to see hat I understand a hazard a guess that you might check up on: Here's what I can see / interpret: You are using CivAir in your mission to create civilian flights between airfields (and perhaps also inbound/outbound zones. Using civAirConfig, you want 30 flights at max to be active at the same time (maxFlight = 30). At mission start, this will create 15 flights in-air between source and destinations, and spawn 15 further ones, every 25 seconds, randomly picking from the available source airfields. So what are your source airfields? Well, unless you define a single source, all airfields on the map serve as source, else only the zones that you have designated as a civAir source with a civAir attribute. As far as I can see, you only have a single airfield marked civAir, and it also has a value "exclude". That's an edge case I did not forsee: a single defined airfield but that airfield should be excluded. Can you add at least two more civAir zones to the map to some other airfields, to allow planes to travel between them, and perhaps lower the number of maxFlights in civAirConfig to 4 to test out if civAir is doing it's thing? After that, ramp up the numbers, but 30 flights with no place to go seems strange to me. Then again, I have only the context of what you kindly shared in your post to go by, so probably there's more to the mission.

Huh. I'm as baffled and thrilled at the inventiveness of people as the next guy. Great stuff! I'll have a look - since originally CR zones were written to work with "registered" cargo (through cargomanager), this is going to be educational I hope . Thanks for the headsup, @DD_Friar! I've had some thoughts about a module for exactly that purpose (Hook and (hopefully soon) inbound Herc, for transport mission galore), when I came across that steaming pile we currently have for cargo/warehouse API/UX. Unfortunately, although DCS has two (competing, silly) events each for take-off and landing (ED's API team really showing some low-ability moves here), there are no cargo events. I did ask nicely ED to perhaps consider implementing cargo_unload and cargo_load events, and ED, in their usual and polite way, did not deign to respond. So there's currently no logistics module, as there is nothing to build on. I'll look at cargo receiver, and see if I can make it easier to be used as a crutch. Boy do I hope that ED allow some grown-ups to work on the cargo/warehouse API before the Herc drops.

That is a really cool idea, but unfortunately current DCS has no provisions to support that. Entering ground units is part of "Combined Arms", a module that (to me) evokes the semblance of being created by an unwilling, sullen, low-ability temp. I deem it being of shoddy quality; it breaks any number of established DCS UX, and it is unworthy of DCS. Worst, it uses non-standard and undocumented API for entering and leaving units. At this point in time, controlling how and if a player can enter a ground unit cannot be accomplished with scripts.

Umm... <blush> I don't know. I never actively changed the settings, since I don't know how to (how do I do that)? Up until a few weeks ago I had the choice between multiple VR libs for my Vive, and now there's only OpenXR. I'll be happy to experiment/inspect If you can tell me what to do.

I'm sorry Dawger but you are again wrong! I feel that they aren't wrong. When done correct, a human-staffed ATC is leaps and bounds above ATC. So yes, that's the coolest thing ever. Now, how many of your friends are trained and willing to do that for you on a second's notice? Ah, right...

I feel it was a non sequitur. Me being the PIC means I'm responsible and accountable for my actions. Using additional tools / procedures to make an approach safer is IMHO being responsible and smart, like using a GPS in your cockpit even though having sectional charts would be sufficient under VFR. Or requesting a progressive on an unfamiliar airfield even though you have your Jeppesens open and studied pre-flight. I'd also point out that "sufficient" is far removed from "good", and given a choice, I always prefer my experience be good. IRL and in games. Ha. Indeed! There's a lot of that (non-core 'eye-candy' development that has little bearing on the fidelity of the core simulation) going on. Didn't ED tout 'Mach-Cones' (Vapor cones) as something to look forward to in their Jan 2023 newsletter? To me, that's pretty much the quintessential "empty fluff" that takes effort to develop with little tangible return from a pilot's perspective.

That's good to know. Which makes me a bit apprehensive since I seemingly can't access it: null

I seem to have missed when this started, but I just noticed that somehow the option to play DCS using SteamVR has vanished, only OpenXR seems to be available. Did I somehow accidentally messed up my installation, or has DCS dropped support for SteamVR in favor of OpenXR? Of course I now also seem to see a performance drop, and I do not know if it is real or coincides with the purported change. My missions become unflyable (strong stutter, 0.5 FPS or worse), after changing airframes more than once. I can switch between Huey and A-10A, but changing into a third cockpit (e.g. Kiowa) kills the game outright, and it can't recover - a full restart of VR is required. Am I just imagine things, or has SteamVR gone the way of the Dodo, and has VR performance plummeted in the last 8 weeks (2080Ti, Vive Pro 2)?

Indeed. Imagine if "Cogito, ergo sum" was stated as a fact, not opinion. <shudder> Yeah, I know: "cfrag, si tacuisses..."

Astute -- believing their opinion to be an universal fact aside, their opinion is also strangely reminiscent of a "manly man's", gung-ho approach to flying, exactly the type of character trait that most people learn to avoid. It's akin to people asserting that "traffic lights are a waste of time; drivers have the ultimate responsibility". While the latter part is true, the premise is not connected. And asserting that "people who like traffic lights are wussies and should not drive" would strike me as a bit childish. Personally, I like traffic lights as IMHO they make the roads safer, even though I'm fully responsible and accountable for my actions in a car. I believe that smart people look left and right before they traverse an intersection -- even if they have a green light. And when I approach an intersection that has no traffic lights that makes me more careful. Mistaking my being careful (feeling "naked"/unprotected) with being scared is... telling? But I digress. I would welcome better ATC in DCS because I believe it would make it more enjoyable for me. Egotistical, yes.

That flat-out assertion in a wish forum tells me everything I need to know. Thank you for sharing your opinion.