Nealius

1. STPT 1 drifted from desired location 2. 8 (FIX) on ICP > SEQ to select HUD FIX 3. HUD SOI > slew diamond over desired point 4. TMS-up to set delta (0.04nm) > ENTER to accept > STPT 1 diamond shifts closer to desired position 5. STPT 2~6 should be updated by this 0.04nm delta yet are not Procedure can't be made any clearer than this. Adding a crude test using container crosses. I deliberately put the STPTs 100ft south of the centerpoint. I conduct HUD FIXes by slewing about 0.02~0.03nm north on STPT 1 and 2. STPT 3 was not shifted (I did not update it). My understanding is that if I had slewed STPT 1 0.02~0.03nm for a fix, ALL of my STPTs should have also been shifted by the same amount in the same direction. Otherwise the FIX function would be useless. FIX.trk

Extremely loud wind noise if head goes outside canopy bounds.

More observations after research and retries: Chuck's guide mentions TMS-up is required before pressing ENTER on HUD and TGP fixes, however Wag's video only mentions this for OFLY and FCR fixes. He omits this step on the HUD and TGP fixes. The DCS Viper manual does not have a section for the FIX page at all. Now knowing I need TMS-up, I reflew the same profile using both HUD and OFLY fixes to update the INS, and the STPT diamond properly adjusted itself for the fixed STPT only. It did not update any of the other STPTs in the flight plan. Even after fixing the first two STPTs, the next three were still drifted, consistently 0.04nm (243ft). Is there a known issue with FIX only updating the selected STPT and not the entire flightplan?

30 degrees off would hurt the missile's velocity a bit and make it easier to intercept or miss, I would think. I point my nose on target to fire, but immediately crank or beam after.

