Skip to content

Fix Kupo of Fortune by adding pacing to wait the voucher to be ready#32

Open
mpolonioli wants to merge 3 commits into
Ashylila:masterfrom
mpolonioli:fix/kupo-of-fortune
Open

Fix Kupo of Fortune by adding pacing to wait the voucher to be ready#32
mpolonioli wants to merge 3 commits into
Ashylila:masterfrom
mpolonioli:fix/kupo-of-fortune

Conversation

@mpolonioli

Copy link
Copy Markdown
Contributor

Sorry to come back on this but I have done some more testing on this feature and it turned out that PR #31 did not resolve the crash, just make it less likely to happen. Since a crash is a serious problem and it was all my doing I have spent some time to figure out how to solve it.

The cause of the crash is most likely "firing the play action before the voucher is ready and closing the frame before the reward is given". I did not found a reliable way to check this readiness progammatically. So, I simplified the flow and removed the "non-working fix" and simply added pacing to wait the voucher and the reward (6 seconds).

Now it is much slower, but does not crash. At least in my testing which involved 50 vouchers.

I have also noticed that the configuration to "play a random chest on the right" was not working and fixed it.

I would cosider this feature very experimental 😅

@Ashylila

Copy link
Copy Markdown
Owner

I'll take a look when I get back home

@Ashylila

Copy link
Copy Markdown
Owner

I'm sure there's a programmatic way around this somehow — gonna try dumping the whole window and watching what changes when the reward lands. Thanks for digging into it though

@Ashylila

Copy link
Copy Markdown
Owner

Quick q — only just really noticing this now but, was driving the Kupo window through addon events intentional? The resource-inspection handler leans on addon->Close(true) / direct callbacks instead.

@mpolonioli

Copy link
Copy Markdown
Contributor Author

Quick q — only just really noticing this now but, was driving the Kupo window through addon events intentional? The resource-inspection handler leans on addon->Close(true) / direct callbacks instead.

Good catch, that's an inconsistency, and no, it wasn't a deliberate design choice. I may have trusted Claude too much for this...

I think both the hexagons (chests) and the Close button can be interacted via ClickAddonButton by node id. I'll look into this tomorrow

@Ashylila

Copy link
Copy Markdown
Owner

FireCallbacks are preferred, i feel like addon events are way too brittle and might even be part of the crash issue, every time ive tried using them it was nothing but trouble.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants