K-dot-B

None of the available IR missiles give a tone when pointed at the sun. In the attached track I used R-3S missiles, but this can be reproduced whit all of them. There are old threads from around 2016 saying the missiles on the MiG can't lock the sun, but I distinctly remember getting a tone from the sun about a year ago, so the feature had been implemented at some point. mig21_sun_no_tone.trk

None of the available IR missiles give a tone when pointed directly at the sun, as seen in my track. It may be worth it to investigate this issue with FC3 as well, but I don't have those planes myself. su25t_sun_no_tone.trk

But it didn't happen after just one or two turns, did it? I probably jumped to conclusions too fast, you're right. To me the report made it sound like this was a new issue where the sight gets toppled from the slightest mistreatment, and not the known weakness of the system when doing quick turns. I also did want to make a point about how difficult it is to reproduce an issue that seems trivial to some, that's true. The periscope being able to see backwards and the gyro only failing to one side still remain as possible bugs.

My problem is that following your exact steps led nowhere. You wrote "gently" in your description. I turned left and right in a hover many times gently without ever getting the gyro to topple, you can see this in the beginning of my first track. At the end I had to kick the rudder pretty harshly, which I knew would mess up the sight, but the report suggested it was something else causing this. People interpret written symptoms differently. A track is solid evidence.

The only possible bug I noticed is that the sight always gets stuck in the right side, no matter which way I turn. I'd appreciate if others would look into this, I could do a separate report on it. Mini-rant: This test took me about an hour to set up and do (fueled by my love for this module and the anger about OP's reluctance to help), and it turned out to be a non-issue. We can't really expect the forum staff to go to such lengths with every "bug" posted each day. It is absolutely crucial to include a track with every report no matter how minor it may be. Ridiculous.

@FusRoPotato @RedBjorn Is this the issue you're describing? Mi_24_raduga_issue_gimball_limit_3.trk Mi_24_raduga_issue_gimball_limit_4.trk

The stern wake of the Type 071 Amphibious Transport Dock appears offset from the end of the ship: ship_wake_issue.trk

Pleasantly Dadaist in style. I also noticed that something was weird with the nav equipment, turning the test switch made the associated warning lights turn on even in a cold and dark heli. Maybe the equipment isn't wired correcly to the electrical system and has power at all times.

There is a short manual for CA in the game files that answers all of these questions. Iirc it's somewhere in the core DCS/Mods/Tech/Combined Arms/doc

Any mods you're using? This is from another thread (only the reply is relevant):

This is an issue I'm also struggling with. I found it very hard to nail down the exact steps to make it happen, but I managed to record some tracks (on rare occasions the issue may happen in game, but not on the track). It happens all the time on PG and Syria, but not always on the first try. Syria produced the most erratic behaviour, maybe because it has the densest road system of all the maps. Interestingly, I couldn’t reproduce it on Caucasus. The most useful clue I got is that when the issue happens, the offset WP0 always appears on a road. (Also seen in Shadow KT’s tracks) Here are the results of my most successful tests: Test 1: Add waypoints very close to the aircraft, path works normally: offsetWP0_issue_PG_norm.trk Test 2: Add off-road or on-road waypoints far from the aircraft, error happens. Observe the offset WP0 always appearing on a road: offsetWP0_issue_2_PG_off.trk offsetWP0_issue_2_PG_on.trk offsetWP0_issue_2_Syria_error.trk I did more tests with complex paths, but the track recording never worked with those. This is just speculation, but it seems DCS is tracking aircrafts as being on/off the road system like ground vehicles when adding waypoints with Combined Arms, and this messes up the pathfinding.

Fantastic, thank you!

I added a new video from molevitch as evidence. It shows all the issues mentioned in the report, check it out at the end of the original post!

