AI-assisted change proposal. Filed by agent driven by @soloturn via GDD.
Flying (MovementMode.FLYING, useCollision = true) collides with engine:unloaded - the placeholder block WorldProviderCoreImpl.getBlock() returns for any position whose chunk isn't loaded yet. It's penetrable: false, so a fast-flying player is stopped at the edge of generation rather than flying on through air that would, once generated, turn out to be empty.
There's no ready single-point "will this be terrain or air" query today to distinguish the two predictively. ScalableWorldGenerator/BaseFacetedWorldGenerator do support cheap LOD-scale generation (world.rasterizeChunk(chunk, scale)), which is the right building block, but nothing currently exposes a point query over it - only whole-chunk rasterization.
Idea: a coarse point-density query (e.g. against the generator's heightmap/density facets directly, or a low-res rasterizeChunk call, whichever is cheaper) that flight collision could consult for positions in unloaded chunks - predicted-air lets the player fly through, predicted-terrain still blocks. Doesn't need to be exact; it only has to be right often enough that flying into the generation frontier feels smooth instead of catching on an invisible wall.
Came up while profiling fast flight for #5361/#5374 - unrelated to that issue's actual bottleneck (generation throughput), just adjacent and worth its own ticket.
Flying (
MovementMode.FLYING,useCollision = true) collides withengine:unloaded- the placeholder blockWorldProviderCoreImpl.getBlock()returns for any position whose chunk isn't loaded yet. It'spenetrable: false, so a fast-flying player is stopped at the edge of generation rather than flying on through air that would, once generated, turn out to be empty.There's no ready single-point "will this be terrain or air" query today to distinguish the two predictively.
ScalableWorldGenerator/BaseFacetedWorldGeneratordo support cheap LOD-scale generation (world.rasterizeChunk(chunk, scale)), which is the right building block, but nothing currently exposes a point query over it - only whole-chunk rasterization.Idea: a coarse point-density query (e.g. against the generator's heightmap/density facets directly, or a low-res
rasterizeChunkcall, whichever is cheaper) that flight collision could consult for positions in unloaded chunks - predicted-air lets the player fly through, predicted-terrain still blocks. Doesn't need to be exact; it only has to be right often enough that flying into the generation frontier feels smooth instead of catching on an invisible wall.Came up while profiling fast flight for #5361/#5374 - unrelated to that issue's actual bottleneck (generation throughput), just adjacent and worth its own ticket.