key_stroked

I retested and you are 100% correct. My earlier test was flawed because the target was right behind the ridge line obstructing it instead of my aircraft being right up against a ridge line. Thanks for clearing it up! What's interesting is that the AI search radar can go through buildings but the tracking radar can't.

This is related to this discussion: That forum link happens to show a video taken by an ED beta tester detailing exactly what I just tested in the ME with an SA-15 on the Nevada map. There was an original claim by players that the FCR radar beams weren't originating from the FCR dome on top of the rotor mast, but instead coming from the nose of the aircraft where the TADS is. Raptor from ED claimed this was false. So I think Raptor is actually correct, but there is a caveat that he didn't mention which explains the behavior shown in the video from the link and the screenshot above. The video and screenshot collage clearly shows that if TADS can't see a target, the FCR can't see it. Specifically, if TADS can't get a contrast lock, then the FCR has nothing to paint as a target. My theory is that this is because of the LINK feature. LINK allows the TADS to snap to a target painted with the FCR. While the radar beams are most likely coming from the FCR dome, I believe there is game logic in the programming code that tells the FCR to not paint a target if the TADS can't achieve a contrast lock. One possible reason would be to avoid a multitude of CTDs and program freezes while the game tries to find the related target to snap the TADS to but can't. Whatever the reason, the fact is if TADS can't see it, your FCR can't either, which completely negates the advantage of putting an FCR at the very top of the aircraft and peeking it over a hill to avoid exposing your entire helicopter. Raptor originally gave this explanation for why this appears to be the case, and he said some calculations were corrected for a future patch, but as of patch 2.9.9.2474 the FCR still can't be used as it was originally designed: So my question is...when will this finally be fixed ED? I shouldn't have to expose my entire Apache aircraft body to get a lock with the FCR.

If it's based on the height of the aircraft (and an antenna setting that Hobel didn't change during his test video), then why does the radar pick up the target through the gap in the buildings? If it's based on just height, he shouldn't have been able to make contact unless he was above the height of the building roof before it slants down and creates that gap. Clearly the building is obstructing contact from where the nose is situated.

Lol. Looks like it's coming from the nose of the aircraft. And Raptor9 gave that guy hell for actually telling the truth. Well done ED.

Why wasn't this fixed in the hotfix?

Custom shapes and colors over airbases or FARPs are completely covered by the hexagons showing how many spawnable aircraft are there. You have to zoom in almost all the way in order to see any detail beneath the hexagons. It also just makes the spawn map look cluttered and confusing. For small missions and maps I can see the usefulness of seeing at a glance where you can spawn, but for large multiplayer servers where there are dozens and dozens of places to spawn, it's an absolute mess. We also need the map filters returned to the top bar. Before this patch, if you wanted to see the map before spawning in an aircraft, you either had to slot into a tac commander and see the F10 map by default, or slot an aircraft and cancel the briefing to bring up the F10 map. In both cases, you had all of the map filters on the top (show/hide aircraft, weapons, ground vehicles, SAM detection rings, health bars, etc.). Right now with the current spawn list map, all of those tools are missing and everything is turned on by default, creating a jumbled mess.

We are the closed beta team. This isn't a finished module.

So how about that Kiowa? It's been 17 years...is it still on track?

I have the same issue in Multiplayer and reported it but accidentally put it in the main AH-64D forum. Can my thread be merged into this one please? https://forum.dcs.world/topic/346035-29351704-dcs-crashes-after-turning-on-vid-feed-in-left-mfd/#comment-5410359

I've provided a log and a trackfile. Is this being looked at?

https://www.reddit.com/r/hoggit/s/fiDzcejewa

It's always the first flight I do in the Apache per session in a multiplayer server. Track and log files attached. dcs.log SDCS_Syria2-20240327-222144.zip

That's one of the first things I did, and I explained that in the original post. It didn't work for me.

Let me check. ** Nope, still broken. Default view for the Apache is still set to 90 in SnapViews.lua, but hitting "Zoom Normal" defaults the camera FOV to 124.4 This screenshot was from today. I'm on the multi-thread executable version 2.9.2.49940

Yeah that's right. I don't know where the ED default view settings are, because SnapViewsDefault in the normal DCS directory only has the FC3 aircraft listed. I can't find the value of 124.4 anywhere. But yes, "default view" is getting completely ignored.

Yes, the zoom normal bind in every module.

Unfortunately, it didn't affect the Apache. So far, I haven't seen ED acknowledge that this is totally FUBAR now.

Are the green values min/max FOV? Are you suggesting to just set them to the same number? I also don't have a Server.lua file in that directory (same directory as SnapViews.lua). How am I supposed to generate that file?

Prior to the patch on 19.12.2023, the key assignment "Default Zoom" would correctly change the FOV setting to match the "{--default view" entry for any given aircraft in SnapViews.lua. After yesterday's patch, the default zoom is now 124.4 which basically turns the camera into a fish-eye lens and it's completely unplayable for me. I tested different values for the Apache in SnapViews.lua, but it won't use whatever value is set for the "default view" entry. As a test I set "90" for the default FOV in the Apache: But when I hit default zoom, it goes to 124.4. I've tried deleting SnapViews.lua from the Saved Games\DCS.openbeta\Config\View directory and let DCS rebuild it after saving a custom SnapView with no change. I've tried running a repair with no change. The issue of default zoom not resetting the FOV is a bug that has been around for several open beta versions. Before this latest patch, the workaround was to briefly select a snapview (windows key + numpad number) and then default zoom would work. Now, I'm just stuck with an FOV of 124.4 unless I manually change it with the "Zoom slow" keybinds, but you have to leave the console window open to get back to your desired FOV if you decide to zoom in or out at any point. Can this please be hot fixed?

Missed those. Thanks!

Ah interesting. Thanks.

CPG communications controls don't list anything labeled foot pedal. I thought the CPG foot pedals actually link to the control surfaces for flying from the front seat? I know the F-14 RIO pedals are setup for coms. Maybe you were thinking of those.

As far as I can tell, the TEDAC has no radio/ICS transmit buttons. In the real Apache, does the CPG have to let go of the TEDAC to find the radio HAT switch on the cyclic to use the radio or talk to the pilot over ICS? Seems like an oversight not to include radio controls on the thing the CPG would have his hands on the most, especially during combat. Or does the CPG just have a hot mic all the time?

Yes please