Moonshine

Still more info needed?

yeah not a viper issue. several maps have incorrect or not functioning ILS for years now, especially on PG. they have been reported for quite some time but you know how it is.. reference:

ILS is not on for inactive runways. the active runway is determined by wind direction as its set in the ME. if the airfield has only one ILS approach direction and the wind is not in favor of that approach, no matter the time, no matter the weather, ILS wont be active currently. probably another thing ED should consider changing.

Well TV will be fully gone, which is fine and realistic. Dont know how much thst could impact FLIR quality

if you look closely in my post above, i did give ranges at which I usually get a decent boresight for my mavs (mostly using H or K variants lately). for D and G the range might be a bit less due to poor image clarity. however, if you choose a very distinguishable object (like one house that is standing pretty much alone) it makes it easier because the mav then does not lock the stupid street lamp next to it that you cant see yet or any other nearby structure. so boresighting on an object in a city or town isnt that smart. Playing with the gain and the contrast does it for me (usually turn it down couple clicks on the rocker switch and the image does improve for me) what i dont know is the effects on image clarity of user specific graphic settings, quality of monitor people have and for the sake of it, how good your eyesight is.

no, LANTIRN does not have TV mode. while im not opposed to have LANTIRN modelled correctly and therefore losing the TV mode, in the current state of the FLIR where static map structures etc are significantly brighter than a running vehicle on the FLIR, TV mode is the only one that is actually useful for finding stuff. Losing that before the FLIR is properly done on ground vehicles and objects (or the SNIPER pod is available as alternative) will not do the module any favors.

Cant wait to not have TV imagery anymore, especially with how FLIR currently is. Good luck finding stuff I hope both pods will be available in the future as the block 50 viper from the air national guard did get Lightening II pods as of 1999 https://www.af.mil/About-Us/Fact-Sheets/Display/Article/104571/litening-advance-targeting/

just did some quick googling, CM designation is a CJ that got a CCIP upgrade. so it should be a thing in both versions, currently not implemented along with lots of other datalink stuff

you have got a point. interestingly and i think this is NOT modelled in DCS at its current state, is the quote about coupling the needles to get guidance to that (i assume OFLY) markpoint he set (as in, surely you cant make one with the hud and neither with the TGP or AG radar as you cant see a thing until he basically flew over the runway, so OFLY seems logical). might have to dig in some manuals i believe the function we are looking for is called "command steering" (ILS Flight Director). the use of the Horizontal and Vertical Steering Bars is not only for an ILS approach but also for example used in LADD and CCRP loft according to some manual that should not be named in the forums. so having ILS on would provide guidance using the needles for course deviation on a CCRP loft for example. while "CMD STRG" is shown on the DED, it can currently not be activated/deactivated using MSEL (0). maybe one day it will be implemented

no you cant. ILS (the system) is a beacon (well several beacons) on an airfield. the ILS has two main components - Localizer, - Glide path/ slope. The localizer gives the aircraft lateral guidance. It tells the pilot where the centre of the runway is, by signalling the pilot to move either to the left or to the right through a cockpit instrument (vertical needle) The glide slope or the glide path provides the pilot with vertical guidance. The glide slope is set such that a glide slope angle maintained by the pilot. The horizontal needle of the slope moves up, if the aircraft is too low and moves down if it is too much above the required path. the method described here in this post is a "makeshift instrument approach" (this is NOT ILS, you wont get any needles to help you) for an airfield that does not support ILS guidance. by creating different OFLY markpoints at specified altitudes you can create a makeshift approach by then flying along the set markpoints using your instruments only. the aircraft setting those markpoints in the first place will likely have to go around

Well it is broken. When you try to make a markpoint and your TGP is SOI, the option „TGP“ under the MARK page in the DED is available. Using dobber right to step through the different MARK options does switch to FCR, HUD, OFLY but the TGP option does never show up again, thats what’s currently broken. and if the TGP is not available at all, chances are you do not have one on the jet or the hardpoint isnt powered

is reported here:

not sure if this is correct or not; currently with every sensor pressing TMS aft will CZ the SPI back to the selected steerpoint (works with TGP and even HUD for example) however, for the AG radar, TMS aft does not CZ, you have to press the OSB on the MFD. is that intended like that? AG-Radar_TMS-AFT_not_CZ.trk

