Rhayvn

With a nearby tanker? I found a workaround, it's tedious, but it works fine. But, it shouldn't be necessary.

I had a chance to test this again and "RTB on bingo fuel" set to OFF does not prevent the aircraft from refueling on the closest tanker. I got the same behavior with both OFF and ON settings.

Return to base of origin would be good as well. The 'nearest base' is not always a safe one to return to for a tanker or AWACS.

Can we get a reply to this? This was broken before, acknowledged, announced as fixed and then broken again. It's not a new issue that needs to be investigated.

Bumping this up as it was an old issue that was fixed for a while but has now returned. AI do not obey the RTB on Bingo Fuel if there is a tanker in the area. When an E3 or another KC-135 decides to refuel instead of RTB, it can occupy the tanker for around an hour while it refuels. Adding additional tankers does not really help much since they will also go to another tanker to refuel. I have seen a KC-135 refueling another 135 that was also refueling an E-3 at the same time.

Still flashes Masked when in STBY mode for me.

This is not much of a problem in modern era missions, most kills are catastrophic. But for WW2, many shoot downs result in the AI crash landing where the pilot and a heavily damaged aircraft survive and are still present on the map. The airframe eventually disappears but the group still counts as active. When using a SPAWN command to generate the group, this results in the group never counting as destroyed to trigger the respawn.

I've been a pilot for years, I'm well aware of how they work, which is why I am reporting this. Because it appears to be due to differences in temperature set in the mission editor but also is different between modules. 1. It's consistent between those of us that tested it. 2. The error increases at a steady rate from zero on the ground. 3. Changing temperature causes the amount of error to change but the error is still pretty much linear. It is not Density altitude, which would be a consistent deviation throughout the altitudes tested. 4. The F15 was tested in formation and did not have the error. The number the 15 shows is consistent with the number reported by other views in DCS. If the 16 altimeter has a real life difference between normal indicated altitude and other types such as density or pressure altitude, it would be good to know that. Perhaps it is modeled correctly and the 15E is not (The 15 automatically adjusting for temperature deviation). That would mean the 16 is showing real Indicated altitude and the 15 is showing True altitude. Perhaps that is even correct. If it's meant to model variations in temperature, why is it zero on the ground (seemingly regardless of how high up the airfield is)? Just one example from the Caucasus free flight instant action. Which is an air start and is relatively close compared to the other tests my group has done. I have seen this altitude be off by as much as 400 ft at 8000 ft ASL and 1500 or more above 20,000. OAT is 10C in this mission. 4000 indicated. 3922 actual. 8000 indicated. 7842 actual. 18000 indicated. 17650 actual. 30000 indicated. 29430 actual.

From a Cold Start, the altimeter, in Electric or Pneumatic, show a progressively larger error the higher you go. At sea level, it matches. As you increase altitude it is off by about 600 feet for every 10,000 feet up you go. It reads too low. External views, tacview, F10 map, and other airframes all the show the correct altitude (Flying in formation to test). This was tested on multiple clients by multiple users on different maps.

Same but in regular 2D. If you are flying really low or diving at the ground with the radar on, you get severe slowdown. I believe this is something they are working on. I have tried differetn CPU thread counts to no real benefit. I had to just bind a command to turn the radar from on to stby and back for when I am in those situations.

Taz, any chance of an IC safe version of MP for the latest OB? The main post still lists that the IC Safe version does not pass as of 2.8.5. It looks like ED may have rendered this not possible with the change to file protections but I was hoping you could work some more magic.

It's related to a bug with the AUTO bomb fall line incorrectly compensating for wind in most cases. You will find that if you drop into or with the wind or with very little crosswind/wind you will have success. You can mitigate this by looking at the TGP offset number in the upper left of the TGP display. That shows the angle the TGP is from the nose of the jet. Ensure you are between 2L - 0 - 2R and the LGB should guide every time. My guess is that the reason it's less evident in a a dive is because it reduced the amount of wind correction a drop would require, therefore the erroneous offset the current system is giving you in AUTO.

From the most recent DCS Open Beta patch, MP servers using the Sinai map seem to be unable to communicate with the tanker of the CV. The CV will respond, but tells you you do not have permission to land. The tanker does not respond. This works ok in single player running the same mission. I tried both single and multi thread in multiplayer with the same results.

The RWR panel lights on the lower left and next to the RWR display are either full bright or off. The dimmer switch on the lower left panel does not seem to alter them other than that.

This is easy to reproduce. Pick just about any non apartment building in Caucasus and drop multiple JSOW-C or GBU-31 on them and they will show no damage. Even ones that used to be destroyed with 500lb range weapons. This has been reported through other channels and is still evident and easy to verify. If you claim you can not reproduce it as the thread tag says, you are either not actually trying or you are using a different build than the current open beta.

