lordfokas / blazemap Goto Github PK

Currently Cartography needs to link directly to engine classes for async work.
Any big addon will benefit from access to those so exposing access via API will protect against most changes and refactors, except breaking ones.

When the void is exposed to skylight the game freezes.
No error's or exceptions are logged.

When the void is exposed but there's a block above then there's no issue.

When it's a column of only air. Freeze.

Minecraft 1.18.2
Forge 40.2.9
Blaze Map 0.5.16-beta

M1 Mac
MacOS 14.4.1

Prism Launcher 8.3

Version: 0.5.4g

Log:
latest.log

Opened Test World 1. Moved into new chunks. Satisfied new map chunks were loading, I saved and quit. Then, without closing Minecraft, I opened Test World 2. That loaded fine. I then saved and quit that world. However, Minecraft then wouldn't move past the "Saving world" screen. Had to use Task Manager to close Minecraft as not even alt-F4 could kill it.

In the log from the second world, the following log line appeared, which I would assume is related:
[16:43:42] [Blaze Map (Client) Debouncer Thread/ERROR]: Exception in DebouncingThread main loop!

No further detail or stack trace accompanied that error line.

However, on closing Test World 1, each of the Render threads did throw an error and crash, as is expected when the main game thread closes. My suspicion is that these killed threads might have caused issues when reloading the other world, causing the error in the DebouncingThread and not allowing the world to save and quit properly.

Replicating going the other way (loading Test World 2 first, moving into new chunks, save and quitting while chunks still loading, then opening Test World 1) also showed the DebouncingThread error, except the game also hung on loading, which I'm not sure if that's specifically related to this issue or if that's more related to #12 , since it was closed while still generating chunks.

Log from replication
latest.log

Hi I play on the terrafirmagreg build and I would really like your mod to be able to add to this build

Version: 0.5.x (alpha)

Sometimes when joining the world, it will hang on the "Joining world..." screen. Once force closed, the Launcher will return to the screen complaining of being out of memory. This was despite the Minecraft instance being given 16GB RAM via the launcher and HWInfo showing that there was free space both within the instance (delta before and after starting Minecraft <16GB) and also in Physical Memory availability.

After crashing, the log would not be further written to, so there's no error message indicating what triggered the hang.

This seemed to trigger fairly reliably when focusing on a window other than Minecraft between hitting "Play" in the launcher and the main menu appearing. However, I can no longer replicate this as of v0.5.4g. But I did have it hang at least once on this version. It just wouldn't then hang when I went to replicate on purpose to investigate...

TODO:

1. Validate the issue definitely isn't reoccuring
2. Do memory availability checking before processing map images. If memory available to the instance is lower than some threshold, hold off on processing that chunk/map layer.

My suspicion from a later crash in a new world is that Blaze Map may be briefly pushing above the memory available while loading new map layers from disk? This is especially suspicious as a lot of the times I was having crashes, it was when I had more virtual memory committed than physical memory available, meaning it would take more work to move things in and out of swap if it briefly needed to load a large number of map layer chunks into memory at the same time.

When setting minimap to 'nether' layer and then travelling back to the overworld the game freezes.

Minecraft: 1.18.2
BlazeMap: 0.5.17

Platform: M1 Mac
OS: MacOS 14.4.1

Launcher: Prism Launcher