then you get substantial parallax effects when trying to lock a target at longer ranges..so i suggest finding something between 5-9 nm away for boresighting purpose

yes ground alignment still is possible, you need to enable ground jettison in order for it to work. also it is rather hard finding something far enough away for a reasonable boresight when on the ground, so while still possible i question how useful that is. not often that you stand somewhere with nothing in front of you for multiple miles for a decent boresight distance, hence why aligning it in the air seems more practical. i personally use some sort of house along my route to the target to get a good boresight. using TGP in snowplow mode helps you find things easier in front of you. alternatively if i cant find anything along my route i might just do it on the first target before firing the missile. or use your buddy - fly trail for some miles, does work as well

You can by using an OFLY markpoint. from there the GS can be held using the OFLY wp as a reference. also remember, the one setting the OFLY markpoint had to improvise all the way to even set that point for the others to then follow and make use of it. by setting multiple OFLY markpoints along the descent you can improvise a glideslope, so the following planes just fly from markpoint to markpoint at a given speed Edit: since creating OFLY markpoints sets them at sea level (MSL), youll have to change its elevation to the desired value manually, so they appear at the right position in your hud

on stable version yes, on Open Beta not

this is true setting SSAA to 0x does fix this temporarily. can @BIGNEWY confirm this? i made two tracks (although i bet one would have been enought since it depends on user graphic settings anyways) Graphic settings used for NVG_Alignment_no_SSAA.trk Graphic settings used forNVG_Alignment_1.5x_SSAA.trk (the only difference is the SSAA)

works for me. a reminder: if you boresight your mavs at 9nm (you can compare that to zeroing a gun to a certain range), your mav crosshair and tgp crosshair will perfectly match at 9nm. now since the pod is offset horizontally (due to its position on the aircraft in relation to the position of the maverick), at a distance of 4nm to your target, your mav will be offset to the left (remember, you boresighted to 9nm). at a distance of lets say 15nm, your mav will be offset to the right as this is past the point of your boresight. maybe you heard of setting a convergence distance for wing mounted guns in WW2 aircraft. same principle applies. at close range your bullets wont get to the center of the crosshair, at long range your left wing guns will shoot too far to the right. only at the specified distance they will meet the desired impact point. reliable auto handoff with mav D was achieved at around 4-6nm to the target.

even the ED Viper manual (page 265) states how it is supposed to be, just the sim does not reflect this at its current state. further details are described in the M3

i have no problem with it being shown as white / yellow in case there is no AWACS that has already identified said contact, hence a second source is needed to correlate the information, but i have a massive issue if something has been positively identified by AWACS as bandit, shown red and the very instant my radar spots that contact it immediately turns into a white square hence losing all previously correlated information to said contact. that can not and should not be a thing, imagine the chaos that this creates in a crowded airspace. if that would be the case, why even have an AWACS since his information gets lost anyways as soon as your own ship paints anything. no other aircraft loses the DL info to a contact upon painting it with the own ship radar, putting the viper in a massive disadvantage in its current state and i fail to see why that would be a thing in real life for the viper but not for any other (western) AC with similar capabilities. and no i am not talking about "balance", this is a sim after all.

so, even with a C2 present, positively as hostile identified contacts still turn white upon being spotted with the own ship radar. how is that possible that a contact, identified by C2 as enemy (or friendly for that matter), shown red on DL suddenly loses all that info as soon as my radar sees him too? for reference, i turn the radar to silent midway through and as soon as the hits time out, it returns to red symbology... FCR_Color.trk

this. Burn through range is at around 25-28nm currently, so until then, it will show 99.9

as the title says: select TGP and enter point track Select MARK (icp7) Markpoint option TGP shows up on DED (when TGP SOI) create markpoint Cycle through the markpoint options (OFLY, FCR, HUD..) the TGP option never shows up again. TGP_Mark_Option_Missing.trk

despite the changelog listing things as fixed, the issue as described in this post, the triangle indicating the position of OA1 is showing up below ground, despite its altitude being set correctly. track attached Offset-Aimpoint-location_bug.trk Offset-Aimpoint-location_bug2.trk