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.