Changes using /gamerule do not persist when a world is unloaded/reloaded

Was this working on your realm prior to the 1.18.10 update?

Yes, everything prior to 1.18.10 was working.

I can confirm the major bug! Game rule data is not saving at all after all players have left the realm. Command blocks and command block output has been getting reset constantly on my realm. This has crippled my realm. Moving to a back up does not work and replacing the world does not work. This is really bad. I moved the map to a new realm and its still is not working. Also the realm is crashing when the last player leaves which is making the realm unresponsive for 20-30. During that time players cant connect. Opening setting to check members and stuff will result in a infinite loading box.

–
Reply from @unknown
Please limit comments to information related to this specific issue, which is that gamerule changes do not get saved with the realm. Any other issues you may be having (command blocks, crashes, etc) should be reported separately. However, please also note that crashes are automatically logged by the realm server and are not accepted here on the bug tracker unless they contain a specific list of steps that someone else can follow to reproduce the crash. For more information please see the Bug Tracker Guidelines

Umija, I believe brett is talking about the command block output game rule which does indeed get reset along with all of the other settings accessible via /gamerule.  Which is extra annoying when players are seeing command block output when they shouldn't be.   Again, it is directly related to game rules reset.

Umija5895M,

The description has been updated and I have also attached a video.  Please let me know if there is any other data I can provide.   Thanks.

Confirmed. This is also happening for me on Bedrock realms since 1.18.10. 

Prior to 1.18.10, gamerule would persist.

I can confirm this is happening in my creative realm. Gamerules don’t save their setting, and my day/night cycle and weather cycle commands keep resetting to true.

Sorry in advance for this comment but this better be fixed ASAP. I and many others are not paying for Realms for stuff like this to make it into full releases!

Also as a side note, this has only affected my realm since 1.18.30 but it didn't seem to happen until I changed some gamerules in the game pause menu and now it's just when ever I reload the world (activating another world/join when realm is idle)

This bug is still active and seems to affect my realm immediately after leaving rather than with any kind of delay. I myself am affected by the CommandBlockOutput gamerule, so Umija5895's response to "Im Brett K" regarding that is especially insulting. Perhaps they should learn to read a comment properly before making assumptions.

My temporary workaround until this gets fixed is to (rather ironically) place a repeating command block inside a ticking area with the gamerule command inside it, so that it automatically sets it to what you want whenever the world is reloaded. One command block per gamerule.

Can confirm in 1.18.31, my brother just got a realm subscription and having to use '/gamerule commandblockoutput false' every time someone rejoins is a pain. The first person to join's chat always gets spammed from repeating /testfor and /teleport commands.

Can also confirm this bug. From what I've tested, the gamerules DO stick if you edit them from the Realm menu itself (e.g. weather and day/night cycling). The options for which you need the /gamerule command ingame do keep resetting which indeed requires repeating command blocks to "fix".

Another issue, which I do feel has some relation to this particular bug, is that I have some commands in place to make me auto-equip an elytra. This stops working occasionally. but when I /give myself the elytra it will then magically equip the elytra I already "had". Also, doing a /clear command convinces me the player IS wearing the Elytra although it doesn't show/work. This usually stops working around the same time the /gamerule bug goes away, hence I think they might be related. This is all on a realm; everything works fine again when playing the map offline.

I do realize the 2nd bug might warrant a whole seperate bug report, but I wanted to share because I strongly feel there is correlation.

Yes @Marco Bergsma that's right. It's ONLY the gamerules that are NOT in the world settings. Great deduction!

That other issue seems like a separate command-functionality based issue. This issue in this case is that the realm is only saving world settings. Intended behavior is that "permanent settings" were meant to be set through the realm menu, , for EXAMPLE, the /difficulty command used to only last until restart. This issue is a problem because these ingame-command-gamerules cannot be permanently set through the menu.

In my friend's community realm we have to do /gamerule showcoordiantes true everytime the realm is unloaded as it keeps reverting back to false. We've also tried turning the coords on in the realm world settings but it still reverted.

