[GEN][ZH] Fix wrong class member set to INVALID_DRAWABLE_ID in ParticleUplinkCannonUpdate::createGroundToOrbitLaser()

[Mauller]

This fix was originally discovered by @helmutbuhler and split out of the original PR it was contained in.

Within createGroundToOrbitLaser the wrong ID variable was being set to invalid once the beam had been destroyed.
This corrects that by setting the ID on the correct variable.

• Relates [ZH] Minor memory corruption and leak fixes #716

[feliwir]

Looks good to me. Please add @helmutbuhler as Co-Author when squash-merging

[xezon]

This change has game mismatch maybe label. Does it need testing?

[Mauller]

This change has game mismatch maybe label. Does it need testing?

Yeah the ones i labeled with possible mistmatch need a quick test to check they don't break compat. I will need to rebase them all once we confirm that the hashmap reversion fixes AI based replays.

[xezon]

Hash map change is reverted, so this can be tested now.

[Mauller]

Hash map change is reverted, so this can be tested now.

Rebased with main and pushed so it is ready for testing.

[sorcerer86pt]

played golden replay on this one.

vc6 no mismatch all worked until the end.
win32 as expected, immediate mismatch message

[Mauller]

Tweaked to cleanup comment and ready to go.

[xezon]

Did you find out if this changes any retail behavior?

[Mauller]

Did you find out if this changes any retail behavior?

Not just yet, was checking the stealth one.

[Mauller]

Just testing and between this fix and retail there does not appear to be any visual difference or behaviour difference.

[xezon]

I eyeballed the particle effects and did not observe a visual difference.

Does this change fix any memory leaks?

[Mauller]

I eyeballed the particle effects and did not observe a visual difference.

Does this change fix any memory leaks?

Looks like there is a chance that a memory leak could occur if an orbit to ground particle beam already exists.
Under normal conditions the code appears to create a new beam each time it is used and rarely goes into the first block of code where the incorrect value was being set.

The first block appears to be there to destroy the existing beam. So i guess if the beam was interrupted and started again it would cleanup in that block then make a new one in the consecutive code.

[Mauller]

I could not get the game to fall into the block where the cleanup code for a current beam was setting the invalid drawable ID on the wrong drawable.

I tried powering down the particle beam uplink with a microwave tank while it was firing, but even once it lost power it continued to fire till the end of the normal firing cycle.

Sold power stations as well and it continued firing after losing power and never fell into that block.

So i think there is little chance that this will have an issue with retail. Since the game always creates a new particle beam when firing, i think retail will just end up with some small memory leak if the obscure situation occurs that hits the relevant code.

[xezon]

I put a breakpoint on this code and it never hits when shooting with the Particle Cannon. This indicates that it is a theoretical issue only. As far as I can tell this fixes no retail bug.

[xezon]

Improved the title a bit.