cfrag

Version 2.3.3 - 20240926 - Minor Update A few more busy weeks. DML appears to be stabilizing (most of the DCS bugs identified and bridged, some can't be fixed without ED's help) and this update is thankfully small. Behind the scenes I'm working on a new module that is quite different, and that I'm sure that many of you contributors will appreciate. It's not ready for prime time, and I'm hoping to be able to tell you more with the next release. Changes in Detail: Documentation Main Various corrections Quickref Various corrections Demos (none) Modules - persistence 3.0.1 - corrected a typo in shared data fallback code - playerScoreUI 3.0.1 - DCS Jul-22 code hardening - Scribe 2.0.3 - improved time measuring by switchiong from passive (event based) to active Enjoy, _ch

Thank you so much

Thank you for your willingness to contribute to the community. Please heed my licensing choice: "License: Freeware - Free version, Do Not Redistribute" Thank you.

It also means that I'm a bit mystified why you don't try this yourself...

Yes.

That would probably be csarManager.createCSARMissionFromZone(). The issue that you are bound to run into is removing the mark once you pick up the evacuee. Perhaps scour csarFX for that, I think that would be the best place to put the mark and remove it again as you also need a place to store the mark reference.

If your question is "does csarManager automatically place F10 Marks on the map for each evacuee" then the answer is no. But it's a great idea that I could add soon.

Huh. My creaky old rig is still on a 2080, with a vivePro 2 VR. Mayhaps you demand more visual splendor than I do, although I do remember that one of my recent missions (the COIN one, I think) is really unkind, and requires some 4 minutes to stabilize before I can attempt a flight. Hopefully ED get a grip of DCS's memory management soon.

I wasn't even aware that they were disabled (I don't use them much). I certainly did not disable them in the miz.

That's a common DCS bug with smoke that is not synched correctly for clients. It usually resolves itself after 5 minutes at latest. That would be the idea, as soon as I have enough feedback from this mission

Ha! Thank you so much! -ch

Ah. That's 'stopGap' eye candy (boring empty player slots filled with more interesting static representations of the aircraft). I'll add an option so you can disable it in-game from a menu. That being said, if a couple of static objects bring down your rig (in VR, I know), I guess it's time to either take down some of the graphics options, or splurge on new hardware.

I'm sure that this is an easy question, I'm merely too noob to figure it out. There (I think) is a list that contains all the missions that the server should 'play', and that can tell the server which mission is the next. You can even save a list with the Web GUI. If you set up an ad-hoc server, you can create such a list, and it is persisted. But where is the actual (real, active) list for the server located at and what is it called? I can't seem to figure it out. Any hint appreciated.

Version 1.30 - 20240922 - Feature Update: Troop Transport (Helicopters) Again, thank you all for the feedback. Here's the list of changes (please see the OP for how to use the troop transport feature) added second player-controlled Hook added ability for helicopter troop transport & deployment added two ground troop spawners that are requestable by troop transports troop transports are Hook, Hip, Hind, Huey (, Blackhawk prepared) Enjoy, -ch

