Hytale World Events on Your Server: The /worldevent Command, EnableWorldEvents and Creative World Settings

World events are the part of Hytale that happens without anyone asking for it, which is exactly why server owners want a switch. As of Part 4 of the pre-release patch notes for Update 7, dated September 24, 2026, there is one, and it exists in three forms: a setting on the World Settings screen, an in game command, and a flag your server stores per world. This guide covers only what the patch notes state. Lines worth reading in their original wording are quoted, and where the notes are silent, this article says so. Which Build This Applies To All of this is on the pre-release channel, build 0.7.0-pre.4. The stable and live documentation channel still pins Release 0.6.8, which does not include any of it. That decides whether you can use a line of this today. On the stable build, treat this as a preparation document. On pre-release, treat it as provisional: the Update 7 notes are a living page added to in parts, with the byline still reading "Posted by Hytale Team / September 3, 2026" while Parts 1 through 4 were appended to it. The deadline is real, though: Hytale Chapter 1 releases on October 12, 2026, announced by the official @Hytale account on 24 September 2026. Our full write-up of the latest batch is here. The Short Version There is a World Settings option now, added in Part 4 for Creative Worlds, toggleable on and off. Creative Worlds default to off. The notes say Creative Worlds will now have world events switched off by default. The command is /worldevent. World events may be toggled on and off with it. Server side, the documented form is /worldevent enable, taking true or false, toggling when the argument is left off. The flag is per world. The WorldEvents plugin stores an EnableWorldEvents flag in a new WorldEventsWorldConfig, and new Creative worlds get it set to false. Hedera's Lair no longer ends in a void breach. Portal worlds changed too, across Parts 2, 3 and 4: persistent instances, a fix to inherited world settings, per-player entry limits, and portals with no time limit. Events can be authored to wait. TimeCondition waits on world time, GameFlagLevelCondition on campaign progress, and WorldEventAsset can put an event on the player world map. It is pre-release. Build 0.7.0-pre.4, terse notes, no documentation page for /worldevent, and it can change before October 12. What a World Event Is, as the Notes Describe It The patch notes offer no definition, so here is only what the lines themselves support. A world event is authored as an asset: Part 2, dated September 10, 2026, says WorldEventAsset gained name and icon fields for a map entry, so an event is a named thing with an identity a player can be shown. Parts 1 and 2 add conditions that decide when it proceeds: a clock condition, a campaign progress condition, and an interval condition. Part 1, dated September 3, 2026, says the void event in Hedera's Lair was reworked so that it "now escalates after fixed amounts of time", so events can run in stages rather than firing once. The configuration picture, then: events are assets, gated by conditions, running in a world, and now switchable per world. What any shipped Chapter 1 event does is not in these notes, and this article does not fill that gap. The /worldevent Command Part 4 gives the player-facing line first: World events may be toggled on and off with the command /worldevent. And the modder and server-facing line in the same part: World events can now be switched on and off per world with /worldevent enable, which takes true or false and toggles when you leave the argument off. Read together, the documented behaviour is narrow: /worldevent enable true and /worldevent enable false set the state explicitly. /worldevent enable with no argument toggles whatever the current state is. The effect is per world, not per universe and not per player. Those are the only forms the notes document. There is no published subcommand list, no stated permission level and no stated output message. Write down only these forms for your staff and test anything else on your own pre-release instance first. Our guide to tuning a Hytale server from the console covers keeping a command reference honest as builds change. One practical consequence of "toggles when you leave the argument off": a bare toggle is fine for a human standing in a world and a poor idea inside automation. If a script runs /worldevent enable twice, it has done nothing, so scripts should pass true or false explicitly. EnableWorldEvents and WorldEventsWorldConfig: Hytale World Event Settings Per World Behind the command sits a stored flag. Part 4 states it directly: The WorldEvents plugin stores an EnableWorldEvents flag in a new WorldEventsWorldConfig, and new Creative worlds get it set to false. It is owned by a plugin, and it lives in a world config object. WorldEventsWorldConfig is described as new, so anything written against an older shape of world config has a new neighbour to account for. If you carry plugin patches forward, our notes on the Update 7 server plugin breaking changes are the companion reading. The stated default applies to new Creative worlds only. The notes state no default for survival worlds, adventure worlds or anything else, and this article will not invent one. On a non-Creative world, check the flag rather than assuming, and set it explicitly so the answer does not depend on a default nobody can cite. Why Hytale Creative World Settings Now Turn World Events Off Two player-facing lines in Part 4 are the ones builders will notice: Added a ‘World Events’ option to the World Settings screen for Creative Worlds, so that they can be toggled on and off. Creative Worlds will now have world events switched off by default. The reasoning is not spelled out, and it does not need to be. A Creative world exists to hold a build, and an event that changes the world while somebody is building in it is at best a distraction. The same instinct shows in Hedera's Lair, reworked in Part 1 and stopped from ending in a void breach in Part 4. So the default is now the safe one for build servers, and turning events back on is a judgement call rather than a documented one: a showcase world during an event weekend, a test world where you are authoring events, or a creative world doubling as a public hub. In each case the toggle is a deliberate act, which is what a default of off buys you. If you are building the world itself rather than the events in it, the World Builder v2 guide covers the generation side. Hytale Portal Worlds and Instances: Lifecycle, Inheritance and Limits Portal worlds got attention in three of the four parts, and the changes matter to anyone running a hub that sends players elsewhere. Some instances can now persist. Part 4 says portal instances accessed via TeleportInstanceInteraction can now stay around between sessions when their asset asks for it. The same line is careful about the exception: worlds spawned from the portal device summon page still set setDeleteOnRemove and setDeleteOnUniverseStart themselves, so those stay temporary and get swept on the next start. Persistence is opt in at the asset level. The inheritance bug is fixed, and the source is not what you might assume. Part 3, dated September 17, 2026, has the player-facing version: Other worlds that you access through Portal Devices will now adhere to the world settings selected when the original world was created, such as those related to fall damage and PvP. And the precise version: Renamed InstancesPlugin.inheritWorldConfigSettings to inheritDefaultWorldConfigSettings and dropped its origin world parameter. It now always copies fall damage and PvP settings from the universe default world, which is what fixes instances and portal worlds inheriting from the wrong world. Note where the settings come from: the universe default world, not the world the player walked out of. If your hub has PvP off and your universe default world has it on, the instance follows the universe default. That silently changes behaviour, so check those settings before October 12. Networked setups have more such edges, covered in our comparison of native transfers and proxies. Part 3 also says portal worlds can now remain open without a time limit, which turns a portal from a temporary excursion into something closer to a persistent destination. Entry can be capped per player. Part 2 adds two related lines: portals may now be given a per-player entry limit, displayed in the Ancient Gateway UI, and portal keys can now cap how many times each player enters, with PortalKey carrying the per-player limit and the portal device pages showing the limit and the entries left. For a minigame or dungeon run that is a budget mechanic you no longer have to build, and it shows the player what is left. If you are assembling runs like that, the custom minigame development guide is the broader context. Blocking Interactions Per World, and Names That Localise Two more Part 4 lines belong here, though they are not about events. First, a world can now switch off specific interactions. The new BlockedRootInteractionTags list in GameplayConfig.WorldConfig takes root interaction tags, and anything matching is blocked on the server and hidden from the HUD. The second half is the useful part: a player is not offered something that will then be refused, which beats a silent denial, and it suits a build world or a lobby. Portal instance configs now carry a DisplayName, and a world's display name reaches join and leave messages as a Message, so it localises instead of printing the raw key. For an international audience that is one less English-only string leaking into chat. Authoring Conditions: TimeCondition, GameFlagLevelCondition and the World Map If you are writing your own events rather than switching shipped ones off, Parts 1 and 2 hold the authoring surface. TimeCondition. Part 1 says a new TimeCondition completes once the world time reaches the Day, Hour and Minute you set, and any part left at -1 is ignored, so a condition without Day is simply a time of day that comes around again. Leave Day out and you have a recurring daily event; fill it in and you have a one-off. GameFlagLevelCondition. Part 1 also says world events can gate on campaign progress with GameFlagLevelCondition, which completes once a game flag reaches the Level you set, with Comparator picking how the two are compared and defaulting to GreaterThan. A flag with levels and a comparator is a progress gate, so content can be held back until players have got somewhere. Map visibility. Part 2 says world events can now show themselves on the player world map: WorldEventAsset gained name and icon fields for the map entry, and IntervalCondition gained fields that decide when the event appears and what text it shows. The asset decides what the entry looks like; the condition decides when a player may see it. So an event can be advertised in advance or hidden until it starts, which is a pacing decision rather than a technical one. None of this is a no-code system, but it sits next to the ones that are: the Encounter Manager boss fight guide and the trigger volumes guide cover what you can build without writing a plugin. A Recommended Hytale Server Config by Server Type The notes make no recommendations, so this section is opinion built on documented behaviour. Adjust it to your server. Survival. Events on: they are the ambient content that stops a world feeling static between player-made goals. Set EnableWorldEvents explicitly, since the notes state no default for survival worlds. RPG and adventure. Events on, and this is where GameFlagLevelCondition earns its place: gate bigger events behind campaign progress so a new player does not walk into something meant for later. Creative and build. Leave them off, which is now the default for new Creative worlds anyway. Turn them on for one world, for one reason, with /worldevent enable true, and off again afterwards. Consider BlockedRootInteractionTags for interactions with no place in a build world. Minigame and hub. Events off in the hub, because unpredictable world changes in a lobby are a support ticket waiting to happen. Per-player portal entry limits are the feature to look at here. Any multi-world setup. Check the universe default world's fall damage and PvP settings, because that is now the source instances and portal worlds copy from. Whatever you choose, set it explicitly and write it down, the same argument our MaxViewRadius server config write-up makes for capacity settings. What Is Not Documented Yet It is pre-release. Build 0.7.0-pre.4. The stable docs channel still pins Release 0.6.8, so none of this is guaranteed to exist in the build your players run today. The notes are terse. They are release notes, not documentation, and several sentences quoted above are the entire public record of the feature. There is no official documentation page for /worldevent. No published permission requirements, no full argument list, no output format. /worldevent and /worldevent enable with true, false or no argument are the only documented forms. The default for non-Creative worlds is not stated. Only new Creative worlds are documented as getting EnableWorldEvents set to false. Nobody here has tested any of this. This article is a reading of the patch notes, not a report from a running server. The shipped Chapter 1 events are not documented here. The community has been discussing a Goblin Dimension portal, and the patch notes do not document its trigger conditions. The configuration surface is what is documented, and it is what this article sticks to. For what has been shown publicly, see our Chapter 1 first look. It can all change. The Update 7 notes have grown in parts through September, and another part could rename or reshape any of it before October 12. A Checklist Before October 12 Know which channel you run, pre-release or stable, because half of this is meaningless on 0.6.8. Decide the world events answer per world, not per server, since the flag is stored per world. Set EnableWorldEvents explicitly on every world you care about, non-Creative ones included. Use explicit true or false in scripts. A bare /worldevent enable toggles, which is wrong the second time it runs. Check your universe default world's fall damage and PvP settings, because instances and portal worlds now copy from it. Audit portal instances for persistence, remembering that portal device summon page worlds stay temporary by design. Consider per-player portal entry limits where you previously built your own run budget. Review BlockedRootInteractionTags for lobbies and build worlds. Give portal instance configs a DisplayName so join and leave messages localise. Re-read the notes near launch. The page is still being added to. The Bottom Line The interesting thing about Part 4 is not that Hytale has world events. It is that they are now a setting, with a screen, a command and a stored flag, and that the default for new Creative Worlds is off. That is a game acknowledging that not every world wants things to happen in it, which is the first thing any server owner would have asked for. The caveat is equally simple: pre-release material on build 0.7.0-pre.4, documented in single sentences, with no reference page behind it. Read the commands as written, set your flags explicitly, check your universe default world, and re-read the notes the week Chapter 1 lands. Getting a server ready for October 12? List it on HytaleCharts so players can find it on day one.