I've been doing a lot of pre-planned pop ups as described in books like Vipers in the Storm, and I'm having trouble getting enough INS accuracy for the HUD symbology to get me on a good wire for the planned delivery. Everything ends up shifted some 200ft while the system tells me I have a delta of 0.00nm and accuracy high for both SYS and GPS. 200ft is fine for TGP work and guided munitions, but for pre-planned popups this shifts the VRP/VIP, the PUP, the pulldown (OA1) and the AOP (OA2), as well as the TD box, enough that major corrections are required to get on a good wire for delivery, when we should be able to line up the FPM on the OA2 triangle, on the wire intersecting the TD box, then switch CCIP without having to do so many last-second corrections. After all, that's the whole point of the VRPCCRP/VIPCCRP system, as I understand it from written pilot accounts. Prior to the new INS/GPS features, I was able to follow the popup symbology bang on and hit every number as calculated. Setup: 2005 mission, unrestricted SATNAV, Kola, steerpoints on centerpoint of bridges for easy nav fixes, target not more than 100 or so miles from departure field, first STPT/fix point on center of bridge 35nm from target, second STPT/fix point on center of bridge 16nm from target. Running a fix on these two points should make sure everything's good, but for some reason it's not working for me. When checking my first fix point, using the TGP the pod is exactly on the bridge centerpoint, FIX delta 0.00nm, SYS and GPS accuracy HIGH, so I don't run a fix yet. I go low, pulling no more than 3G perhaps, and when approaching the bridge the STPT diamond is shifted away from the centerpoint and on the end of the bridge, some 200ft off from where it should be. FIX delta still says 0.00nm, SYS and GPS accuracy HIGH, but I do a HUD fix by slewing the diamond over the bridge center and press ENTER (per Wag's YouTube tutorial), however the diamond snaps back to the edge of the bridge, as if the fix didn't take. Approaching second fix point, same issue. STPT diamond in the HUD is shifted to the end of the bridge. Slew diamond over center point, hit ENTER for a HUD fix. Diamond reverts to old position. FIX still says delta 0.00nm, SYS and GPS accuracy HIGH. Execute my pop, ID target, roll in and put the FPM on the AOP triangle, notice TD box is shifted a ways behind the target. Thus my AOP is shifted behind where it should be, my dive angle is shallower than it should be, and my track time (calculated to be 5 seconds) is now about 2 seconds because the symbology is so far off of the actual target. On egress, another one of my bridge waypoints was shifted about the same amount as well, this time checking the FIX as delta 0.00nm, SYS accuracy MED, GPS accuracy HIGH. An interesting pattern I noticed with this drift is that it always drifts in the direction of my origin airfield. E.g. if the target area is 150 from where I started, the symbology shift is roughly the reciprocal, 330, from the actual STPT. Starting from a field on the opposite side of the map, the drift is observed to also be opposite. Sometimes I think it's not the INS/GPS itself shifting, as the TGP seems to get on point just fine, and there are times where the TGP is right on a taret but the HUD/HMD TD isn't quite in the right spot, so it seems like the HUD symbology is the only thing actually being shifted. Is there something I'm missing to get the HUD symbology more accurately on my STPTs and/or targets?

I would start troubleshooting by deleting and reassigning the axis, as well as double-checking binds as Gilligan said. This sounds like a controller issue. AP works fine for me on cold start with the deadzone slider set to 0%.

Exhaust flames shouldn't even be visible except in low-light conditions. They should also be more "pops" like muzzle flashes than the eternal bonfire we normally get.

Specific conditions: 1. Slot into Dynamic slot that has no waypoints set, choose F-16, ramp start 2. Manually input coordinates for STPT 1 3. TGP slaves to STPT 1 as normal 4. Create markpoints with TGP 5. Cycle markpoints and TGP will snap back to STPT 1 every time, even after CZ 6. Manually enter coords for STPT 2 7. Select STPT 2 and TGP will snap back to STPT 1 every time, even after CZ Fortunately SPI still works for weapons employment, but TMS-aft would keep sending me back to STPT 1 instead of last SPI. In standard MP slots with waypoints already loaded, everything works fine. All I have at the moment is a long MP track file with some button mashing as I was troubleshooting: https://we.tl/t-0AwNLrW6ph

That was my first thought as well, especially after the DDOS attack that happened over the summer.

Hopefully after they fix the one in the F-16. With GPS the F-16's INS shouldn't require manual updating, yet it is frequently inaccurate by up to 100m. Pre-planned JDAM strikes are impossible. Pre-planned pops are also unreliable with the PUP point and AO2 aim-off being way off intended target, which does not match real-world accounts of popup techniques described in Vipers in the Storm.

Today I'm frequently getting 500 errors saying "too many connections."

GATOR system. Basically landmines scattered by cluster munition cannisters: https://en.wikipedia.org/wiki/GATOR_mine_system

I only have the lastest two. I believe the uninstall occurred prior to these two logs. Autoupdate_log.txt (11OCT) is when I manually reinstalled Kola after discovering it was gone (mission grayed out in WebGUI). Autoupdate_log_old.text (03OCT) was the DCS 2.9.8.1214 update, and makes no mention of Kola; I presume because it had been uinstalled prior to this update. I last hosted Kola map on this dedicated server around 04JUL, on DCS version 2.9.5.55918, wich means the disappearance would have occured on one of the following updates: 2.9.6.57650 (11JUL) 2.9.6.58056 (22JUL) 2.9.7.58923 (09AUG) 2.9.7.59074 (14AUG) 2.9.7.59263 (20AUG) 2.9.8.1107 (30SEP) However I have no logs for those updates. autoupdate_log.txt autoupdate_log_old.txt

Where would I find these installation logs? The Saved Games Logs folder only contains logs from when the server was running a mission, not when it was updated or when anything was installed.

Setup is 4 guns and Fire Can. 1. When target approaches, the FC tracks steady, the guns get on azimuth, but their elevation is jittery and won't track. 2. Guns only fire three rounds when target is within 1-2nm, despite advertised threat circle of 10nm. 3. After target overflies the emplacement, the FC continues to track steady, but the guns endlessly spin counterclockwise and will not track. KS19.trk

I'm the only one with access to the dedicated server, and I did not manually uninstall Kola from the dedicated server--I literally don't know how to uninstall terrains from the server. I didn't even remember how to install it, as I don't often use CMD/Powershell, and had to search the forums to find out how to reinstall it.

Kola map, no mods, only two scripts are MOOSE and AIRBOSS. Client track fails to load. https://we.tl/t-iiXSt3M42j Out of 6 tracks I've tried the past month or so, only half have worked, including ones with heavy external scripts. Single player, multiplayer, doesn't seem to make a difference. The ones with no mods and no scripts also fail. There's no correlation--at least on my machine--between these hangups and scripts, nor SP vs. MP. Each time the error log claims there to be terabytes or petabytes of missing data on .trk files that are only 100mb or less.

That might be part of what many people are questioning. In DCS we get DME and bearing.

I had Kola map on my dedicated server roughly since release, however with one of the recent updates between August and now, the Kola map was somehow wiped from my dedicated server install, forcing me to manually install it again.

No idea on why engines won't shut down without APU power, but procedure for just about any aircraft is to turn off avionics before killing the electricity, so APU on is the only way. Apache is the same way, as are the Russian helos IIRC, minus the whole engines not shutting off thing.

Generators only work above a certain RPM. APU and APU Gen has to be on to keep electrical power on when in ground idle. Engines also won't shut off unless APU and APU Gen are on.

Different context than what we are discussing, but yes. Adding to what RustBelt said, plus the context of this discussion (rudder use for roll at high alpha, NOT rudder use in general), going way back to even the A6M, you can see the rudder is located noticeably aft of the horizontal stab, no doubt increasing rudder effectiveness at high-AoA; which is oddly often overshadowed by discussions of the A6M's faults.

I had this happen some months ago, but I'm hard pressed to remember which module and how I rectified it.

This is a widespread issue with reports scattered all over the forums. So far the blame has been pinned on "external scripts" or "large track files" when missions without scripts and small track files also fail.

Every aircraft rolls with rudder deflection at high AoA, does it not? And official, period training videos make the same “blanket statement”, so I fail to see the issue here.