Hytale Update 6 Part 12 Pre-Release Patch Notes (August 13, 2026)

Hytale Update 6 Part 12 arrived on August 13, 2026, and it opens with a mod browser: in the client, on the main menu, with install and update buttons. Underneath it sits what we would call the heaviest set of breaking server changes in the Update 6 pre-release run so far. Whitelisting, bans, command permissions and the block accessor API all changed shape in one week. Everything below comes from the official pre-release patch notes page, whose "Pre-Release (Update 6 Part 12)" section is dated August 13, 2026. That page is rolling: one URL, overwritten as parts are added, so the Part 12 section you read today is not guaranteed to sit there in the same form next week. It is why we write these up section by section, and why Part 11 on August 6 is still readable here in full. What Is New in Hytale Update 6 Part 12? Three things carry the drop. The in-game mod browser, which arrives roughly when it was said it would. The 16 million block builder ceiling and the compact .lpf prefab format that makes it practical. And a breaking-changes cluster that will stop several plugins compiling and quietly change how your whitelist works. Then creative tool fixes, five crash fixes and a good deal of quiet plumbing. One thing Part 12 does not carry: a build number. Part 11's section named its version and we printed it; this one names none, so we are not supplying one. Nor is there a stable Update 6 release date. The Hytale Mod Browser Is Here, and It Landed Inside Its Own Window The headline feature is stated in four lines, worth reading exactly as written: "The first version of the mod browser is now available from the Hytale main menu, showing featured, popular, and recently updated mods." "Filter by category, or search mod names and descriptions for something specific." "Open any mod to see its description, screenshots, download count, supported game versions, and install buttons." "View, update, or remove your installed mods from the 'My Library' screen." Note the phrase "the first version" — the notes label it a v1. Even so, it changes the shape of the hobby: discovery, install, update and removal without leaving the client, with "supported game versions" printed on the mod page, which is the single most common cause of a broken install in every modded game there has ever been. A promise kept, and on time On July 16, 2026 Hytale published "First Look: Chapter 1 and More", which we covered in our Chapter 1 first look write-up. That post put rough timings against a set of features, and the Mod Browser was bucketed under "2-3 weeks (Update 6)". Counted from July 16 that window runs to about August 13, and the mod browser shipped on August 13. Worth saying plainly, because the opposite is usually the story: an estimate was given in public and the feature landed inside it. What the notes do not say Two things the four bullets leave open, which we are not going to fill in by guessing. The notes do not name where the browser's mods come from. "Featured, popular, and recently updated" describes a catalogue with a backend, but no registry or partner is named, so we are not naming one. Nor do the notes describe any server-side behaviour — nothing here says a server can require, push or verify a mod list against a joining client. As documented this is a client-side install and library manager, so if you run a modded server, keep treating your mod set as something you distribute and document yourself. Our guide to installing and managing Hytale server mods is not superseded by this. One piece of context on what the browser is arriving into. Reading CurseForge's Hytale section on August 14, 2026, its game-version filter offers exactly two options, Early Access and 0.5; there is no 0.6 filter, and zero of the 5,626 mods listed there are tagged for Update 6. That is nobody's fault — no sensible author tags a stable release against a moving pre-release branch — but it sets expectations for the browser's first weeks. "Supported game versions" is the most important field on those mod pages precisely because almost nothing is claiming 0.6 yet. Read it before you press install. Builder Tools Now Take 16 Million Blocks, and Big Builds Save as .lpf The second headline feature is three lines: "Builder tools now support selections of up to 16 million blocks." "Large builds now save in a new compact format, keeping file sizes small." "Copying, cutting, pasting, or saving large selections is now a lot faster." Sixteen million blocks is a cube roughly 252 on a side, or a 400 by 400 footprint a hundred blocks tall. That is town-scale, not building-scale: the difference between copying a structure and copying a build site. The "new compact format" gets named in the modder-facing section: "Large prefabs now save in a compact binary .lpf format. Anything from 300,000 blocks up is written this way, and .lpf files load everywhere prefabs do." Three things follow. The 300,000 block threshold is automatic, so the size chooses the format, not you. It is binary, so do not expect to diff or hand-edit it. And it loads everywhere prefabs load, which is what matters if you ship prefab packs: no second pipeline to maintain. Ruin fields like this one are exactly the scale the new 16 million block ceiling is aimed at: a whole site copied in one selection rather than tower by tower. A general official Hytale screenshot, not a Part 12 screenshot. The supporting work that makes the ceiling usable A bigger number alone would only move where things break, so Part 12 spends most of its creative tooling budget on the surrounding problems: Paste previews stop stalling. They now fall back to "a simple outline or a solid shape when the clipboard is very large, so it appears immediately instead of stalling or showing nothing". Limits tell you the number. "When a selection goes over a tool's limit, the game now tells you so and by how many blocks." A failure that quantifies itself is worth a lot when you are trimming by hand. Notifications stop stacking, with builder tool actions and saves showing one notification that updates rather than one per update. Undo and redo "use considerably less memory after making several large edits". With one honest caveat, stated in the notes themselves: "Undo and redo now keep to a memory budget. After an extremely long run of very large edits, you may not be able to undo all the way back to the start." That is a trade, not a bug, and the developer-facing half names the knobs: HistoryBlockBudget and RedoHistoryBlockBudget on BuilderToolsConfig, "which drop the oldest entries once the budget is exceeded". If you run a creative server where builders work long sessions, find those two fields before somebody discovers the limit the hard way. Our Update 6 creative building guide covers the tool set they sit on top of. Custom tooling can join the same accounting through a new SelectionSnapshot.estimatedBlockWeight(), which has a default implementation but should be overridden if your snapshot's real cost differs. One more that is easy to miss: "Volume APIs such as BlockSelection.getSelectionVolume() now return long instead of int, so extreme selections no longer wrap to a tiny value." That is the new ceiling showing up in the type system. Any plugin storing a selection volume in an int should be checked. Breaking Changes Every Hytale Server Owner Should Read This is the part of Part 12 that will cost people a weekend if they skip it. None of it is optional reading if you run a server with plugins. Whitelisting is now a permission, and your whitelist.json gets renamed "The HytaleWhitelistProvider has been removed. The whitelist now runs on the hytale.server.join permission, and the whitelist commands grant and revoke it. If you have an existing whitelist.json it will migrate to whitelist.json.migrated." Three facts landing on three different people. If you run a whitelisted server: your whitelist is no longer a list, it is a permission node, and access control now lives wherever your permissions live. The commands still work and grant or revoke hytale.server.join behind the scenes, so nothing changes for your moderators day to day. What changes is where the truth is stored. Copy whitelist.json somewhere outside the server directory before you update; afterwards, confirm whitelist.json.migrated exists and have a known whitelisted player actually connect. A renamed file is not proof the entries arrived intact. If you use a permissions plugin: this is now your problem too. hytale.server.join is a node like any other, so anything that hands out permissions can hand out server access — a wildcard included. Check whether any group with broad grants now implies join access to a server that is meant to be closed. This failure mode did not exist last week. Our server rank and permissions guide covers structuring groups so a wildcard does not become an accident. If you use a plugin implementing HytaleWhitelistProvider: it is removed, not deprecated. That plugin will not compile and it will not load. Check your mod list for custom whitelist logic before you update the server, not after. Ban handling collapses into a single Ban type "Ban handling is now one type. AbstractBan, InfiniteBan, and TimedBan collapse into a single codec-stored Ban." Three types become one. Any plugin that branched on which ban class it held needs rewriting, and anything storing bans in its own shape needs to read the new codec-stored form. In exchange the extension points get much better: "The server configuration can name where bans are stored under a BanStorage block, which is decoded after the plugins load." "Plugins can now decide how bans are handled and stored. Implement BanProvider to replace ban handling, or BanStorageProvider to keep bans anywhere you like." For a network running several servers, BanStorageProvider is the interesting one: bans in a shared database rather than a file per server is now a supported shape rather than something you bolt on. BanProvider goes further and replaces the handling itself, which is where appeal systems and temp-ban escalation would live. The phrase "decoded after the plugins load" is made possible by new Deferred and DeferredCodec types, which let a value be read before the codec for its type is registered — the chicken-and-egg problem of naming a plugin's type in the server config, solved generically. Commands must declare their permission up front "Commands now declare their permission up front. canGeneratePermission has been removed, so a command that overrode it to return false must call requireNoPermission() instead. The HytalePermissions constants also changed from String to PermissionQuery, and code that needs the node string calls getId()." Two compile breaks in one entry. The canGeneratePermission removal is a mechanical swap: find the overrides that returned false, call requireNoPermission() instead. The HytalePermissions change is sneakier, because a constant changing from String to PermissionQuery breaks every place you passed it where a string was expected, logging and config writing included. Add .getId() where you need the node text. The upside is that a PermissionQuery "can be held as a constant and passed to every permission check, which avoids rebuilding the id and wildcard strings on every call" — a free win for any permission check in a hot path, once you are compiling again. BlockAccessor is removed entirely "The BlockAccessor interface is removed. Every member now lives on WorldChunk, which was its only implementor, so anything typed BlockAccessor becomes WorldChunk. IChunkAccessorSync, ChunkAccessor, and OverridableChunkAccessor are no longer generic, so drop the <WorldChunk> argument, and WorldChunk.getChunkAccessor() is gone in favor of using the World directly." For most plugins this is a find and replace: change the type, drop the generic parameter, stop calling getChunkAccessor(). It is broad rather than deep, which means it will touch a lot of files in anything that manipulates blocks. Two follow-on entries land in the same area: "getCurrentInteractionState moved off the accessor and onto BlockType. Call blockType.getCurrentInteractionState() instead of passing the block type in. The old per-block methods on WorldChunk are now deprecated, so resolve a section with ChunkStore.getChunkSectionReferenceAtBlock and go through BlockOperations." "Custom falling-block impacts take a section instead of a chunk. FallingBlockImpact.apply now receives a Ref<ChunkStore> sectionRef covering the block at position, and the block test and place helpers on BlockAccessor and IChunkAccessorSync are gone, replaced by ChunkStore.getChunkSectionReferenceAtBlock plus BlockOperations.testPlaceBlock, BlockOperations.setBlock and BlockOperations.TestBlockFunction." The through-line: block access is moving from chunk level to section level, with BlockOperations as the front door. Resolve a section reference once and go through BlockOperations — the deprecated per-block methods on WorldChunk are the signpost. Protocol APIs deleted, and validation got stricter "Removed Packet.serialize(ByteBuf), the generated validateStructure(ByteBuf, int) methods, the ByteBuf helpers on PacketIO, and ValidationResult from the server protocol API. Call Packet.serialize(MemorySegment, int) to write a packet and toObject(MemorySegment, int, ReadCursor) to read one. Validation now runs during the read and throws ProtocolException on malformed data." This continues the direction the protocol has moved all through Update 6, off ByteBuf and onto MemorySegment, and it is why we maintain a standalone Update 6 protocol breaking changes guide for server operators. The structural change is that validation is no longer a separate step returning a ValidationResult you could inspect. It happens during the read, and it throws. Code that checked a result object and carried on now needs a catch block and a decision about what a malformed packet means for that connection. Two more in the same section. The payoff: "Improved packet decoding performance by 2-4x on both the client and server." The tightening: "Made packet validation stricter: non-canonical VarInts, malformed UTF-8 strings, and mismatched offset tables are now rejected, with identical rules and limits on the client and server." If you run a proxy, a bot or a bridge that writes packets by hand, read that second one twice. Non-canonical VarInts are the classic thing that worked for years because the reader was forgiving. It is not forgiving now, and identical rules on both ends means there is no direction in which you get away with it. A server with a broken core plugin now stops instead of limping "The server now stops when a core plugin fails to load, set up, or start, rather than running on in a broken state. The option that boots past a broken mod does not cover a core plugin." Filed under bug fixes, but you will feel it on the next upgrade that goes wrong. A core plugin could previously fail and leave the server running in a partial state, which is the worst outcome: players connect, something is quietly missing, and you hear about it from a report hours later. Now it stops. Expect at least one upgrade where a server that used to start does not, and treat that as the fix working — and note the second sentence, because the escape hatch that boots past a broken mod is explicitly scoped out of this. New Server-Side Building Blocks Not everything on the server side breaks something. Part 12 adds a useful set of no-code and low-code pieces: Global server flags. A new GameFlags builtin plugin "keeps global server flags in Universe Storage", set and checked from content through SetGameFlagInteraction and GameFlagConditionInteraction. Server-wide persistent state with no plugin of your own: event progression, seasonal switches, one-time milestones. Instances can send players back where they came from when the current instance unloads, via a new boolean on InstanceWorldConfig with an optional instance key. Anyone chaining dungeons or arenas has been writing this by hand. Instances can show a .ui document as they close, named by a DocumentDisplayOnRemoval field on InstanceWorldConfig: a results screen when the timer runs out, no code required. World events can create, remove and roll back trigger volumes through TriggerVolumeCreateAction and TriggerVolumeRemoveAction, with a TriggerVolumeContext tracking what an event created. The rollback is the part that matters: volumes get cleaned up rather than accumulating. Volumes can throw you. A new VOLUME_ORIGIN value for RelativeMode on SetVelocityEffect "launches entities away from (or toward) the volume origin no matter which way they face" — knockback and gravity wells that ignore which way the player is looking. Notifications can replace themselves via a new tag field and a seven-argument NotificationUtil.sendNotification overload, which is the mechanism behind the single updating builder tool notification, exposed for your own progress toasts. Prefab saves report where they wrote, returning a Path from PrefabStore and a CompletableFuture<Path> from PrefabSaver.savePrefab, where null means failure. Necessary now that the extension depends on the build's size. Smaller items: memory entries can carry a translatable description; particles can fade by camera distance at both the near and far end; and BuilderToolsPlugin.Action.ROTATE is renamed Action.TRANSFORM. Two modder-facing fixes change behaviour rather than adding surface. Trigger volumes "no longer drop an event when a burst reaches the per-tick budget" — signal effects, block event rules, NPC signal actions and volume create events over budget now "wait for a later tick instead of vanishing". If you have built volume logic that worked in testing and failed under a crowd, that was very likely this. And a nasty parser bug is gone: "Fixed JSON reading so a { or } inside a string value no longer throws off the parser." Anyone whose config broke because a display string contained a brace now knows why. Player-Facing Fixes and Quality of Life The best single item is a portal button with a safety catch: "The Ancient Gateway now has a button that can be used to close the active portal. Fortunately, each Gateway has a convenient failsafe that will prevent this button from working if someone is still on the other side of the portal." A close button that refuses to strand people is a small piece of considerate design. World creation got two direct improvements: a larger Customize button on the World Creation screen, and a Create World button on the World Settings screen that appears when customising a new world, so you no longer have to back out of customisation to start. The creative tool fixes are the longest list, and several are the kind of bug that quietly wastes an afternoon: The # mask again keeps brushes and commands inside your current selection, and !# again keeps them outside it. # now also works with the line tool and scripted brushes. /stack while looking up or down at an angle now joins the copies into one continuous run instead of leaving a gap between each copy. Extruding a selection by holding alt and dragging no longer reduces the size of the area you had selected. /stack --empty is no longer accepted and then immediately ignored. Empty space may now be copied, and may also be extended when extruding a selection, matching how other build tools handle empty space. Liquids may now be copied with the /stack command. Undo now correctly reverts a whole tool action. Pasting a prefab into an unloaded area now waits for the space to load instead of failing. The prefab editor gives more detailed error messages on a failed load, and offers to retry. Prefab folders now include their subfolders by default when you load them in the prefab editor. Entities in prefab previews no longer glow pink. The # mask fix comes with a developer-side explanation, which is rare and welcome: the EditOperation and BrushConfigEditStore constructors now take selectionMin and selectionMax, "so the # mask tests against the player's selection rather than the area an operation happens to cover". The mask had been testing the wrong box. Pass null when there is no selection, or resolve them with BuilderToolsPlugin.getMaskSelection. Alongside it, BuilderState.extrudeSelectionFace takes a new empty parameter controlling whether empty cells clear their destination; pass false to keep the old behaviour. Custom UI also stops refusing UIPath values written as markup text. Elsewhere: instance portals now correctly save the world you travel into, and time remaining in a portal world can no longer exceed the amount it started with. The cave weather effect from the magic ruins dungeon no longer breaches the surface on new chunks. And creatures that place blocks can now do so at the very bottom of the world. Stability: Five Crashes, and One With a Sense of Humour Five crash fixes, quoted in full: "Fixed a crash that could occur when processing benches had over seven input slots." "Fixed a crash that could occur when returning from an instanced area to a world that had already closed. Those who find themselves in this predicament will now be returned to the main world spawn." "Fixed a crash that could occur when pasting creatures that would then despawn the moment they appear." "Fixed a crash that could occur when interacting with a prefab that contained an older patrol path marker." "Fixed a rare pathfinding bug where a creature's route was so troublesome that time itself would come to a standstill until the server restarted." That last one is a hang, described with more style than it needed. If you have had a server go unresponsive with no crash, no error and no obvious cause, and a restart was the only cure, this is a candidate. The bench crash has a companion entry in the protocol fixes: "The processingSlots and processingFuelSlots fields of the processing window data are now 32-bit ints rather than signed bytes, so a bench can carry more than seven active slots without the mask wrapping." Our reading, not something the notes state outright: those are one bug seen from two ends, a slot mask that fitted in a signed byte and wrapped on the eighth slot. If you build custom processing benches, that silent ceiling is gone. The closed-instance fix is the one owners will appreciate most, because it converts a crash into a teleport: a player whose instance expired mid-transition now lands at the main world spawn rather than dropping out of the game. FAQ What is new in Hytale Update 6 Part 12? Part 12, dated August 13, 2026, adds the first version of the in-game mod browser, raises builder tool selections to 16 million blocks with a new compact .lpf prefab format, collapses the ban types into a single Ban, removes HytaleWhitelistProvider in favour of the hytale.server.join permission, requires commands to declare their permission up front, removes the BlockAccessor interface, deletes several protocol APIs while making packet decoding 2-4x faster, and fixes five crashes. What is the Hytale mod browser? An in-client browser reachable from the Hytale main menu that shows featured, popular and recently updated mods, lets you filter by category or search names and descriptions, shows each mod's description, screenshots, download count, supported game versions and install buttons, and manages what you have installed from a "My Library" screen. The notes describe it as the first version. How many blocks can Hytale builder tools select now? Up to 16 million. Selections from 300,000 blocks upward save in the new compact binary .lpf prefab format, which loads anywhere a prefab loads, and copying, cutting, pasting and saving large selections is faster. How does Hytale whitelisting work after Update 6 Part 12? HytaleWhitelistProvider is removed. Whitelisting now runs on the hytale.server.join permission, and the whitelist commands grant and revoke that permission. An existing whitelist.json migrates to whitelist.json.migrated. Practically: back up your whitelist before updating, and audit any permission group with broad grants, because anything that can hand out permissions can now hand out server access. Will my plugins still work on Part 12? Several will not compile without changes. The removals alone cover HytaleWhitelistProvider, BlockAccessor, canGeneratePermission, ValidationResult, Packet.serialize(ByteBuf), the generated validateStructure methods and the ByteBuf helpers on PacketIO. The three ban types also collapse into one, and HytalePermissions constants change type from String to PermissionQuery. Test on a copy before updating a live server. Is Hytale Update 6 out yet? Not as a stable release. Twelve pre-release parts in, Update 6 exists only on the pre-release branch, and the newest post on the stable game updates channel is still "HOTFIXES: UPDATE 5" from July 22, 2026. No stable release date has been announced, and we are not going to guess one. What Part 12 Means If You Run a Server Four jobs, in order. Copy your whitelist.json somewhere safe before you update, then verify afterwards that whitelist.json.migrated exists and that a known whitelisted player can still connect. Audit any permission group with a wildcard or broad grant, because hytale.server.join is now just another node and a generous group can let people in. Check every plugin against the removals: HytaleWhitelistProvider, BlockAccessor, canGeneratePermission, the old ban types and the deleted protocol APIs. And expect the first bad upgrade to stop your server rather than limp, now that a failed core plugin halts startup — the correct behaviour even when it is the inconvenient one. For builders the news is simpler: sixteen million blocks, faster copies, smaller files, a paste preview that appears immediately, and an over-limit message that tells you how many blocks to trim. Just remember that undo now has a budget, and a long session of very large edits will not rewind all the way to the start.