How to specify where a world is saved?

[ryansheehan]

After this commit I can no longer specify where worlds get saved. Is there a new way to specify where to save a world when it gets created?

[4dnr3w]

bumped as I am struggling to put my previous .wld in to the updated docker

[ryansheehan]

As far as I can tell, the world path is now hard coded. It was nice to be able to group the save file with the config.

[hakusaro]

It was removed because it was hard crashing instead of working.

[ColinBohn]

It looks like the commit you linked has some advice:
Removed -worldpath because you should now just use -world with the full file path

Is using -world with the full path to the world file not currently working?

[ryansheehan]

The problem with -world is that if a world does not exist the server still tries to start and just hangs. The nice thing about -worldpath, especially for a docker setup, was that it provided a direction for where new worlds get created and can be volumed into the host machine. It's a bit more of an inconvenience now for docker because the command becomes quite large having to directly specify the fully qualified path.

It's not the end of the world. I have published a new container and instructions to specify the full hardcoded path. It's just a little more painful to use. Not sure why hard coding the path to .wld files does to improve the server.

[hakusaro]

@ryansheehan it was implemented at the TShock level but it should really have been lower in the API. More broadly we’d love to have an official Docker process. If you want to contribute your Dockerfile and port a build system to actions we would be more than happy to carry on with maintenance.

[QuiCM]

The problem with -world is that if a world does not exist the server still tries to start and just hangs. The nice thing about -worldpath, especially for a docker setup, was that it provided a direction for where new worlds get created and can be volumed into the host machine. It's a bit more of an inconvenience now for docker because the command becomes quite large having to directly specify the fully qualified path.

It's not the end of the world. I have published a new container and instructions to specify the full hardcoded path. It's just a little more painful to use. Not sure why hard coding the path to .wld files does to improve the server.

I believe if you use -world as well as the -autocreate(?) flag then it will generate a new world should the path specified not exist. If the world does exist, it will load it. Not exactly intuitive unfortunately, but the best we can get for the moment

[ryansheehan]

Unfortunately the autocreate flag misses a lot of the options the interactive provides. For now, I've updated the container and docs for proper volume setup. I'll take a look at creating a container directly from source to contribute.

…

On Fri, May 22, 2020 at 10:42 PM Chris ***@***.***> wrote: The problem with -world is that if a world does not exist the server still tries to start and just hangs. The nice thing about -worldpath, especially for a docker setup, was that it provided a direction for where new worlds get created and can be volumed into the host machine. It's a bit more of an inconvenience now for docker because the command becomes quite large having to directly specify the fully qualified path. It's not the end of the world. I have published a new container and instructions to specify the full hardcoded path. It's just a little more painful to use. Not sure why hard coding the path to .wld files does to improve the server. I believe if you use -world as well as the -autocreate(?) flag then it will generate a new world should the path specified not exist. If the world does exist, it will load it. Not exactly intuitive unfortunately, but the best we can get for the moment — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1835 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB46ER6AM4G7Z3WH7I3G4TTRS5A3HANCNFSM4NG4KCSA> .