falconzx

same bug for me. I set up user curves to align physical detents to the military power value when i restart dcs, all is back to default.

Sry i reviewed your tacview and i don't see any issue. The missile is tracking because the Su27 is way inside his 60°gimbal limit. He's guiding his missile, no reasons to think it shouldn't track.

Drift is modeled in TGP. And you can test it if you want. This misalign described it's not related to INS Drift, try to do INS Fixes procedures and you'll see with your eyes that even if you do a perfect Fix you will not correct this. It's subtle but enough big to make DTOS unreliable with GP bombs. Inviato dal mio 24069PC21G utilizzando Tapatalk

But impressions on this topic seems not to be aligned with that FAQ statement. Is it a placebo effect generated by better sound and textures? Anybody did some real tests?

So, is it or not?

Yes. Just try to use DTOS with Mk82 and try to designate a target. No wind, perfect conditions. Bring your TGP just for double check the difference in designations. First designate with HUD only, DTOS is an in-built avionics mode designed to do that. And check how precise you are tossing some bombs. Then try correcting the designation with TGP and see your precision how much increases. Same thing with the A-CAL procedures. Try to fix a drifted INS on your reference point with HUD and you'll probably do a mess. If you fix it via TGP it will be a lot better. The real question is: is this misalign a weird bug or something crafted by ED intentionally?

If what you're reporting it's true, the MAV misaligned is acting like a INS weapon with a coordinate drift. We should have a MAV camera Line of Sight angle-to-angle align to reduce the offset between tgp and mav cameras.

At the current state of the module, what we observed is not an inaccuracy related to the INS+GPS. Taking care of the standard procedures, that @BIGNEWY kindly reminded us, the drift is within the expected amounts, expecially when observing it through a Targeting pod in INS tracking mode. What we continue to find very odd is the constant misalignment of the SPI/Steerpoint symbology on the HUD, (given that what a TGP is showing in INR is the current INS solution for that coordinates+elevation). That Square, or diamond, is never aligned to the same point where TGP is pointing, there is always a difference and in some missions i've flown that discrepancy became very big (more than 200ft). I don't know how to reproduce the steps to make that misalign bigger, but it's never correct, even when just took off with a hot started jet. Seems there is always an elevation error, because the symbology seems to drift over/under the ground so it moves changing the view perspective. But, for example the calculated SPI for CCRP is never the HUD symbol (just try a good drop to see it), but the actual INS postion shown by a Targeting pod in INR, so it's the HUD to be inaccurate. This is the issue i think it's making the DTOS mode quite useless with GP ballistic bombs, if you don't have a TGP all the designations made by the HUD are wrong. Aswell, expecially in the pre-GPS-era operations, without a TGP even the INS fixes made by HUD are inaccurate.

Maybe i'm saying something obvious, but try to go in CNTL Menu and do the FLIR CALIBRATION. With that done i achieve almost the same quality of the Litening pod, in NON-XR flir modes, i mean.

Anyone knows how to add new current hill units to the new 2.0.4 databases?

or... enable GND Jettison Switch, then Jettison on ground the empty tank before the crew put a new one (in this way you are manually simulate by yourself the removal of the empty one)

Just tested in current patch: If you act as you described with no target bugged, just in scan, the radar will stop working, and even if you go MUSIC OFF the radar will be frozen and unoperable (probable bug, and not intended behaviour). You can fix the radar only going back to mode3 and cycling the MUSIC ON/OFF. But, reproducing your steps while having on FCR a bugged target, then the radar will continue to work and the ECM will continue to transmit ( another bug as i said before the patch, probably it should stop transmitting)

to me, sounds like a bug.

For me this issue was persistent every time i enter a server, i do a sortie with other modules, usually Su-25T, then if i sit in a F-16C i have problems with the HMCS alignment, i do it correctly and all the references are offsetted (not only the SPI box, but also PDLT). When the bug is much more severe it's hard to complete alignment because the real cross is not where you see it, so you get ALIGN FAIL if you try to do it correctly. After a lot of attempts aligning with the head around the hud you can also get the ALIGN OK then try to correct with second and third phase, but also like this you will not get a proper functioning HMCS. So to avoid that nightmare before sitting in an F-16C i quit the server and rejoin it. This worked for me everytime.

do you exit the MARK page after creating marks?

Decide with your friend a STN table with arbitrary number. Like 1 - 00023 2 - 00024 You both populate in your DED the table identically. When done the leader put #1 in "Own" position, the wingman will put #2. It will work. If not probably some of you messe up something. Also the DLNK time is important to be syncronized. If in a pre 1993 mission check time in Page1 and syncronize with your mates manually. In a current date mission you can Just put GPS Time On and all ll be ok. Inviato dal mio 24069PC21G utilizzando Tapatalk

I had some trouble designating targets with FCR GM (nav master mode) nearby SAMs. Attempts to designate someting (to retreive coordinates for example or performing a nav fix or putting a markpoint), on the same bearing of the SAM station but at slightly different range result in a SPI shift on the exact position/range of the SAM (way more precise than a HTS PGM2 solution... that's the funny part :P) This is pretty annoying when trying to use FCR to create a fast markpoint in order to POS HARM launch (closer than the target to enlarge the search area of the HARM over the target zone) because of this shift. Here the track. SPI_moves_FCR_close_sam_emission_FCRdesignation.trk

I apologize about my track, the LOS vertical angle between me and the contact was not so big(~20°) to see the bug clearly. In this second and shorter track i prepared a situation where the case is very clear. Steps to reproduce: stay high, wing level, command STT on a plane flying on the deck, hot. When he pass under you it will break the lock as he passes the 60degree gimbal. FCR returns to search and the ANT ELEV Axis will be broken. Detailed issue observed: As you reproduce the steps the axis center (50% of the potentiometer range) instead of centering the antenna on the horizon (0 degree angle) it remains where the contact has dropped, so in this case -60° degree. As this in effect you are no longer able to put your antenna upper than 0 degree, because you reach 0 degree as the potentiometer is at its 100%. I supposed you developers can see whats my pheriperals input status is in the tracks, if not, its very hard to check this from a track file. You should repeat the steps with an absolute axis assigned to ANT ELEV knob. I'm pretty sure you will not see the bug if the controller is a relative axis (like F-18 one) or buttons. F-16_ANT_ELEV_AXIS_RECENTERs_2.trk

In this track i intentionally drop contact by gimbal limits, after a couple of try my radar elevation is not anymore centered to 0 pitch angle as it should with physical axis in the center position. Thank you PS: workaround to momentarily fix is to cycle radar modes. F-16_ANT_ELEV_AXIS_RECENTERs.trk

Squadron Name: 36° Stormo Virtuale & SIG A101 Aircraft Selection: F-16C, F/A-18C, J-11A, F-15C Pilot Roster Falcon Wasp Merlin Knight Duriel Wildcat Iron MTSection Varmo Tralif Stockman

In the past i also used to put in NAV the FCR in GM mode (AG). It's done via OSB buttons, but it's still not retaining in the current patch. After switching master mode it resets to CRM RWS.

As a lot of manuals describe (i can send it to you if needed), the Hotas function TMS-right depressed more than 1sec should transition from any CRM RWS mode with or without a track target to TWS retaining eventually bugged targets. In the current patch, if i do it i get VSR, (locking the bugged target to a VSR STT... not very stealthy) then from VSR i get the TWS.

SPI is constantly updated (and sent to bomb) by the Sensor Of Interest.

Not realistic in VR. Too big. On screen they are fine.

Yep and as i tested, if your video would been longer we would have seen the fix's corrected position moving towards the original position in a number of further updates.