cfrag

Version 2.4.1 -- 20250116 -- functional update And here we are, in 2025. Still no flying cars, nor jetpacks -- I remember watching the opening ceremony of the 1984 Olympics in LA, and my jaw hit the floor when this guy flew in using a jet pack - straight out of my sci-fi addled brains. Then I thought that it won't be long until everyone will be able to strap on and fly wherever they want. Today I realize that what I saw then was an early rendition of ED's "... and beyond" videos: long on promise... I'm still hopeful for both. And while reminiscing, I remembered the many unfinished things in DML. So this update connects many modules internally, and awakens sleeping potential between them: spawners now can set a lase code that is applied to units that have orders to lase targets vehicles transported with heloTroops now retain their ability to be controlled by players (Combined Arms) after a long time, "Sleeping Beauty" jtacGrpUI has been awakened and made a full DML module with a reporting system that rivals Messenger's flexibility Tied together, the changes significantly increase your ability to deliver broader, more interesting and better integrated missions that involve target lasing, troop transport, and CAS. I've also added a small update to Fogger, to make its use more intuitively: set the 'lcl' attribute, and it will add the local elevation to the fog's thickness, making fog end 'thickness' above the location where the trigger zone is located. It's a small thing, and adds a surprising amount of ease to Fogger. Finally, I heeded the advice of a friend who thought that the demo "Inferno at Sea" that exemplified drop zone functionality was too good not to turn into a fully fledged mission. So I took the demo, embellished it slightly and - presto! out came "Towering Inferno At Sea", a fun little helicopter naval rescue trainer. All changes in Detail: Documentation Main - jtacGrpUI (new) - updates to modules - lazie troops demo documentation QuickRef - various updates Demos - lazie troops (new) Modules - cfxZones 4.5.1 - (internal) support for wildcards - cloneZone 2.5.2 - fix for damaged! issue with verbosity - dcsCommon 3.2.0 - a ton of new and better wildcards infrastructure - better support for twn - fogger 1.1.0 - lcl attribute (new) - onstart attribute (new) - groundTroops 3.0.0 - support for lase code - support for CA 'drivable' - heloTroops 4.2.0 - filer troops with active despawn from pickup menu - code hardening against DCS bugs introduces with past releases - support for individual lase codes - support for CA drivable units - jtacGrpUI 4.0.0 - near-complete re-write - spawnZones 3.0.0 - support for individual lase codes - support for CA drivable with heloTroops Enjoy, -ch

Simply trigger a large CSAR zone with randomized location. The beauty of that is that you don't need to crash some beautiful AI planes, the CSAR zones creates a new randomized CSAR mission, and no planes get hurt in the process. If used as I describe above, autoCSAR is not impacted.

?

Create a trigger rule that never is executed (for example set it to Time more 9999999), and add an action "Sound To All" for each sound that you want to include into the miz. That way they are added to the miz and aren't automatically stripped ME's automated optimizer

Indeed, scheduled for tomorrow.

Apologies, I thought that this was closed. What item still needs resolution?

Please do. I'm sure it's just a tiny thing-

To get to the bottom of this, let's remove some variables: remove MIST and CSAR, as these are scripts that have nothing to do with DML. Then, when you are inside the Huey, when you go to Communications->OTHER (and remember, it is inside the OTHER tree), what menus do you get? There now should be HeloTroop's "Airlift Troops..." menu. In the "Other..." tree.

Oh, wait. Are saying that inside an aircraft (helicopter) you cannot see the menu for helo troops? In that case, please make sure that the helicopter that you are using is one of the helicopters that is a 'legal' troop transport, and if not, change the config zone so that it becomes one.

So we see that radioMenus (the module) did load correctly - we already are 90% there Let's see the zone that you built to display a menu, check all spelling and then see if and why it does not display. Can you check for simple spelling, and then (if all checks out), post a screenshot from the trigger zone's attributes?

