cfrag

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.

Huh. I believe that you are mixing purpose and game goals here. There are multiple purposes for ATC in the real world. One of them is managing air traffic risk - for those in the air, and those on the ground who would - quite literally - be impacted if something goes awry above. For many RW pilots, ATC chatter - which they observe passively by listening to the radio -- is their mind's eye to get a local picture of who is around. During airfield procedures, ATC is vital, and many pilots feel 'naked' when they approach an uncontrolled field because they feel that trusting CTAF to be accurate is akin to running across the street blindly trusting the verbal instructions of your friend. It works, but can be much better. Now, in a game, especially sleepy backwater DCS ATC isn't that important - except that for many pilots not having ATC is the issue -- instead of being in a backwater region. And TBH, if you create your mission with some flights around your base, that ATC in DCS will lie to you, Tower will actively try to kill you (clearing you to land with traffic on the runway), and Ground/Tarmac is non-existent. Some people don't mind, and it's entirely inconsequential if your (absolutely legitimate) goal is to 'merely' blow stuff up. But some people enjoy procedures, and these procedures extend to airfield and RT. What really, really annoys me that airfield procedures are exactly that: procedures with defined states. Every state is fully defined. Putting this into code isn't that difficult. How do we know that? Look at other flight sim games that can do that. DCS's current ATC/TWR/GND is abysmal, even for a late 1990's game. Granted, having non-player aircraft observe ATC is something else entirely, so let's momentarily focus purely on procedures. I think that we can agree that ATC / RT procedures is an essential aviation aspect in reality. It can be an important aspect to a part of the flight sim gaming community DCS's implementation is currently (2024) severely lacking and 99.99% unrealistic Let's hope that this will be taken care of soon, even if ED takes a simplified approach of only implementing the international civil aircraft operations procedures first, and work from there. My feeling is that it can only improve. Will it make the game better for those who primarily fly to blow stuff up? Probably not. But I think it will make DCS an overall better game for dorks like me, who kind of enjoy some procedures, and love the fact that I can ignore others (that's another important aspect: having current DCS allow players to ignore procedures is a great thing!). -ch

I believe that you should be more specific what you are looking for. Below please find a script that I think does what you are asking for. The fact that I was able to throw it together while waiting for my toast tells me that you are after something with more finesse -- so let's hear it. That is probably because DCS is excessively recalcitrant when you try to script radio messages - it suppresses all errors, and does not tell you. Look at how the script steps out of that context to enable debugging. Here's the entire script ci = {} -- carrier meths function ci.isShip(theBase, carrierOnly) local desc = theBase:getDesc() local cat = desc.category if carrierOnly and cat == 2 then local theUnit = theBase:getUnit() return theUnit:hasAttribute("AircraftCarrier") end return cat == 2 end function ci.getCarrierInfo(theBase) local theUnit = theBase:getUnit() local msg = theUnit:getName() .. ":\n" -- calc heading local pos = theUnit:getPosition() local heading = math.atan2(pos.x.z, pos.x.x) -- make sure positive only, add 360 degrees if heading < 0 then heading = heading + 2 * math.pi end msg = msg .. "Expect " .. math.floor(heading * 57.2958) .. " BRC." -- other stuff here return msg end -- comms response function ci.getCI(args) timer.scheduleFunction(ci.doGetCI, args, timer.getTime() + 0.1) -- step out of current context end function ci.doGetCI(args) local allYourBase = world.getAirbases() -- get all local msg = "Carriers:\n" for idx, theBase in pairs(allYourBase) do if ci.isShip(theBase, true) then msg = msg .. ci.getCarrierInfo(theBase) .. "\n" end end trigger.action.outText(msg, 30) end -- set up function ci.start() -- install menu for all missionCommands.addCommand("Get Carrier Info", nil, ci.getCI, nil) end -- go! ci.start() And below the miz (pop quiz: can you identify which 'Carrie' the miz refers to? Hint: it's not the King Novel/De Palma movie). carrie.miz

They are a potential hazard, and can be difficult to see, so they are on the map so that a pilot can be aware of them and not descend below a certain altitude. In mountainous regions (Alps where I live) these lines can even span between deep ravines and create special hazards at altitude. They (rather the pylons) can also be helpful for locating yourself when lost, and can be followed similar to roads or tracks. So having them on maps is helpful and increases safety.

Just (re-)stumbled across this thread. The fix is as easy as it is annoying: ED introduced (without announcing nor justifying the change) a new event 'runway touch' that sometimes (it seems randomly) fires instead of 'landing'. So fixing the grabber script is simple: if (event.id ~=4) and (event.id ~= 55) then return end -- neither 'landing' nor 'runway touch' Below please find an updated script that should work as described (read: untested, please let me know if something is wrong so I can take a look at it, was on my way to grab a coffee). grabber.lua grab'em now.miz

Here's a miz that controls the flow of signals to messenger with changers. The goal of the entire assembly is to only let the signal sent from radioMenu output A! through to messenger? input if the flag 'owner' is set to 1 (to simulate ownership of red), and block it otherwise. You can use the radioMenu to set owner to 1 or 2 (note the outB/outC attributes). It is set to 0 on startup. The signals for messenger are also created with radioMenu, output A!. Note the funky use of 'pulse', and see if you can deduct why I'm using it -- Note that this is not for beginners, but you don't strike me as one, so happy puzzling. gated changes.miz

That is because I was lazy. You need two changers: once to act as a gate, the other to provide the gate's signal to open/close. I'll see if I can create a demo miz for that, but that may take some time, on the road right now.

I believe that there are many ways to do what you want to achieve, and your approach seems fine. My approach would be a bit more straightforward: use the Changer as a gate that can close, and simply only propagate signals through the gate if/when the owner of Gaz is red (1). So instead of baseCaptured, I'd use airfield (it has a direct ownedBy# output) and use changer to guard the signal from unitZone so it only flows into the randomizer when Gaz is owned by red.

Version 2.3.5 - Feature Update So yes, my professional opinion of DCS's warehouse API is low. Very low. I personally deem the quality of the entirety of ED's design work that has gone into that part of DCS to be non-existent, amateurish. I also think that any time on my part sunk into supporting that aspect to be wasted. DCS is a quality show, and it deserver better. A lot better. That being said, I was approached to add support for persistence to warehouse inventories. This would enable mission designers who do appreciate that I wouldn't touch current warehouse inventories for DML with a long pole to brew their own inventory management, and still have the ability to persist the missions. This update to DML provides completely transparent, drop-in persistence for warehouse inventories. Against my better judgement. Please do not expect me to follow this up with a DML module for warehouse inventory management any time soon, at least not until ED show us something that resembles a professional warehouse API design. Because, in case I didn't mention this before, I think its current state is really, really bad and unworthy of DCS. Other than that, this update contains some more fixes for bugs that were introduced with recent DCS releases (more and more strange objects turn up in events and need to be guarded against), and while I worked on persistence for inventory, I also fixed some long-standing bugs in existing modules (most of these bugs are quite arcane, and you are unlikely to have ever run across them, one I discovered while supporting adding persistence to a larger Warbirds mission) Documentation - Main - WHpersistence (new) - minor corrections - QuickRef - minor correction Demos - (no changes) Modules - airfield 2.3.0 - lock/release cycles on mission load for better persistence - autoCSAR 2.2.1 - more DCS bug hardening - cloneZone 2.5.0 - restored cloned connection on mission reload (persistence) for empty! - heloTroops 3.1.5 - better destination guards on loading mission - impostors 1.2.0 - better filtering of dead groups - noGap 1.3.1 - parity with stopGaps 1.3.1 - radioMenus 4.0.2 - ackSnd now broadcasts when no group specified - raiseFlag 3.0.0 - supports persistance - slotty 1.2.0 - better nilling of players - WHpersistence 1.0.0 - initial version

I'm unable to reproduce the issue. Can I trouble you to perhaps PM that miz to me (or a simplified version that isolates that behavior)?

Not directly, no. But looking at what you are trying to do, i think that would be the least of your challenges: Uh - you're in for a hellish experience here. Tutorials usually read/set cockpit switches and await control inputs using the miz actions "X" tree which are mostly unavailable via normal scripting (you can read the value of a cockpit/3D model item using unit.getDrawArgument(), but AFAIK you can't set it, so you'd have to resort to active polling and asking the player to change the setting of that model item. Each aircraft has it's own model items, they do not have standardized names, and finding an argument value for a specific plane for a specific switch is a painful procedure involving the model viewer. Add to this the fact that in single-player you may be able to figure out what kind of aircraft "you" are flying, that is impossible in MP - the is no concept of 'I' in mission scripts. What invocation is that? What does it do? I believe everyone agrees that this would be great. Currently, I don't see a way to do it in vanilla DCS. Mayhaps if you have access to ED's private mission scripting tools for third paries.

The reason seems obvious to me. When DCS opens Miz Ed with an empty (default) document, it initializes the 'change' flag to the wrong value. It's a tiny error that has annoyed everyone for ages. The DCS experience is a nutshell, so to speak.