cfrag

To not beat about the bush - is it possible that you are using DML's QuickRef to base your mission designs on, and when running into issues you sometimes forget to check the main manual and the demo missions that are (pretty much unless the last DCS release screwed up) known to work? So, do DML's persistence demos work on your DCS installation? It's entirely possible that DCS's last release has thrown a spanner into the mix, or that something else is amiss that I need to fix. I'm happy to do so, and I would love some good examples that I can follow up on.

Oh, come on! Nobody who ejected that way ever complained!

Agreed. The problem is that we no longer live in an environment that is conducive to that kind of business. I would prefer to see ED/DCS to continue, rather than die on the hill of old-school business principles. I saw more than one company go down for "standing their ground on principles" rather than going with the flow, and it'd be sad if DCS goes the way of the Dodo because it can't adapt. We already see the detrimental effect that the current situation has on DCS: the core is increasingly hollowed out, we get increasingly immature modules that can't make it to the finish line within years of them going 'EA', and it takes longer and longer for ED to complete features promised almost a decade ago. I won't really be 'happy' to pay subs, but I'd prefer paying a sub over losing DCS altogether. Looking at DCS core's current state certainly makes me feel uneasy: too many band-aids, too many unfinished or missing features, too many really, really badly implemented functions (look at ME's multi-object selection for a rude awakening of what ED today deem "production worthy"), and a steady flow of unfinished new products. IMHO, without a paradigm shift, DCS is heading for a cliff in the foreseeable future. I'm hoping that will change, that ED re-orients, and I am perfectly willing to pay a price for that.

Agreed. I wish that ED would sidestep the issue entirely and get onto a steady income trajectory. Of course I purchased the "thin" Tiger update, and it again made me think about alternate, more steady sources of income for ED, like having free DCS like it is now, and "Pro" DCS on a subscription (that steadily funds core dev) that has everything DCS has now, plus more, like Vulkan, fog, a much better UX, etc, and the ability host missions (or similar). The point not being what exactly "Pro" would constitute, but providing a steady income for ED (and Nick's own comments be damned) to finance improvements to the aging core. I'd be happy to pay this 9 USD each month if we could get that same volume of change / improvement each month (I'm already spending some 100 each month to host two public servers, so I deem 10% of that a sage investment into the foundation). Who knowns, it may also enable ED to engage someone who actually knows UX design -- the past three additions to DCS (MP faction selection, cargo management and multi-object select) are so abysmally amateurish and bad that it breaks my heart just looking at them.

Bah, you guys are sissies. Sitting in the sledge, getting cozy heat from the jet exhaust! We here in Switzerland use a propeller plane! NO heating for Santa, just like God had intended it.

saveNotification When set to true, each time that the mission is persisted, a text notification is sent to all players. Default is true (notify players when saving) Doesn't that work for you? This usually indicates that something in your DCS setup is non-standard and you may have to use "root", "serverDir" and "saveDir". Please also remember that the data is saved into a directory that has the same name as the mission itself, not at the mission level.

Version 2.10 - Fog Control - 20241206 This update provides support for DCS's new Fog system. Use Communication -> Other to get to the Fog control to get any fog density and remove fog altoghether. Enjoy, -ch

I may have been joking about the Typhoon and Fulda map - but today is St. Niklaus day, and here is something for you DML friends to enjoy: the "fogger" fog module in working, but not completely finished version, along with a simple demo that allows you to change the current fog via the communications->Other menu. Happy Nikolaus! foggy bottoms.miz fogger.lua

Version 2.3.8 - Feature Update - 20241205 You all know the conundrum: there is this one-time event when a player - any player - does this one thing, and this should start something important in your mission. This is especially important if you are designing multiplayer missions that do not pause and wait for players to join, but happily run on the server. DML now provides "Usher", a module that is designed to handle many first-time PLAYER-events -- like player "XYZ" connects for the first time (similar to "Valet", except that Usher only reacts to the very first time), the first player enters a specific unit, the first player joins a particular faction, or the first player to enter a specific aircraft type (e.g. an A-10A) In addition to being able to send out some very crafty special commands, Usher also comes with some (to me at least) QoL abilities to generate dynamic text output with advanced support for wildcards. Other changes include a massive internal overhaul of MX to correct for an unannounced "feature" in DCS that screws with objects when they are killed, that patches into coalition.addGroup() - a significant change that luckily remains completely under the hood. Also, yesterday saw the release of a new DCS version with new Fog abilities, and I'm now looking into providing simple DML support to create fog at the drop of a hat. Below is a sneak peak of that ability, showing the upcoming Typhoon landing in heavy fog at Bamberg airfield (unannounced Fulda Gap map): All changes in detail: Main Usher (new) Usher me to my plane demo (new) Various updates Quick Ref Small updates Demos Usher me to my plane demo (new) Modules - cfxMX 3.0.0 - patch coalition.addGroup to be able to rececord all spawns - read all objects and reference them by name - new reference functions to backtrace statics to their original dynamics - convoy 1.3.0 - start & arrive messages only when wpupdates are enabled - new "listOwn" attribute - dcsCommon 3.1.4 - better wildcard support - fireFX 2.1.0 - rnd support for fire size - better support for persistence - playerScore 5.0.0 - completely rewrote logic for detecting kill - supports penalties for neutral kills - reconMode 2.4.0 - improved SALT, naval units - no optimization for naval checks - new optimization for groups that have been spotted - bearing and distance from pilot added - usher 1.0.0 - initial release - valet 1.1.2 - new wildcards <u>, <p> and <g> to harmonize with usher

This appears to be a common, known intermittend DCS multiplayer bug. I've reported it a couple of months ago, and there is some hope left that ED eventually get around to fixing it. Maybe this is something to report in the Kiowa forums, I have no affiliation with Polychop other than that I own their models and like the Kiowa.

Huh. The good: there now is a kinda-sorta multiple object select in ME. From an UX perspective it’s an almost comically inept implementation. if it wasn’t so sad, that is. Seems to me that interface design and DCS simply don’t mix.

Huh. Now, don't I look like a shave-tail louie. Thank you, @Flappie --indeed, I didn't notice 'player' instead of client! Cheers, -ch

I recently noticed the following odd behavior when spawning player aircraft that seems different from jet versus warbirds, that can be easily re-produced. Create a miz, add a client each for a frogfoot Su-25T and a TF-51 cold from ground (see enclosed ref miz) Start the miz. Enter Frogfoot. Note no other plane in sight Re-slot to the '51 Note that the Frogfoot is gone (expected behavior) Re-slot from the 51 to the Frogfoot. Note that the '51 briefly disappears (expected) From the Frogfoot's cockpit, note that an AI TF-51 has spawned hot, and starts taxiing. (UNEXPECTED WORRISOME BEHAVIOR) Why is that? Is this new behavior? I usually don't create miz with warbirds, so this is the first time that I have noticed this. It is very odd and (to me) disconcerting behavior when de-spawned player aircraft exhibit fundamentally different behavior and (much worse) client aircraft re-spawn as AI aircraft. Or am I simply doing something wrong? My thanks to anyone who can shed some light into this ( @Flappie - you seem to be quite knowledgeable in DCS's deep waters?) strange spawns.miz

Indeed. People "doing their own research", thinking they are "special", and that they are privy to some "secret" knowledge that is somehow suppressed by "orthodoxy", suppressed by "them". You know: Anti-Vaxxers, Flat-Earthers, Q, Sov-Cits, you name it. That's why I prefer to withdraw when these people show up in a thread.

Well, if it's a third-party addon (a.k.a. "MOD") or paid-for DLC, it's a no-go for any server-based mission, I'm afraid. I'd love to see some more 'local color' so to speak in the form of various animals, and do hope that ED find it in their time to provide them. They are a nice addition for helo drivers, but completely irrelevant for the jocks, and they do not fulfil the criterium of "must-have". Then again, SA came with penguins and orcas, and I loved that, for reasons I can't rationally explain

I always thought that "five is right out"? My Antioch manual requires updating, I see. Anyway, for me it's lights out when the conspiracy theorists enter the stage, and I think that this thread is well past that point.

I don't think it ever was. It's a haphazard, silly implementation that points to an underqualified temp worker with a passing knowledge (i.e. might have flown with someone and heard some chatter) of some procedures. When someone rambles about DCS's supposed 'realism' this is the first thing that comes to my mind. "Realism" my left foot. The current implementation is a bad joke, and a massive blemish on ED's record. My father used to say "anything worth doing is worth doing well". Sadly, no such ethics evident here. I prefer current ATC taken out completely rather than having this broken, amateurish stuff. It seems that ED have gone that step in Multiplayer already (GND/TWR no longer respond in MP when you contact them).

Here are the new versions of MX and PlayerScore, plus a demo miz that shows a negative score factor for neutral kills. Enjoy, -ch playerScore.lua cfxMX.lua Neutral kills the mood.miz

It would require the exact same work in Ungrief. The challenge is to differentiate between a unit kill and an object kill. Until DCS changed stuff internally, the method of choice was to look if the killed target belonged to a group (making it a unit) or did not have a group (in which case it was a scenery or map object). So, if you kill a map object (which are all neutral) simply by missing something else it would look like a neutral unit kill. If Ungrief was watching, you'd be kicked unless I find a way to discriminate the two. So, I'm looking for a clean solution that then also can be back-ported to Ungrief. Oh, and the change also affects Red and Blue units. The issue was mostly masked because of the other checks that PlayerScore performs and still was able to backtrace the kill.

Perhaps, but IMHO not the most important ones (i.e. the ones people associate with nukes): Flash and mushroom cloud EMP and shock waves (heat, pressure) moving at different velocities Ionizing radiation that prevents/disrupts radio comms When I was working on an 'inferno' type script that simulates large-scale conflagrations, I also observed the detrimental effects these visual effects have on game performance, so simulating a firestorm on the ground, although simple to achieve, is also not advisable. So if all you want is lay waste to the map and your miz's performance - the destruct zones can be your ticket. And they don't synch over network, so this is a single-player only thing. And if your fps is still above 2, add fire/smoke effects until it drops well below the 1 mark

Say what? That is entirely not the going educated opinion. Just what sources are you referring to? A "mild" nuclear exchange (say on the Indian sub-continent with some 100 nuclear blasts) is expected to kill a quarter of a billion people world-wide, most of them from hunger. In the event of a Russia-US nuclear exchange and several thousand nuclear explosions happening, the expected result is a nuclear winter with a near-total collapse of trade -- and the hunger-death of a couple of billion people (you do realize that Earth's population can only be sustained by industrial food production that collapses because trade collapses): the resulting famine will kill off 50%+ of humanity worldwide. Here's some educational material that may be helpful, and it's nicely presented:

So I started on that, and I found that although the nMod change was small, some undocumented DCS internal changes *really* threw a spanner into the entire playerScore module. The fix is inbound, and I think I can finish it by tomorrow so you can have an early version to test. But - man! DCS Mission Scripting Environment is a hot mess. Now, when you kill a ground vehicle, it instantly loses the group that it was part of. I can fix that with some trickery, sure, but that requires the MX module write down all known units and groups. And that means that DCS's own coalition.addGroup() method needs to be patched so spawners and cloners still can spawn and have their spawned units be correctly recognized... what a mess. I'm now knee-deep into engineering a minimally invasive fix, and with some luck I can contain this mess to changes to two modules: MX and playerScore. Keep your fingers crossed.

We have to protect our precious bodily fluids. Huh. Not one, but two classic quotes in a single comment. My hat is off (if I had one) to the DCS community !!

Now that is indeed something that I overlooked, thank you for the hint. I'm adding a new attribute "nMod" which is a multiplicator applied to killscore for neutral kills. It defaults to 0 (sets the score to zero), and if you really want to punish your players, set it to -10 or -100 (or even higher, ummm, lower) which will tank their score near irredeemably. I'll start working on that soon.

Indeed, and unlikely. If a civilization has harnessed energy in a way that it allows them interstellar travel, their mode of transportation would certainly not be susceptible to a primitive (from their perspective) energy-based attack, much like today's tanks aren't susceptible to [primitive kinetic-energy] attacks like small rocks flung from a sling -- and that technology gap is only some 10'000 years. Nuclear bombs may seem awesome for us today; to a Kardashev Level II type civilization, they are likely to be quaint jokes; spit-balls and similar, what children get to play with in kindergarden.