Floyd1212

I was complaining in another thread about not getting any radar returns for groups that are clearly right in front of me (often shooting at me), so I recorded a video and saved the track to post as a bug report. However, when I replayed the track, there were times when I was getting returns in the track when I wasn't getting returns at the time in-game. Here is a screenshot of what I was seeing in game, as captured by my video. But here is what I see when I playback the track file. The first thing you might notice is that the MPDs are displaying completely different things. This may be part of the problem, though really it shouldn't be. I use external touchscreen monitors in front of me running Helios to interact with them, and for some reason the track recording system does not register button presses I make through Helios. It does in real-time while I'm flying around, but what you see during the track replay is totally out of sync. But even when the displays don't match, every time I press the single-burst scan button, I see the white sweep back and forth. Why would returns not show up on my displays in game, but then show up in the track replay? At one point in the video, I am running in on the enemy units that are shooting at me, and still not getting any returns. Here is the track and video file. FCR Test.trk https://youtu.be/REv8tLs6h5Y EDIT: I should also point out that the original reason I was making the video/track was because I couldn't get any returns while perched on top of that hill. They are clearly within range and unobstructed by trees, so is it the look-down angle from up there? Is the radar not designed to scan low like that? And before you ask, yes, I manually adjusted the radar elevation to the lowest setting to look down, but you don't see me doing that in the track, just the video.

We get NAK responses a lot, even when the data goes through. We sometimes get duplicate messages incoming when the data was only sent once. We sometimes get members listed twice when added via the MBR DIR option. We sometimes don't get a response when requesting a PP report with other members flying nearby. This is all on a MP server with some aircraft flying solo and others flying multi-crew. Never tested with an AI wingman.

I am also experiencing zero returns on occasions where I have complete LOS of the target group. The T90 in the group is lasing me and firing Snipers my way, but the FCR is unable to see them in a scan. Then, sometimes it works and I get targets. What is the maximum look-down angle I can expect from the FCR? Can the radar see through the main rotor disc?

Are you in the PLT seat, or CPG seat? Do you have the FCR fitted to the aircraft? You weren’t able to select Limas from the back before, and maybe you still can’t unless the FCR is installed?

Check the other thread about some liveries removing the FCR.

Definitely having issues with a human CPG. This might be the "desync" issue that was mentioned in the patch notes, but it is more than just an issue of where it works for the CPG but the PLT doesn't sync; it isn't working reliably for either of us. Half the time we get no returns, some of the time we get returns that the CPG sees but the PLT doesn't. Sometimes it's revered and the PLT sees the returns and the CPG doesn't. If I fly solo, it works fine. Maybe someone from ED can confirm what we should expect in a multi-crew environment at this time? (If this is unexpected behavior and it should be working at least for the CPG, I would be glad to provide a track.)

It doesn't change after a kill, it changes after a launch of a missile. It shows the "X" on the target immediately after launch and moves to the next target. The SHOT page is related to the targets you have fired on, but we haven't seen a video on that yet.

I believe this will be the upcoming LINK function. In the meantime, I think your method is the (slower) work-around.

Before moving to the front seat, I settle the helo into a stable hover, trim, and set the ATT and ALT Hold. Once everything is settled, then I swap to the front seat. This means George doesn't have to move the controls much from where I left them to maintain the hover. If you were flying forward and swap seats, then let George get you into the hover, when you swap back your controls are no where near where they need to be to maintain that hover. I have "T" bound on my keyboard for FTR Up, in addition to the controls on my cyclic. When I move to the back seat again, while still in a hover, I tap "1" to swap seats, immediately followed by "T" to trim, without ever touching my cyclic or collective. This trims the controls in the sim to where George left them, and then my stick is in the center position like it would be after trimming and releasing. I then quickly set ATT and ALT Hold again and I'm still in the stable hover i was in before. I rarely have George fly me anywhere, so I can't speak for transitioning back and forth while in flight.

It can be done with the current flight model. Tuvas does have some fancy controllers (with motion tracking) that help him out, and then a lot of stick time, I'm sure.

