Armchair programmer here. I admit my suggestion could be BS. Just throwing it out there.
If it's normally 180/30 but now it's 180/60 or whatever the framerate is, perhaps add an extra value at the end, like 180/60 x 2? Tie the multiple at the end to the framerate or something.
5+ Years Programmer, ~2 Years game development here. You are correct that some calculation needs to be changed but I don't like multiplying right there. That's the calculation for the offset of the projectile each frame, if you multiply there you're artificially increasing the speed of the projectile.
The only issue is what specifically that change would look like is kind of up in the air and hard to determine without seeing the code. I don't exactly know how they actually do the hitscan on the projectile. Do they let the projectile move one frame and line trace from where it is then back to where it was spawned? (Line tracing is like shining a singe ray of light between two points in the world to see if there is anything inbetween, say a player). If they do it that way, then why don't they line trace the "expected" distance out into the world first? Granted, this solution would cause strangeness with the spawned glowing projectiles onscreen if a hit is immediately registered (the hit would register before the projectile got there). Maybe they could have the projectile flagged as hitscan for X many ticks where X = TICKRATE / 30 and TICKRATE is a multiple of 30 (you can't have fractions of a tick). I don't know what the solution is.
The solution 343 should shoot for is to make something that is tickrate independent (doesn't require a specific tickrate to function properly). All of the Halos in MCC were programmed to be tickrate dependant. If you actually remove the 30 FPS cap on these old games without changing anything they would appear to run at 2X speed. Standard ways of making movement tickrate independent is to scale (multiply) by the tickrate. This can be accomplished in two ways: 1- if the tickrate is constant, you can make it accessible as a variable and multiply by 1/TICKRATE, 2- Time how long it takes between two updates and multiply by that value. If I have something moving at 100 cm/s, then each frame you'd want to offset that object by 100 * 1/TICKRATE or 100 * TIME_BETWEEN_TICKS. It should be noted that these calculations don't seem applicable to the projectiles, however but movement in general. This is why we are having issues right now, on higher tickrates the distance moved between two ticks is smaller.