If a SAM vehicle is part of a moving ground group, the entire group will get stuck after the SAM engages an air target. This may also be true of AAA or any other unit that has to stop to engage an air target, I only tested it with SAM vehicles. The group will not move again until the SAM vehicle is destroyed. I have tried this with every combination of ROE and ALARM state setting that would still allow the group to engage air targets. SA8Stuck2.trk SA8Stuck.trk

Any track I posted with an SU-27, Mig29S or Mirage-2000, they are jamming. If your replay does not show that they are jamming, then that is part of the problem with you trying to re-create the misses.

Seconding this. Disabling the jamming greatly reduces the problem for the same aircraft and AI level. Though it does not eliminate it. Some missiles still track poorly in terminal. Again, this is very different that it was prior to the patch.

Caucasus. SU-27 Tacview-P16-27-CA.zip.acmi P16-27-CA.trk

Multiple track files have been provided. Can we get some sort of response? I have an entire group of people losing motivation for DCS due to the incredibly poor reliability of the 120s. I just reviewed two separate trackview files of the group over the last two days and there were 3 hits out of over 20, 120 launches. SM-2 and Hawks are not showing the issue, so it is definitely a 120 problem. All the target has to do is be low and roll. Please don't claim that your fix for barrel rolling targets didn't cause this nearly identical issue, that didn't exist against AI prior to the patch.

It's only part of defending against an incoming or potential incoming (Fox 3) missile. You definitely don't go lower than necessary and don't stay there unless you are using terrain masking to negate a range (Or other) disadvantage. It's highly dependent on what missile you are facing. Some will intercept you before your shot forces your target defensive, some will not. Fox3s don't care if your target is defensive, only how much energy they have left when you -start- to defend. Early enough and they aren't dangerous. I find it better to err on the side of caution. All that is just 1v1 too. In general, I find that (Blue vs Red) the closer you let the AI get, the more you give away your advantages. For the jamming, it's a setting in the ME with multiple options. Detected or Locked is the option I prefer as they will use it to mitigate ranges while also leaving it off for stealth if nothing is painting them. If you set it for Locked only, they tend to not use it until far too late because most Blue engagements are in TWS.

Why do you think it's nonsensical? I am not talking in this thread about bullying opponents you outrange so badly you can basically ignore any potential return fire. On not permitting the 29S to use their jammer, why are you artificially limiting their capabilities?

I think Default has an excellent point here too in that it is mostly an AI problem. I do not see the same problem at lower AI skill levels. Almost entirely at Ace level with some Veteran in higher tier ACs. Also, many aircraft don't generate the issue. Mig-23s, for instance, don't manifest the terminal guidance issues. But, a high performance AC with high level AI can expose a problem with the missile. Note that the changes in the last patch were based on a specific thing players were doing. If the fix for that enabled the AI to do something similar that is outside of the normal effectiveness for missile defense, then that needs to be fixed too.

Are your targets jamming? You generally can't lock up a jamming target at those ranges unless they launch, since their signature increases at that point. You are seeing the issue in more detail on the ones where your first shot does not hit. When the target is low and notching, the problem is most prevalent. This is different than pre-patch. "AI set to "Launch by target threat estimate" though. However, that would typically make it more of a threat, not less." Not really. It still means they hold shots longer in some cases rather than always making use of their range. I can mean it would be harder for you to defeat their missiles kinetically in rare cases where they drive closer to no escape range or have inferior weapons. But those aren't the case when you are using 120s. "Not sure about the exact situation, but in most cases, that's a bad idea. Exceptions being mostly radar performance on some aircraft and attempting to merge due to an asymmetric weapons situation." Descent is to counter incoming missiles. Even with descending, you will often have a fairly narrow window between an ER hitting you and your missile going active. The AI always does this, so the AI vs. AI tests, it wasn't something that could be controlled. If you have tacview files, I would be interested in viewing them.

Default774, if by "Random launch range" you mean the line in the ME that is "AA Missile Attack Ranges=RANDOM BETWEEN MAX RANGE AND NO ESCAPE ZONE LAUNCH", I always remove that. For the most part, it just prevents the AI from engaging before it has to defend. Resulting in them not doing A-pole or descending after their own launch. It has the base effect of making nearly every AI target much easier to kill. Especially with the inherent range advantage the 120 already enjoys. Also, do you have the jamming enabled for the 29S. You were locking it in a 16 at ~30 miles. Usually that's not possible if jamming is enabled. Also, note that it never fired on you. Generally, the 29S will fire a 27ER or, more rarely, a R-77 before you can burn through the jamming. Edit: One additional track file the previous post didn't have the room to add. P18-29-2.trk