SlipHavoc

No, it was Lt. Lothar Zogg, the radio operator in the B-52.

I love how they're putting in 120 airbases, plus dozens of smaller fields and helicopter bases, and like half the comments about it are "not enough airbases, you should have put in my favorite ones, unplayable, will not buy".

I found a possible bug with the 1LOOK RAID mode. In both RWS and TWS mode, with 1LOOK off (DATA OSB, 1LOOK unboxed), you can lock a target with STT, press the RAID/FOV HOTAS button to enter RAID mode (boxes EXP), press again to leave RAID mode, unlock the target, and the radar returns to your search settings (azimuth and bar). However, with 1LOOK on, lock a target with STT, press RAID/FOV HOTAS button, press again to leave RAID mode, unlock the target, and the radar is now in a very fast 3 deg azimuth scan. Pressing the azimuth OSB then sets the azimuth to 23, 43, 63, 83, and then 140, and then cycles correctly through 20, 40, 60, 80, etc. Track file attached, please let me know if you need any other info. Thanks! Keywords for searching: 1look, one-look, one look, raid F-18 radar 1look raid bug.trk

I've been doing some practice with the radar and found an issue with the TWS mode. Normally, you should only be able to have a 6-bar scan with a 20 deg azimuth, and if you set the bars and azimuth with the OSBs, that is enforced. But if you set the azimuth to 80 deg using the OSB, and then use the HOTAS controls to set the bars (move the TDC cursor up to the bar setting and use TDC press to select), you can select 6B and the radar will remain at 80 deg azimuth, which it shouldn't be able to do in TWS. If you then press the azimuth OSB, it will be set to 20 deg and can't be changed, which is correct for 6-bar. Short track file attached, please let me know if you need any other info. Thanks! F-18 radar hotas tws bug.trk

None of the maps in DCS look like they came from a 25 year old game console. That's language inflation at work again. You can speak up without resorting to the most extreme adjectives.

It seems there is a language inflation thing happening over the last decade or so. Things are not merely bad or suboptimal any more, they're abysmal, abhorrent, terrible, disgusting, worst ever, etc. And things aren't good or better any more, they're fantastic, amazing, glorious, epic, brilliant, etc. It's really annoying. No wait, I mean, it's abysmal, abhorrent, terrible, disgusting, and worst ever.

Almost every plane we have in DCS, other than the WW2 props, is a Cold War era plane. People seem to forget that the Cold War didn't end in 1975, it ended in 1991, and included the entire first decade of the computer revolution. There were plenty of planes with MFDs, HUDs, FLIRs, and other technology that is still relevant today. The F-15C, F-16C, and F-18C are all Cold War planes, and so is the F-15E. It's always fun to see the Viggen brought up in this context as well, since the AJS-37 that we have in the game didn't enter service until after the Cold War (1993 or so). Although I do think it would be great if ED could add an option to the Mission Editor to restrict pilot helmet options, so missions could enforce whether HMD and/or NVGs are available. Other than weapons, that's probably the single biggest and most noticeable anachronism for a Cold War setting for the F-16 and F-18.

I think they learned a lesson about roadmaps, which is that people take them way too seriously, and then literally for years afterwards, bring up stuff that hasn't been done for various reasons, always in the most rudely sarcastic and negative way possible. I'd be quite surprised to see any kind of official roadmap published for 2025.

A couple years ago I published the initial DCSAutoMate version. It was pretty rough, with a bare-bones console interface and very little error checking, but it worked. I'm now happy to announce **DCSAutoMate v1.0.0**, which is pretty close to the vision I originally had for the program in the beginning. It's now a proper Windows GUI, and although still basic, has a much easier interface and a lot more capability. The GitHub page has the full documentation, as well as the source code and a complete zip file: https://github.com/SlipHavoc/DCSAutoMate Main features: Write your own Python scripts to completely customize any startup checklist in DCS. Scripts included for the following modules: A-10C and A-10C II A-4E community mod AH-64D AJS-37 Viggen AV-8B NA Harrier C-101EB and C-101CC F-15E F-16C F-4E F-5E F-86F F/A-18C Ka-50 Blackshark II and Ka-50 Blackshark III Mi-24P Mi-8MTV2 OH-58D UH-1H All included scripts have at least Cold Start and Hot Start, many also have Air Start and Shutdown, and support multiple variations such as ground or carrier, day or night, HMD or no HMD, etc. Uses DCS BIOS to move any cockpit control, and can now also read cockpit controls to make your scripts reactive. Can also send keyboard commands to DCS to move controls that aren't mapped in DCS BIOS. Open source and free to modify or customize as you wish. I've made this primarily for my own personal use, so the included scripts do the startups that I use myself, which aren't necessarily the "proper" steps, but are reliable and get the plane into a fully combat-ready state. Most of the scripts are heavily commented, and DCS BIOS has pretty good documentation so they should be easy to change. Inspiration for this originally came from programs like DiCE, DCSTheWay, and DCS Scratchpad. My thanks to those authors for showing some of what can be done, as well as the maintainers of DCS BIOS, ED for designing a great game that supports things like this, and the authors and maintainers of all the many Python libraries, IDE tools, and other infrastructure that goes into even a small project like this!

