cfrag

My apologies for being unclear. I usually create missions for all modules, so anyone can play them. Unfortunately, this can lead to airfields running out of parking space. Updating all missions to add the FC versions may be a bit tiresome. I probably too (if they are different modules - I already own all three of them). The Tiger in particular is a fun module.

ED just released in an announcement (here) that there will be a "Flaming Cliffs 2024" coming soon, which adds the F-5E, F-86F and Mig-15bis. This is fine for me, and as a mission designer, I have some questions: Are these the existing modules, re-packaged for FC3 or will these modules be FC-ized with simplified cockpit? More importantly, if they are different, will they have different representations in Mission Editor? Example: today we have the A-10A (FC) and two A-10C to choose from. Will there be separate FC 2024 F-5E, F-86F and Mig-15bis? This could really throw a spanner in my missions.

Yes. [A snarky, unhelpful answer to a low-effort question. If you want other people to invest time in answering your question, I recommend that you at least afford them the courtesy of investing some effort into the question itself. Oh, and the full answer to your question is "Yes, and very good ones, too."]

That sounds intriguing. Can you elaborate how that works so that, for example two consecutive runs of the same mission create different results? I'm always looking for good alternatives like this.

I prefer steam because I got rid of all the other installers that littered my hard drive (I'm kind of lazy that way) and polluted my experience. Since I'm an avid SteamVR user, I need Steam anyway, so this was a natural. Also, with Steam comes ease of mind - I'm somewhat security sensitive, and games downloaded from Steam seem to have the (illusion?) of greater security/authority. I'd rather load and run a game from Steam than a rando server of unknown pedigree located in Russia. Same with giving my credit card number. Oh, yeah, as @Eugel mentioned, a GUI interface to VR is very convenient for someone who regularly switches between flat (mission development) and VR (testing and flying). The downside is of course that ED receive less from my purchases, and that I can't participate in free trials nor ED's miles program. I've solved the no free trials problem by simply getting all the modules...

DML wouldn't be much helpful if it couldn't do that. It's rather a large part of it. In DML lingo, modules have 'inputs?' (note question mark) that look at flags. If the value of a flag changes, the module interprets this as a signal to do it's thing. Almost all modules in DML work that way - they have inputs (plural) that can be connected to flags, and when the value of that connected flag changes, something in that module is triggered. So let's look at fireFX's documentation. Among other attributes, there are the inputs 'start?' and 'stop?' (again note the question mark. That's DML's convention to denote an input, that the module is constantly querying the flag 'connected' to it) start? DML watchflag (input) for when the effect should start. Defaults to <none> stop? DML watchflag (input) for then the effect should stop Note: unlike the smoke zone module, which can take several minutes for the smoke to stop, this fireFX’s smoke and flames take roughly 10 seconds to peter out) Defaults to <none> A large part of DML modules specialize in providing a counterpart to these inputs, they have "outputs!" (note exclamation point). But DML is completely agnostic to how you change flags that it is listening to. So, if you, for example put down a trigger zone, and then have one flag set to change when a unit enters it, you can then connect that flag to start?, and that fireFX in that trigger zone that looks at that flag will start its fire. If you then connect another flag to "stop?" and you write some trigger rules to change that flag when the unit leaves that zone, the fire will go out when the unit leaves the zone. And that's pretty much 99% of the DML way right there: control DML features with flags that signal the module to do something or stop doing something. Ohj yeah, and there are of course tons of modules that specialize in sending signals when you want something to happen. Look, for example, at the radio menu module that allows you to configure entire menus and the flags that it changes with a simple trigger zone (in DML, you seldom go back to the rule editor, it's so much more convenient to do everything right there in the trigger zone where it happens). Please see the attached slightly modified miz. Watch as the APC trundles along the street, the fire first ignites, and then extinguishes, triggered by the units entering and leaving old-school (non-DML) trigger zones. smoke above water.miz

If you use a cloner (instead of spawner) then commander is out of the picture and the clone uses the group/formation that you assigned when you created the clone template. what you have changed in commander only affects troops that are under commander's authority, and clones are not among them. So how can you tell? Look into a modules 'dependencies' section. If you see 'commander' listed, ground units from that module can be under the influence of commander, all others do not.

And it will work well for that, and any other mission that requires ALL units (including air) controlled by commander to be in echelonR formation when not following a road. Now, since commander only controls ground units (that can include vehicles spawned by spawners) this may not be an obstacle for you. For a full DML implementation, I'll need to try and engineer a solution that can apply individually to ground units spawned by DML and that do not follow roads. I'll see what I can do.

