Gilligan

Fire the laser after the target is designated. You don't need to hold it "on," just a quick shot to get the ranging data. In my experience, for best results, don't actually designate the "body" of the target you want to hit. Designate a tire, the tread, or the ground under the target if you can see it.

In my experience you will not get a good boresight alignment on the ground, as it is not really possible, in most cases, to grab a point far enough out. Most anything you can grab while on the ground is going to be within one nautical mile. I prefer to do my boresight in the air, especially if I can find something that is already damaged or destroyed and I can easily see it's smoke plume. However if you are re-boresighting while in the air and attacking a target that SHOULD be pretty close. Just pay attention to the range you are finishing the boresight. For the most part, what you are describing is fiarly typical behavior that I would expect from the maverick.

Just for my own understanding, because I am interested in the reasons "why," as well. Going over the chucks guide again, the engine is fed from the fore and aft reservoir tanks. The reservoir tanks are fed via the corresponding fore and aft internal tanks. The fore and aft internal tanks are fed via the internal wing tanks. The wing tanks are fed via any of the 3 external fuel tank options. From what I am reading (and cross referencing the chucks guide), in layman's terms, the external tanks are drained first. Then the INTERNAL wing tanks will be drained. Then the Internal fore and aft tanks will be drained, and lastly the fore and aft reservoir tanks will be drained. That makes sense. The filling diagram seems less clear - from either ground or air receptacle, fuel is fed into centerline external tank and the fore and aft reservoir tanks, and then into the external wing tanks, via the externals? If that is the case it should not mater what the fuel state of the aircraft internal tanks are? Or does the fore and aft reservoir tanks feed the internal wing tanks, which in turn feed the external? Even then the centerline tank should fully fill anyway? I suspect this is a problem with the chucks diagram, as it seems to imply that the rest of the fore, aft, and resveior tanks are all filled in series AFTER the external and internal wing tanks are filled. This does not seem to align with the real world case as stated by RogueSpecter or the model's behavior in game. RogueSpecterGaming, from reading your technical comment, specifically that the valve to the line outlet of the internal wing tanks is open when the wing tanks are not full, and closed when they are, would mean that if the draining sequence was reversed for fueling, that once the wing tanks are full, that valve for the line out (or the inlet into the internal wing tank from the refuel manifold?) is closed, and therefore unable to fuel the external tanks? As to why the internal wing tanks fill before the external, is that a consequence of residual pressure in the externals? At that point it's a DiffEQ problem about how quickly the external tank can depressurize vs the rate at which the internal wing tanks are filled, with a supposed equilibrium around 5,000 pounds IRL, and 4000 lbs in-game. That makes sense. I think. Regardless, thank you for the technical explanation.

I'm at work and do not have the ability to view your track replay at present, however I believe what you're experiencing is parallax. The maverick seeker head(s) and the TGP do not share the exact same line of sight to a point on the ground, there is a difference in position for each of the optics. This means that after you boresight them at a given distance, looking at or trying to lock a target at a different distance will introduce SOME error called "parallax" (the effect whereby the position or direction of an object appears to differ when viewed from different positions, e.g. through the viewfinder and the lens of a camera.) The amount of parallax error varies with the difference from your boresight range that you are trying to ID/Lock/Engage a ground target. The reason it "behaves" how you want to when using the active pause is that you are at a single, steady, and unchanging distance to the group of targets (the few dozen feet difference between the targets is negligible). Where-as when you are actively flying, you could be anywhere between 15+ to 5 miles from your intended target depending on your approach & etc. I usually try and boresight my mavs right around 8-10nm, and try and lock targets at that same distance. As far as I can tell, he was not cursor-zeroing the SPI after initiating a pint/area/INS track on a location with the TGP (or other sensor), causing the offsets to remain in effect with all other steerpoints in his flight plan.

I had always assumed it was just a DCS-ism and done Ground Jettison to refuel them. Will try opening the fuel door next time. Thanks for that.

One of two things are happening: Normal INS drift. Over time the INS system builds up small errors over time called "drift." The longer you fly, the more errors stack, the further off your SPI's will appear vs the intended terrain markers. The INS system in the F16 is "GPS corrected," so if you are flying with the GPS enabled after a certain amount (IIRC about 300 meters) of drift accumulation the GPS will attempt to "correct" this error but it can still be a couple hundred meters off. The second thing that could be happening is that you are offsetting your SPI via one of the sensor systems like the TGP, Ground Radar, or HAD/HTS. Take the TGP for example, if you slew the cursor off the steer/mark point you have selected and initiate a point/area/INS lock on a location, there are X, Y, and Z offsets to that point relative to steer/markpoint that are automatically stored and will be applied universally to all other steer/mark points. To cancel out or "zero" out this offset, use the cursor zero function either by pressing the corresponding MFD button, or by using TMS down short.

