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