Commits on Sep 11, 2026

• Bound every scan by work, not by trust

  …

  No Java crash report, no JVM fatal log, no Windows fault event — and the game
  log shows a public server rather than a single-player world. That pattern is a
  hang, not a crash, and the cause is that the scans were written for a quiet
  world.
  
  A single-player world holds a handful of entities and a few chests. A public
  server near spawn holds thousands of each, and every one costs several JNI
  calls per frame — entity ESP even reads a name string per entity per frame. The
  base scan was the worst of it: it walked every block entity in 289 chunks once
  a second, which near a chest room is a multi-hundred-millisecond stall on the
  render thread, every second.
  
  So everything now has a ceiling: entity targets are capped and sorted nearest
  first so the cap keeps what matters; block entities cap both what is kept and
  what is examined, because looking for shulkers on a server that has none
  otherwise walks the lot; the drawing caps boxes independently; and the ore sweep
  budget is halved, since each position is a Java allocation and three calls.
  
  Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

  L lodestone committed 3 days ago
  9ed562f
• Fix the crash: Extend View was resizing the world behind the renderer

  …

  Every recent crash report was the same one — Sodium's UniformBufferManager
  throwing "Overflowed the mesh time buffer" from setupTerrain — and it was
  Extend View's doing.
  
  Asking for a wider view is three things in principle: set the option, raise the
  client's copy of the server-announced distance, and resize the chunk store.
  Doing the last two by hand is what broke it. A renderer sizes its buffers from
  the view distance it was told about, so quietly growing the world behind it
  leaves more chunk sections in existence than those buffers can index.
  
  None of it was necessary. Setting the option and sending the settings packet is
  the entire request; the server answers with a chunk-cache-radius packet and the
  game's own handler resizes the store and notifies the renderer properly. So the
  module now only asks, and is clamped to 32 — past vanilla's own maximum the
  renderer is outside the range it was built for.
  
  Two more hardening fixes found while reading that path: getChunk is typed
  ChunkAccess, so calling a LevelChunk method id on the result is undefined
  behaviour rather than an exception unless it is checked first; and block ESP now
  caps how many boxes it will draw, since picking coal at a wide radius finds tens
  of thousands and each is eight projected corners.
  
  Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

  L lodestone committed 3 days ago
  e71864a
• Auto Dodge, and freecam hides the HUD

  …

  Auto Dodge treats the two threats differently, because they are different
  problems. An arrow is already in flight on a known path, so the answer is
  geometry: solve for the time of closest approach, and if it passes within about
  a player's width, step across the path on the side you are already drifting
  towards — sooner means a smaller step, so urgency scales the commitment. A
  hostile mob follows you instead, so the answer is distance, weighted by inverse
  square so the one breathing on you outweighs the one across the room.
  
  Both produce a direction to want. The last step is the one a naive "run away"
  skips: try that heading, then progressively wider deviations either side, and
  take the first that is actually walkable — head clear, and something to land on
  rather than a ledge. blocksMotion is the game's own passability test, so tall
  grass reads as passable and a fence does not. A one-block step is a hop rather
  than a stall.
  
  Freecam now hides the HUD. 26.2 moved it out of Gui into its own Hud class, so
  the flag F1 sets is Hud.isHidden; the old Options.hideGui is gone, which is the
  same restructuring that moved Minecraft.screen onto Gui.
  
  Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

  L lodestone committed 3 days ago
  024eb73
• Extend View: ask the server for more chunks

  …

  A server sends chunks out to the smaller of its own view distance and the one
  the client asked for in its settings packet, so asking for more is not a trick —
  it is the documented way to get more, and it works wherever the server's limit
  sits above what the client was requesting.
  
  Three parts, because any one alone does nothing: set the render-distance
  option, raise the client's copy of the server-announced distance (which
  otherwise caps the effective distance locally), and call broadcastOptions so
  the request actually goes out. The chunk store is widened to match via
  ClientChunkCache.updateViewRadius, so chunks that do arrive are kept instead of
  dropped the moment you move away.
  
  The request is only sent when the number changes; one settings packet per frame
  would be a flood. Loaded chunk count is shown next to the slider so the effect
  is visible rather than assumed.
  
  Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

  L lodestone committed 3 days ago
  8042e32
• Fix the freecam spin properly, and add No Culling

  …

  The spin was not the rotation bookkeeping at all. LivingEntity.getViewYRot does
  not read yRot: it interpolates yHeadRotO to yHeadRot. The camera entity had
  yRot and yRotO set and its head angles left untouched, so every frame the view
  lerped between a stale head rotation and the current one by whatever the
  partial tick happened to be. The camera now has yHeadRot, yHeadRotO, yBodyRot
  and yBodyRotO written alongside yRot, and holds still.
  
  Minecraft.smartCull turns off occlusion culling, so chunk sections the renderer
  believes are hidden are drawn anyway — which is what makes a cave visible from
  inside the rock instead of a black wall. Exposed as No Culling under Visuals,
  with the honest caveat that it cannot show chunks the server never sent.
  
  Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

  L lodestone committed 3 days ago
  8f6541c
• Fix the invalid-entity disconnect and the freecam spin

  …

  Trigger Bot attacked whatever the crosshair touched, with no filter. Vanilla's
  handleInteract does not merely ignore an attack on a dropped item, an
  experience orb or yourself — it disconnects the client for it. Both attack
  paths now require the target to be a LivingEntity other than you, which is
  exactly the set the server accepts.
  
  Freecam span because it tried to hold the body's rotation still: it reset the
  player's yaw each frame and accumulated the mouse delta into the camera, so any
  frame where the reset did not stick re-applied the same delta forever. It also
  cleared ClientInput every frame, which raced the tick that fills it, so the key
  reads came back empty and the camera would not move.
  
  Both go away by not fighting the game for the controls. The mouse turns the
  player as usual and the camera simply follows the view; the body is held still
  by pinning its position, velocity and fall distance every frame instead, with
  position and rotation packets both suppressed so none of it is sent.
  
  Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

  L lodestone committed 3 days ago
  5a43d17
