Large schematics do not place with command block chain
facetorched opened this issue ยท 4 comments
WorldEdit Version
7.3.9
Platform Version
Fabric 0.16.9
Confirmations
- I am using the most recent Minecraft release.
- I am using a version of WorldEdit compatible with my Minecraft version.
- I am using the latest or recommended version of my platform software.
- I am NOT using a hybrid server, e.g. a server that combines Bukkit and Forge. Examples include Arclight, Mohist, and Cardboard.
- I am NOT using a fork of WorldEdit, such as FastAsyncWorldEdit (FAWE) or AsyncWorldEdit (AWE)
Bug Description
Attempting to load and place a schematic with a chain of command blocks results in Your clipboard is empty. Use //copy first.
when attempting to paste. This is because when attempting to paste, the schematic is still being loaded, (presumably in a different thread). Adding a delay (for example with repeaters) can allow enough time to load then paste.
Pressing the button a second time will successfully load the schamatic (because it has been loaded previously).
Expected Behavior
The schematic should be placed.
The conditional command blocks should not execute until the first command block has finished loading the schematic.
Alternatively, there should be a reliable way of testing if the first command block has finished. (the LastOutput tag for example)
Reproduction Steps
-
Set the config option
command-block-support=true
-
Enter in commands in order from left to right:
schematic load my_schem
placement world 0,0,0
//paste -m !air
- Set the leftmost command block to Impulse and Needs Redstone. The other two are chain, conditional and always active.
- Place a large schematic named my_schem.schem in the schematics folder
- Press the button
Anything Else?
No response
this is expected behavior. disk I/O ops (such as loading schematics) are done async so we don't block the main thread. the paste would need to be delayed to wait for that to finish.
Thanks for the clarification @wizjany . I agree that for a player, running I/O asynchronously is best. And I would be willing to agree that for command blocks this is best too. The main issue is that it is impossible to know how long to set the delay to. If the I/O thread could report when it's done, this would solve the issue.
That said, if it seems like this is outside the intended use of the mod, please change from bug to feature request.
yes, this is more likely a feature that needs to be ported from WE-CLI, which has a wait command for things like this. problem is that it's blocking, which is extremely bad for minecraft servers (as opposed to the cli which is run independent of a server). ultimately this is one of those cases where you should be using the API to automate worldedit, not command blocks.
Thanks! Was not aware of the CLI, a port of the wait function would work.
Not sure about the feasibility, but another work around would be an option on the load command for a paste callback.
I'm doing proof of concept work right now, but I may eventually move away from command blocks :)