Maybe it's only the SAMs then, because I just tested with AIM-9Ms and they track flares that are in the air before they're fired. I used an F-15C, so it doesn't have the new tracking code. I didn't get tone on the flares, but as soon as I fired it went straight for the flares that were in the air. Anyway, from a practical standpoint, it seems like this new ability to see what the missile is actually tracking before it fires is mostly an advantage. Previously if a target was pre-flaring you would just fire blind, hoping the lock it claimed to have on the target was really on the target, but now, you'll know, and you can adjust accordingly. Now I wonder if IR missiles will track parachute flares, like illumination rockets. And whether this is also a step on the road to getting IR missiles that can track ground targets... As far as the coding goes, apparently you think it's simple, but what I'm saying is that you don't know whether it is or not, unless you're an ED programmer. But the fact that it has to be implemented per module, and that it wasn't implemented for every module on this release, suggests to me that it's not as simple as you think. Programming is funny like that.

What a missile is able to detect is up to the missile (or should be), but how it shows what it's detecting is up to the launch platform. If you have code to support all the things that any launch platform can get from a missile, and all the things any launch platform can command the missile to do, it could be pretty clunky. OTOH, one of the lessons I've learned from my years of programming is that you can never tell, looking at it from the outside, how much effort will be required to make any given change to a program; it depends entirely on implementation details that you cannot see until you're neck-deep in code. So my saying that a standard function for this would be too clunky is also a guess, albeit informed by ED saying they have to implement it separately on each module. I'll have to do some testing on my own to see what is tracked and what isn't, I can't tell what those videos are trying to show. I'm not sure what the practical difference will be though. Before, the F-18 for instance would show the missile locked on the target, but on launch, it would immediately go for the flares. Now, it'll show it actually locking onto the flares, and you can hold off on launching until the other plane runs out, so that'll be an advantage. I guess on the other hand, in a plane that can't cue the seeker to a radar target it might be a little more fiddly to get your lock back onto the enemy if the seeker starts tracking a flare, but if you're saying that any flares dropped before a missile launches are totally ignored, I'm definitely going to have to test that myself to verify, or see a video.

Come to think of it, is this actually going to be a disadvantage? I haven't yet had time to play today after the patch, but my thinking is that this isn't going to change whether the missile is decoyed by pre-flaring, but rather that you'll actually be able to see it tracking the flares before you launch, so you can tell if it's locked onto the target or the flares. Seems like that is going to be an advantage for the planes that have it enabled. But in either case, it's just a visual indication, and pre-flaring works exactly as well as it always did. I could be wrong about how this is going to work though, looking forward to trying it out.

Having a standard function has both advantages and disadvantages, that's why I said it's a tradeoff. ED picked the option where there isn't a standard between planes, and that has its own advantages and disadvantages. One disadvantage is what we see here: adding pre-flaring tracking behavior presumably requires modifying the function separately in each module. However the advantage is that each module can have specialized behavior in that function that fits with its own avionics, and the function can be smaller and customized to that specific module. As it turns out, I am a professional programmer. I do mostly web development, but this exact same tradeoff appears all over the place, for instance in whether to use an existing framework or roll your own, use an ORM for database access or write your own custom queries, or to make web controls generic and reusable vs customized. There is no universal right answer, and it seems there will always be someone looking over your shoulder and armchair criticizing... IMO ED should not be optimizing for multiplayer competitive deathmatch anyway, so I don't really care if one module or another has some kind of "exploit" for a while that makes it unrealistically better or worse than it should be in Growling Sidewinder or SATAL. Of course I would like it if the behavior is kept as consistent as possible across modules, because I do like realistic behavior, but I expect ED will do that, it's just going to take more time because of the tradeoffs they chose in this case. And anyway, even if this behavior were perfectly consistent, there would still be "exploits" you can do in deathmatch servers, starting with the fact that your life isn't on the line, so you can take unrealistic risks. You can also optimize the HOTAS controls to be much better than the real life planes, run in lower resolutions, sit in a comfy office chair instead of an ejection seat, and pull the paddle switch in the F-18, and many other unrealistic things.

It was always a game, and always will be a game. If you want full reality, the only option is to join your national air force. As far as different coding for different modules goes, that's simply the way it is, it's not an "excuse". In coding there's always a tradeoff (one of many such tradeoffs) between modularity and standards vs flexibility and specialization. If you have a "standard IR missile tracking function" that is used by all the planes, then adding pre-flare tracking to that function would enable it in all the planes. But that function would also have to have code that handles how IR tracking actually works in every plane, making it bloated and hard to maintain, and maybe slower, and if it has a bug then it affects all planes too. Games of the past (I've been playing combat flight sims even longer than you) didn't have anything like the complexity in DCS, and didn't have third-party modules at all, let alone ones that are as or even more sophisticated than the first-party modules, so they never had to deal with problems like these.

I had thought that it took a lot of throttle as well, but I found that once the RPM is over 56%, it takes about 8-9 seconds for the light to go out, and that was throwing me off. I am able to get the light to go off reliably by advancing the throttle just enough to get it over 56%, and then waiting. I also tried in the air, but was never able to get the RPMs under 56%. Not sure if that's because my forward speed was always enough to windmill the engine up past that RPM, or if there's some difference in the engine system that accounts for weight-on-wheels somehow. I even tried doing a vertical climb and turning on active pause just as I started to tailslide so my airspeed was almost zero, and the RPM never dropped below about 61%. I also tried a hot start on the ramp with a 100+ kt headwind to see if that would windmill the engines up, but it didn't, and I was still able to get the ENG START CYCLE light to come on in the A-10C at least. So there's something odd going on under the hood. At least there's an easy workaround by just advancing the throttles a bit. Anyway, thanks! Hopefully this is enough to troubleshoot.