Closed Fatalution closed 1 month ago
This issue has nothing to do with heck/chroma animations - those aren't read out of the JSON anyway. This is caused by the 100k+ light events using lightID and such, and is almost definitely due to memory constraints on web version.
Basically, maps with tons of light events (and especially ones that use lightID) use a lot of memory and go over the 2GB limit on web. You can circumvent this by enabling "skip loading lights" in advanced settings, or by using the desktop version.
I do want to optimize light event memory usage and make a more elegant way to handle these cases but for now those are ways you can bypass the issue.
The desktop version - you mean standalone? Was unaware that existed, only used web :)
Thanks for the clarification about the lightIDs! I think it would be nice to enable the check for the crash - and if it happens, reload the replay without loading the light events (as a half-assed measure for now). Just a thought
Yeah that's what I was thinking of doing, but it's not very simple to check how much memory the lightshow will use before loading it (and triggering the crash). I could add a threshold where it skips loading the lightshow above a certain number of events but the amount of events needed to crash varies a lot depending on the amount of custom data.
I'll keep this issue open until I can find a reasonable solution to it.
Made tons of progress optimizing lightshows in 0.6.4, so this map now loads fine (but still performs kinda bad at some points).
While I was at it, I also added a setting for max # of light events so full-on crashes can be avoided in the future.
Describe the bug:
Title
How to Reproduce:
Steps to reproduce the behavior:
Expected behavior:
No crash
Additional context:
The way to fix it would be easy - strip the input JSON from any Heck/Chroma track animations. Then, use the modified JSON as the diff