10-28-2016, 07:03 AM
(This post was last modified: 10-28-2016, 07:08 AM by ShadowCone.)
I guess running cuberite once will solve the problem and put the files where they need to be.
Well, screw that, I made my experiences when trying out android.
Tl;Dr: place them wherever you want.
Lets say snap placed the cuberite executable somewhere that you can run cuberite from anywhere with just calling Cuberite. (that's called the PATH variable). It's up to you where you run that cuberite executable.
Cuberite is written that it takes your location as base path. The documentations says you should run cuberite as ./Cuberite which means starting it from the same directory as cuberite itself is in.
So just go ahead, create a new empty directory, cd in it and run the cuberite binary. There you go, you have your ini files and your world.
You now may find some features not working. An example is the webadmin, as I encountered it. This is caused because cuberite is able to generate config files based on default values, but it's not able to generate everything to start from scratch. You may be able to find them somewhere in the depth of your drive, but the easiest way is to get a copy of the Server directory on github, let's say as "cuberite" in your home directory, cd in there and run cuberite from there. It's then not ./Cuberite, but it's exactly the same as if you would normally do.
At first start, cuberite might give you some red warnings. This is due to the fact that it might not find some files, generated the crucial ones, but maybe tells you no webadmin is there. It's up to you to get these files
Summarizing: get the Server directory from github or any build and run cuberite from within there. It doesn't matter where the cuberite binary is located.
Edit: cause you mentioned root running the server on startup. We'll, root is a bad idea, but I won't want to say that. The question of where to find the ini files is the same as to ask the startup script 'Where do you cd before running cuberite?'
"To the center of the pull of gravity go, and find your planet you will."
Well, screw that, I made my experiences when trying out android.
Tl;Dr: place them wherever you want.
Lets say snap placed the cuberite executable somewhere that you can run cuberite from anywhere with just calling Cuberite. (that's called the PATH variable). It's up to you where you run that cuberite executable.
Cuberite is written that it takes your location as base path. The documentations says you should run cuberite as ./Cuberite which means starting it from the same directory as cuberite itself is in.
So just go ahead, create a new empty directory, cd in it and run the cuberite binary. There you go, you have your ini files and your world.
You now may find some features not working. An example is the webadmin, as I encountered it. This is caused because cuberite is able to generate config files based on default values, but it's not able to generate everything to start from scratch. You may be able to find them somewhere in the depth of your drive, but the easiest way is to get a copy of the Server directory on github, let's say as "cuberite" in your home directory, cd in there and run cuberite from there. It's then not ./Cuberite, but it's exactly the same as if you would normally do.
At first start, cuberite might give you some red warnings. This is due to the fact that it might not find some files, generated the crucial ones, but maybe tells you no webadmin is there. It's up to you to get these files
Summarizing: get the Server directory from github or any build and run cuberite from within there. It doesn't matter where the cuberite binary is located.
Edit: cause you mentioned root running the server on startup. We'll, root is a bad idea, but I won't want to say that. The question of where to find the ini files is the same as to ask the startup script 'Where do you cd before running cuberite?'
"To the center of the pull of gravity go, and find your planet you will."