Comment 3 for bug 895815

Revision history for this message
DCoder DCoder (dcoder1337) wrote :

Westwood's consistency to produce mindfucks is astounding sometimes.

 anyhow, I found the FLH bug
 it doesn't affect normal projectiles like missiles or cannons
 it affects most, if not all, visual effects like lasers and electric bolts
 1) TechnoClass::Fire, the big weapon firing manager, calls GetFLH to get the right FLH
 2) GetFLH looks at the current burst step to determine if lateral flip is needed
 3) TechnoClass::Fire saves that FLH locally
 4) projectile is created and placed at the saved FLH
 5) muzzle anim is created and placed at the FLH
 6) burst step is incremented
 7) special effects are constructed, if necessary
 8) special effect constructors (or their Draw routines on the next frame) call Owner->GetFLH to determine their starting point
 9) GetFLH looks at the burst step, which was incremented in step 6), and returns a once-again flipped FLH

As I see it, there are two solutions:
A) move step 6 to happen before step 2, so that all calls to GetFLH result in the same value. This will cause all Burst sequences to start on the other side than they do now...
B) inspect each special effect separately and patch them to take FLH from step 2 instead of looking it up by themselves. This means they cannot update FLH on the fly (Electric Bolt currently does this - as the Tesla Tank moves, the bolt is always drawn from an up-to-date FLH).

Either way, I definitely do not see this as blocking 0.2 .