I agree, and I would like to be a bit more specific in case people ask: I think OP is talking about the background that people see when they see the "DCS Main Screen" where they can choose multiplayer, mission, training etc with the icon strip of modules at the bottom - while not in VR. I don't think that OP is talking about Mission Editor or other DCS-related scenes. While I don't think that we truly need spectacular new animations, I think ED can (and should) take a page from the (cool) existing VR "Hangar" scene that is displayed for VR users. The one where we sit in a hangar next to an aircraft (Flanker by default?). That hangar scene can be edited, and even allows for some limited animations (unfortunately quite undocumented, but I've seen and played with some clever rotating lights). I'd love it if this VR hangar could also be expanded to flat-screen DCS and show a hangar scene that also allows some similarly limited animations and customizations. Customization like, for example, showing the model that you chose as today's background scene. Or some Carrier deck. Or some ground vehicle. or, or, or... The possibilities are as numerous as we have objects in DCS

Adding DCS Warehouses to DML has been on the table for some time, and I'm looking into this. Since it is new, I'm a bit hesitant to start working on in for the simple fact that many of DCS's additions to the scripting environment have a decidedly "low-ability/effort" feeling - they exhibit more of a spur-of-the-moment implementation vibe than an engineered approach. The current 'warehouse' API looks decidedly that way to me it differentiates items and liquids (why? why not treat everything inside the warehouse as a "thing" and provide a unified method to manage their inventory). Liquids aren't abstract, but already instanced with numbers. So in case that you want to manage water or other liquids of your own design, you are already SOL. it provides separate accessors to set and get items - but also provides accessor to add and remove. As an engineer, I'm immediately suspicious what the difference between 'adding' and 'setting' a quantity is. All warehouses are owned by airbases. Why? What if we want to set up a warehouse that simply owned by a faction (as a strategic target to be destroyed/captured)? IMHO, it's plain bad code engineering, and therefore I'd want to wait a bit and hope that the Warehouse API settles a bit; maybe it receives an overhaul from someone with a greater understanding of code architecture. I'll see if and how badly I need warehouse integration for my first "Foothold" step-sibling. IMHO, the Warehouse API screams 'stay away'.

DML works different from the classic mission frameworks. With DML there is no scripting involved for Mission Designer - all scripts are already written for you, and you use trigger zones to place their abilities. Trigger zones in DCS have these attributes that were never used in plain vanilla DCS, so DML uses them to direct all of its (DML's) new abilities. You can see how useful and simple that is right now: click on the trigger zone that places the fire in one building, copy and paste it over another, and adjust the value for the AGL attribute. Boom - another fire at the location and height that you want. That's how DML works: you pick the abilities you need from DML's large repository of 'LEGO Blocks', and place them on the map with trigger zones. No scripting, just connecting trigger zones with attributes that you edit in ME. The attributes in the triggerzone are fireFX - this tells DML that you want fire here, and that this trigger zone contains the configuring information agl - this tells DML the altitude in meters above ground level where the fire is placed onStart - "yes" this tells DML that the fire effect should be 'on' when the mission starts. There are some more and cool abilities that you can access/change with other attributes to your heart's desire. The details are tabulated in fireFX's module description in DML's manual (do not be deterred by DML's docs. Much of the bulk is made up with detailed discussions of the many demos that come with it). Yes, the ONSTART trigger. That is where the DML components are loaded and run to be ready for you whenever you need them. These are the scripts that look at the trigger zones that you place and eagerly look for your direction. If you do it for the first time, I expect it will take you a few minutes - you simply have to copy/paste the contents of the three DOSCRIPT actions in the MISSION START rule. Once you have done that a couple of times, I expect that time to drop to less than 30 seconds (10 seconds per script). Once the scripts are loaded, DML is ready to supplement your mission and looks for trigger zones that have special key attributes that tell it that this trigger zone is a DML zone. This mission only uses the 'fireFX' ability, other DML missions will add more modules (e.g. 'messenger', 'cloneZones', 'ownedZones', 'heloTroops' etc). You pick and choose, since it's your mission. This particular mission uses the following parts: dcsCommon - the 'helper' bedrock of code snippets that DML needs to do its thing. Many little functions to allow DML to interface with DCS cfxZones - DML's god-like trigger zone manipulation layer. In a sense, this is DML. It gives all DML modules the ability to access trigger zones, read atributes, and - most importantly - allow the trigger zones to "talk" to each other fireFX - a DML module that specializes on fire effects. That's the DML way - most modules specialize on an isolated ability. By adding the module to your mission, you enable the ability. By adding a trigger zones with the modules key word (here 'fireFX') you activate the ability. The trigger zone tells DML where, when and how you want the ability to be placed and activated. Yes - DML does not require (actually, it does not support) your own scripting/modding. It is designed specifically for mission designers who do not want to mod/script by themselves. BUT you are strongly to encouraged to read parts of the manual and look at some of the demo missions (usually the demo mission for the ability that interests you) Mission editing skills (outside of scripting) are always good to have. And if you come across some good documentation in this regard, please pass it on to me. ME is one of the worst documented jewels in DCS. IMHO it's the heart of DCS, and it's treatment as stepchild seems truly heartbreaking to me. It's one of the reasons we have DML: so more people can create fun missions without having to go through mission authoring hell. TBH, with DML, you still have to go through that, but your stay is often much shorter Oh, and if you are interested - here's the DML main thread. There are even some tutorial videos to watch.

I can try and take a look at it. In all, the formation for ground troops (or any other) isn't well documented, and when I originally wrote the commander module I was not able to get infantry to do anything except head where I wanted them to. I'll see if I can improve that. As you can see, 'off road' is a formation in DCS, a terrible way of going about that.

Something like this? Flames are optional, and it's overkill to run DML just for some fireworks/smoke, but adding that with DML takes you almost a full minute Now, if you want to straight-code it yourself, get the point (probably from a zone you place), add some altitude to the map's altitude (use lang.getHeight for the point) and then use trigger.action.smokeEffectBig with the point where you added the altitude. If that's too much, you can still fall back on DML See the miz smoke above water.miz

This may help. Look at the "BombersBhere" trigger zone for details. Random Bombers Inbound.miz

Bullet. Tracer Bullet.