Ares

Offset problems with odd number of Bursts > 1

Bug #895815 reported by reaperrr
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Ares
Confirmed
Medium
Unassigned

Bug Description

If a unit has an FLH where the "L" value is not 0, and a weapon using this FLH has a Burst= higher than 1, there are two problems, most likely caused by the same bug.

1) When Burst= and odd number >1 (3, 5, 7 etc.), the muzzle flash animation is actually displayed on the opposite side of the projectile starting point.
Also, with odd Bursts >1 the first shot is fired from the opposite side than it is fired from if Burst=1, but the muzzle flash appears on the same (correct) offset in both cases.
It seems that the game mixes up positive and negative L value for the actual projectile when the number of bursts is odd.

2) The last shot of an odd number of bursts higher than 1 (3, 5 etc.) is fired from the same offset as the previous shot, instead of toggling to the other side again. Since it's the only shot that appears from the same offset as the muzzle flash anim, I believe that the last shot in this case simply switches back to Burst=1 behaviour, so it's actually the only shot fired from the correct offset.

##### STEPS TO REPRODUCE #####
Example:
[UnitArtINI]
PrimaryFireFLH=100,150,100

[PrimaryWeapon]
Burst=3

--> For the first shot, the muzzle flash will appear from the left side and the actual projectile from the right, for the 2nd it will be the other way round, for the 3rd BOTH will appear on the left. For Burst=1, both appear on the left, too.

Revision history for this message
WoRmINaToR (worminator) wrote :

For bug number one: All of those things you mentioned only happen when you have a burst value set to an odd number. Burst=2,4,6,8,etc. will animate in all respects exactly the way it should.

and for the record, Westwood was probably never confronted with this bug because they use even burst values on their units (particularly 2), which behave perfectly fine.

Revision history for this message
reaperrr (reaperrr) wrote :

ugh, seems you're right, bug 1) is indeed limited to odd numbers of bursts as well. I made the mistake to test this with odd bursts only, and since it happens with even bursts too in RA1 and TS, I made the (wrong) assumption it still happens in RA2/YR. My bad.

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 .

DCoder DCoder (dcoder1337)
Changed in ares:
assignee: DCoder DCoder (dcoder1337) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.