Allow root/parent folder for heightmap folder
braceyourself07 opened this issue ยท 7 comments
What feature do you want to see added?
In config.yml
there is Paths.heightmap: "heightmap"
indicating a folder that contains png images of heightmaps. You can utilize these files to make a height brush with the command:
//brush height file://cliff.png
And FAWE will respond with the confirmation "Equipped brush height"
I run multiple servers and would like to only have one heightmap repository. So I would like to be able to put this in config.yml
:
Paths.heightmap: "/heightmap"
(I have a folder called "heightmap" that is mounted in each server's root folder, all pointing to the same directory). But it will not recognize it.
I understand that it is likely set up this way for safety, but for running several building servers it would be a lot more effective if I could have all of the servers read from the same parent folder.
Are there any alternatives?
I'm going to experiment with symlinked folders in the /plugins/FastAsyncWorldEdit
folder to point to a folder outside of the server root. But it would be convenient to just have the ability to do it in config.yml
Anything else?
No response
You know I didn't even think to try that. Using /schematics
worked, so I assumed it would work with heightmap. I'll give it a go and report back.
I don't see a setting to allow symbolic links in worldedit-config. Our individual servers are each on their own container (using pterodactyl) and we have any shared folders mounted. Looking in the server container I don't see any symlinks, so I don't know if that's the method it's using to mount that folder. But using /schematics
in worldedit-config.yml does work and all the servers point to a common schematic folder.
I'm assuming it's that it's a symbolic link meaning it's not working. Is it a hard or soft link?
No response - Using a (hard)-symlinked folder inside the FastAsyncWorldEdit folder would be the best bet. In the worst case (especially due to misconfiguration), files could be exposed which should not be exposed - or worse, vulnerabilities like path traversal attacks could be introduced (especially with ../path
)