cfrag

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.

Update 1.62 - 20241023 Changes: autoCSAR DCS bug on isExist hardened against cloneZones now correctly reconnect from persistence better nilling in slotty Enjoy, -ch

You may want to try a raiseFlag on the input that hides the menu 1 second after mission start. I'm not sure that that works for all use cases, but it should for menus that are available for all aircraft.

I first want to finish Expansion (it's close to what I wanted to do with it). After that, there have been a couple of suggestions. Cold war is something that I have kicked around, a bigger Expansion on a different map (probably Syria) is probably the next step. No definite plans yes.

CTLD is outside DML's scope, and I have rarely looked at it, IIRC, it uses a unit's/group's name and that will throw you off if you are using a DML clone - because clones adhere to DCS's requirement that all names must be unique. You can force a cloner to keep the clone's original name and ID by setting the 'identical' attribute to true. If you do that, remember that the 'Highlander directive' is in force - there can only be one. With identical active, any previous clones from that cloner are destroyed when a new clone group with the same name/ID is created. But CTLD should (hopefully) work with that group.

That is most probably because the aircraft are flying too high to be part of the volume that wiper checks (a sphere with the same radius as the zone -- wiper was built to remove debris on the ground. My (severely limited) imagination failed to foresee that use case. That being said, perhaps you can trigger the spawning cloner's declone? input to remove the group? Or you could perhaps use a groupTracker's destroy? input for that purpose.

Huh. Thank you for clearing that up. I believe you could have led with that, along the lines 'I effed around with some scripts, added the Herc, and then I got an error, perhaps where I screwed with the script...". I don't mind people effing the scripts - I rather expect you to . I do mind when you send me on a wild goose chase because you do not disclose important details like changing scripts

Do you have any indication which script throws the error? Malformed number is a strange one, usually a typo. If you run it as a DOSCRIPT instead of DO SCRTIPT FILE, we can often see the first line of the script and that often tells us what script is misbehaving.

Thank you, I'll have a look at it.

Well, I think it's still the Herc mod. Methinks it would be best if you removed it.

Disappointing indeed. It looks like that's a Hercules bug, though (DML scripts in my missions always identify themselves). Let's hope that the Herc will make the transition to a 'real' DCS product soon, I've pre-warmed my credit card already

Aaaaaand the award for this month's greatest understatement goes to: @Tippis!

Ha! Welcome to advanced trigger transmogrifation! So you already know the answer, just not which DML "bricks" to use. Let me point you into the right direction: What you are looking for is (in old-school TTL electronics) a 'gate' - something that lets a signal through when one condition is met, and prevents it from passing through otherwise. Have a look at the second use case for the 'changer' module. So when the airfield belongs to red, the gate opens, and otherwise it closes. Connect the triggeing flag to the changers change? input and then changeOut! to the cloner's clone? input. The triggering signal will only propagate if the gate is open. But how do you tell the gate to open/close? That's a job for the first use case for a changer. Use another changer to create a direct signal to the first changer (the one that functions as a gate) and connect it to the "on/Off?" gate input. And get the current airfield's owner (perhaps from an airfield's ownedBy# attribute and use the 'bool' conversion to match the "=1" trigger method. So you will be using two changers to process/gate the incoming cloner signal. If you can't get it to work, we can hit it over the head until it does.

Update 20241019 - Many DCS bugs worked around, added Chinook Mission works again, and now supports the Chinook. Enjoy, -ch

FC 2024 FUN PACK - Flaming Cliffs Practice Sandbox [all FC aircraft] Download: ED User Files Forum Thread: HERE Your Flaming Cliffs 2024 planes have arrived and assembled outside, ready to fly. All planes are fueled and armed, the only thing they need is you in the cockpit. So suit up and strap on, pilot! Features Ogle at all your aircraft Once you are inside your cockpit, take a good look around. The airfield is populated with aircraft that you can jump in - you own them all (well, except the Hercs). So taxi by those planes carefully, and enjoy the view of the other planes that you own. Landing Practice Senaki Kolkhi's 09 is marked with blue smoke for landings. There is another blue smoke marker on the 5 mile final approach point. To practice landings, take off, turn around and then position yourself over the 5 mile final to set up for nice, easy landings. Additionally, when touching down inside the touch-down zone, your landings are automatically rated, giving you details on quality, speed, run length, etc. "Touch-down zone", you say? Switch to F-10 Map view, look for the green rectangle on Senaki's 09. Logbook ("persistent" -- if you want it to be) What good is a practice ground when you have nothing to show for later? The Fun Pack logs all your flights per type: total time, landings, departures, "super-marginal landings", start-ups. And it saves that data to your permanent storage ('persists') if you "de-sanitize" your DCS. This is entirely optional, and requires some work on your side that I'm too lazy to detail here. Perhaps Google it. Air-to-Ground Practice Taking off from Senaki's 09 and fly that heading until you see red smoke. In the field south of the smoke marker, a number of vehicles await your destruction. They will NOT fire back. At any time you can re-spawn all ground targets with the Communication-->Other-->Ground Targets menu. Note that target positions for all vehicles change each time that they spawn Air-To-Air Practice Should you want to practice your air-to-air combat prowess, you can call up as many enemy fighters from a selection of 12 fighters as you like. Be advised that these enemies will engage you, and most of them have missiles. To have an enemy appear north of Senaki Kolkhi, go to Communications-->Air-to-Air and choose the era and type. You can spawn as many enemies as you dare. I recommend that you re-arm your aircraft for CAP should you engage into air-to-air combat. Most aircraft are configured for ground attack by default. Multiplayer: FC Fun Pack uses "stopGap". If you experience planes crashing on startup, you should install 'stopGapGUI' on your server (only server) to work around a DCS synchronization bug. Multiplayer supports dynamic player spawns for both sides, any plane with any armament. Red players spawn from Kutaisi. Enjoy, -ch