Edit 1: Molevitch kindly sent me a video showing each dial moving, see it in the attached files at the bottom. There are some inaccuracies in the way the ARK-15 frequency selectors work in game. I discussed the matter with @molevitch , another forum member, who has a real ARK-15 control panel. He gave me a description and pictures on how each selector should work, and I will quote his description where applicable. I also provided a track showing the selectors’ movements in game. Here are the issues: Middle ring (10 kHz selector) issue 1: The 10 kHz knob stays on the bottom and rotates around itself, which would be mechanically impossible. Correction: The knob should be attached to the middle ring and move around the center in the semicircular slot. I found plenty of examples showing the way it works in real life (more attached at the end of the post): Middle ring (10 kHz selector) issue 2: The values on the dial start from 0 and go to 9. Correction: The sequence of the numbers should be as follows: 1-2-3-4-5-6-7-8-9-0. There may also be a blank position at the beginning, as described and shown here: “An image showing 4 x snapshots of middle dial from blank to 1, to 9, to 0. You can see the handle moving around with the dial position.” Centre knob (1 kHz selector) issue: The knob can’t turn continuously. Correction: It should be possible to rotate the selector continuously, going from 9.5 to zero: “Each dial has 20 positions, (same rotary switch structure/wafers), so the inner dial has 20 x 0.5 increments. It can be turned continuously, so at 9.5 it rolls over to 0.” Outer ring (100 kHz selector) issue: This ring currently goes from 0 to 17 without the possibility of rolling over. Correction: The selector should have 20 positions in total: one blank on each end and numbers 0-17 in between them. The dial should be able to turn continuously: “Each dial has 20 positions,... Outer dial can be turned continuously from 0-17 plus 2 blank positions.” *New* See attached video showing the movement of the knobs. Some additional pictures: This is a frame from this Mi-24 cockpit video: https://youtu.be/2kC3tWzwD_A?t=53 It clearly shows how the 1 and 0 positions are on the opposite end of the 10 kHz selector. From what appears to be a Tu-134 navigator station, with the dials in various positions: Mi24_ARK15_selector_issue.trk ARK_15_dials.mov

It's called "Stick and Cockpit Elements - HIDE/SHOW"

In the pilot-commander's cockpit the Control (упр) button on the ARK-15 panel appears held down when spawning in the helicopter. Pressing the button for the first time releases it from its stuck state and it functions correctly afterwards, as seen in my track file. Mi24_ARK15_button_issue.trk

Hello All! I hope I'm posting this in the right place. I have noticed a strange phenomenon with the Mig-21 and the AV-8B, where the Mig seems to corrupt the kneeboard controls of the Harrier (see attached screenshots). So far I was unable to narrow down the cause of the issue, or find a way to deliberately trigger it, but it happens to me consistently if both modules are installed. Here's what I know so far: -Uninstalling or disabling the Mig-21 gets rid of the issue, the kneeboard controls revert to normal on the Harrier -Installing/enabling the Mig will not trigger the problem immediately, it only happens after a varying amount of time. -No other controls on my DCS installation are affected (I also have the L-39) -Repairing DCS doesn't help -I heard at least one other person report the same kneeboard issue, but with the Mig-19 module, so maybe it is related to RAZBAM products? I tried to check the input lua files for any obvious discrepancies, but my untrained eyes couldn't spot anything. Any input would be appreciated, this is a major head-scratcher for me. I'll update this post if I manage to find more clues.

This fix works, thank you so much! (There is also a weird side effect to this issue. The wrong lua file seems to affect other modules. I noticed that whenever I had the Mig-21 installed, the kneeboard bindings in the Harrier all turned orange and I was unable to change them. I also heard that other users had the same problem in the Mig-19 too (both RAZBAM modules?). So far the only way to fix this was to uninstall or disable the Mig-21, but correcting the joystick default.lua file got rid of the issue.) EDIT: After some testing the problem is back, but at least the ARU controls are still fine.

For anyone still looking for a fix try disabling the SSDP Discovery service in Windows. I have seen this suggestion in another thread and so far this has worked for me.

Disabling SSDP helped me too! Thanks for the suggestion.

The STOP button indeed puts you on the BIT page but it does not affect the head position, at least in my experience. I just doubt that irl the default stowed position of the pod would be "sensors forward", like we have it in the game. Even the LLTV pod on the Su-25t has shutters to protect the leses when turned off.

Since we are discussing the LITENING, I just noticed that currently in the game the head always looks forward, even if the pod is on standby. I would think that kicked up debris could damage the lenses during takeoff and landing, especially in the Harrier where the nose gear is very close to the TPOD. Should't the head turn around when in standby to protect the sensors like on the picture? This one further illustrates the point: