You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
this pull request adds a new copy_to argument to the createworld command, allowing scripters to specify custom destination folder paths. this fixes pathing conflicts when initializing or copying worlds into modern datapack dimension subdirectories (eg, world/dimensions/minecraft/...).
Problem
when using createworld with copy_from, we previously locked the file destination path directly to the server root using Bukkit.getWorldContainer() plus the world name; with modern vanilla and Paper datapack dimensions, Bukkit initializes the dimension inside nested subfolders while Denizen was copying files to the root directory, completely ignoring the template files. the strict forbiddenSymbols security check was rejecting any paths containing forward slashes (/), stopping scripters from passing normalized subdirectories entirely also which is going to be very necessary with world path formatting.
Testing
Tested on the latest supported patch-versions
Verified copy_to correctly redirects file operations and lock cleanup (eg, uid.dat, session.lock) to the custom folder path while preserving standard Bukkit world registration
used various testing examples:
This seems wrong at a fundamental level. Path should be implicit from data input and logical process from there.
(In old code this is literally root/{name}, in new Minecraft ... I don't know the exact rules, but something like root/{name}/dimensions/{dimension}?)
Remember that createworld is also the load world command, and also the create without copying anything command. It needs to work equally and beautifully for all cases.
(In old code this is literally root/{name}, in new Minecraft ... I don't know the exact rules, but something like root/{name}/dimensions/{dimension}?
the new layout is actually why I added the : handling here; with the 26.1 world storage changes, namespaced dimensions get stored under the world's folder as dimensions/<namespace>/<dimension>. eg, minecraft:lasagna would be world/dimensions/minecraft/lasagna, rather than just root/minecraft:lasagna; mwthorn's thread has another example.
should i check if they specify the namespace, handle it differently for >26.1, or something else?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
this pull request adds a new
copy_toargument to thecreateworldcommand, allowing scripters to specify custom destination folder paths. this fixes pathing conflicts when initializing or copying worlds into modern datapack dimension subdirectories (eg,world/dimensions/minecraft/...).Problem
when using
createworldwithcopy_from, we previously locked the file destination path directly to the server root usingBukkit.getWorldContainer()plus the world name; with modern vanilla and Paper datapack dimensions, Bukkit initializes the dimension inside nested subfolders while Denizen was copying files to the root directory, completely ignoring the template files. the strictforbiddenSymbolssecurity check was rejecting any paths containing forward slashes (/), stopping scripters from passing normalized subdirectories entirely also which is going to be very necessary with world path formatting.Testing
copy_tocorrectly redirects file operations and lock cleanup (eg,uid.dat,session.lock) to the custom folder path while preserving standard Bukkit world registrationused various testing examples:
~createworld test_dimension copy_from:my_template copy_to:world/dimensions/minecraft/test_dimension~createworld mwtown_city copy_from:world/dimensions/minecraft/the_end environment:THE_END copy_to:world/dimensions/something/mwtown_city;here's a startup log referencing this test with tags parsed for verification:
https://files.behr.dev/file-share/createworld-copy-to-branch-latest.log
A working build of my latest successful build which has no errors can be built with this branch or found at:
https://files.behr.dev/file-share/denizen-createworld-copy-to.jar