Rhayvn

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?

Actually all of the keybinds (That I use) that were not working prior to the patch are now working. Also, on our MP server, landing gear state shows the correct up or down state for other player F4Us. The default view was moved back as well. So there were actually a lot of fixes done in this patch.

Neither did Essex carriers with zero crew on them, but thanks for that amazing info and contribution!

@-Rudel-Fully understand that. This is a MP CV where we need to takeoff and land so the deck needs to stay mostly clear. Attached are some screenshots of where static personnel were placed. We could try adding one at a time until the desk fouled error appeared, but it would be tedious to do that. If there is a diagram that shows where static can and can not be placed, almost exactly like the ones you have above, that would help. If the dashed line in the right hand diagram is that marker, then great! We can move all the statics ahead of that line.

They work fine in Single Player, in MP, their tails fall through the deck. Also, it would be good to get a diagram of where we can place static objects and not get an LSO 'Wave Off - Deck Fouled' call on final.

I did a test for a few different aircraft that I have at 5000, 12000 and 24000 feet. The speeds listed are TAS and what you can sustain pretty much indefinitely in level flight. For the clean aircraft, if there is a '/' the number before is without water injection and the number after is with water. For the GA lines, that is Ground Attack and are the speeds with a full load of rockets and bombs with the number after the / as the speed after dropping all the ordnance. It's pretty close to the P-51 in overall speed, depending on the specific altitude (Due to SC gearing most likely) and beats the 47 and D9 handily. They can only match it with water/mw90 active.

It is the same. There is no speed change after firing rockets and you seem to permanently have the drag associated with them. Bombs and fuel tanks appear to work normally.

Same, with multiple aircraft types. Current mission has at least 3 red and 4 blue aircraft doing those circles.

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.