• Freecam: client-side spectator via a detached camera entity

  …

  The old freecam moved your body with collision off and suppressed the position
  packets, which is a ghost, not spectator. This detaches the view instead.
  
  Minecraft.setCameraEntity points the camera at an ArmorStand constructed with
  NewObject and never added to the level: nothing ticks it, nothing renders it,
  nothing about it is sent anywhere. The player is not touched at all, so the body
  stands where it was doing exactly what the server expects of someone standing
  still — there is nothing for it to disagree with and nothing to pull back.
  
  The mouse still turns the player, so each frame the turn it applied is taken
  back off the body and added to the camera instead. WASD/space/shift are read
  out of ClientInput.keyPresses and then cleared to Input.EMPTY so the legs do not
  walk while the camera flies. Previous-tick and render-previous positions move
  with the camera so the view does not smear, and the ESP overlay projects from
  the detached camera, so it keeps working while you are out there.
  
  Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

  L lodestone committed 3 days ago
  84930c6
• Stop the server pulling you back; selectable X-Ray; base finder

  …

  The rubber-banding was not bad luck, it was three specific vanilla checks:
  
  - A server counts ticks where your vertical delta is >= -0.03125 while you are
    not allowed to fly, and disconnects at eighty of them. Flight now dips below
    that threshold on a timer, which puts the counter back to zero, so the kick
    never arrives.
  - handleMovePlayer re-simulates the move you claim, with collision, and pulls
    you back when the result differs. Teleport steps that pass through a block do
    exactly that, so steps are capped and a "stay within server limits" switch
    holds velocity and step size to what is accepted.
  - Nothing at all is checked if nothing is sent. LocalPlayer.sendPosition only
    builds a packet when the position differs from xLast/yLast/zLast or
    positionReminder reaches 20, so writing the current position into those every
    frame suppresses movement packets entirely. Freecam is now genuinely free
    rather than a fight with the server, and Blink falls out of the same trick.
  
  Added Bhop, which is just vanilla's own sprint-jump bonus and therefore nothing
  for a server to disagree with.
  
  X-Ray takes a block selection: thirteen groups, each with its own colour,
  deepslate variants folded in.
  
  Base finder reads block entities out of the loaded chunks instead of sweeping
  blocks — shulker boxes, ender chests, beacons, brewing stands, enchanting
  tables — covering the whole loaded area in one pass, with a coordinate list.
  Container ESP moved onto the same mechanism and is much faster for it.
  
  Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

  L lodestone committed 3 days ago
  d2ee128
• Rework kill aura and criticals, finish ESP, add auto respawn

  …

  Kill aura was a nearest-target loop on a timer, which in modern Minecraft
  lands twenty hits for a fraction of the damage of one. It now waits on the
  attack-cooldown bar (Player.getAttackStrengthScale), picks targets by
  nearest/weakest/smallest-turn, asks the game whether it can actually see the
  target (hasLineOfSight) instead of ignoring the through-walls switch, and
  rotates for the swing.
  
  Criticals were backwards: the hop was applied with the swing, so every hit
  landed while rising and none of them were critical. It now hops, holds the
  swing, and lands it on the way down.
  
  Frame-rate dependence fixed throughout: physics runs per tick, so velocity
  modules act on a tick boundary (Entity.tickCount) and velocity speed sets an
  absolute speed instead of scaling each frame, which compounded into a
  slingshot. Aimbot smoothing is time-based, so the turn takes the same time at
  30 fps as at 300.
  
  ESP finished: X-Ray and container highlighting. Blocks have no list to walk, so
  the volume is swept a slice per frame with a fixed budget and the completed
  pass swapped in; block identity is System.identityHashCode on the singleton
  Block, one int compare rather than a chain of reference tests.
  
  Also: auto respawn.
  
  Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

  L lodestone committed 3 days ago
  fcbd080
• Lodestone client: injected in-game menu driven through JNI

  …

  The project gains a second half. The external explorer stays (and is how every
  name below was verified against the running game), but the cheat menu now runs
  inside Minecraft:
  
  - inject a DLL, hook glfwSwapBuffers, draw egui in the game's own GL context
  - drive the game through JNI rather than raw memory, so writes go through the
    GC's barriers and methods can be called directly
  - five draggable windows: Combat, Movement, ESP, Visuals, Misc
  - client-side only: nothing depends on owning the server
  
  Modules wired to the game: fly (vanilla/smooth/glide/teleport), speed
  (abilities/velocity), no-fall, jetpack, auto-sprint, noclip, step, high jump,
  jesus, spider, freecam; kill aura, aimbot (camera/silent, smoothed), trigger
  bot, reach, auto clicker with jitter, anti-knockback, criticals; entity ESP with
  boxes, tracers, nametags and health bars; fullbright, custom FOV, no hurt
  camera, no weather, no view bob; hide-from-capture.
  
  Per-module keybinds, a panic key, and settings saved to disk.
  
  GL state the game leaves behind has to be neutralised before drawing and put
  back after: a sampler object on unit 0 renders everything black, and a stale
  GL_UNPACK_ROW_LENGTH scrambles the font atlas.
  
  Unload unhooks and goes inert rather than unmapping the module, which crashed
  the game while the window still pointed at our window procedure.
  
  Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

  L lodestone committed 3 days ago
  a6eba02