KingContaria / seedqueue

Minecraft mod that generates multiple worlds concurrently and lets players reset them on an ingame wall screen.
MIT License
32 stars 18 forks source link

Chunkmap Freezing (village resetting) #63

Closed DuncanRuns closed 2 months ago

DuncanRuns commented 2 months ago

Implements ideas in the comments of #53

DuncanRuns commented 2 months ago

Updated original comment since the information there was entirely inaccurate

DuncanRuns commented 2 months ago

Related issue: Chunkmaps aren't build in the background unless the previews are built as well, meaning upcoming chunkmaps won't be frozen accurately unless background previews equals the max queued seeds

KingContaria commented 2 months ago

Related issue: Chunkmaps aren't build in the background unless the previews are built as well, meaning upcoming chunkmaps won't be frozen accurately unless background previews equals the max queued seeds

This probably has to do with the way worldgen tracking works, the QueueingWorldGenerationProgressListener sends Runnable's to the client, specifically MinecraftClient#renderTaskQueue. This should be ran every frame tho so I'm not exactly sure what's happening. It might still be reasonable to just check if we're in queue using SeedQueue#getThreadLocalEntry and if we are just execute it serverside? Logging is surpressed for background trackers anyway so it wouldn't affect that and it might help make Max World Generation % more accurate too since we don't have to wait for the server-client delay

The chunkmaps are built, they just don't get added to any LevelLoadingScreen instance

DuncanRuns commented 2 months ago

TODO:

DuncanRuns commented 2 months ago
[12:18:47] [Server thread - Random Speedrun #125418/INFO] (Minecraft) [STDOUT]: 6956: WGPT<init> | WGPT0
[12:18:47] [main/INFO] (Minecraft) [STDOUT]: 6958: LLS<init> | WGPT0
...
[12:19:50] [Server thread - Random Speedrun #125420/INFO] (Minecraft) [STDOUT]: 70440: WGPT<init> | WGPT4
[12:19:50] [main/INFO] (Minecraft) [STDOUT]: 70440: LLS<init> | WGPT4

First time running these creation functions provide a near negligible delay of ~2ms But it then becomes certainly negligible after JVM warmup. I think this is acceptable. (I also think generating,0 start timing was an arbitrary choice in the first place so this possible 2ms is definitely no biggy)

DuncanRuns commented 2 months ago

In its current state, I'm currently able to lock a village every few seconds, very low false positive probably due to the new start timing, and no background jank going on

As a sanity check, performance impact is pretty much non existent (my usual is 36-40, I assume the increase is because smaller simulated window sizes) image

DuncanRuns commented 2 months ago

https://www.youtube.com/watch?v=9dwRG0hCIUY

DuncanRuns commented 2 months ago

Oh right I forgot to mention Do we want chunk map freezing to only happen on wall?

KingContaria commented 2 months ago

Yes I think it should be wall exclusive, although you can just make the frozen copy even when seedqueue isn't active, just check SeedQueue#isOnWall in the LevelLoadingScreen mixin.

One last style thing, the injects dont need the parameters, just CallbackInfo is fine since none of the parameters are used

DuncanRuns commented 2 months ago

would you like me to implement unfreezing for locked instances? I'm thinking this should probably just be default with no option needed if I implement it

KingContaria commented 2 months ago

would you like me to implement unfreezing for locked instances? I'm thinking this should probably just be default with no option needed if I implement it

Oh i missed this, I like that idea. You should probably move your LevelLoadingScreen mixin into the worldpreview compat package one, /compat/worldpreview/render is kind of the wall rendering package and you can use the getAsSeedQueuePreview method in there to check SeedQueuePreview#getSeedQueueEntry for if its locked

DuncanRuns commented 2 months ago

I was gonna ask for wisdom on accessing the entry, that makes it a lot easier