EPTCould this be used to find opponent's location like the one Scan posted: https://tl.net/forum/brood-war/551565-pylon-bug-to-find-opponents-location
since that used attacking one's own unit as well? Or is it a different instance (the translation of Firebathero says that he's never seen this happen before).
Translated detailed explanation that sounds about right by user onehae5930:
+ Show Spoiler +
@onehae5930
1 year ago
1. Unit objects contain parent address information for some of the parent object's information.
Example: Lava (parent) - Set rally point - Unit (child) - Move to rally point
Hydra (parent) HP - Lurker Cocoon (child) HP
2. The Zerg unit hatching mechanism runs in the following order: Egg - Hatching - Unit.
Example: Units that die during the hatching phase don't display a death animation, indicating that a new object exists between the egg and the unit.
This saves time for computation and memory allocation to transmit egg information to the unit.
3. When the hatching sprite is applied, memory is initialized, resulting in a 0/0 HP value. Since this is a simple animation sprite task, it does not affect the actual units.
4. Therefore, if attacked at the same time as hatching, the hatched sprite is marked as dead.
However, units that have completed calculations are assigned the unit values generated in memory upon hatching.
5. Unit designation, in the graphical UI, proceeds in the following order: Egg - Hatching - Unit.
During this process, the hatched object is marked as dead, and the graphical UI displays the death status (the selection area disappears).
At the same time, the unit information address is retrieved, and the unit information is stored in the unit object in the unit designation UI.
Conclusion. A bug occurs when a unit object is marked as dead, but a unit with a memory address that is still alive is created.
7. Even if a unit with a memory address dies, the sprite object is already marked as dead, so the change value is not updated and it is not removed from the unit designation.
8. The Mutal's basic attack is also stored in the same memory as the unit creation. However, since the basic attack lacks portraits and health, the unit designation UI does not change.
9. A group of Mutals dies while performing a basic attack. The dead Mutals' basic attack objects are placed in the memory space where the Mutals were.
10. As mentioned in section 1, child objects reference their parent's address. While the basic attack references the parent's address, the dead Mutal's address becomes its own.
11. The child object recognizes the location it last bounced from as its parent object and changes its parent's address.
Conclusion. The moment a (positive) Mutal dies, the attack of the (positive) Mutal or the dead Mutal is uploaded to the corresponding memory, and the parent address value to be referenced becomes the spawning pool that it last bounced from, changing the parent address value to the spawning pool's address. Since the parent address value and the current address value are the same, the spawning pool ends up remaining in the dead (positive) Mutal's place.
1 year ago
1. Unit objects contain parent address information for some of the parent object's information.
Example: Lava (parent) - Set rally point - Unit (child) - Move to rally point
Hydra (parent) HP - Lurker Cocoon (child) HP
2. The Zerg unit hatching mechanism runs in the following order: Egg - Hatching - Unit.
Example: Units that die during the hatching phase don't display a death animation, indicating that a new object exists between the egg and the unit.
This saves time for computation and memory allocation to transmit egg information to the unit.
3. When the hatching sprite is applied, memory is initialized, resulting in a 0/0 HP value. Since this is a simple animation sprite task, it does not affect the actual units.
4. Therefore, if attacked at the same time as hatching, the hatched sprite is marked as dead.
However, units that have completed calculations are assigned the unit values generated in memory upon hatching.
5. Unit designation, in the graphical UI, proceeds in the following order: Egg - Hatching - Unit.
During this process, the hatched object is marked as dead, and the graphical UI displays the death status (the selection area disappears).
At the same time, the unit information address is retrieved, and the unit information is stored in the unit object in the unit designation UI.
Conclusion. A bug occurs when a unit object is marked as dead, but a unit with a memory address that is still alive is created.
7. Even if a unit with a memory address dies, the sprite object is already marked as dead, so the change value is not updated and it is not removed from the unit designation.
8. The Mutal's basic attack is also stored in the same memory as the unit creation. However, since the basic attack lacks portraits and health, the unit designation UI does not change.
9. A group of Mutals dies while performing a basic attack. The dead Mutals' basic attack objects are placed in the memory space where the Mutals were.
10. As mentioned in section 1, child objects reference their parent's address. While the basic attack references the parent's address, the dead Mutal's address becomes its own.
11. The child object recognizes the location it last bounced from as its parent object and changes its parent's address.
Conclusion. The moment a (positive) Mutal dies, the attack of the (positive) Mutal or the dead Mutal is uploaded to the corresponding memory, and the parent address value to be referenced becomes the spawning pool that it last bounced from, changing the parent address value to the spawning pool's address. Since the parent address value and the current address value are the same, the spawning pool ends up remaining in the dead (positive) Mutal's place.
As always a little promotion of my own channel, where I have shown almost every single bug I was able to reproduce across different versions of the game, many still working in Remastered:
+ Show Spoiler +
https://www.youtube.com/watch?v=iSwVE665tGE
