falconzx

let's feedback the latest one. -Signal intensity interpolation, which was the most useful thing, is lost. -Major threat is so close to the center that you can't determine a precise relative bearing (so notching become hard) -Often the missile indication merge on top of the priority threat locking you, so you can't read anything, it's all piled up into the center. I hope there's data supporting these PRECISE changes because it is very inefficient compared to the previous update.

yes Brightness and contrast setting are associated to the pages and to the master modes. So you can configure at best your screen for a night mission (ex. having very dim pages in A/G when you use NVG and bright pages in NAV when you turn off your goggle)

Nope, if it's more correct like this i will love it. :) Thank you.

What about the decreased precision to the green circles with the latest big patch? In Furballs is unusable. Is intended to be like that or is it a bug?

happened during tests trying to reproduce the bug, so before the bug occurs i turned on and off RWR and changed settings several times. Then it became blank except for A/A threats. track attacched. RWR stopped working on SAMS.trk

It's correct and it's supposed to work as it is. The fact that's being not considered is the RL axis. That's why I use an absolute axis like in the RL F-16. If you have a rotary under your fingers you feel the physical position of it, you feel the detents, so on the F-16 you dont need any hint or symbology to know where the antenna is commanded to look, i understand SAM stage of RWS can be tricky with buttons, because you have to look what the antenna is doing after you commanded the change and not while you are changing it.

why looking at 2.5 table when there are newer tables? go to this link. https://github.com/Quaggles/dcs-charts/tree/master/Aircraft RCS and IR Values

I just replayed your track and I took a couple of screenshot from it to show what i mean Here is when you just created the mark: TGP shows 4150521 - 4147877 DED shows 4150527 - 4147882 My question was: even if little, why this difference? which is the correct one? From where TGP take the datas if the DED shows another number? It's not a huge difference but is anyway more than .001 Here is after you recalled the steerpoint, so it's like asking our TGP: hey go on the coordinate stored, so i'm expecting it should be the second one, the one is showing on DED. And this is not happening, the TGP shows a new fresh coordinate.(in this case moved by the first one by .001 but this difference it's not constant if you do more tests) TGP shows 4150520 4147876 DED shows 4150527 - 4147882 (the same as before) Anyway the point you recalled is not anymore on the vehicle, but is on top of it. So this way of marking point is definitely unsuitable for precision bombing. I'm not saying this is wrong, i'm just asking how it works, and if this is how it works in real Litening and Mark function.

I think they just forgot to add the word: - possible- before "radar scan volume" . So the equivalent of that is the 60+- elev and 60+- azimuth, so the MFD display. In RL the only limitation here should be the range. The fact it's not correlated with the radar, the radar can also be turned off, It make sense the IFF continues to work regardless to radar state and settings.

Yes that was true in the past. Now with the latest patch you don't have accuracy increases if you are aiming a point in the ground! Lasing allow you to update coordinates and elevation only if you are aiming to a building or on top of a vehicle. It's like TGP without laser "knows" the exact elevation of every point of the land mesh of the scenery without considering 3D object, but if you lase you can take in consideration the 3D object bounding boxes. So what i noticed is: TGP coordinates display are the true coordinates of that land point, it's perfect, what is not perfect is our INS, so when you make a markpoint, the coordinates passed on DED are completely off! So if you want to save a precise coordinate of a point in a RECON activity, it's impossible through markpoints. You can only write down on paper what you read on tgp. That's why i'm asking, what is supposed to be the origin of coordinates displayed by TGP? How can they be so perfect, and how the plane knows the exact point if the INS is so much inaccurate and instable?

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