[chief1983]

I think it might be worth investigating where in the revision history the lock time for retail resolutions became accelerated, might shed some more insight into the overall behavior changes.

[AdmiralRalwood]

I've attached a new patch to the Mantis issue that may fix both problems simultaneously; only downside is that the way the HUD gauge renders may need changing if we want the visual for the lock indicator to still move across the entire screen. Could probably do some sort of scaling based on the resolution of the HUD gauge in comparison to the resolution of the virtual frame...

[Italianmoose]

I think it would also start to get noticable over time as the box in which the targetting functions gets relatively smaller and smaller in comparison to the rest of the screen as resolution and pixel density increases. (It could make a fun addition though - better fighters can lock on over a wider area!)

[AdmiralRalwood]

I think it would also start to get noticable over time as the box in which the targetting functions gets relatively smaller and smaller in comparison to the rest of the screen as resolution and pixel density increases. (It could make a fun addition though - better fighters can lock on over a wider area!)

The size of the "virtual frame" the tracking happens in has no effect on the cone in which aspect tracking starts.

[Italianmoose]

Fair enough, my bad. I'll get to testing lock times to quantify the effects of the new patch.

[Italianmoose]

New patch, same testing method as before:

1024x768: 2.2, 2.2, 2.5, 2.3, 2.5, 2.2
1920x1080: 2.4, 2.2, 2.5, 2.3, 2.3, 2.4
5760x1080: 2.4, 2.5, 2.4, 2.5, 2.3, 2.3

3.7.2 RC5 (i.e. no fixes whatsoever):

1024x768: 2.5, 2.5, 2.4, 2.5, 2.1, 2.5
1920x1080: 3.2, 3.3, 3.3, 3.2, 3.3, 3.2
5760x1080: 8.7, 8.6, 8.7, 8.6, 8.7, 8.5

ATM I can't compile FS2O under windows so I can't test extremely high resolutions. The minimum lock time for the Harpoon (according to weapons.tbl) is 2.0 seconds.

[Yarn]

While trying to test MageKing17's newest patch, I think I found out why my lock times are different between retail and FSO.

In retail, the lock triangle starts at one of these points, whichever is farther from the target:

• The center reticule
• A point far enough from the target such that at least a certain amount of time is necessary for the triangle to reach the target, assuming the player and the target are not moving

This means that if the triangle would start between the target and the center reticule, then it instead starts at the reticule.

FSO, however, doesn't appear to perform this check, so if the target is far enough away from the reticule, then the triangle starts too close to the target. I will check to see when this behavior was introduced.

[Swifty]

I think this was changed because of TrackIR. Because of TrackIR, the assumption that the player's view direction would always be in the center of the screen was no longer always valid. Therefore, the lock code had to be updated to match this assumption.

[Yarn]

That sounds likely. I found that the behavior changed sometime between 3.6.9 and 3.6.10, and according to the SVN log, the TrackIR stuff was added during that time.

I did some more testing, this time while pointing my ship at the target. At 640x480 resolution, the lock time was about 2.0 seconds (consistent with what's in weapons.tbl) in both retail and FSO r11315! And yes, I also tested the mission in FSO r11315 without moving my ship and got the same times that I got in r11242, so lock times don't seem to have changed since then. This means that, in cases where retail would put the lock triangle at the center reticle, FSO is putting it somewhere between the two points described in my previous post.

[AdmiralRalwood]

That sounds likely. I found that the behavior changed sometime between 3.6.9 and 3.6.10, and according to the SVN log, the TrackIR stuff was added during that time.

I did some more testing, this time while pointing my ship at the target. At 640x480 resolution, the lock time was about 2.0 seconds (consistent with what's in weapons.tbl) in both retail and FSO r11315! And yes, I also tested the mission in FSO r11315 without moving my ship and got the same times that I got in r11242, so lock times don't seem to have changed since then. This means that, in cases where retail would put the lock triangle at the center reticle, FSO is putting it somewhere between the two points described in my previous post.

Why would lock times have changed since r11242? No changes to hudlock.cpp have been committed since r10622, and that was just the debug console...

While trying to test MageKing17's newest patch, I think I found out why my lock times are different between retail and FSO.

In retail, the lock triangle starts at one of these points, whichever is farther from the target:

• The center reticule
• A point far enough from the target such that at least a certain amount of time is necessary for the triangle to reach the target, assuming the player and the target are not moving

This means that if the triangle would start between the target and the center reticule, then it instead starts at the reticule.

FSO, however, doesn't appear to perform this check, so if the target is far enough away from the reticule, then the triangle starts too close to the target. I will check to see when this behavior was introduced.

The fundamental logic of hud_calculate_lock_start_pos() doesn't seem to have changed from retail, though...? If the hypotenuse of delta_x and delta_y (distance of the target's projected position from the center of the screen in the "virtual frame") is greater than or equal to Lock_start_dist, the starting position is set to the center of the virtual frame. The actual position it gets drawn at may vary greatly from its coordinates in the virtual frame; however, the actual lock time should (theoretically, and assuming I actually understand this code, which is far from guaranteed) be the same.

[Yarn]

Why would lock times have changed since r11242? No changes to hudlock.cpp have been committed since r10622, and that was just the debug console...

I was only verifying that my result from r11315 was indeed not caused by a recent change, whether to hudlock.cpp or some other file. I didn't think that it would be different, but it seemed like a good idea to check anyway.

[Italianmoose]

Out of curiousity, how much will this affect game balance? In theory it should make most missions easier, though stock missions will return to the difficulty we remember them to be (I'm thinking the de-fanging of the Sathanas in particular)

[Cyborg17]

Well, game balance was being slowly eroded from retail by this.  It really should just restore the natural game balance for this part of the game.

[chief1983]

Regardless, the latest version of the fix in Mantis #3140 was committed and is in the latest round of nightlies.