Jump to content

SaladinoSaurus

Members
  • Posts

    58
  • Joined

  • Last visited

Everything posted by SaladinoSaurus

  1. Our F-16 should most likely have the RWR Slave option, which provides air-air search and automatically STTs with the FCR by slaving the FCR to the priority target on the RWR scope. It is entered within ACM by TMS-right when no target is being tracked. The aircraft will enter a submode of ACM called "RWR Slave", which is indicated by the "ACM" text adjacent to OSB1 and the "RWR" text adjacent to OSB2. I can provide further explanation if necessary, but I think it's more useful if I provide evidence in PM when inquired about it.
  2. Can I get a reason as to why this has been moved to ... Wishlist ? I reported it as a bug, and after providing evidence it has been moved to Wishlist?
  3. Any update ? This has seemingly been on "investigating" for nearly a year now.
  4. As the title suggests, certain AGM-88 HOTAS functions don't work in the WPN page, mostly in the POS submode. Track attached, and ofcourse I can provide evidence that it SHOULD have (similar to EO delivery modes) HOTAS functions ... AGM88 no Z-axis cursor HOTAS functions (or pinky switch).trk
  5. The HSD datalink rotary at OSB 6 in the DCS F-16 shouldn't have an off position, it should automatically be on "TNDL". I can provide evidence in PM. Track attached, because why not HSD DL incorrect rotary bug.trk
  6. *This only holds true for page 1. Not Page 2, which makes sense since page 2 is L16 stuff.
  7. I can PM the evidence if required. The HSD Control page should save its options per mastermode (MM), but it's the same regardless of MM, it reduces the customization it gives you and it's incorrect as far as my knowledge goes. Track attached. HSD Controls not saving per MM bug.trk
  8. It got fixed, thank you ! EDIT: It still happens sometimes, but I cannot reproduce it consistently
  9. The FCR should be in STBY *IN THE A-G mastermode(?) when weight is on wheels. The freeze submode is indeed a non-radiating mode, but after the FCR BIT (which isn't implemented) the FCR should go into STBY, unless another mode is commanded (but I don't think you can command any other mode since all other modes are radiating modes). I think you can deduce it's wrong because when you cycle through the A-G submodes is when you select CCIP, the FCR will be in AGR, which is a radiating mode (it shouldn't be possible). I can provide evidence if required, track is attached. Steps to reproduce: 1. Get weight on wheels 2. Get into A-G mastermode, and cycle through all submodes, you will see it will go into AGR and GM FZ, which is likely incorrect. You can also figure it if it's correct checking if (for example) you're in AGR in the AIR, and you set the R/F switch to QUIET, it should go into STBY/OVRD, but it doesn't. FCR should be in STBY with WoW bug.trk
  10. When going into A-G and cycling to CCRP with the NWS/AR switch, the FCR will stay in the last selected mode (in my track CRM/RWS) instead of going into GM (which I believe is the standard preplanned FCR A-G mode), CRM is not available in the A-G mastermode, so this shouldn't be possible. This only happens with the NWS/AR switch, if you select CCRP via the OSBs on the MFDs, it will work correctly (and then NWS/AR switch also works correctly). Steps to reproduce: 1. Get into A-G mode with bombs that can use CCIP/CCRP/DTOS (anything except IAMs If I recall correctly) 2. Cycle with the NWS/AR switch through A-G submodes, the FCR will stay in the last selected mode instead of going to GM when in CCRP Track attached, I can also provide evidence in PMs if required. HOTAS A-G submode selection FCR bug.trk
  11. When you have a PDLT selected and have the PDLT mnemonic highlighted in the 2nd HSD Control page, the HSD should automatically increase (NOT decrease) the range when it's outside of the display, currently in DCS it does not do that, neither when you toggle on/off the PDLT mnemonic in the HSD control page. Steps to reproduce: 1. Select PDLT on HSD 2. let PDLT get out of range, HSD will not increase range regardless of PDLT mnemonic. Track attached HSD PDLT not range bumping bug.trk I can provide evidence in PM if required
  12. The FCR ghost cursors on the HSD remain even though I have deselected the FCR option in the HSD control page, it should remove both the scan volume and A-A/A-G FCR ghost cursors. Steps to reproduce: 1. go to HSD page, and select OSB 5 (CNTL) 2. Select OSB 1 (FCR), you will see the FCR a-a/a-g ghost cursor remains displayed Screenshot: I have also attached a track HSD FCR CNTL bug.trk
  13. Currently in DCS the F-16 has 700 steerpoints, as far as I know the F-16 could either have 127 or 999 steerpoints. 127 with an INS + GPS solution (which we have in DCS) or 999 with an EGI solution. The allocation for steerpoints is also wrong, you should be able to select threats as steerpoint (similarly to how you can set most things as a ACQ point in the Apache), because that's what the steerpoints are for. I have attached a track and can PM evidence of the correct steerpoint allocation if required. stpt allocation bug.trk
  14. The AA Ghost cursor should be a "ghost" or mirror of the FCR AA cursor, to represent the position of the AA cursor on the HSD. When you make the HSD SOI and use the expand feature the AA Ghost cursor stays in the position it was last on in the display, which is a bug. It can also make the AA cursor get outside of the scan volume. Steps to reproduce: 1. HSD SOI 2. Increase/decrease, Couple/Decouple or Expand/Zoom the HSD 3. You will see the FCR AA cursor stays in the same position even though it's actual position hasn't been slewed AA Ghost cursor HSD bug.trk
  15. Do you mean that the MAV FOV circle is not aligned with the TD box? Or do you mean that the MAV FOV circle is not aligned with where the maverick is actually looking?
  16. In DCS 2.9.2.49940 the DTT scan volume is not being centered on the secondary non-bugged target, it should behave per the following: In the attachments the track shows a scan volume centered about the FCR cursor (which is correct only for SAM). I have a screenshot below showing the incorrect scan volume centering aswell. EDIT: You guys might have different info based on new documentation, but it's really difficult since I don't know what info ED has which I don't. It isn't really transparent. DTT scan centering bugbug.trk
  17. Indeed I did, I reposted it because it got marked as [REPORTED] but it's still present in this version. I might've made a mistake calling it VAHS instead of VAH (it might be VAH) It's a small bug that irks me because I lose track of my FPM sometimes, because it's cluttered in the Heading scale. VAH is just the name for all the tapes/scales you see on the HUD, so Velocity, Altitude and Heading (VAH). I called it this because I thought it'd be easier to find *this acronym in the manual
  18. Great catch, that is a bug,. According to the MLU M3 pilots guide manual on page 206 all these OSB rotary functions are described: In DCS 2.9.2.49940 this behavior is as you shown in the screenshots, wrong. I have added a track below, which shows even weirder behavior ? removing SOME friendlies, but not others? I assume something messed up with the "recent" datalink rework/update to DCS HSD friendly decluttering bug.trk
  19. Posting a bug report about the VAHS Heading Scale not moving with the FPM in the following Master Modes: NAV, AAM/A-A, JETT and MSL. The A-G and DGFT mode DON'T have this behavior, explained later. In these three videos (I have timestamped the rough moments of when you can see the Heading Scale move down with the FPM(Flight Path Marker)) you can see that the Heading Scale is moving with the FPM downwards, I do understand that these F-16s are all different, but it would make sense that the Heading Scale moves with the FPM to prevent them "going through" each other and not being able to see your heading / FPM: This video is a very new F-16, the VAHS Scale is also a newer one as you can see with the Speed, Altitude and Heading box showing the exact heading, look closely under the black square in the middle after you've clicked the link, you can see the Heading Scale moving down with the FPM. I assume this is in NAV mode. This is a tricky one. Here you can see "the" older VAHS Scale with no Speed, Altitude or Heading box. I have timestamped roughly 2 or 3 seconds before you can see that the pilot is going into JETT mode and if you look VERY closely, you can see the FPM bump down the Heading scale for a fraction of a second before he gets back into A-G mode. This HUD footage also shows the older VAHS Scale, after he simulated his weapons employment with his AIM-9 (in SIM and MSL master mode) he pulls up and you can see the FPM bump down the Heading Scale again, just to show this happens in NAV, AAM, JETT and MSL Master Modes. In A-G mode the Heading Scale is always just below the Boresight cross thingy of the HUD, and in DGFT mode there is no Heading Scale showed lol. (He ejected and is fine, he got away somewhat unharmed) In DCS none of this is the case, I have made simple screenshots, all of this is in NAV mode, but I have tested and it's exactly the same for AAM, JETT and MSL mode: When landing gear is down, the Heading Scale also behaves differently, but that seem to be correct in DCS, so no need to change that. VAHS FPM bug.trk
  20. Seems like a good time to fix this since the Viper is now slowly getting more devs. Behavior seems to be the same on Open Beta 2.7.5.10869.
  21. You do realize Eagle Dynamics is modelling a General Dynamics (now Lockheed Martin) F-16CM (CM means standardized with Common Configuration Implementation Program, CCIP) Block 50 Fighting Falcon "Viper" used by the USAF/ANG from circa. 2007, right?
×
×
  • Create New...