SlipHavoc

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.

There's a related bug for the A-10C and A-10C II here, but I've found it also affects the A-10A: In testing, I've narrowed it down more and was able to replicate it reliably. The A-10A starts the left engine fine, but fails to start the right engine if the outside temperature (as set in the Mission Editor) is 7 deg C or below. If the temperature is 8 deg C or above, the right engine starts just fine. However for the A-10C and A-10C II, it fails if the temperature is 4 deg C or below, and works if it's 5 deg C or above. In the A-10C, I think the problem is because the engine idle speed is just under 56% at that temperature, and so the ENG START CYCLE light stays on (manual page 582 says the light will be on if the RPM is below 56%), and the other engine won't start until that light goes out. (Note: This also affects manual startup, not just the auto start. The other engine will not start if that light is on.) I think the same thing is happening internally in the A-10A, but with slightly different temperatures. Workaround for all A-10 models is to advance the throttle a small amount so the idle speed when it starts up is just over 56%, that allows the second engine to start. Please let me know if you need example tracks or scenario files, but it was very easy to replicate once I figured out it was temperature related. @Yurgon for visibility as well.

I only play in VR, so your guess is wrong. Your negging posts are also not above reproach, and I'm reproaching you.

It's interesting to me that people think they can get others to do something for them by calling them amateurs and unprofessional. Is this like negging but for software?

I've been looking for those for quite a while. I found two maps where the EWR locations are marked, but they're large scale maps showing the entire country, and the markings are about 12 km square or about 7.5 mi square. I've spent a while in Google Earth trying to find any sign of the sites in those areas, but haven't found anything definite, even with the historical imagery, although I haven't searched systematically. But I'm also not sure the markings are correct. If anyone has exact coordinates that would be much better. One of the maps is in On A Steel Horse I Ride (a history of the MH-53 helicopters, which guided the TF Normandy strikes among many other things in their long careers), page 338. Another is this book excerpt about TF Normandy. The markings are in the same place on both those maps, although I'm pretty sure I've seen another map with the markings in a different place, but now I can't find that map or remember where I saw it. I'll definitely be following this thread.

On a related note, for anyone interested in all the many considerations that go into designing and improving flares, I found a (publicly available, unclassifed) document called GENESIS of INFRARED DECOY FLARES: The early years from 1950 into the 1970s, by a person working at Naval Surface Warfare Center, Crane Division. I haven't read it in detail, but have skimmed it, and it discusses things like the pyrotechnic composition, ignition time and reliability, radiating spectrum, safety, visible plume area, liquid vs solid pyrotechnics, effects of aircraft speed, and many other factors. There is way more that goes into countermeasure flare design than I had ever thought.

This map still has the southern half of Israel, and the Syria map has the northern half.

I'm pretty sure some people here would actually celebrate, which is bizarre to me.

I'm aware that the video was a very basic startup sequence, but at least one of the YT comments was about the PWR XFER switches specifically, and there was related moaning about it on one of the reddits, and I thought it was interesting that those switches were mentioned in the manual. I too never bother with the full and complete startup sequences including all the self-tests and BITs and fire light checks and whatnot. If I wanted to do the boring part of flying, I'd join the air force... In fact I created and released a utility specifically to completely automate and customize the startup and shutdown scripts (like the built-in autostart sequences, but more so, and MP server compatible) so that I never have to do them manually. For the cargo loading, good to know, thanks!

In the Quick Start guide that was just released, the startup checklist includes the following: LOAD SHARE switch - TRQ PWR XFER 1 and 2 switches - ON (after APU start)

Very interesting, thanks! A few things I noticed: The FAQ says "DAFCS and force trim" will be coming later in early access, but on page 56-57 the description of the Centering Device Release Button sounds like the force trim system that is available on most other DCS helicopters. There was a good deal of speculation about what the trim system was going to be, so it'll be interesting to see what the initial implementation ends up being. In the startup checklist (starting on page 77), page 81 says to turn on the PWR XFER 1 and PWR XFER 2 switches after starting the APU. This is also in the abbreviated startup checklist on page 133. There was a comment about those switches on the YouTube startup video (and related poo-flinging in reddit), as that step was not shown in the video. I would say I hope this serves as a lesson to people to be patient, but I know it won't be. Poo-flinging is so much more entertaining, unfortunately. Logistics features are detailed starting on page 115. Looks like there's a new cargo loading interface integrated with the rearming screen, and implying that it interfaces with the internal warehouse APIs. And if I'm reading it right, when the module is complete it looks like we will be able to carry up to 7 different types of cargo simultaneously: 4 internal pallets and 3 external sling loads.

