Closed DuncanRuns closed 2 months ago
Updated original comment since the information there was entirely inaccurate
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
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
TODO:
[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)
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)
Oh right I forgot to mention Do we want chunk map freezing to only happen on wall?
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
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
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
I was gonna ask for wisdom on accessing the entry, that makes it a lot easier
Implements ideas in the comments of #53