@Grimes Would it be possible to create a simple mission with a group of 4 units, and a way to place a user mark on the F10 map, and then script the group to move to the user mark with the action = AI.Task.VehicleFormation.ON_ROAD task? If this is possible, I may ask around to see if someone can work it up as a useful tool for experimentation, and demonstrating this issue. It is beyond my current abilities, but I feel like it should be doable, yes?

I do get a minor "blip" on the cyclic input when I return my stick to center after releasing FTR. In fwd flight it isn't enough to do much, and with ATT Hold set and the aircraft stable, it isn't enough to do much there either; it doesn't break me out of the position hold I have set. I have always just lived with it. If you are talking about how the SCAS will freak out for a couple seconds after establishing the position hold and then eventually settle itself again, that is unrelated, and was introduced in the 2.9 patch.

Yeah, we haven't seen a way to "reverse" back to a target you already engaged, designated by the "X". Wags said he would cover what those mean in a future video, so maybe there is a way to do it.

If you are referring to the clarity of the image, try disabling DLAA. DLSS and DLAA both introduce some motion artifacts on the displays, and I have found this to be worse when using PNVS at night.

Yes, displaying a second viewport that needs to be rendered in addition to your main viewport will bring a performance cost. Same with enabling mirrors. I personally haven't noticed a difference since 2.9 in this regard, though. When you say it stutters, do you mean just the view of the TADS stutters, or your entire screen stutters when TADS video is on the screen? Another thread that might be relevant: https://forum.dcs.world/topic/333405-apache-flir-vs-tv-performance-impact-81-to-14-fps-video-and-trk-file-attached/

For me, in low wind (<5 knots), it will buck around dramatically for a moment, then settle again and hold the position. Once or twice I still had a slow drift, but after making some trim adjustments it held position. Are you giving it a chance to settle back in and recover the hover?

We expect a few more videos from Wags, so how fast we see those roll out might indicate when the feature will be released in the patch.

Had this happen again tonight. I got the aircraft all started up solo, and as I throttled up the engines I got a low RPM warning which switched my left MPD to the A/C page. After that, my human CPG joined and started doing some setup of the front seat. He was on TSD page and pressed T3 for SHOW, then T6 for COORD SHOW, then L4 for ENEMY UNITS. This then disabled the Collective channel of the FMC. Something was out of sync when he got in the aircraft, and from the back seat it appears he was on the A/C page, and pressed UTIL at T6, then COLL at L4, disabling the collective channel. I got the warning on the EUFD that FMC was disabled, but he did not. When I re-enabled the coll channel from the back, the warning went away for me and it showed up on his EUFD as being disabled. At that point, we were out of sync for the remainder of the flight.

With no binds for the throttle axis at all, and using the mouse to raise the throttles in the cockpit, the problem still occurs? Check that axis across all your controls. DCS likes to auto assign axis to controllers that you never intend to use for those functions.

Thanks for the update!

Between the left MPD and the keyboard unit are the controls for the IHADSS brightness and contrast. Make sure the SYM BRT knob is turned up. If that doesn’t fix it, maybe hop into an instant action hot start mission without your flight controls even plugged in and see if the IHADSS is working in that scenario.

I don't think this behavior was introduced with 2.9; we were seeing this prior to that. You would have a missile in the air on the second target, and all of a sudden the TADS would drift off the target and you would have to use the "MTT Promote" function to get the TADS "slaved" back onto the target. Not sure if this is correct behavior or not, though.

Maybe the radar altimeter is located in/near the tail and as you yank the stick back the tail drops and briefly shows a reduction in altitude before the aircraft starts to climb?

This also happens to you in a single-player quick start mission, on all maps? What about a hot start and you shut down the engines and bring them back up again?

Here is another track file to instantly demonstrate the issue/question. ASE Test.trk The ASE Page (right) shows the true orientation of the threats in relation to the aircraft; 3 o'clock and 7 o'clock. The same threats on the TSD Page (left) when set to N-UP show the dotted line drawn back to the lower-center of the map, where your ownship would be shown when set to Heading-UP mode. This gives you the impression that the threats are at 1 o'clock and 9 o'clock from your current position and orientation. Is this how it works IRL?