Which file? The miz (mission) file iteself? Yes, it is fully self-contained, replace the miz and you are done. If you are talking about the server side stopGapGUI, you install it once and then forget about it. It does not need any updating (hasn't for over a year now). I wish it did. It would make DCS so much better if shared missions would be integrated, like Steam does with Workshop. Made it a wish-list item to Eagle Dynamics: integrate publishing of missions into Mission Editor and discovering/downloading of missions into the main game. Even made some Interface mock-ups. Never heard a word from them back, so there's that.

Agreed - the currently available FARPs look fugly, like a relic from 1990 (which they probably are...). I don't understand why they at least can't have some "livery" - textures to paint on, many vehicles have that already. One texture each for woodland, one mountainous, one desert, one snow, one gravel, one jungle, one "city"/urban. I'm currently working with the invisible FARPs as a stopgap. The problem with those is that they only have one spawn point, and are heck to integrate with warehouses.

Here's to tooting one's own horn... Perhaps have a look at this:

Update 20240921 - Version 1.72 Changes Nicosia civ helo new placements to avoid collisions Adana civ Helo repositions to avoid collisions better Scribe module log keeping Enjoy, -ch

Update 20240921 -- Version 1.72 Changes added 1 more csarFX vehicle some more scenery at hospital drop-off Batumi improved logging via "Scribe" hardened persistence Enjoy, -ch

Or some other software, agreed. And I guess that is the root cause: the maps are auto-created and optimized for minimal size/best performance and complete disregard for user accessibility; after all, anyone with access to to the original model and software can rely on the app to resolve all mapping. I’m not sure that a module’s vendor prioritizes a modder‘s convenience over their own or the product‘s performance. Sad, perhaps, and understandable. I surmise that the absence of a paint pack is a dead giveaway that the vendor hasn’t (yet) prioritized modders. Give it some time, and only work on modules that have a paint pack. That could help teaching vendors about priorities…

Dear ED ( @BIGNEWY or @NineLine to pass along perhaps?), for many of us mission creators it's a bit of a mystery what happens during mission start-up. More precisely, it's not clear what happen when, in what order. This is usually not important for ad-hoc missions, but many of us wish to produce quality missions, and for this some added understanding of the mission startup process could be immensely helpful. What I'm looking for is the order (or sequence) in which the following steps happen, and if you can add more information, the more the merrier: Mission Startup Sequence: please order the following from the standpoint of a (client) mission map is loaded weather is loaded and applied all flags initialized / ready to access (synched with server) All map objects allocated and initialized (synched with server) static objects allocated and initialized All AI units (ground, air, naval) allocated and initialized FX allocated (smoke, fire etc) All map airfields initialized All FARPs initialized All naval airfields (carrier) initialized All warehouses initialized AT START triggers invoked (i.e. the fist moment that a DOSCRIPT ACTION Lua script can start intercepting events and check for the existence of objects and spawn or change warehouse contents) Mission's INITIALIZATION SCRIPT (from TRIGGERS) invoked Single-player: player interface invoked Multi-Player: ready to synch with clients First check if an airfield is contested/captured Multi-player: object synch with host complete (note: server-existing colored smokes aren't synchronized, bug exists and has been reported years ago) First moment when events are posted to world.eventHandler First point in time that the mission triggers are invoked (outside ATSTART) (this point may warrant its own breakout) Point in time, condition if/when, and order, of events when a player enters the cockpit (i.e. Birth, engine start-up, player enter, weapon add, etc). Thank you so much for any information that you can share on this topic. Kind regards, -ch

Goodness, please don't, or make a confirmation dialog optional. I'm purely selfish here, since confirming that I really want to quit is not something that I feel should be especially safeguarded against and adds one more step (in VR especially). I'm quitting missions a lot (I spend a lot of time designing and testing missions), and accidentally quitting missions has happened to me (since it's such an automatism: ESC-look at quit-click), but not so often that I would want to add another layer of actions. Yes, you can lose some of your mission playtime that way, and I feel for you. But adding some safeguard that affects all and prevents an edge case seems excessive to me. The kind people at ED seem to be quite heavy-handed at UX, and I prefer they keep their attempts at user interaction at a minimum. For a quick demonstration at just how poorly DCS implements user UX, look at the CH-47 cargo interface. "Abysmal" would be a shocking compliment.

Note that while some of the (terrific) new objects (endless Kudos to Massun) do come with lighting, these lights are limited by DCS's (inferior, tuned for performance not eye candy, a choice that I will not fault) lighting engine; these lights aren't fully emissive in nature. This means that they don't cast shadows, nor light the interior of the cockpit, and are often too dim to be of practical use for helo flight simming. They do show up in some NVG, though (for example Huey), so another deep bow of THANK YOU to Massun. null

I strongly recommend that you only share missions that you have the author's permission to do so. Although obviously well-intended, the version that you have posted here is an older version that does no longer correctly run with current DCS, and it may reflect badly on the author. Just share a link to ED's user files where the mission has its home, and people can always find the most up-to-date version, and perhaps similar missions.

DCS's event API is a cruel joke on us mission creators. That event ID is only invoked every second blue moon for players who have two children or less and can't be relied upon.