The Problem

You need to relog if you use //setbiome to see the changes.

A Solution

Don't relog and make changes appear ingame.

Alternatives

No response

Anything Else?

No response

this would require re-sending full chunks to the client with some packet hackery. don't think we have any interest in doing this.
fyi you can also just teleport away and back to get the server to resend the chunks to you.

you can also just teleport away and back to get the server to resend the chunks to you.

Why don't we just do exactly this, and provide an easy clickable message to automate this maneuver for the user? Something like this:

> //setbiome plains
 Biomes were changed for approximately 1547 blocks.
 You won't see changes until you rejoin or move away and move back.
 [T] Teleport your player away and teleport back to see changes?

(The T will show the text Click to reload your chunks)

Upon clicking, the message will set the view-distance and simulation distance of the player to the minimum, tp the player to 30million / 30million, wait 5 ticks, then tp the player back to their original position and restore their render/simulation distance?

I'm very certain that any reasonable user of the WorldEdit mod would much prefer an unelaborate dumb kludge like teleportation than a complex knarly prone-to-be-broken-by-updates packet hack.

No guarantee that the client would unload those chunks from cache immediately. I don't really see the issue with rejoining to see the changes, especially for a server where it'll take just as long as the teleport.

I am surprised by the quick response, and, rereading my prior message, I completely forgot to thank you and thank the amazing work you do for WorldEdit. So, I thank you very much.

No guarantee that the client would unload those chunks from cache immediately.

I agree that there is a race condition here and thorough testing would be needed in order to make sure such a feature would be consistent in all cases. AFAIK from my limited tests under extremely laggy conditions, the chunks do not need to be unloaded in the internal/external server, rather they only need to be re-rendered in the client. When I paste a massive schematic, put a tp command in the buffer, and another tp back here command in the buffer (which causes the two tp commands to be executed immediately one after the other when the paste finishes), the biomes are successfully reloaded visually and according to F3 (the F3 seems to draw its data from the client state, not from the server state).

I don't really see the issue with rejoining to see the changes

Two big reasons why I always avoid rejoining whenever possible (and I would assume some other people might be the same way):

• Edit history. I sometimes go through a bunch of testing before committing to a particular decision. Perform action, check it out, undo, tweak, rinse & repeat until satisfaction.
• Chat history. This is a much bigger one. Often times, I like to be able to go back and see what I did. Yes, I can just open a text file somewhere and copy every command I execute but this is a major productivity drain because it prevents rapid test-tweak-retest.

I agree that the first item is not an issue for multiplayer servers and indeed I do have several localhost paper servers running on my laptop tuned with low-latency granular thp just so that I have access to FAWE (which is a life-saver when I need to manipulate gigabyte-size schematic files), but its such a major pain to micro-manage all these servers when I need to manage world save files and move schematics between worlds (each schematic piece is developed and edited in its own world for a multitude of essential reasons) that I still do most of my editing and development in single-player worlds with normal WorldEdit.

For other people, they likely use plain old WorldEdit single player without an external server either because they don't have the technical know-how or a non-Windows-operating system to be able to practically employ a localhost Minecraft server.

Closed by 1a12db4