Crescendo

Thanks, Ali Fish. Attached to this post is every '.log' file in my "\Saved Games\DCS\Logs" folder. Crescendo_logs.zip

Hi USSR_Rik, Thanks for the reply. What directory are these .log files located in, and which specific logs do you require?

Hello all, Problem: Whenever I exit out of DCS World the executable 'Launcher.exe' does not close. If I open and close DCS World multiple times, multiple Launcher.exe processes will begin to accumulate in Task Manager. For example, after opening and closing DCS World five (5) times, the Processes tab in Task Manager looks like this: If I try to manually close any of the Launcher.exe processes in Task Manager I receive the following error: If I use the 'taskkill' command with administrator privileges in command prompt, I receive the following errors: What is going on? I would be thankful for any help with this issue. [Note: This is not a showstopping problem I suppose, but if I were to open and close DCS World ten times or more in one computer session (which is not unusual), the total memory usage of the Launcher.exe processes becomes quite onerous.]

Viper, no offence taken on my end! Hashing things out like this is often inevitable when picking nits. If this is acheived by toggling "FZU39" to "No", then no, I don't believe it has any noticable effect. I don't have track evidence at this time, but from memory the BLU-108s still fell short in the "Easy - Spring" mission, and behaved normally in the "Kobuleti Target Range" mission. Right now I'm going to bed, but I can post some tracks tomorrow if you haven't already done so yourself.

Thank you for posting that link. Your experiences correlate with the tracks I posted above. The Abisi-Psta region in my second track is 1000ft+ above sea level, and the CBU-97 falls short.

Thanks for the reply, Viper. I do understand that releasing CBU-97s at higher altitude will typically promote a more 'normal' ballistic trajectory, as I mentioned in my first post (which you acknowledged above). I personally only flew as high as 10000ft MSL in the "Easy - East Georgia - Spring" mission, so perhaps that explains my issue. However, it is my experience — at least around the Kobuleti Target Range — that CBU-97s do not follow a ballistic trajectory at low altitudes. I have always assumed that this is normal IFFCC behaviour designed to specifically mitigiate the problem of BLU-108s falling short of the target at low altitudes. In these circumstances, it is my understanding that the CBU-97 trajectory is similar to the "Optimal" trajectory of a laser-guided GBU-12, only more exaggerated. That is, the impact point is calculated somewhere ahead of the target such that the CBU-97 has sufficient energy to ensure that the 1800ft AGL HoF release point occurs directly over the target. This is illustrated in the following track, where I release a CBU-97 using CCRP at ~2700R and ~250KIAS over the Kobuletic Target Range: CBU-97 - Kobuleti Target Range - 2700R.trk As demonstrated in the above track, the CBU-97 is clearly on an "Optimal"-esque trajectory. It then detonates above the targets such that the BLU-108s parachute down directly on top of them. Now, consider the following track, where I release a CBU-97 using CCRP at ~2700R and ~250KIAS in the "Easy - East Georgia - Spring" mission: CBU-97 - Abisi-Psta - 2700R.trk Note in the above track that the CBU-97 does not have an "Optimal" trajectory and thus releases its submunitions short of the target. The difference between it and the Kobuleti example is quite stark. Also note the radar altimeter after the pickle point: The terrain is essentially flat, so the CBU-97 radar altimeter HoF over 'bumpy' terrain does not appear to be the culprit. What is going on here? :huh:

