Jump to content

key_stroked

Members
 View Profile  See their activity

  • Posts

    553

  • Joined

  • Last visited

 Content Type 

Posts posted by key_stroked

    FCR radome emission rumors

    in DCS: AH-64D

    Posted · Edited by key_stroked

     

    1 hour ago, Raptor9 said:

    First of all, the bug that produced the appearance of the FCR not emitting from the radome has nothing to do with the TADS, with LINK, or anything else than what I specified. The information I provided in other threads regarding this issue came from the ED devs and my own testing using internal debug tools, not the Hoggit rumor mill. Second, the actual issue that was causing this effect was resolved months ago, so if there are still some individuals in the social media channels making these claims, I would wonder if they have even played DCS: AH-64D in several months, or if they are simply repeating things that someone else said to drive a narrative for whatever reason.

    The image below was just taken from the same DCS version that anyone in the DCS community can play and try out for themselves. Clearly the FCR can see the target while the TADS is still obscured by the ridgeline ahead. And as you can see, the FCR is performing a continuous scan to show that the target was just detected at the current altitude.

    image.png

    To provide some context, if the FCR does not see enough of the target, it may not be able to determine whether it is a target of military interest or simply ground clutter, even if it does register the radar reflection from the vehicle. Case in point, in the images below (again, from the same DCS build that everyone else can play) you can see that the raw radar information displays a radar target out there as a bright white reflection, but it is only partially visible to the FCR. The TADS doesn't need to see the whole target to establish an image auto-track on it, but the FCR does not have enough information to determine what it is, so it rejects it as ground clutter. As opposed to a tracked target in the foreground of which it does see enough to classify.

    21.png
    22.png
    23.png

    Finally, the aircraft altitude is increased until the FCR can gather enough radar information to determine what the target is.

    3.png

    As you can see, there is no issue with how the FCR is behaving, there hasn't been for months, despite what people keep claiming. However, one must keep in mind some practical limitations of radar as a sensor. Just as a radar cannot determine whether a tank is operational or destroyed by a missile, the radar cannot classify a vehicle if it only sees a portion of the vehicle.

    Threads merged.

    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!

     

    Screen_241111_183012.jpg

    What's interesting is that the AI search radar can go through buildings but the tracking radar can't.

    Screen_241111_183158.jpg

     

    Screen_241111_183234.jpg

    • Like 1

    FCR radome emission rumors

    in DCS: AH-64D

    Posted

    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.

    Screen_241111_152807.jpg

    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:
     

    Quote

    The mathematical calculations that determine when a target is visible to the radome need corrections (and have been corrected internally for a future patch). These calculations are based on the aircraft height over terrain and the antenna elevation setting. The emissions are not coming from the nose, but it is a happy coincidence that the incorrect calculations are manifesting to give the appearance of this.


    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.

    • Like 2

    FCR - difficulty acquiring targets - elevation cue seems backwards? TRACK ATTACHED

    in Bugs and Problems

    Posted

    25 minutes ago, Raptor9 said:

    I didn't give anyone any hell, I told him he was stating incorrect information, and it still is incorrect.

    Hobel, and anyone else making this claim, are mistaken. The mathematical calculations that determine when a target is visible to the radome need corrections (and have been corrected internally for a future patch). These calculations are based on the aircraft height over terrain and the antenna elevation setting. The emissions are not coming from the nose, but it is a happy coincidence that the incorrect calculations are manifesting to give the appearance of this.

    Hobel does not have access to the debug tools the devs use to determine this. But I have personally seen and tested these things. Is there an issue with the elevation control calculations? Yes, I have said this already multiple times in multiple threads. But the cause is not "the radar is coming from the nose". I'm not going to show you the trignometry that is involved, since it wouldn't mean much anyway, so I figured I would break it down as best I could to inform to you all the real cause.

    You all can tell yourselves whatever you want or make me out to be the villian for telling you what is actually going on under the hood. I don't care; and it's threads like this that make me question why I bother interacting with or communicating with the players when this is the response. It is not my job to do so, but I try to be as transparent as I can be to keep players informed. Perhaps it isn't worth the effort.

    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.

    Give us a way to remove the blue hexagons showing spawn numbers from the spawn selection map and please add the map filters back

    in Multiplayer

    Posted · Edited by key_stroked

    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.
     

    messy.png

    Screenshot 2024-07-14 143856.png

    • Like 1

    Default zoom/FOV broken as of 2.9.2.49629 [Open Beta]

    in View and Spotting Bugs

    Posted · Edited by key_stroked

    On 1/2/2024 at 11:24 AM, SharpeXB said:

    I think to fix this you need to just delete your old Snapview.lua and generate a new one by creating a custom snap view in the game. That will make a new .lua. 
    Make sure Snap View Saving is checked in the Options 

    Unfortunately that means setting up your views again unless there’s some lua surgery possible. 
    But if all you’re looking to do is set your FOV default (initial spawn and “normal”) that’s this here

    [13] = {--default view
            viewAngle        = 95.000000,--FOV
            viewAngleVertical= 63.088276,--VFOV
            hAngle            = 0.000000,
            vAngle            = -10.000000,
            x_trans            = 0.000000,
            y_trans            = 0.000000,
            z_trans            = 0.000000,
            rollAngle        = 0.000000,
            cockpit_version    = 0,

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

    Default zoom/FOV broken as of 2.9.2.49629 [Open Beta]

    in View and Spotting Bugs

    Posted · Edited by key_stroked

    4 hours ago, Flappie said:

    I tried to reproduce the issue in 2.9.2.49940 but couldn't.

    Has the latest patch solved this issue?

    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

    image.png

    image.png

    Default zoom/FOV broken as of 2.9.2.49629 [Open Beta]

    in View and Spotting Bugs

    Posted

    6 hours ago, Flappie said:

    Thanks.

    So if I understand correctly, this "Zoom normal" function should:

    1. either load the "default view" section from SnapViews.lua
    2. or load ED default view if there's no existing "default view" entry in the SnapViews.lua

    But the current OB directly goes to step 2.

    Is all of the above correct?

    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.

    • Thanks 1

    Default zoom/FOV broken as of 2.9.2.49629 [Open Beta]

    in View and Spotting Bugs

    Posted

    10 hours ago, njoyyoursalad said:


    Yes, the green values represent min/max FOV figures. If you change 140 to something like 100 then your FOV will only expand to a maximum of 100°. It doesn't work on all aircraft though so I'm hoping that someone with a bit more knowledge will chime in with a way to cover all aircraft. 

    As for Server.lua, you can copy that out of your ..\Eagle Dynamics\DCS World OpenBeta\Config\View\ directory, paste it into ..\Saved Games\DCS.openbeta\Config\View\ and then simply apply your edit to the copied file. 

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

    Default zoom/FOV broken as of 2.9.2.49629 [Open Beta]

    in View and Spotting Bugs

    Posted · Edited by key_stroked

    22 minutes ago, njoyyoursalad said:

    Editing Server.lua in your ..\Saved Games\DCS.openbeta\Config\View\ directory will fix at least some aircraft: 

    function default_fighter_player(t)
    local res = { 
        CameraViewAngleLimits  = {20.000000,140.000000},

    It doesn't work for everything, and it limits your maximum FOV, but I suspect someone probably has a more effective method to use as temporary workaround. 

    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?

    image.png

    Default zoom/FOV broken as of 2.9.2.49629 [Open Beta]

    in View and Spotting Bugs

    Posted

    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:
    image.png

    But when I hit default zoom, it goes to 124.4.

    image.png

    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?

    How is the CPG supposed to use the radio/ICS without radio controls on the TEDAC?

    in DCS: AH-64D

    Posted

    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?

×
×
  • Create New...