Yes, this can happen, and has happened to me once in the past. It was during a long LOWOS campaign mission. I was not on the DED page, and some other weird things were happening along side, particularly the TGP also became unusable, as it would, uncommanded, change it's orientation from looking at a steerpoint or markpint, and instead look some random direction over the horizon to the north. I could cursor zero back to the steer/mark point, but it would only stay looking at that spot for a few seconds, and then re-orient itself to the [seemingly] random direction. I hypothesized that the HAD is interfering with the TGP, as it is intended to do when you lock an emitter, but instead the HAD was commanding the TGP to look at [something else]. I suspect there is something happening if an emitter "despawns" while locked with the HAD that might cause some sort of error. Which means it's a scprit that is part of the mission causing the problem, and is therefore, supposedly, outside of the responsibility of eagle dynamics to fix or address (understandable). This may not be the exact cause but I suspect there is something going on that is similar to my hypothesis. If I had had the where-with-all I would have tried turning my HTS off and seeing if the TGP went back to normal, but I was to frustrated at the time. So my question to you guys in here experiencing the problem, did you notice if your TGP was behaving normally or abnormally when you were having HAD issues?

I appreciate y 'all's diligence.

Only had time to try one scenario, but it was working last night.

I have experienced this in the past as well. I'll see if I can get a track this weekend.

Howdy, Unfortunately I have not had much free time the last couple weeks to test things out, however I did try and get a short track file of the mission in question but was unable to replicate the issue (spawned in, ejected right away, and respawned as before but everything was working as it should). Similarly, in one other scenario ejecting then respawning works as it should.

This is a bit of an educated guess, but more often than not the F16 autopilot issues are related to having the "paddle switch depress" command bound to something that is activating inadvertently.

I was playing a modified version of the Flaming Cliffs F15C mission - Strike Escort. Some time ago I re-saved a version of the mission where I set the player aircraft and wingmen to be F-16C's. I did this many months, if no longer, ago and have flowing it several times without issue. This most recent time that initiated this post I was shot down and respawned via the "briefing" option in the pause menu as I have done numerous times before. When I respawned the aforementioned screens/displays were nonfunctional. Both MFD's and the HSI were black screens, and the HUD display would not, render? I ejected from that aircraft and respawned again however the condition remained. So I exited that mission and started the instant action flight in the attached track file with the condition again remaining persistent. Log attached. I found these 3 Lines in it: 2025-07-10 03:57:38.122 ERROR_ONCE DX11BACKEND (18732): texture 'MFD_LCD_F16_LEFT' not found. Asked from '' 2025-07-10 03:57:38.122 ERROR_ONCE DX11BACKEND (42144): texture 'MFD_LCD_F16_RIGHT' not found. Asked from '' 2025-07-10 03:57:38.123 ERROR_ONCE DX11BACKEND (43828): texture 'EHSI_LCD_F16' not found. Asked from '' As well as a whole block of "Cockpit: Failed to create Element 'ceMeshPoly' - reason unkown" lines associted with the HUD, MFD's, & HSI. The only time I've tried playing that mission again the game crashed a couple minutes in and I sent that crash report at the time. I have not tried since. dcs.log Honestly I don't remember at this point. I want to say I basically went through the startup procedure to make sure everything was as it should have been, in which case I would have verified BATT set to MAIN PWR but I cannot say with certainty. Interesting. I am speculating that the previous flight where the condition started set some sort of state/condition that was persistent for that play session, but that would not affect subsequent track files on machines that that state/condition set did not occur? Hopefully the log file helps. I will try to reproduce it this weekend.

Was flying a mission, was shot down and respawned. When I respawned the aircraft had no HUD, no MFD's, and no HSI. I turned off the MFD switch and waited it tick, then flipped it back on. Nothing. Played with the HUD Brightness wheel, nothing. Pressed various OSB's. Nothing. Ended the mission and booted up a standard instant action flight (track attached) and the condition persisted. No Screens.trk

Good to know. Thank you. I do not believe I had the "HARM evasion" option checked but that's cool as hell if that's a thing. Regardless I'll check. Not running any IADs scripts. I do not believe the SA2 is going offline at any point. I'm getting the rwr radar track notification for the duration of the missile travel time and post impact. I am experiencing this issue across multiple maps/missions/campaigns. FWIW I am successfully hitting SA6's in POS mode.