Our hackerspace is using a Python Wrapper that leverages the API when it calls the Minecraft jar. The server.config file wants java and java arguments, but is there a way to start the Minecraft jar gracefully with python through the gui after properly formating the run argument?
MineOS pretty is restricted to java-based jars, so you won’t be able to invoke servers that are c++ based, Python-wrapped, etc.
If you can provide any additional information about the python wrapper you’re using, we can judge what functionality of MineOS still can be be co-used alongside your Python wrapped server, but for the most part, it’s likely limited to backup/archive/restore (and not start/stop/console).
Via Email from Buddy:
I copy the content of the Python API (e.g.CaesarWrap) to the root of “/var/games/minecraft/servers/minecraft_1_8/”, then execute
“/var/games/minecraft/servers/minecraft_1_8/mc.py var/games/minecraft/servers/minecraft_1_8/settings.ini”.This script sets up a creative zone on a survival server.It is a work in progress and being developed by a member of our hackerspace Unallocated Space.
Minecraft Wrapper - GitHub - Crypt0s/CaesarWrap: A Minecraft wrapper script which provides a lot of easy functionality and not is being actively maintained.
I looked at the source code for this git and a few things come to immediate attention.
Firstly, the python wrapper uses the following code:
p = subprocess.Popen('java -Xmx1024M -Xms1024M -jar '+mc_location,
stdin=subprocess.PIPE,
stdout=subprocess.PIPE,
stderr=subprocess.PIPE,
shell=True)
The thing about subprocess.Popen is that it makes the newly-created java instance a child process to the master one. That means the successful running of the server depends precisely on the python process running ‘mc.py’. If anything were to happen to mc.py’s process, such as it stalls or crashes, your server would be inaccessible.
The screen method that MineOS uses mitigates this issue. By invoking screen, the screen/Minecraft instance is forked and orphaned–so that even if the web-ui crashes, the screen/javajar runs uninterrupted.
Of course, choosing between one or the other has massive design consequences:
screen method.
- [pro] java jar’s are double-forked and run independently of parent calling process failure
- [pro] users can attach to the screen remotely/locally and act as if they were at the original console
- [con] sending messages TO an instance requires a convoluted CLI command, which I also think restricts input to ASCII.
subprocess.popen method
- [big pro] transmission to open PIPE is unrestricted
- [con] cannot connect to PIPE from external program without programming an outside interface
- [con] child process dependent on parent
Predictions
The only way I can see this wrapped-server being accessible to MineOS is if the script is retro-fitted to work with screen, but that may also pretty much deny all the benefits you have from your custom-plugins (by forcing all your content to be channeled through screen stuffing), so this is unlikely a favorable option.
It wouldn’t be hard to make it so that you have control over what command is run from MineOS (in fact, it’s pretty easy), but it won’t make the server “compatible” with the web-ui insofar that MineOS still gets all the PIDs from java and memory usage by deducing the live servers via their screen instance “mc-servername”.
I’m thinking this over still to see where there might be middle ground.