Impotent code in cgame
Neil Toronto
ntoronto at cs.byu.edu
Sat Dec 16 18:43:30 EST 2006
1) CG_SpawnRailTrail returns immediately if cent->pe.railgunFlash is
qfalse. Then it sets cent->pe.railgunFlash to qtrue. Besides being
stupid, this is the only place that railgunFlash is ever set to qtrue,
so CG_RailTrail is never called from here.
Rail trails are always drawn in response to an EV_RAILTRAIL event. If
someone ever does get CG_SpawnRailTrail to work they'll have double rail
trails. I recommend removing CG_SpawnRailTrail and playerEntity_t's
railgunFlash altogether.
I believe CG_SpawnRailTrail was historically an attempt to make the rail
trail appear to originate from the muzzle.
2) cg_runroll and cg_runpitch don't actually do anything. Here's the
code that uses them, from CG_OffsetFirstPersonView:
delta = DotProduct ( predictedVelocity, cg.refdef.viewaxis[0]);
angles[PITCH] += delta * cg_runpitch.value;
delta = DotProduct ( predictedVelocity, cg.refdef.viewaxis[1]);
angles[ROLL] -= delta * cg_runroll.value;
At this point, cg.refdef.viewaxis is all zeros, so the dot product is
zero, and the angles aren't changed. In my Python implementation, I had,
you know, ignorantly made it work, and it looks terrible and jerky. I
recommend removing it altogether, along with the cg_runpitch and
cg_runroll cvars.
There are other impotent bits I've come across but I recommend leaving
in. EV_DEBUG_LINE and EV_STOPLOOPINGSOUND are never generated by the
server game, but somebody might find them useful.
I'll post more of these as I find them and they frustrate the heck out
of me. :)
Neil
More information about the quake3
mailing list