This is still an issue in 1.19.2 - my (and my friends') realm still needs command blocks to fix all the gamerules continiously

1. REALMS-10656 ticket merged to this one. It is not just per session. Changing from survival to creative, spend a while in creative, then switch back to survival also resets the gamerule back to default (True). In my case the doinsomnia gamerule

So, this is a known bug on realms then?

Grrr... I keep having to do the gamerule for command block output. now i understand why.

I hope they get this fixed. Until then, maybe I will just set up a command block somewhere on a clock that runs the gamerule command every like 5 mins or so. I dont need to hear my command blocks do their jobs lol.

I can confirm that this still hasn't been fixed in Bedrock v1.19.31...

This is exceptionally annoying because in worlds with repeated command blocks your chat will be spammed upon entering the world until you can turn it off manually. If you are on member mode, you're basically hopeless.

The problem still persists in 1.19.50 - /gamerule disablecommandblockoutput, /gamerule sendcommandfeedback are just completely stuck in whatever mode they are in. For me personally, on my realm, it doesn't even help of putting a repeating commandblock with the "/gamerule sendcommandfeedback false" command in it. It simply autoenables every single tick.

Not the end of the world, but the immersion is a bit lost when one uses some command tricks to make stuff happen.

still an issue in January 2023 not sure what version but i'm up to date,

possible solution i'm testing now

set ticking area to keep the chunk loaded and setting up repeat command blocks to set the gamerules back

would just have to edit those command blocks when you want to change them.

cant see why it wouldn't work but i'm sure Minecraft is gonna throw something weird at me lol  

Still not fixed in 1.19.51 only workaround I know of is creating a ticking area with repeating command blocks which update any altered gamerules for the world or a behaviour pack that does this every tick.

This is really annoying for me as I have a project I'm working on with friends and have lots of repeating command blocks which output when the rule to output command block feedback is or should be false

1.19.62, this problem continues to persist.

This still hasn't been fixed in 1.20.10. Is there anyone actually working to fix this issue? It's a pretty big and annoying issue. I should not have to redo my settings every other time I hop onto my Realm. It's very disappointing to see how long this bug has persisted. (Over a year now...)

This issue still occurs on 1.20.15

I just wanted to let everyone following this report know that if you download the world and then change all the settings right using/gameral and then reupload it which if you're the real owner is very easy to do it will save all of your game rules settings so unless you're changing them regularly it won't be an issue for you if you want coordinates to show up every time or if you want command block out put always be off you don't have to add a command block to turn it off constantly. Just download the world edit the settings and then re-upload it

This is still an issue as of 1.20.51 and it is highly annoying. Hopefully there is a fix soon.

I've personally tested this and after everyone has logged off realm, the realm does in fact default itself back to /gamerule playerssleepingpercentage 100. This method only fixes it for about thr same amount of time as the administrator just inputting the gamerule upon login.

2 years later still no fix -  how and why Mojang are getting away with this I have no idea

I am consistently also having this issue for playersSleepingPercentage and it is really annoying to have to reset it every day. It makes me want to go back to using a mod for it, but then it considers it "cheating" and you can't get advancements.

Still running into this for my bedrock realm after updating to 1.20.70

I always have to re-set player sleeping percentage to 0. 

I've had playersleeppercentage on my realm with no cheats enabled since it came out, just today I've noticed it's no longer activated and it won't let me enable It, it says cheats have to be enabled but I've had it on there for a long time with no cheats

still happening 1.20.81 unbelievable

We're going to have a fix for this on the Realms service Soon™, but in the meantime you can toggle the gamerules with the world downloaded locally, then re-upload, as the pinned comment mentions. 

Just an FYI the pinned workaround is not valid when there are bugs such as REALMS-474 which prevents worlds on Realms from being downloaded.

Thanks for the update though CornerHard and fingers crossed it is implemented soon.

Version 1.21.0 I loaded up my realm did /gamerule commandblockoutput false and left it for an hour re-joined and there were still no spam in chat of commandblockoutput feedback so therefore I believe the gamerule command after 2 years has finally been fixed on realms thanks a lot MC you are definitely going in the right direction with patching the game and bugs which are annoying the players 
Thanks once again for fixing this
Kind Regards
Rebel

Yes, we have the same issue. Would love a way for that command to retain so that you don’t have to type in each time. It was working fine, and then changed with an update. Please fix!

Please please can we get a fix for this soon. Downloading the world, changing the settings, and reuploading did not work. We are having to change the spawn radius and sleep percentage every single time we log on. It is incredibly frustrating. 

its started happening again please fix this it was good when it was fixed happening in 1.21.21!

Still an issue on 1.21.21. Workaround is no longer working!

I did come up with a "workaround" - this will disable trophies though.

Place repeating command blocks with your /gamerule command in and set it to always active

Create a tickingarea around the commandblocks.

I'm quite content to use this method as it's a creative world but for survival will be less than ideal for trophies.

Still having issues with this, how has it not been fixed yet?

The download workaround does not work. Downloaded the world. Changed playerssleepingpercentage. Uploaded the world. A few days later, playerssleepingpercentage reset to 100. Downloaded, updated, Uploaded. It only stuck for a couple days. Downloaded, updated, u0loaded. Two hours later, it reset to 100 again.

If you're on PC and the original workaround doesn't work, you can try downloading the world and editing the gamerules directly in the level.dat file instead using an NBT editor, then reupload the world on realms. I've had better luck doing this than using /gamerule

It is absolutely mind-boggling that people have been complaining about this bug for over TWO YEARS. The workaround does not work. How on earth has this not been fixed?

Since the workaround doesn't work for any extended period of time what is the word on the Soon™? It's been over four months since we have gotten the Soon™ answer. Is the answer going to be the slider that is in the preview?

seems to be fixed in 1.21.41 again

Still affects 1.21.50. Affected 1.21.44 as well.

Not sure if it's helpful or not, but in the process of writing an addon to work around this issue, I added a handler to catch the gamerule changed afterevent and save the change to my world data and found that when the realm was unloaded and reloaded, my saved world data was set to the original default. That tells me that the realm is actually using the /gamerule command during startup to set the game rules. So, I rewrote the add-on to add a separate UI that I manually manage instead of handling the gamerule event and it's worked great since.

If you have a workaround addon can you share it with us?

@Gyver5681 Is this something you could share? It sounds like something I'd love to use on my realm if possible.

We released a service-side fix for this on January 8th, 2025. Note that you may need to reset any settings that were cleared prior to that though. 

Also note that there is a UI bug still in our Realms Edit world screen where updating any setting can result in some gamerules being reset to the default. Our client team is working on a fix for this, but in the meantime any gamerule updates made via in game slash commands will in fact persist. 

gamerules in realms problem is still there.

Jorgeson, we confirmed that the remaining issues with gamerules is due to the UI bug mentioned below. It appears that updating any settings via the Realms Edit World menu can result in gamerules reverting to their default. Our client team will be working on a fix for this, but in the meantime, any gamerule updates made via slash commands are in fact persisting across sessions. 

Hi there @DLon King.

Hope that you are well thanks for the update on this.

Is there any timescale or timeline that you can give as to when the remaining issues for this realm ui bug will be fixed on realms

Greatly appreciate the hard work

Kind regards

I can't promise when it will be fixed, but I can confirm that we have an engineer working on it currently.