...And I guess now we can see why it takes a long time to develop a feature like this, even though some people maybe think it should be easy. "Just make it so you can select whatever plane you want to start in!" ha ha. Then you have to have waypoints and aircraft settings specific to each different type of airplane, weapon loadouts, datalink groups, the possibility that the airfield could change sides, the ability to block players from spawning, interacting with areas of the ground that are blocked by other planes (that aren't necessarily part of the dynamic spawn system), dealing with multicrew, and then coordinating all of this across multiplayer servers with dozens of players. Props to ED for taking this on! So many things in software look relatively simple from the front end, but the devil is in the details...

Does the dynamic spawn system work in single player? I tried making a mission in the editor, set up one airfield as Red and another as Blue, set both to use dynamic spawns as shown in the OP, but I only see the dynamic spawn interface when starting the mission as a multiplayer server, not in single player mode. If it doesn't currently work in single player, it seems like that would be a great feature to add, as there are several large missions (such a Foothold or Pretense) that can be played in single player mode and would benefit from having the dynamic slots.

My personal guess is that the "classified means" was the commercial off-the-shelf fuzzbusters mentioned in the next quote. The word "classified" often implies high-tech sophistication, but in this case it could easily just be that if it became known that we were using a COTS device to pick up enemy radars, the enemy could simply buy one of their own and test their own radars against it, and maybe find some easy way to make their radars not trigger the device, and/or determine the range and sensitivity of the device and therefore make accurate guesses as to whether our planes had picked up their signal at a given distance, etc.

I couldn't remember where I heard that so I did some searching. I couldn't really find a single source outright stating that the F-14's RWR wasn't suitable for overland operations, but I found several references to the RWR being unreliable, ineffective, and hard to reprogram. Here are some sources and relevant quotes: More discussion in this old DCS forums thread as well: https://forum.dcs.world/topic/117631-f-14-rwr-question/ And on the other hand, I also found many references to the F-14 doing TARPS recon missions over land during Desert Storm, as well as apparently doing fighter escort missions inland. I'm not sure if those might have been mainly the planes with systems that had been reprogrammed successfully, or if there were other considerations.

Something that was mentioned in the recent dev blog for "the flight sim named after a WW2 Soviet attack aircraft that is now working on a Korean War sim", is that since the war, South Korea has significantly altered its coastline through land fills, and so a modern map cannot be used even as an accurate outline or for some terrain elevation data. That's something I had never even thought about; it's not just the types of buildings that have changed but the actual outline and topography of the country, especially around the cities.

Nope, I meant the Adriatic specifically, as that's the only way a carrier is going to get close enough to affect events in *central* Europe. The Med will also be important, but that's a different theater. As far as Red Storm Rising goes, I think he probably got more right than he got wrong. People sometimes dismiss RSR out of hand, and often at the same time hold up Red Army as the most realistic, but that is a sophomoric stance for several reasons. Someone mentioned the Dance of The Vampires chapter (although maybe deleted or edited the post, as it doesn't seem to be visible now), and here's an interesting article on the details of the wargaming sessions that were used to write that chapter. The images are unfortunately missing now, but the article is still worth a read.

I note that it says "NATO Naval Forces", which are not just the carriers. Also, the only one of those that directly affects "central" Europe is the Baltic Approaches, which at least according to Wikipedia, would have been mostly the German and Danish navies and air forces, plus some UK ground forces.

I don't have any documentation on this, but I can't imagine carriers or carrier aircraft being used anywhere around the central Germany/Europe theater in a WW3 scenario. I think in order to get close enough to do strikes, the carriers would have to be in the North Sea or the Adriatic, both of which are pretty small for carrier ops when your opponent has Mach 4 antiship missiles. Also IIRC the F-14's RWR wasn't suitable for overland operations until the very late 1980s or early 1990s so that removes the main air-to-air platform. The carriers are going to have plenty to keep them busy up north, assuming Norway gets invaded, plus protecting Iceland and the GIUK gap, and keeping the Backfires away from the convoys.

The problem is that whenever any information is released, it's picked over by bored nerds and armchair programmers and used as ammunition for further criticisms. Pick any reason they could give for the patch to have been delayed, and you could come up with some reason why that shouldn't have been a problem, or why they shouldn't have had that error in the first place, or why they should have done something different instead, etc. Short of actually sitting down with one of the programmers and having them walk you through the code line by line (which you're not going to understand anyway), at some point you are simply going to have to accept them at their word that there has been a delay, and the exact reason doesn't matter, because you knowing the reason isn't going to get the patch released any faster.