Rhayvn

This is an old bug that used to permanently stop SA-15, ZSU-57 and SA-11 once they fire. It is back for the SA-15 but not for the ZSU-57. I have not tested the SA-11.

Can someone point me to the right warehouse item to enable loading the pods in the screenshot? All of the bomblets have plenty of quantity. I can find nothing else that seems related.

This is likely related to a change some few months ago where the AI will select one target to attack for each AI aircraft and the other AI aircraft, if they don't have a target of their own (Or they shoot it down) just fly around not engaging the remaining hostiles. This is most easily seen in a 2v2. Each AI aircraft will go after one of the opposing aircraft. When one of the aircraft is shot down, the other fight will stay as a 1v1 with the winner of the other 1v1, now free, never trying to assist it's group mate. It will fly around nearby, or even try to get in formation with the still engaged friendly. It will only engage the remaining hostile if the 1v1 is lost by its group mate. This is truly silly behavior because it makes all fights 1v1 duels even with multiple aircraft around.

Sent you the file. Also, the total time seems to be off randomly. Like in game for 78 minutes according to tacview but the flight in logbook may show 325 minutes or some other odd amount. I don't have an example of one of those logs.

Same issue on Syria Map.

Is anyone having issues since the most recent DCS patch? I get an error after selecting the debrief.log.

Has anyone been able to align the jet after getting a repair? I have tried each alignment option and jester never finishes. I have waited almost 30 minutes for the normal alignment and 20 for BATH and stored. I will try connecting ground power the next time to see if keeping the power on works through a repair, but sometimes the damage takes the INS offline, so that probably won't work for those situations.

Thank you!!!!!

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.