falconzx

I am completely agree about parallax errors, they should be taken in consideration especially in ground align cases. Anyway i am used to do in-flight MAV aligns so the parallax at 7-9nm is neglegible, but i noticed a little vertical inaccuracy when i try to hit something with the Force Correlate mode (in F-16 WPN page is called AREA on H/K versions). In my tests the groundpoint locked by my mavs was a little long. I also noticed a random little slide of the crossair in the exact moment of MAV lock (TMS up). I'm not at home this week so i can't post my tracks, but i suggest people to try testing Force Correlate mode and try to be accurate and consistent with the point you targeted on Litening POD.

During the previous patch i opened a bug report about the inconsistency of coordinates between INS(i guess) and TGP coord visualization. That topic has been merged with CZ problems, but i don't think this inconsistency has actually addressed as issue. So, before opening a new bug report, i just wanna ask: which is the correct behaviour? When i move TGP on the ground i see some coordinates, which is the system that is providing them? if it's the Nav system, why if i put a mark the coordinates appearing on DED are different from coordinates i see on TGP? And why if i make it steerpoint and i CZ i will never get again that point? My guesses are that the nav system (INS+GPS) is constantly correcting, every frame. So when i move the TGP my alignment is different from the moment i create the mark. Is this the real airframe behaviour?

Put TGP, initialize it and use a bit. If you put it in POINT (TMS up), default Mark mode will be TGP (that's awesome). But, if you put it in AREA, then the default mark is HUD, but it's stuck, you can't see the point inside the FPM and it doesn't react to TMSup or down(to reset). Even if i exit MARK mode and i put HUD SOI, it's stuck again, the only workaround is cycle with SEQ all the Mark input modes, until i land again on HUD, there it will work again. Short track included. F-16_TGP mark_hud_stuck.trk

For me and my squadron this feature implementation is one of the most desired. I hope ED Team would make progress on this soon.

Create a Mark via TGP. While doing that, compare TGP coordinates with what popped up on DED. They are different, same in elevation. Then (M-sel) to select that steer, and recall it with TMS-Down(CZ) what TGP slaving to is another coordinate (a new one!). And every time you CZ you get a new jittering one. I think this issue is related to this one. I made a new report because the inconsistency between markpoint recording and TGP coord.display maybe is a different issue. INS_strange_jiggle.trk

Yesterday evening encountered same problems. Cold start, MP, 6xAGM65H. In Air boresighting was possible but when you TMS aft to see how aligned it is the mav goes in another place (a lot away from the point). So unusable. At ground things appears to be more consistent, but, again too much parallax, and theres something weird with Force Correlate, when i do it the mav locks in a different point. More the parallax you have and more this happens.

Do not confuse what you want with how you want it. In this topic there are very useful solution to the problem that respect probably the everyone needs. Discussions are useful when you can collect a lot of ideas and choose the best one.

Just bind the ejection handle to a macro via software. Or put the ejection handle over a 3 stage switch

or... just put as default a program with 1CH and another one with 1FL (i thinks this is what most of us want when changing those programs) This could be a 1 minute fix for ED, that save to us hours changing those programs

it's not only about the FCR to TGP's SPI sync, but IMHO all the SPI system needs a check in many situations and cases. For example: few days ago in 2.8 I noticed that with a loadout A/A+AGM88+HTS+TGP (a classic one for F-16C), my TGP wasn't able to move SPI, or at least in my HSD the SPI symbology was STUCK, probably because of the presence of HAD, but even turning it off via pylon switch i didn't solve this, and going in NAV neither. Now i don't have time to make report, tracks and so on about this specific case (if someone can please do it).

Confirmed. I reported this too in Bugs section.

SPI not consistent and synced automatically between FCR and LITENING.

Nobody want this, lol Map alt+e to a button and press it 3 times, i don't see the problem

Any ETA from ED guys about a fix on this?

The track is uploaded

The fact IC breaks even if you join a purescripts disabled, and you have to restart dcs again and again even if you never entered a purescripts enabled server is very annoying and time consuming for people. I just need it to change my countermeasures preset on Viper and mirage. We need a fix on this please!

seriously? a track to demonstrate that MFD buttons (GAIN+ and GAIN-) have no effect in FCR - GMT mode? If you really need a short track in wich i press the buttons and nothing happens, ill do it... EDIT: GMT_stuck.trk

In 2.7s GMT gain setting was inherited from GM gain setting. So to see moving targets (white) in a prevalent white ground return i used to set a low GM gain to get a lower point of white, and then switched to GMT having there that setting. In 2.8 GMT is not inheriting Gain from different modes, but the gain is still stuck, the result is that the only way now is tweak Brightness and Contrast, but is not a solution for every scenarios. GMT_stuck.trk

The new yellow M4 bad answer of IFF, is coming from all bandits, even if you haven't found them on your radar. In simple words, a cheat! f-16_IFF_scan_see_all_bandits.trk

I don't think commanding IFF scan would result an answer with angle+range from enemy units, it's correct to receive that info from succesfully iff (friendly aircraft). With this patch is even useless to use the radar. To find enemies location in this patch, regardless their range, is enough an iff scan. I think this is a serious issue that worth a fast hotfix. @BIGNEWY

I know that these are opinions, but we are just looking at wich is implemented yet and how is it implemented: For example: If you leave AA mode with FCR set to TWS, when you go back in AA mode, (thank God is like that) the avionics remembers the settings and you will find all the settings you put. The same happens for TGP, HAD, etc etc. It's all coherent, so its very strange that the only page that resets, is the FCR GMT that reverts to GM everytime you do something like exiting AG, like AA or S-J for example.

Inter-Flight Link-16 Data Link Sharing This is what remains as "wip" in the wishlist EA topic. The "integration of HMCS with HTS, Link16 and AIFF" point just disappeared from the roadmap list. As we can see from the community poll, it was a very high desired set of features, so how can be that it suddenly disappeared?? In our squadron F-16 division we are very curious to know what's still missing about the Link16 implementation. So i would ask ED: what is exactly missing on the current OB F-16, and what is actually in progress at the moment in relation to Link16(A/A and A/G) ? Thanks very much.

I don't know how is it in the real plane.But it doesn't seem to me a bug. I expect that the position of the cursor when i press EXPAND will be the center of the area i'm zooming in, so the symbology underneath the cursor will be in the center of the screen. What would be useful is to not having the cursor still in the old position but resetting it in the center when inside the expand mode. BUT putting the cursor in the world space instead of the actual screen space is very annoying when you maneuver the plane while doing those operations. So screen space is important to be maintained despite an eventual cursor position reset.

X56 throttle rotary axis for ANT ELEV here if you say so, probably the bug is related to the latest fix about antenna. On the previous issue only Flappie was able to reproduce

I can confirm and i found a way to reproduce: Put RWS > SAM mode (so single target bugged in RWS) > get close to contact enough to see the radar stop sweeping (in my test less than 10nm) > then turn and put the bugged contact out of gimbal > wait for the radar to loose track and the antenna is stuck. To momentary fix the problem you can enter tws and go back to rws. Attention to underlined step, if the radar is sweeping the bug doesn't happen, but you don't have to be so close that the radar switch to STT, the mode still have to be SAM with the azimuth blue lines visible. By the way i want to take this opportunity to make my warmest congratulation to the Team to have finally nicely fixed the absolute axis re-zeroing!