Terasology
Terasology copied to clipboard
Game server no longer auto-creates a given homedir (when running from binary?)
Normally I'd expect something like the following to work in an extracted game zip:
java -Xms128m -Xmx6144m -jar libs/Terasology.jar --headless --homedir=server --override-default-config=override.cfg
However, unless the server
directory exists the game server will fail to create it. This used to work - maybe we just need to tell the pathmanager real quick to make the directory if it doesn't exist yet?
As a Good First Issue consider starting by looking at PathManager.useOverrideHomePath
as I figure that's what triggers when you have -homedir
set. Although looking around a bit it seems like that PathManager should actually be attempting to create all relevant dirs? Something is awry! Help fix it :-)
If this only happens via game zip then you can build one locally using gradlew distZip
- without modules you might not get very far, but still that may be far enough. Can copy in a modules dir from a regular game zip if needed.
Edit: As a very related note instead of logs
we're getting logFileFolder_IS_UNDEFINED
which is silly. That is hopefully an easy fix in the same area
This is probably something I changed when working on the command-line handlers without asking the people who actually run the servers.
The trade-off here is that expecting the target directory to exist gives some protection from typos: if you say sever
one day instead of server
it will stop you there, instead of going ahead to start up but with none of the configuration or data you expected it to have.
And if the value is a non-absolute path like this, it'll help you notice if you expect it to resolve to /Terasology/server
but one day end up with /Terasology/facades/PC/server
because IntelliJ or something changed how it sets the working directory. (This is not a purely hypothetical example, I had something like this happen not too long ago.)
I'm not strongly opposed to changing it back to auto-creating if that fits the workflow better, just wanted to document some of the considerations here.
Okay, thanks for adding these considerations. I would say this is something we should discuss in a bigger round and just make a decision which behavior we want. If we decide to keep it as is we can note this here for future reference and close the issue. If we decide to change it back, we can also not this here for future reference and keep it open until we have a PR changing it back, then close it.
In the org meeting it was decided to keep the behavior as is and don't auto-create directories. However, there are follow-ups that need to be taken care of before this issue can be closed:
- [ ] improve error handling (proper message instead of NoSuchFileException)
- [ ] test that "default user" path does not run into the "directory not present" situation
- [ ] consider writing tests for this behavior
Is it still open? May I work on it? Can someone help me?
@pree-T Sure, go ahead, give it a try and open a PR linking this issue :slightly_smiling_face:
Thanks a lot @jdrueckert .I am relatively new to open source contribution .Will anyone please help me to fix this issue @ujjman @jdrueckert @Cervator ?
@pree-T How much programming experience in Java do you have? This is marked as a "Good First Issue" but targeting developers that want to get started with Terasology, but do already have development experience. If you don't have a lot of programming experience in Java yet, I'd recommend looking for issues in our module space instead: https://github.com/Terasology. They are more suitable for beginners.
If you do have experience, do you already have a Terasology workspace set up? If not, please have a look at https://github.com/MovingBlocks/Terasology/wiki/Contributor-Quick-Start to get you started.
In any case I'd recommend to join https://discord.gg/terasology and ask questions there.