When the miz starts up, the various modules usually print out some diagnostics, and errors if something goes wrong. Can you have a look at the messages DML puts up during miz start (if you erase them at miz start, you can go to message history) to see what DML is complaining about? That could already help you fix it. If that doesn't work, we can always look at screenshots from your trigger zone setup (look closely for typos, DML is as unforgiving as my elementary school teacher, a veritable Ms. Wormwood, here), and if all fails, post a simple version of your miz (without any mods), and we can try and find out what's going wrong.

Perhaps. Then again, we see the same terrible UX blunders in the sim (look at the 'join faction' mess, and the clownishly bad CH47 cargo dialog), so I'm not sure what to think - except that the result is the same: terrible, terrible UX and a bad customer impression. I wholeheartedly agree. Frankly, there is so much basic functionality missing from ME: try and change the faction of multiple groups or objects, something so basic that I would have thought that it would be the first thing to be implemented in a mission editor, yet two decades down the line, ME can't do it. Look at the tool palette at the left edge. EVERY UI designer knows how important the upper left corner and left edge is, and that they are the exclusive area for only the most important, most used tools for editing. In ME they are squandered for silly, third-tier functions like 'new mission', 'open' or 'save' that can easily be relegated to menus. From this I assert that no-one with even a hint of UX knowledge has looked at ME in decades, and I lament that it appears that this stain is now leaking into the main app (simulator) as can be evidenced by amateurish interface blunders like the 'join coalition' blunder and cargo clown show.

Unfortunately, I think that UX talent is exceedingly thin at ED. If you look at the UX/Implementation of the new band selection or last year's line art function, you start wondering if they have any UX expertise at ED at all, and counting yourself lucky that tabbing in dialogs works somehow, sometimes, in some places. Yes UX matters a lot, it's how customers experience your product. This realization seems not to have reached the relevant people at ED yet. So let us hope that the abysmal UX releases of the past 18 month become a thing of the past some fine day.

Agreed. This *might* be an option for some warbirds. In the jet age, this is as unrealistic as a 120 second repair job. What I would like is the option to taxi to a tarmac location on airfields to 'officially' turn in your aircraft. Upon arrival there you can get instant refuel, rearm and repair, just like with a full respawn. It's unrealistic, yes, but it may give a sense of accomplishment and satisfaction to players.

Indeed. Plus the Su-25T. It does not apply to many (all?) FF modules. So, for example, you must shut down the A-10A to rearm, but not the C. I *thought* that the Ka-50 was also affected, but, alas, I seem to misremember.

I'm not conversant with DCE, but DCS level 2.5.6 seems a bit out of date. May that be an issue? We are currently at 2.9.11.x

It's abysmally bad interface design that prevents usage rather than enhances it. Unfortunately, it seems to me that one of the most urgent acquisitions for ED is some UX talent. The 'multiplayer join side' dialog already was really bad (and shows how a team can completely screw up UX with a dialog that has just three buttons and some text); the Hook's cargo dialog(s) are worse. This band selection thing UX looks like someone intentionally violated all UX best practices to see what prank they can get away with. To me, it's a really bad trend, and since an application's UI is also its calling card, it badly tarnishes DCS's look as amateurish. We know that ED can do better, and I'm hoping that they do improve in the the near future.

Yes! And optionally also allow mission designers to get rid of the requirement to shut down the engines for rearming.

Agreed. I think that it is why it would be a good idea if Mission Editor allowed more options under control of the mission designer. The repair time wait interval may be something to allow a mission designer control over. There are others, but OP chose this as their request, so I am focusing on that. Indeed. Then again, nobody outside of ED knows what DC really means in the context of DCS, so I'm waiting to see if and what materializes in the years to come. I agree that whatever ED delivers, there will be many discussions and more friction between people and their ideas of what a "proper" mission may be.

There is one way, but it is currently limited to reading and setting flags. Network's doString_in() is set up generally to execute in other environments, but at this point in time, it only executes the methods that read and write mission flags,

