no its a flare position, the map ent info_flare in the entities.def for wfa.
The pitch/yaw of the flare is set by the mapper. I have the client load the ent as it does with a camera portal surface, basically, using modelindex2 and 3 and have it not culled by pvs (so they see it no matter where they enter the map from) and store it in a cg. array. (cg.flare.bigflare.type, .pitch, .yaw)
Then what I do is trace from the view origin (this is all client-side) in the direction of the translated pitch/yaw till it hits a surface sky (ignoring surfaceparm glass, new trace trap), then translate that into screen cords.
note that the beam lags; it draws for 3 frames from it's original position; it doesn't lerp to movement its just a bfg laser beam. But the translation from world-origin-to-screen is flawless, it allows me to make some pretty damn cool effects (like when a player going kami shows up make one huge assed green blur in the view get stronger the closer he gets, or trippy draw effects for players, or even crosshairs with text and info that track clients if you view through the sentry, or floating status lines, you get the idea for hud stuff)
Anyway then what i did was take the flare array I made for Acrid for TrueCombat using percentages. I then just literally diff between 2 origins: one straight forward 256 units and crawl up the trace 256 units for the other one. If the flare has .1 offset, then its 90% towards the forward origin. if its .9, its 90% towards the flare origin.
It has to be something I'm missing, like a rotatepointaroundvector function, because it DOES work, it just starts going awry at extents.