falconzx

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!

Or, in a more practical way, fly your plane in TRUE heading. (DED->list->misc->magv->set to manual, set 0.00 enter.) For example, in my squadron we usually put all the planes we fly in true heading as uniforming procedure.

So the doubt is: Is it just a shortcut for a scan pattern we can select already via OSB or does this scan include a forced STT lock in case the radar eventually picks something?

Oh thanks very much for the info. So there is really a bug or a wip feature.

Isn't the additional data to perform a stored heading align pre-inserted by ground crew?(i'm just guessing) In DCS i think that type of "support" is simulated only at the first spawn for obvious reasons. Enable that everywhere means that you are simulating to have your crew even if you land on an highway in the middle of nowhere.