Jump to content

AvroLanc

Members
  • Posts

    1323
  • Joined

  • Last visited

Posts posted by AvroLanc

  1. 8 hours ago, Lord Vader said:

    Hi @Mr. Wilson

    The HUD Altitude switch is not implemented in our version of the F-16C.

    According to the documentation, when selecting EEGS/LCOS or AAM/MSL modes, they are intentionally reverted to VAH scales and in Dogfight mode no scales are available unless landing.

    Thank you for your time.


    In regard to the HUD Altitude switch…… is there any reason why it’s not implemented? Is it planned? Are you saying it’s not part of the 2007 Block 50 you’ve modelled? Seems strange since all of the F-16 documentation out there from Block 50’s to MLU’s all have this feature.

    It would seem to be a very simple thing to add when such basic display settings are common on most DCS aircraft. A simple BARO/RAD/Auto mode is pretty common for the complex 4th gens. Seems to be a very curious omission. There is of course ample documentation on how it works and looks. 

    Hopefully you can add it.

    • Like 1
  2. This is referring to the IDM datalink functions. This is a slightly older datalink that works over the VHF/UHF radio. Currently IDM is not modelled at all. Some functions may come later, as Wags keeps hinting. Although time will tell. 

    The specific function described above is using the IFF IN hotas command to initiate a datalink round which asks each flight member’s IDM to send their current position. 

    You can also assign A2A targets to each specific flight member (as in Wag’s roadmap). You can also send/receive FCR cursor position and HSD current Steerpoint. Similar to link 16. 

    There is also functionality to receive a CAS 9 line message and corresponding HSD symbol. And also SEAD functions. Would be very nice to get these functions at some point. 

  3. 23 hours ago, skypickle said:

    There is also a button on the TADS to change ‘first’ to ‘last’ in the event of backscatter

    I don’t think this has any effect on backscatter at all.

    See the definition of BACK SCATTER someone posted above. 

    A typical way around BACK SCATTER is to stop lasing and fire the missile in DIR LOAL and lase immediately after launch. 

    I’m pretty sure Back Scatter is a safety inhibit, so the 2nd trigger detent won’t work in this case (unlike with a performance inhibit). 

  4. 54 minutes ago, Chain_1 said:

    Just tried your replay in MT and both worked as advertised.  The issue was needing to turn down the map gain under the data page (like in the Viper, if you have that).  The GMT bricks blended in with the terrain until I turned it down.

     

    No, this is not the solution.

    Yes it will make the bricks more visible, but it doesn’t address the bug. The GMT and SEA modes are both displaying terrain mapping incorrectly in MT.

    They should not display ANY terrain unless the INTL (interleaved) option is selected, and then only on alternate sweeps. Compare this with the correct behaviour in Single thread. 

    • Like 2
  5. 7 hours ago, RogueRunner said:

    I also like to know. Everybody falls back to ground attack points and such. From a pure navigation point of view, in the Mirage for instance you can tune to a TACAN channel and create an offset for 200 degress and 70nm and the INS will give you steering to follow to reach that point. Navigation beacons in the DCS world is sparse so it makes sense to make offset waypoints to enter a valley or some other point you want to fly to.

     

    The Viper OA1 and OA2 can do this for waypoints but you can only enter feet which obviously makes the range an issue, you would most likely only be able to put in a few miles at best.

     

    EDIT I guess with modern systems you do not need this much, it pertains more to older INS systems. Would still have been nice to do, for example if you get a bullseye call ffrom GCI for ground targets it would have been easy to program the offset from bullseye to get to that target

     

     

    This is not the use case for Offset points in the F-16. Typically BULLS calls are for Air-to-Air stuff. For a ground target the AWACS/JTAC/FAC/other agency would give a LAT LONG or Grid as part of a nine-line, you can put this into the nav system as a normal steerpoint. When working with a FAC/JTAC, you might use the VIP feature when the JTAC refers to an IP, but this would not be the Bullseye. OA1 and OA2 don't work how they should in DCS....they've been wrongly implemented, so I would avoid using them.

  6. 8 hours ago, LastRifleRound said:

    How does an OA fix a steer point but not a line up?

    Sorry but what do you mean by ‘line up’?  A simple left/right steering error? A specific pre planned attack heading? An attack run in referenced to a known ground location (IP)? Or the correct lat/long of the target? 

  7. 27 minutes ago, RagnarBSE said:

    Hi Chaos, i have follow the wags video, in VRP i don't press TMS up  to follow WP. Is all auto mode. Let me know!

     

    Thx in advance

    Have you enabled VRP by mode selecting (ICP zero key) VRP mode in the DED?

    You don’t TMS up in VRP (that’s a VIP thing). Make sure the HUD says VRPCRP and simply slew the diamond over your chosen visual reference point. The target location, which is the Steerpoint, will be updated in sync. Fly the azimuth steering line and drop. 

  8. 6 hours ago, LastRifleRound said:

    OAs are sighting in with a sensor, to line you up for a visual attack on a target that may be difficult to acquire visually to begin with.

    The OA itself is not visual, but the attack on target often is.

    Well it could be. But you could say that applies to any CCRP attack.   
    You typical start in CCRP and transition to CCIP if the target is picked up visually, CCIP having the advantage of AGR slant ranging which CCRP lacks (in the F16). 
    It’s not really the line up which OAs seek to solve……it’s the error in Steerpoint position caused by a drifting navigation system. Again radar Offsets are designed to be used in completely blind/night/imc conditions. VIP/VRP are the visual equivalent. 

    6 hours ago, SickSidewinder9 said:

    The short answer is yes.  It's done in the DED.

    Nope, the answer is no.

    Offset Aimpoints in the F-16 are used differently. 

  9. 20 hours ago, LastRifleRound said:

    This isn't really an argument against an offset aimpoint. An offset aimpoint is used to make sure your attack geometry is correct at roll in. It just has to get you close enough that when you nose down you'll be close enough to the right vector to get on target. An offset aimpoint is meant to aid a visual attack, not replace it.

    With always perfect coordinates and GPS that never fails, there aren't many scenarios outside of some weird vectoring situation from a third party that would use it in DCS. If you went no GPS, iron bombs, and gave a long enough flight to accumulate drift, and wanted to execute a pop up from low level or a mid-altitude attack on a target that is difficult to visually acquire (think Osirik reactor strike or some such), an offset aimpoint (or in the Osirik case VIP) is an excellent tool.

    As for OP, the function you seek does not exist in this jet.

    Offset aim points in the F-16 are NOT designed for visual attacks. They are designed for use with the A/G radar in GM mode. In a pre-GPS day when INS could drift an offset allows you to make a blind attack on a non-radar significant target by slewing your sensor (radar) over a radar significant offset. 

    VIP or VRP are for visual attacks, but these are different than OA’s. Same principle but visual rather than blind. 

    OAs are broken in DCS anyway. Don’t use them for anything at the moment. 

    • Like 2
  10. 1 hour ago, VarZat said:

    Yes, but the problem with this is that it is not accurate. I dont know if it is a bug or not, but the range i am looking for is only on the EHSI. 

    I definitly prefer using VIP or VRP, i am trying to get better at doing them more on the fly without having to do alot of planning.

    Ok, so the Bx.x range in the hud is slant range, rather than ‘along ground’ range - is that your issue?  But you said you were doing low level, so effectively they are going to be very similar. 

    I’m not sure why you want to be looking at the EHSI during a low level attack when the same information is presented better elsewhere. 

  11. 6 hours ago, VarZat said:

    Problem with this is it rounds up to the closest full number or something like that, so if im doing a popup at 6,3 NM, it wouldnt work.

    You get a decimal distance x.x anytime the distance to the current SPI (you want a pre planned Steerpoint here) is less than 10nm. 

    Look for BX.X in the lower right data block. Make sure you Cursor Zero. 

    You can set up a PUP with either VIP or VRP, but this isn’t strictly needed for what you want. 

  12. There's been a persistent symbology error with the HUD in CCRP.

    The Range and Bearing to the TGT/SPI in the bottom right of the HUD (window 14), currently shows the absolute (real) bearing to the nearest degree. This is incorrect, it should show the relative bearing left or right in tens of degrees. The left and right isn't specified i.e. it should only read 00 to 18 in 01 increments.

    Please see lots of HUD footage online and the reference manuals available. I've included a video below, and I'm PM'ing BN with some further info.

    Thanks.

    hud clip.png

    F16 CCRP Relative.trk

    • Like 1
  13. Note that you can still use the system to take a ‘route’ into account. You can enter a TOS for every Steerpoint….

    During mission planning you’d enter/plan a TOS for every SP (given a certain desired Ground speed along the route from the start point.) Obviously the planned Time over Steerpoint for say SP 5 would then depend upon the route you’d planned, and all previous Steerpoint TOS’s. 

  14. Is there an up to date reference for how the aim-54 decides to loft. 

    This seems to be out of date? Or is it?

    Ive seen PD-STT not lofting at 20nm, when the guidance below suggests it should only fly direct when within 10nm.

    Is PD STT lofting range dependent behaviour more complicated than just <10nm?

    This is with the C variant. 

     

×
×
  • Create New...