Aplologies for being unclear. What I meant to say is that a 3 minute wait before repairs commence appears arbitrary to me and IMHO serves no discernible purpose. For that reason I (as a mission designer) would like some control over this to eliminate it altogether. I see no added gaming value in those three minutes over any other, arbitrary, value. To me, a game is what you, the player, make of it. DCS's online segment is (IIRC) around 10-12% of the entire user base, and there are many disparate gaming styles in that community. To me, there is exactly one way to play DCS correctly: when you have fun. Some people like one play style, others prefer another. And IMHO all are valid - as long as you don't have fun at the expense of others, e.g. as a Griefer (who should eternally rot in a deep, dank dungeon). When I create a mission, I strive to make it fun so that as many people as possible enjoy it. I don't control what other people like, and when people tell me that they like to try a certain aspect in a new mission, I'll try to accommodate. Over time, successful patterns emerge - for example the "Foothold/Pretense" style of content seems a good, successful formula. So if people enjoy what you call "air quake", let them have fun. If you don't like that style, simply look for a different server that serves up a mission that better suits your playstyle. Neither is better, you merely prefer one.

Perhaps. Fact is that in my experience it has been shown that trying to force people to do something (e.g. enforcing no runway take-off etc.) leads to smaller groups and a less popular mission/server. Trying to impose one's will on other people seldom works in favorable ways. Agreed. Given the alternative instant respawn through re-slotting, I don't think it's going to make a big difference. With instant repair people may take the effort and try to RTB and land. In many of my missions I try to incentivize the latter by awarding points for kills etc. only after landing back at base. People then still re-spawn to skip repair, rearm and refuel time. Most people that I know are on the clock when they play DCS: they have kids, partners, elderly relatives, and a job. They feel that they can't be bothered to waste 5 minutes of their quality time on waiting for an arbitrary silly time. DCS is UT with an optional 5-10 minute break after downing the potion, there is nothing realistic in DCS in this regard either. If your plane gets dinged up, it's in for a couple of months in the shop. Even if not, after you land, you are in for a multi-hour debrief, some more debrief with the intelligence dudes, some sleep, and at least a day of prep for the next sortie. There is no way that you'd take off 10 minutes after landing a smoking husk of a plane, that's pure arcade gaming, so we may as well concede that.

What makes you believe that there isn't any in DCS? Can you put a number on that? I believe that you mean to request 'occluded object culling', i.e. that objects (geometry) that are behind other objects or terrains should be culled (removed) from the rendering pipeline before they are submitted to rendering. I believe that DCS already uses object culling for the viewing frustum. Adding a visibility pass to determine which objects occlude others doesn't add much, and may even be more expensive - this is especially true for large objects like carriers or buildings that may be partly occluded and require tests to determine if all their geometry is occluded. So simply rendering all geometry inside the view frustum can be a much more cost-efficient approach compared to trying to cull objects/geometry by determining if they are obscured (occluded) by other objects/terrain. I believe that since around 2005 most render pipelines support a 'bounding box' check for early culling, and it's usually applied for initial view testing/culling during the render process. Applying it after view (frustum) culling on the remaining geometry, to determine mutual occlusion requires that the (massively parallel) GPU first waits for all view culling processes be complete before it can start on mutual occlusion culling. This forces a global synch of all parallel operations in the pipeline. That breaks the rendering pipeline into discrete steps and I believe that it will induce a heavy performance penalty. I do not fully understand what you are recommending here, and why that would improve performance. But it's been a couple of years since I last worked on render processes, so maybe things have changed drastically. (Note: I think it best to disregard 'client-side' from the title, because I think that all rendering in DCS is done on all clients exclusively, no rendering is done on the host.)

Ah. Make sure that you try this in the "mission" environment in the console first. It is well possible that GetDevice() is only avialable for the "export" environment

Indeed. At that time, it made sense since The Hog was DCS's premier attraction, and it was rather well known that NTTR was where the hottest Hog action was taking place (in the form of training of course). It may also have been a nice way for ED to monetize work that ED did for their military customers that used the Hog sim, and quite likely also wanted/used the NTTR map.