Rhayvn

You cared enough to come here and post yet not even comment on the bug or provide a track file. Jeesh, the hypocrisy.

Definitely worth a test. MOOSE apps tend to spawn single ships by default and when I have asked about 2 ship behavior, they have suggested I make it two single ships. If you are just using MOOSE Spawn function, then it uses the DCS AI behavior. MOOSE features like AI dispatcher, use different/additional logic. The main issue I tend to see with the single ship groups is that they can all focus on one target and exclude all others if they triggered their engagement on one unit. Usually if a second or third unit is far enough away that they all focus on one. Target fixation vs. target ignoring. Slightly better issue, but still one.

"The number of times people have tested stuff that's broken, but when they do post a track it's user error....." Was this user error? Downloading it then loading DCS and pulling up the track takes nearly as much time as setting up two AI aircraft in the ME. This is not a complicated test to create. It also does not tell you what the group/waypoint settings were, whether the recorder is using mods or scripting that may interfere, or a host of other things that can cause strangeness. Already someone else did the same type of test and found additional variables without resorting to a specific track file. Sometimes, doing a simple test yourself is the easiest way to proceed. You wasted more time with your track file lecture than it takes to setup the test. So here we are.

They seem to occasionally react to AIM-54 and R-77, but not always. It's difficult to tell when it's the AI launching against other AI because it sometimes fires 54s as Fox1. The R-77 also usually is launched in STT by the AI. STT locks cause the AI to react for both the 54 and 77, but not the 120.

Occasionally. Also, probably related, if there is a 2v2 and it becomes a 2v1, the extra AI aircraft will just orbit and watch the other 1v1. It will not attempt to attack the remaining single ship unless its wingman dies, at which point it actually engages. This seems to be mostly a WVR issue but is hard to decipher in BVR/Fox3 tests. It appears the AI logic will split groups into 1v1s if they start with even counts, but is blocked from ganging up if the odds are not even. It's highly frustrating to watch a free wingman that could easily get a shot on the hostile in the other 1v1 just orbit until/unless his buddy dies. I just watched 10 different runs of 2v1 Mig21s or Mig19s against a single F4. Not once did the wingman take a single shot at the F4 in any of those runs despite several times being in perfect position to do so. DCS AI is not good at handling multi aircraft groups which is probably why the scripted features in MOOSE almost always use single aircraft groups by default.

Seems to be working properly now. Same test miz as before and the group continues after ZSU stopping to fire.

No, it's not. It takes less than one minute to recreate in the ME as you should know because you did it. All your specific questions are pointless because the answer to them is All. It's not a specific situation. One track file will not show that and people tend to dissect the specifics of a track file rather than looking at the base game issue that this one is. I'm also a little annoyed that something that was so obvious (Noticed in the very first post patch engagement) and prevalent was missed in testing and we are now stuck with it until ED decides to fix it. Which could mean a month or more where BVR lacks even a modicum of challenge. I already spent enough time testing the different aircraft, missiles and waypoint settings to waste more and go and turn track files back on and risk the return of the micro stutters that turning them off eliminated for me. I'm happy to help track down more obscure or difficult to recreate issues and have done so many times in the past. That isn't necessary here. Besides, some joker will almost always post a track when the problem is this easy to recreate, saving me the trouble.

AI aircraft do not react to ARH A2A missiles at all since the patch. Multiple tests. They fly as if the missiles are simply not there. Sometimes a very last minute change can be seen as if they see the missile visually well within a mile. With the same group settings, an SARH missile causes the AI to evade as they did pre-patch. Mostly bad attempts. With a notch and dives or attempts to outrun the missiles but at idle thrust(?) both in notch and extend phases. But, at least they react. Something was broken in the patch. This is easily re-created with two AI aircraft in an empty miz with Fox 3s and watching for 30 seconds. Edit: Since people seem more interested in whining about track files than actually discussing the issue. Fox3Test.trk

It's a bit over-tuned. You have to get within about 7 miles for FOUR HARMs to have a chance for 1 to get through reliably. It will shoot down 5-7 incoming GBU38/54 in a swarm before the remainder hit. IF they are all close together. Good luck to you if you have to use GBU12s and It's moving. Or, if you do not have 4 HARMs or 8 GBUs to expend on it. Unable to test yet for simultaneous attacks from different directions. New HARM code for it appears to be 132.

The question is, is the 5 minutes time limit (It's more like just over 4 minutes from my tests) a total time for that flight, or 5 minutes at a time. If so, some direction on how long we need to wait to go back into WEP to reset the timer would be nice. From testing going into and out of WEP MAPs and adding up the time, it's a total of 5 minutes in the short term and the engine loses significant power and will seize if you do not back it off. I tried using WEP for 4 minutes and then going to low power cruise for about 10 minutes. Then back into WEP. It lasted another 4 minutes and I got the low water light just before the engine losing power. Hopefully this is just a simplified modeling step because it seems solely tied to MAP and time. I have not even tested if landing and refueling resets the timer. If it does not, then it's even more artificial. But, with the WEP-Cruise-WEP test, it seem like it does slowly reset.

Angling the mirrors does not change the reflection angle. That's the problem. It just makes them appear to be thinner or wider. It is definitely broken. You can actually adjust them normally but only downwards for the top one and inwards for the side mirrors. But angle them outwards and they stop changing the point of view at artificial points.

Yes, latest MOOSE version.

I have tried but it has some very odd behavior. Helicopters will not start on the helipads in the helicopter only bases but they will land on them. Helicopters set for vertical takeoff and landings will taxi for takeoff around certain airbases depending on which spawn point they originated at. They always use the runway for landing. A huge percentage of the first aircraft respawns all fly to and land on the Tarawa despite every RAT setting I tried. Many larger aircraft will still spawn in smaller spawn points and hit objects at the airfield either on spawn or while taxiing, also despite the RAT setting that are supposed to prevent this. Small and grass field bases will be chosen for takeoff (They air start) or landing if you don't specify the departure and destination bases. Despite RAT settings to exclude them. They work fine in the air, but not so much when they have to touch the ground for any reason.

Same bug as the SA-15. Any group a ZSU-57-2 is part of will no longer move after the 57-2 has stopped to fire.

The HVAR rocket pylons create drag and do reduce the maximum speed along with other drag effects. If you ever arm HVARs, even if you re-arm and remove them, or try a loadout without HVARs after landing from a mission you carried and fired them, you can never remove the pylons again. This means that after they are on the plane once, the pylons, and drag from them, remain until you get a new client. Can this be corrected?