-
Posts
58 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Everything posted by SaladinoSaurus
-
Community poll for HARM and Maverick on stations 4 and 6
SaladinoSaurus replied to BIGNEWY's topic in DCS: F-16C Viper
You do realize that the USAF never even carried CFTs or Chutes... and the USAF Block 50s never carried LANTIRN either... -
Community poll for HARM and Maverick on stations 4 and 6
SaladinoSaurus replied to BIGNEWY's topic in DCS: F-16C Viper
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?). -
must align correct as-is [PLEASE INCLUDE TRACK] HUD bugs after repair
SaladinoSaurus replied to Furiz's topic in Bugs and Problems
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.... -
reported Air turbulence stops the INS alignment (trk file attached)
SaladinoSaurus replied to Schuke's topic in Bugs and Problems
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. -
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
-
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
-
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
- 1 reply
-
- ccippipper
- f16
-
(and 2 more)
Tagged with:
-
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.
-
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.
-
I know.. INS in F-16 is still WIP. It seems like you can get a status 6 with a normal GC alignment (setting INS knob to NORM and wait 8 minutes), which is actually not possible. The highest you can get with a normal GC alignment is status 10, status 6 is only possible with an EIA (Enhanced Interrupted Alignment) which requires you to move the aircraft and do lots of fancy stuff (EIA also needs atleast 4 more minutes, not 42-ish seconds). Status codes(number) with time and description (of a NORM alignment). The following might be completely wrong, I am not 100% certain as I don't have the Block50CM manual --> Also: at status 70 you should get a Steady RDY/ALIGN text on the DED (and HUD(?)). Another tiny bug: When confirming the coords on a NORM alignment (normal GC alignment), you should Re-enter them, not press Enter on the ICP. This is for both LAT and LONG coordinates. (in DCS both methods work). Why? The RLG INU (Ring Laser Gyro, Inertial Navigation Unit) will flag the alignment as possibly degraded and stuff goes bad. Try it for yourself, I unfortunately couldn't get my track file of me starting up the jet with a NORM alignment (track file was too big), but I can show a screenshot! ^This shouldn't be possible. A standard EIA will need atleast 12 minutes for a complete Standard Enhanced Interrupted Alignment.