Jump to content

SaladinoSaurus

ED Closed Beta Testers Team
  • Posts

    35
  • Joined

  • Last visited

About SaladinoSaurus

  • Birthday 01/01/2020

Personal Information

  • Flight Simulators
    Falcon BMS, DCS World
  • Location
    Netherlands
  • Interests
    Flight Simulation

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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?
  3. You do realize that the USAF never even carried CFTs or Chutes... and the USAF Block 50s never carried LANTIRN either...
  4. Correct, as far as I am aware the USAF F-16s don't have the pylons wired to support smart weapons like JSOW, JDAM (and WCMD?).
  5. If you turn off the INS on the INS panel and turn it back on you will have to do an alignment again.... I don't see why this is a bug report....
  6. How much does the aircraft move? Possibly it is enough to disturb the alignment and "activate" NARF(if this is modelled), ED will need a track file though.
  7. I have done a cleanup and repair, and the exact same thing is happening. I don't think it's because it's a bug, I think it's incorrect SPI Logic. In DCS currently when making a slew difference in CCRP or EO-PREplanned and changing master mode to NAV (without pressing Cursor Zero on OSB 9) the slew differences aren't applied to all the steerpoints, or any steerpoint... in the MLU-M1 Manual I have gathered more info that it should do that, quoting this: This is from the MLU-M1 manual, PDF Page 164 (154 in the actual manual). It literally states what I said in the bug report/right here. Even though we don't have a greek F-16CJ Block 50 or a F-16AM MLU, I have no doubt there would be such big (and confusing) differences in the SPI Logic. Now for the second part: About the steerpoint being classed as SPI in the VIS Submode for the mavericks, figure 1-290 in the HAF -34 manual (PDF Page 459, section 1-443), you can see that the steerpoint IS NOT visible on the HUD, and there is no TLL going to the Steerpoint. As I said earlier I am pretty sure this is because the steerpoint is being classed as SPI / Target, but I don't know as I don't see the internal code. You can also see in the figure that the steering circle thingy (the circle with dash above it navigating you to the selected steerpoint) is shown on the HUD, in DCS that's not shown... again because I am pretty sure the steerpoint is getting classed as SPI / Target... I have linked 2 different track files, the one named SPI_LOGIC_2 is the one about the whole CCRP and EO-PREplanned (PRE Submode for Maverick) thing while the second one named VIS_STEERPOINT one is about the second part in this reply. Once again, check HAF -34 manual, PDF Page 199 (Section 1-183), Figure 1-116. It says all things about all different A-G modes... I will quote another thing about it: If you look at the figure, the EO-PREplanned, CCRP and LADD modes all have the * before the Steerpoint, this is in DCS possibly incorrect HUD symbology, because it still shows, but it does bring the actual steerpoint with the TD Box which is weird (this behavior is shown in both of the SPI_LOGIC track files) Sorry for posting such a big reply, just trying to give as much info as I possibly can. SPI_LOGIC_2.trk VIS_STEERPOINT.trk
  8. First part of the bug report: In the Open Beta version of DCS (2.5.6.59398), the steerpoint/SPI logic is completely messed up, especially for the CCRP-type modes (CCRP, EO-PREplanned (PRE Submode for AGM-65s) and LADD -something not implemented yet-). I will use the CCRP submode for example, but the behavior is exactly the same for the PRE Submode for the AGM-65. When entering A-G mode (CCRP), the HUD symbology is incorrect as the Steerpoint Diamond is being shown, while the steerpoint diamond should always be occluded in the CCRP mode (aswell as EO-PREplanned and LADD) as the steerpoint will be coincident with the TD Box (square with dot in it). The steerpoint is being slewed with the SPI which is correctly modelled right now, I have tested it and the AP will follow the TD Box/SPI and not the Steerpoint diamond, so this is only incorrect HUD Symbology. But now it gets a little funky, when going back to NAV mode without pressing Cursor Zero (in the A-G CCRP mode) the steerpoint location will not get updated, while it should be "updated" to where the slew difference was made in the A-G CCRP mode, this is also backed up with the steerpoint diamond still being on the original location and the AP flying towards the original steerpoint. However when re-entering the A-G CCRP mode, the TD Box will be at the location it last was (when not being Cursor Zero'd), this is very weird and it's not modelled correctly, there is basically no need to use Cursor Zero as the use of Cursor Zero was to revert the Steerpoint location to it's "orginal" location, which with the current SPI logic it does automatically without using Cursor Zero. Cursor Zero now only reverts the slew difference made in the selected master mode. I will link a track file also showing what I meant here above. How the SPI logic should act is the following: When making a slew difference in any CCRP-type A-G mode (CCRP, EO-PREplanned and LADD) and NOT pressing Cursor Zero before going back into the NAV mode, the slew difference you made will be applied to all steerpoints in your flight plan (I am not 100% sure if it is actually ALL or if it's just steerpoint 1-25), and the steerpoint diamond on the HUD will be on the "slewed" location and not the original one. If you do press Cursor Zero nothing will change with the steerpoints. In the HAF -34 manual, PDF Page 199 (Section 1-183), Figure 1-116 you can see that in the CCRP, EO-PREplanned and LADD modes the steerpoint diamond will be coincident with the TD Box and therefore the steerpoint diamond will be occluded. Even though this is an HAF manual, I doubt it will be any different for the USAF F-16s, as this is the "base" software. Second part of the bug report: Also, in the VIS Submode for the AGM-65, the steerpoint(/diamond) seems to be classed as "SPI" in the code before the TD Box gets ground stabilized, this is seen because of the TLL(Target Locator Line) from the HUD Boresight cross "pointing" to the steerpoint(/diamond) before the TD Box gets "designated"/ground stabilized. Here are some pictures of the above^ Before the TD Box gets "designated"/ground stabilized^ After the TD Box gets "designated"/ground stabilized^ It is weird because I am pretty sure the TD Box would always be SPI even before getting ground stabilized, because the TD Box (would) gets FCR AGR'd. Anyways, I hope this was understandable at least, sorry for the wall of text... SPILOGIC.trk
  9. Setting XMT on HSD is not necessary, as this is a rotary that selects to what datalink "network" you will Transmit for example A-A info or A-G info, setting it to L16 will mean that you'll send your data over Link-16 network. This isn't modelled yet so no use in it at all
  10. In DCS in the F-16 when you command a Weapon Release in CCIP the CCIP Pipper (circle with dot in it) does not show on the location where you commanded the Weapon Release on the HUD. This is for both a normal CCIP drop and a post designate CCIP drop. It seems like this should show with some HUD footage to back it up: https://youtu.be/2uh4yMAx2UA?t=252 ^This is a Post Designate CCIP drop, with the Time Delay Cue -the solid dash- still on the steering(?) line. You can see that the CCIP Pipper is on the location where he pressed Weapon Release. This is an older HUD Scale, not the same one as ours in DCS. https://youtu.be/FdR6Zk33zV8?t=42 ^This is with the same HUD Scale we have in DCS, this just shows a normal CCIP drop without the Timing Delay Cue on the Steering(?) Line, as you can see the CCIP Pipper is on the location where he pressed the Weapon Release button. In the HAF -34-1-1 Manual, PDF Page 446 section 1-480, Figure 1-283, you can see the CCIP Pipper on the HUD when doing a Post Designate CCIP release. I will not post screenshots of said as it may break rules. I hope this made sense I have also linked a track file, thanks. CCIPPIPPER.trk
  11. 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 in my eyes 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 even with AUTO-GCAS (not important, just a fun fact), 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: I have a Falcon/Viper's eye! EDIT: 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.
  12. Sorry... I am new to the forums, I just used the option that would seem to fit the most. As for the INS vs EGI question, I don't know! Ask the HAF why they didn't go all-out on the EGI, it allows for MANY, MANY more steerpoints as opposed to 127 (I am talking about 1000+, probably even 3000).
  13. An EIA is still possible with EGI and INS + GPS (AFAIK, it at least is possible with INS + GPS) equipped aircraft, it just requires you to turn set the FILTER MODE to INS, (LIST > 4 > Dobber RIGHT (SEQuence) and pressing any number on the ICP to set it to INS. This will set the KALMAN FILTER to only filter/update from the INS data it gets, not the GPS data (performing an EIA will not work when getting KALMAN filter updates), a standard EIA will increase the INS accuracy by about 40% for the first hour of the flight. The F-16 we have in DCS uses an INS panel, not EGI. I am not talking about EGI, EGI needs only 4 minutes for a NORM alignment and only 30(! crazy) seconds for STD Heading alignment.
  14. I do! But I have been told posting pictures of the source would get me banned :(, any other way I can confirm this is correct?
×
×
  • Create New...