report of anm_leak freezing in LoLK

[ExpHP]

From Project Tojiko via email:

I was playing some LoLK replays with the anm_leak patch applied, and I found the game freezing after clearing certain chapters. I testplayed on the Practice Start (lang_ja and anm_leak for test purpose, freeze did not appeared with only lang_ja applied) and the same happened.

I am using the Steam version of th15 (1.00b).

I requested a replay to help further investigate.

[ExpHP]

• Actually seems like every replay is crashing. Always about 20 seconds into a stage.
• Game matters. TH16 is not affected
• Changing batch size has no effect
• Changing discriminant size has no effect

Crash is at this line: https://github.com/ExpHP/thcrap-patches/blob/44ccb4d2b1fc202d87e2e22581d08841b2da7495/patches/anm_leak/global.asm#L369

• This means batch_num is somehow greater than the available number of batches...
• ECX = 0xC2. That seems like it's probably pretty far outside the number of batches
• TO CHECK: is the game not using our IDs?
• They don't look like our IDs at all

[ExpHP]

In stage 1 it's happening specifically during a call to EnemyFog::Destructor. Likewise in stage 2.

This function gets called once (with a reasonable ANM ID) as the midboss disappears off the edge of the screen. Then the second call consistently happens about 5 seconds after that. Weird.

Comparison of Fog in first and second calls. ecx+08 is the ANM ID

[ExpHP]

I've figured it out. Uggggh.

The issue is as follows: A crash occurs (with 100% certainty) at the clear of the next chapter after a midboss in LoLK (and ONLY LoLK).

(Clearly, I did not test LoLK very well with my last update. 🤦)

Here's the cause:

• The when:
  • As soon as you drop the midboss HP to 0, the chapter is cleared, and a PointDevice snapshot is saved. (even in Legacy mode). The snapshot of the midboss enemy includes a EnemyFog, with an ANM ID for a snapshot VM.
  • At the end of the next chapter, this snapshot is destroyed to make way for a new snapshot.
  • The destructor for EnemyFog performs a search-by-id for its VM in order to set some flags.
  • TL;DR: The game crashes when the search-by-id function is called on a PointDevice snapshot VM ID.
• The why:
  • In my previous updates to fix #1, I gave my patch full control over the ANM IDs assigned in TH15-TH17, and optimized the search-by-id function based on my ID format.
  • ...but when the above events occur, my function is being called on the ID for a snapshot VM. Snapshot VMs are allocated using different functions that I do not override, they have their own fast array and live in a different list on AnmManager.

My choices appear to be:

1. I can make the allocation function for snapshot VMs also go through my system, but I'm reluctant to do this because of the multitude of binhacks typically required to deal with the totally asinine way that the game doesn't assign IDs until long after the VMs are allocated. (and these snapshot IDs are assigned through different codepaths than normal IDs, so it will require totally brand new binhacks)
2. I can try to make my system play nice with the vanilla snapshot IDs. It appears that all snapshot IDs are designed to be negative. I don't believe the converse is true in the vanilla game (i.e. it doesn't appear that normal IDs are always positive. A typical ZUN half-measure.....), but since I have full control over the IDs, I can make my own IDs positive. That way, snapshot VMs can be easily identified so that we know now to mess with them.

Currently, I'm looking at the runtime lists in memory and noticing something weird. (with my patch enabled, all of the snapshot VMs suddenly have fast_id = 0x1fff even though I thought I wasn't touching them?) This is making me lean towards option 1 because, honestly.... it'd be a whole lot easier to reason about what's going on if I could just rest assured that no goofy vanilla code is running.

Edit: Never mind that last bit, I'm seeing 0x1fff because with the ultra patch it fills the entire snapshot fast array, and the snapshot list is stored FILO. (so the fast ids are 0x1fff 0x1fff 0x1fff ... 0x1fff 0x1fff 0x1ffe 0x1ffd ... 3 2 1 0)

[ExpHP]

forgot to close in 46edfd543b800050c8af8aa1f2e78f49fa07e45b