Well, as promised I did some testing. I don't have any tracks to provide because I must have played multiple scenarios about 20-30 different times. First of all I took control of chardly38's track. chardly38 has edited the "Easy - East Georgia - Spring" quick start mission and changed the load-out to include 4xCBU-97. Here's what I found: All CBU-97s appeared to open too early and thus the BLU-108s always fell short. This occured at both low and high altitudes, at both low and high speeds, and using both CCIP (high angle roll-in) and CCRP (straight and level). This 'early opening' phenomenon can be somewhat mitgated by dropping from higher altitude (i.e. 6000ft+ AGL). The higher altitude allows for a more complete ballistic arc, such that the CBU-97 opens more 'on top' of the target. I was able to get a few kills on the initial two trucks this way, but the BLU-108s still fell quite short. Most of the time I was only able to kill one or none of the trucks, but I did kill both trucks on one occasion. The wind in the mission (210/17 according to LASTE) seems to exacerbate the problem. I tried entering the mutliple wind layers manually into the LASTE system, but this had no perceptable effect and the BLUs still fell short. In exasperation, I manually removed all weather and wind and the BLUs still fall short at all altitudes and speeds. At this point I figured there must be something wrong with chardly38's "Easy - East Georgia - Spring" mission file, so I opened my own version of this mission and edited the loadout to include 4xCBU-97. My results were exactly the same as the above bullet points. In light of this, I created a custom mission using the 'big X' target range near Kobuleti. I set up two trucks as targets and dropped single CBU-97s on them. Here's what I found: All CBU-97s opened directly above the targets and thus the BLU-108s were dispersed normally above the trucks, resulting in two kills every time. The above behaviour was repeatable from 3000ft AGL to 10000ft AGL at all speeds using CCIP and CCRP. I edited the Kobuleti mission to include the exact same winds as the "Easy - East Georgia - Spring" mission, but the CBU-97s still opened normally and I was still able to successfully destroy both targets (albeit with less skeets firing due to parachute drift). With these results in mind, I decided to check the "FZU39", "FNC TIME", and "HOF" settings of the CBU-97s in both chardly38's mission and my Kobuleti mission. As expected, both were set to default values and were identical. So, in conclusion, CBU-97s appear to open early when using the "Easy - East Georgia - Spring" mission, but open normally near the Kobuleti test range. Tweaks have been made in this area (not sure if they made it in to 1.1.1.1). But bare in mind, CBUs can have issues in mountainous terrain in reality as well. If you're dropping in an area with major variations in elevation, disable the radar fuse and just use the time fuse. For what it's worth, the "Easy - East Georgia - Spring" is set in elevated and mountainous terrain, but the actual ground around the first two trucks seems flat enough such that it shouldn't affect the radar altimeter.

I watched the track also, and yes, the CBU-97s are opening too early such that the skeets are unable to sense the targets. I'm at work now, but when I get home in a few hours I'll replay and 'take control' of the track so I can try pickling a few myself. I'll report back with the results.

Please post a track so we can see what's going on.

Addendum: UFC = Up Front Controller, as explained and demonstrated by other users above. "DMS" stands for "Data Management Switch". With the HUD set as Sensor Of Interest (SOI) and Master Mode set to CCIP/CCRP/NAV, left DMS short and right DMS short can be used to cycle between all default weapon profiles and all custom weapon profiles.

