The bug is this: If an actor (including the player) fires a non-hitscan custom projectile downward while standing on a ledge*, then depending on the ledge and the downward angle, the projectile can impact on the air in front of the actor even though it has a clear trajectory to a distant target. Hitscan projectiles do not do this. Also, non-hitcan projectiles that are hardcoded (SHRINKSPARK, RPG, FIRELASER, FREEZEBLAST) do not do this either.
*this will require some definition
My current preferred hack for working around this ancient bug is as follows. I detect whether the shot would have a zvel of +8000 or more. If it does, then I use a hacked shot: first, I make the actor fire a FREEZEBLAST, and give the projectile the correct zvel for moving toward the intended target. The FREEZEBLAST is immediately rendered invisible in EVENT_EGS. I let the FREEZEBLAST travel for 2 tics. Then, having traveled a safe distance past the point where it would impact on the air, the FREEZEBLAST fires the custom projectile, applying to it the zvel needed to continue on the trajectory and transferring the owner from the original actor. Having served its purpose, the FREEZEBLAST is deleted.
EDIT: below is the definition of a projectile that exhibits this bug. Aside from the VEL_MULT property, it's a fairly generic projectile. And yes, I have seen this bug on projectiles that do not use VEL_MULT
defineprojectile RANGERPROJ PROJ_WORKSLIKE 32770 defineprojectile RANGERPROJ PROJ_VEL 844 defineprojectile RANGERPROJ PROJ_VEL_MULT 3 defineprojectile RANGERPROJ PROJ_HITRADIUS 0 defineprojectile RANGERPROJ PROJ_SPAWNS RAILIMPACT defineprojectile RANGERPROJ PROJ_EXTRA 24 defineprojectile RANGERPROJ PROJ_EXTRA_RAND 6 defineprojectile RANGERPROJ PROJ_XREPEAT 12 defineprojectile RANGERPROJ PROJ_YREPEAT 12 defineprojectile RANGERPROJ PROJ_TRAIL RANGERTRAIL defineprojectile RANGERPROJ PROJ_PAL 21 defineprojectile RANGERPROJ PROJ_FLASH_COLOR 255