The reason your changes are getting "lost" is because they are being reset to their default values each time you select a different profile using the DSMS. For example, if you change the default GBU-12 profile to use CCRP, but subsequently go back to the DSMS status page and select Mavericks, your GBU-12 settings will revert back to CCIP (the default). This may seem counter-intuitive at first, but it's just how the DSMS works. The advantage of this system is that you can quickly adjust the weapon profile settings on the fly, but just as easily reset them to their default values when you're finished. However, this raises a question: How do I ensure that I don't unintentionally revert a weapon profile to its default values, if I don't want it to? To ensure that your changes are always "remembered", you can do any of the following three things: 1. After changing your desired settings, give the weapon profile a unique name (e.g. GBU12CCRP") and press "Save" using the relevant OSB. This will create a brand new weapon profile in the DSMS profile list with the name "GBU12CCRP". Because this new custom profile has been specifically created by you and is seperate from the default weapon profiles, it will always remain will retain your custom settings. To select your new custom weapon profile you will need to use the relevant OSBs on the profile page, or cycle through all weapon profiles using the DMS buttons or UFC. 2. Adjust the default weapon profile to suit your needs, but do not select other weapons using the DSMS status page. Rather, cycle through the weapon profiles using your DMS buttons or the UFC. Your settings will be retained because the DSMS only resets weapon profiles to their default values when a profile is selected on the DSMS status page, not when you select them using DMS/UFC. 3. Once you have adjusted your custom settings, do not select another weapon. This will limit your flexibility in combat and is therefore not practical, but it works. You're much better off trying to understand how the DSMS weapon profile system works and using method 1 and method 2. Personally I use method 1 95% of the time because I have a keyboard that is set up to easily type letters, which makes entering custom names very convenient. Furthermore, I think creating a new, logically-named custom profile is easier than remembering whatever settings you may or may not have changed in the default profiles. I like to set up lots of different profiles (e.g. master mode, autolase, ripple, spacing etc.), so for I find that having mutliple custom profiles makes the most sense. PS. If I've misrepresented any DSMS behaviour, please let me now. Nitpicks are very welcome. :thumbup:

As long as you're pickling from sufficient altitude (I would say at least 3000ft radar alt), CBU-97s will only do "nothing" when there are no targets to be sensed by the deployed skeets. In this case there will be no explosions and the skeets will simply fall harmlessly to the ground (by the looks of it, ED has not modelled the self-destruct feature). When testing CBUs-97/105 make sure you set up some targets. Don't simply drop them on open ground.

Totally agree. Something with a GUI would be very nice.

No problem! Realistic or not, my flare usage is likely to drop too. At the very least my flare programs and employment tactics will change.

Hi Eddie, Good question. I did indeed consider recording the pK (:D) of the SAM at approximately the "Test 4" phase. This is the point in testing at which the SAMs were reliably defeated by my flares. Luckily I have Tacview on at all times, so I went back and had a look at the evidence! Unfortunately, in a lot of the missions I simply exit as soon as the SAM is launched, but there are some examples to refer to. Here's what I found: The flare programs used in "Test 2" (2F/2s) and "Test 3" (1F/1s) are both poor when it comes to defeating the incoming SAM. The 2F/2s program is essentially useless and I was shot down repeatedly when using it. I would say that there is simply not enough flare 'density' to fool the SAM, especially when not maneuvering. The 1F/1s program is not much better — I was shot down almost as much as the 2F/2s program when flying straight and level. However, looking at the Tacview recordings, during one iteration of "Test 3" (1F/1s) I engaged in high-G missile defence maneuvers, and this did defeat the incoming SAM. It seems that the flare 'density' of 1F/1s is enough to fool the SAM seeker, but only if accompanied by missile defence maneuvering at suffcient altitudes. Now, if we consider the 2F/2s program with this missile defence maneuvering in mind, I suspect that the flare 'density' of 2F/2s would still not be enough to fool the SAM. However, admittedly I have no Tacview evidence to confirm this one way or the other. "Test 4" (3F/1s) and "Test 5" (4F/0.5s) is the point at which the SAM was defeated essentially 100% of the time without maneuvering. Of course I would have to run more than five tests to confirm this, but all missiles were easily defeated when using either of these programs. To specifically answer your latter question, at at all times when using the 3F/1s program the SAM initially tracked the aircraft, and only veered off course after launch. In Tacview the SAMs clearly track the aircraft, and are defeated at about the half-way mark when the proportional navigation trajectory suddenly shifts. On the other hand, the 4F/0.5s program is inconclusive. 4F/0.5s certainly defeats the SAM launch earlier, with most Tacview recordings showing the SAM veering off course considerably less than half-way to the aircraft. However, two Tacview recordings in particular are very interesting. In each of these recordings the SAM does indeed appear to be launched while initially tracking the flares! Either that, or the change in trajectory comes so early that it is indistinguishable to my eyes. Conclusions Flare 'density' matters when it comes to defeating the incoming SAM. For my purposes I'll define flare density as the rate at which flares are dispensed, and the amount of flares within, say, <100ft of the aircraft at any one time. Using an x/2s flare program does not appear to provide enough flare density, unless a high amount of flares are ejected at each impulse (say 5+). Using an x/1s flare program appears to be the "sweet spot" for flare density and subsequently defeating incoming SAMs. 1F/1S is the absolute bare minimum required to do it, but must always be accompanied by maneuvering and high altitude to reliably defeat the missile. 3F/1s defeats the SAM easily without maneuvering (provided sufficient altitude), and would likely defeat the missile even at low altitudes with appropriate maneuvering. I didn't test 2F/1s, but perhaps this program is the best compromise in terms of flare economy and performance, as long as the pilot maneuvers appropriately and doesn't fly too low. 4F/0.5s is essentially a gimmick program and is not at all practical unless you intend to "one pass haul ass", but even then it would leave you with almost no flares to counter an unexpected threat. Nevertheless, you could set it to repeat only 4-6 or so times, which could be quite effective if you simultaneously start the program and execute a max performance jink/turn. However, this would make it a purely missile defeating program, not one you would use just "in case" as a jack of all trades. In short: If your goal is to simply outright defeat the SAM at all costs, something in the x/0.5s range is suitable. However, if your goal is a more economical precautionary/defeat hybrid, something in the x/1s range is better. Personally, I think I'll program a typical 1F/1s program for economical high altitude "safe" situations, and a 2F/1s or 3F/1s program for all-altitude "dangerous" situations. :book: Good point. I'll remember that when FC3 comes out. :thumbup:

As promised I did some testing of pre-emptive flare usage. Testing parameters Threat: 1 x SA-13 set to "expert" skill, oriented directly toward player aircraft. Player aircraft: 1 x A-10C flying at 250KIAS, 9800ft, straight and level directly over threat. Countermeasures: Flare program started at 4.0 miles slant range to target, runs continously thereafter. Flight is repeated five (5) times with various levels of countermeasures. TGP measures slant range to the SA-13 at the exact moment of the SAM launch. This slant range is used as a crude measure of any delay in the launch due to flare employment. Results Test 1 - No countermeasures Slant range at launch: 2.6, 2.7, 2.6, 2.7, 2.5. Average slant range: 2.6. Test 2 - 2flares/2sec Slant range at launch: 2.5, 2.2, 2.5, 2.6, 2.6 Average slant range: 2.5. Test 3 - 1flare/1sec Slant range at launch: 2.6, 2.5, 2.5, 2.6, 2.6 Average slant range: 2.6. Test 4 - 3flares/1sec Slant range at launch: 2.3, 2.6, 2.5, 2.6, 2.6 Average slant range: 2.5. Test 5 - 4flares/0.5sec Slant range at launch: 1.8*, 2.6, 2.3, 2.6, 2.5, 2.4 Average slant range: 2.5. * I have no explanation for this aberrant result, and it has been excluded from the data set. Perhaps even an "expert" SAM operator occasionally falls asleep or forgets to press the right sequence of buttons! Conclusion This small experiment suggests that the employment of flares does not delay an IR SAM lauch in any statistically significant way. Beagle One is correct. Therefore, attempting to delay an IR SAM launch with a typical pre-emptive flare program (e.g. 1-2 flares / 1-2sec) is a complete waste of flares. Instead, a virtual pilot intending to take precautions against IR SAMs is much better off using short bursts of a typical IR missile defence program (e.g. 2-3 flares / 1sec) in vulnerable phases of his flight (e.g. on "final", egressing etc.). With this is mind, as of patch 1.1.1.1 the IR SAM doctrine should be defeating a potential SAM launch with liberal flare usage at key points in the attack envelope, not attempting to delay it with a "conservative" program and then transitioning to a missile defence program when necessary. *** Assuming the DCS modelling is correct — a big assumption — this causes me to question my own knowledge about countermeasures employment. In the real world, is the idea to delay or defeat the missile? I thought it was both, but if it's the latter, why do I see A-10s only dropping small, presumably ineffectual amounts of flares (1-4 flares over a ~3 second period) when egressing from a gun run? (Admittedly these are only training videos and I have no idea what restrictions are in place, and what the actual point of the exercise is.) Any subject matter expert care to clarify? :smartass:

Thanks, I forgot that link.

Hi all, This is a fairly simple request. I would like the ability to change the countermeasures load-out of my aircraft using the ground crew radio menu. This is because I find that the default load-out of 240C/120F is not ideal for some missions. This feature will be useful in mutliplayer (because the client cannot use the mission editor), and in singleplayer if you forget to edit your load-out before ramp starting. Personally speaking, if I were able to change the countermeasures load-out it would allow for a little more flexibility in the tactics I can employ, or simply improve my survivability against the primary threat in the mission without having to worry about prematurely running out of C/F.

I'll do so tomorrow, or I'll "+1" if anyone takes the initiative.

Well, I don't pump them out needlessly — only if I have reason to suspect that I might be engaged. Such circumstances would be if I break my self-imposed hard deck in a threat area, or if I am attacking any target below this hard deck and have reason to believe that the area is not completely sanitised of SHORAD (a prudent assumption in most cases, especially with MANPADS). When using the gun or deploying gravity ordnance I typically 'roll-in' on targets at close range from altitude, such that I am not flying at dangerous altitudes for any longer than I need to be. In other words, I'm not pitching down at 5° and continously dropping flares for 10 straight miles. :D Visability is not a concern because I expect I will be detected when flying in that riskier flight envelope. In low altitude circumstances I think a known counter to the threat of being shot down (pre-emptive countermeasures) outweighs the unknown chance that I will be able to hide from the enemy by not using flares. (In any case, if you want to hide there are better ways of going about it (such as terrain masking), but those have risks too.) At high altitudes I doubt your countermeasures would even be seen, and you're going to be detected by radar anyway. In short, I think you're going to be detected on the battlefield when flying around enemy positions at both high and low altitude no matter what you do, unless you terrain mask intelligently. It's not secret that any enemy force is going to actively expect to be attacked. The way I see it is that a non-radar guided enemy may visually detect me a few seconds earlier than usual if I'm pre-emptively dropping flares, but by the time that happens my flares are already 'protecting' me, and I'm either about to engage or I'm already egressing at speed having completed my attack. For a fixed-wing aircraft that has the relative luxury of speed this makes sense to me. If I were flying helicopters I would behave differently. I might be wrong of course. I'm always open to improving my practices. I always assumed it did, and in practice believe it to be so. Perhaps this is purely placebo on my part. :shocking: I'll do some tests tomorrow with a simple custom mission and will report back. For now I'm going to bed. :sleep:

I figured as much. Thanks. By the way, it's not a matter of my recklessly being fired upon or killed by IR SAMs, it's just a matter of personal tactics. I maintain a hard deck of 12k feet when the situation dictates it, but if I need to break that for whatever reason over the target area, I like to drop pre-emptive flares until I regain a safe altitude. I find having more flares gives me more flexibility. What's more, I can't remember the last time I've actually been threatened by a radar-guided SAM, because they are easily avoided with the present unrealistic implementation. Of course when I play a mission that dictates it, I do use the default CM load-out, or even add more chaff as necessary. It would be nice to be able to have the option to do it yourself. Sometimes you can't trust those pesky mission-makers.

Hi all, I would like to know if it's possible to change the amount of countermeasures loaded on my aircraft when playing multiplayer as a client. I know how to change the countermeasures load-out when creating a mission, but obviously this is not useful when playing on a public server. I am hoping that there is a feature similar to the rearm radio menu, or a ".lua" file somewhere that I can edit. Unfortunately, I think I already know the answer: Countermeasures load-outs can only be be set by the mission creator. If this is the case, I might make a thread in the wish list forum. (As for why I want to do this, in the current DCS environment of non-integrated air defence and lack of human air-to-air threats, I find that 240 chaff is simply too much. For me the biggest threats are IR SAMs, so I greatly prefer to have at least 180 flares so that I may use them liberally and pre-emptively. Furthermore, mission authors often simply forget to appropriately adjust the CM load-out to suit the mission. For example, quite often I've flown missions with the default 240C/120F load-out where there are no radar-guided threats (other than AAA) to be found.)

Thanks, repsol.

I use EXP mode almost exclusively. It's very useful for maintaining SA.

I measured my Cougar MFDs with a ruler. Ignoring the curved internal corners (i.e. assume a perfect square), the "hole" is 109x109mm.