Minecraft Forums

Minecraft Intercontinental Railway III is posted.

Over 1.4 million blocks long. Over Mach one.

Thread link!

Minecraft Intercontinental Railway III is posted.

Over 1.4 million blocks long. Over Mach one.

Thread link!

One person. Five months of work.

The Ride: Minecraft Intercontinental Railway III

Far and away the longest, fastest single-player minecart run ever committed to video. 1.4+ million blocks long, at over the speed of sound. 1,414 kilometers/879 miles long. 360 meters per second/1,296 KPH/805 MPH/Mach 1.05. Or, basically a bullet train ride across an area wider than Texas.

How fast is The Ride? See what Mach 1+ in Minecraft looks like...

Major thanks to Nigel Stanford for granting permission to use his music - visit Nigel's website for more:

http://www.nigelstanford.com/

Have questions? Check the FAQ over at Wrecked Gamers:

http://wreckedgamers.com/content.php?cid=the_ride

Replying to my own thread to mention that I solved the problem with WorldEdit's scripting support. I created a simple script that emulates the 1.8 "/tp" command with support for rotation (pitch) and head tilt (yaw). If you could also make use of this, feel free to grab it here:

http://pastebin.com/vpSE7j5D

To use it, paste it into a text editor and save in <minecraft>/config/worldedit/craftscripts as "teleport.js" and call it with "/cs teleport.js X Y Z Rotation Yaw".

Greetings Steve-clones!

I could really use the ability to control the direction and head-tilt for Steve for a project I'm working on, but it's in 1.7.10 and the /tp command didn't get rotation/tilt parameters until one of the 1.8 snapshots and there's not a chance in hell I can move the project to 1.8.

Has anyone made a mod that can basically clone the 1.8-style teleport command (read: /tp <x> <y> <z> <rotation> <tilt>) into 1.7.10? If not, does anyone feel like giving it a go? I'd imagine I'm not the only one that could make use of such a thing...

Quote from zanix

Rsync will only copy over missing and updated files, CP will copy everything.
During a mirror sync, rsync would be faster. During a server startup, cp would be faster if the mirror directory was cleared on server stop (I don't recall if it is).

Basically, this. On Debian and Ubuntu and the derivatives thereof, the ramdisk on /dev/shm is empty on startup by default. Since there's nothing to compare against, rsync is slightly slower than cp due to the extra file check it performs, while cp can just straight-up blast bits into place.

Quote from zanix

Found the current version info url.

https://s3.amazonaws.com/Minecraft.Download/versions/versions.json

We could probably even use this to notify when there is an update or even perform auto-updates.

Indeed - the new launcher has to have a fixed reference location for version lookups (especially since it now supports having multiple jar versions in one client install), so nothing says we can't sniff that file for news on version changes.




I can't help but wonder what the point will be where we exceed what we can realistically accomplish with shell scripts and have to move to an executable, or perhaps a combination of executable and scripts. Maybe even a jar or something that can also capture console output from running servers. An intermediary executable of some sort with a well-documented API would be the best thing since sliced bread for administration...

Sorry for seemingly vanishing - I get to have two wisdom teeth extracted and they're interfering with my ability to see straight, let alone get anything accomplished. (I'm typing this with a blob of Ambesol stuffed into one of them.) I'll probably be out of pocket for another couple weeks but will be following along where possible.

Oh, another thing that we might want to ponder: monitor the crash-reports folder by storing the file count when the server starts, and if any new files appear, force-restart the server. That should (key word!) catch cases where the server blows up and hangs the Java VM without actually stopping it or reporting the crash to console. Since the crash files are date-coded in their filenames, a check for date and compare against start datetime should be a good sanity check.

The reason I mention this is that a few mods use [SEVERE]-level status logging in console for non-severe events such as non-fatal errors (despite how wrong this is) and will trigger the script's auto-restart-on-crash feature if it's enabled. (A couple use [WARNING] level to show their mod names!) Watching for a crash log should avoid this. Some of the bigger offenders here are a few mods in FTB Ultimate that check for new versions but throw a standard Java FileNotFound error (and yes it's marked as [SEVERE]) if they cannot find their remote version check files.

Quote from zanix

I think we should store per-world config variables in the server.properties file itself rather than an additional .conf file. Our values could have the prefix of mscs-.
This way we could make a function that will parse the setting and get the config and not directly inject additional and pontentially harmful bash script values into the script. setPropertiesValue() already has the code we need to make a getPropertiesValue() function.

That's not a bad idea as well, and would prevent the introduction of harmful code since we'd only be reading the file and stuffing values into variables. My only concern is the fact that Java command-line strings can be a bit long, so as long as the get function can handle a thousand-character var (at the more extreme end - usually an optimized server startup string is 200-300 characters long) that approach should work wonderfully.

Script output should be as minimal as possible, so the return values can be parsed for web control.

Another possibility, and this ties into the earlier conversation above re: return value formatting, would be to add a small formatting routine and switches (or alternate commands, which I suspect would be faster/easier at the cost of a bit of redundancy) to control the output. For example, add a "wstart" command that does what "start" does but emits specifically formatted text for an administration panel to capture. (If I had to hazard a guess I'd say we should plan to have the script emit strings in a format that PHP can work with, such as delimited strings compatible with PHP's "explode" command, JSON-compacted strings, etc.)

I'm not sure what to think about force-start...

Wow, everyone seems to be hung up on that one, hehehe...

There is a way to query Minecraft to see if its running, by using the "enable-query" and "query.port" settings in server.properties.
I use a php script to check if the server is online, as well as some other variables it can return for my website.

This might be the best approach since it takes advantage of an existing mechanism built into the server, and should be consistent on all variants (e.g., Forge, MCPC+, CraftBukkit) of the vanilla server.

I think a longer countdown is a good idea, if the user count is 0.
I made this change on my server to 1 minute so users have some time to get situated.
Maybe we can add another argument for the timeout.

The only tricky part of adding a variable warning period is how best to set up the warnings to the players. I'm picturing an idea on how to do this that I might have to test...

Quote from sandain

Ok, that works.

The runlevel changes can be reversed out - it's not a critical change.

The script should be able to run without a .conf file. If one is present, the values stored in the file can override the default values.

The reason I went with creating a blank _world_.conf instead of just running with default values is that the script is capable of running multiple server instances and thus in my opinion should not have default values. Instead, I feel that it should force the system admin to immediately create the defaults for any new instance, and not make assumptions on what to put where, which is why I have it set to throw "exit 1" at the end of the newly-created _world_.conf template to force the admin to edit the file before the server instance can be started with it.

I'll keep the SERVER_COMMAND variable around. I was just thinking that if we are going to do anything to the variables, we should do it now. Speaking of which, do we have to worry about name conflicts, should we add a MSCS_ prefix of something to all variables? Should we be worried about what is in these files? We will be essentially side loading a whole other script without any form of sanity check.

Oh, I agree that now's definitely the time to make such decisions if the per-world conf file is to be kept. While I'm all for sanity checking, I'm not sure if it would be practical - or even possible - to sanity-check a Java command-line parameter set.

As for prefixing the vars from the conf for clarity, I have no opinion on this and think it would be fine with or without it.

I think in this situation, the admin should be using the force-stop + start combo or just force-restart. I think force-start is a bad idea. I will test it on one of my live servers, but I don't know of a way to test it on a hung server.

Like I said, that command can be removed.

I'll see what I can come up with when I have the time, unless you can provide a patch against my current code base sooner.

Same - I wanted to play around with it some more but work keeps interfering with my gaming...

I'll need a snippet of the log from when a user logs in/out.

I'll check the server log when I have a spare moment and see how MCPC+ reports joins/disconnects.

Quote from sandain

That's fine. Let me just ask questions of various differences then.

-# Default-Start: 3 4 5
-# Default-Stop: 0 1 2 6
-# chkconfig: 345 50 50
+# Default-Start: 2 3 4 5
+# Default-Stop: 0 1 6
+# chkCONFIG: 345 50 50

I was never really sure I had the correct values in here, but I would like an explanation of what the changes do. Also, it looks like a s/config/CONFIG/g gone awry in chkCONFIG (and elsewhere in the diff).

Adding runlevel 2 allows starting the script without network services, which is handy for basic testing or if you want to set up a server only locally and not deploy it over a network until it's ready and be able to keep people out of it in the process. (You don't wanna know how many times I had to tell one of my admins to not try to bring up the server I was working on! ) As long as 3, 4, and 5 are in Default-Start, 2 is optional.

-LOCATION="/home/$USER_NAME"
+LOCATION="/home/$USER_NAME/actium_minecraft_server"

I assume this is a site specific modification.

It is, I simply left it in place since I live-deploy this thing.

+ # Check for a world config file. if there isn't one for this world, create a basic one
+ # and stop.
+ printf " Checking config..."
+ if [ ! -e "$LOCATION/$1.conf" ]; then
+ createWorldCONFIG $1
+ exit 1
+ fi
+
+ # Load the .conf file for this world. This will automagically insert the appropriate
+ # variables for the particular server instance that will power the world.
+ . "$LOCATION/$1.conf"

This is clever, I like it. However, I don't think that we should worry about creating a default config file; if it doesn't exist just use the default values already at the head of the script (assuming they don't get removed). If one of these conf files does exist, it should get loaded as needed to override the default values.
Also, we might want to think about what variables we want to have in this "interface". ie. SERVER_COMMAND should probably be made a local variable in the start method rather than being a global.

A few things on this:

1. Setting it to auto-create the _world_.conf is basically there so the template file can be left out of the distribution entirely without being a script-breaker. If it does auto-create a _world_.conf, it adds "exit 1" at the end of it so the instance will not be startable until the user edits it.

2. I put SERVER_COMMAND into the _world_.conf instead of making it a local because I cannot be assured that someone at Oracle, etc. won't change the preferred order for command-line arguments in Java. Also, there's more than one Java variant in the *NIX space (e.g., OpenJava) and their argument order may differ wildly from what Oracle's Java wants. Having it in _world_.conf also makes it possible to run more than one Java VM (or even run a custom VM if someone wants to really go nuts, although this strikes me as unlikely) and have each world use whatever/however.

3. As for what vars to have in there, it should only be for vars specific to a single instance of a Minecraft server that would take up more space than you'd want to use in worlds.conf, etc.

+ force-start)
+ # figure out which worlds to start.
+ WORLDS=$(checkOptionalArgument "$ALL_WORLDS" $0 $1 $2)
+
+ # Start each world requested, if not already running.
+ printf "Starting Minecraft Server(s)...\n"
+ printf "===============================\n"
+ for WORLD in $WORLDS; do
+ #if [ $(serverRunning $WORLD) -eq 0 ]; then
+ printf "$WORLD:"
+ start $WORLD
+ printf " Done.\n"
+ #else
+ # printf "$WORLD: Skipped - already running.\n"
+ #fi
+ done
+ printf "=========\n"
+ printf "Finished.\n"
+ ;;

To match other code, something like this would be more consistent:

- start)
+ start|force-start)

- if [ $(serverRunning $WORLD) -eq 0 ]; then
+ if [ $(serverRunning $WORLD) -eq 0 ] || [ "$1" = "force-start" ]; then

I know things start going wonky when you try starting an already started server, which is why I never added this option. I have not tested how this works, but I doubt that it would work as you hope and don't currently recommend this change. If force-start called force-stop prior to starting the server then sure, however that is what the force-restart|force-reload option is for.

Minecraft servers are themselves wonky, and sometimes the script will find a hung process that will satisfy the serverRunning check but is not in fact a valid running process. This is especially so if the server's in the process of crashing or has crashed but the VM hasn't blown up yet (classic example: a mod blows up during startup and stops the startup process). Basically this is only intended for use by admins to bruteforce things for testing, and should never be connected to a web interface, etc.

Hopefully Mojang will provide a workable API that can be hooked to in order to provide a more robust "is it running?" answer, and I fully expect to remove this command later (or have it removed) as the project rolls along.

- sendCommand $WORLD "say The server is about to go down."
+ printf "$WORLD: Stopping"
+ sendCommand $WORLD "say An Administrator has triggered a server shutdown. Please get somewhere safe."
+ sendCommand $WORLD "say The server is going down in 60 seconds..."
+ printf " in 60s..."
+ sleep 30
+ sendCommand $WORLD "say The server is going down in 30 seconds..."
+ printf " 30s..."
+ sleep 15
+ sendCommand $WORLD "say The server is going down in 15 seconds..."
+ printf " 15s..."
+ sleep 5
+ sendCommand $WORLD "say The server is going down in 10 seconds..."
+ printf " 10s..."
+ sleep 5
+ sendCommand $WORLD "say The server is going down in 5 seconds..."
sendCommand $WORLD "save-all"
sendCommand $WORLD "save-off"
- sendCommand $WORLD "say The server is going down in 5 seconds..."
+ printf " 5s..."
sleep 5
+ printf " stopping..."

Hmmm. I will need to think about this. What if an auto shut down sequence has been started on the server due to a battery backup running out of juice? Do we really want to force an additional minute onto the shut down sequence? If you can convince me this change is necessary, then we should make it so that this is only done when the user count for the world is > 0.

Have 20/50/100 users suddenly scream at you over Mumble about how you took the server down with only five seconds' warning while they were in the middle of 20/50/100 different things, and you'll understand why I stretched out the time to one minute.

Players do not want sudden shutdowns with not nearly enough warning to finish the fight they're in, get to a safe spot, port back to their spawn or home point, mine that diamond (or worse, obsidian) block they're whacking at with a pickaxe, etc. And they are very vocal about it.

Having the time stretch only when players are connected sounds like the smart way to do it - no need to delay at all if the server's empty, just drop or restart it.

Oh, that reminds me... the line in the status commanf that reports the number of users on the server (printf "running (%d users online), with PIDs $PID_JAVA (Java) and $PID_SCREEN (Screen).\n" $(cat $WORLDS_LOCATION/$WORLD.users | wc -l) ) reports zero regardless of actual player count with the MCPC+ Legacy 1.4.7 server jar running Feed the Beast Ultimate 1.1.2. Something may be wrong with, or need to be added to, checkForLogin to support nonstandard server jars.

- printf "Starting Minecraft Server:"
+ printf "Starting Minecraft Server(s)...\n"
+ printf "===============================\n"
for WORLD in $WORLDS; do
if [ $(serverRunning $WORLD) -eq 0 ]; then
- printf " $WORLD"
+ printf "$WORLD:"
start $WORLD
+ printf " Done.\n"
+ else
+ printf "$WORLD: Skipped - already running.\n"
fi
done
- printf "\n"
+ printf "=========\n"
+ printf "Finished.\n"

This new style of output breaks Debian policy (not that the script is fully compliant, I just noticed that it is missing a period at the end of the line and some options produce more than one line of output):

http://www.debian.or...ch-opersys.html

I didn't go for any specific coding or reporting convention, since we can work out all those details. I suspect what we'll need to do for consistency's sake is roll a small routine to format (as required/desired) and printf the text we want the way we want it, and have it handle auto-linebreaking to stop wrapping lines, add verbose/terse reporting options, etc. etc. etc. Something like that could make it pretty straightforward to add compliance with any policy or formatting we want without having to do largescale rewrites to make it happen. It'd be a few more lines of code than just printf-ing everything, but it'd make things prettier, and could be useful for web ineterfacing, etc.

That is enough questions/comments for now. I'd like to tackle these before I even start to look at the backup changes since they are more complicated. Thanks for your work!

You're the one whose work needs some more love - all i did was make a mess outta your and zanix's code!

Quote from sandain

Yes, I am the same sandain on github. I've created a repo there that has my current version as the base. I've been looking over your work, and I have addressed a couple of the minor changes that you did (mainly formating). I will continue to work on merging the two scripts as I review your code. Do you happen to have smaller single-change type of patches that I could review instead?

ps: I'm used to using RapidSVN as a gui to subversion. Is there anything similar for git? I think I have the command line stuff down, but sometimes a gui is so much easier...

Sorry, only one giant heavily-edited version since I literally edited it to suit an existing MC server install. I have a propensity toward commenting my code extensively so hopefully what I did will at least seem reasonable.

All things considered, I'd say the most relaxed licensing you can apply without going public domain (which even removes Copyrights) would probably be your best bet. So, what you have there works for me for one.

As for Git/SourceForge/etc., personally I've found Git to be easier to work with than Subversion, and the developer interfaces for both website and client (for Windows, anyway) are very easy to work with. It's entirely possible to develop Linux scripts like this entirely within Windows (using Git as the repo and Notepad++ or any other text editor that understands UNIX linebreak conventions) and still have them actually work on Linux, which is amazing in its own right.

That having been said, I'm flexible - I've got space on Git, as does zanix, and you apparently have SF space, so if we want to come to a quorum on where to host it and just run from there I'm in.


EDIT: Are you the same "sandain" on Git? If so I'll add you to the access list on my implementation of the script.

Quote from zanix

Awesome, I'll get to script writing when I get the chance.
After testing your modifications, I think I'll have a few more ideas to add in.

I've started working on a restore interface that lists the rdiff-backup backups and lets you pick which one to restore from.
I should probably add it as a feature request in the github issue queue...

That would be wonderful, and should be adaptable to support rollbacks from archives as well since both backup methods are triggered by the same command. Since you've already started, want the assignment on Git?

Aaaand it's up on Git!

Visit the MSCS repository on Git:
https://github.com/W...erControlScript

Download the latest build from Git, as a ZIP file:
https://github.com/W...hive/master.zip
Or, create a directory on your Linux machine and clone the repo:

git clone https://github.com/WebMaka/MinecraftServerControlScript.git

At the bare minimum, you'll need the actual script, minecraft_server, and the world-configuration template file, template.conf. Or, skip template.conf and have the script create a world.conf for your world the first time you try to start it! (Check out ftb_ultimate.conf for a real-world example world.conf for my Feed the Beast Ultimate 1.1.2 server running on Ubuntu 13.04.)


I fully expect there to be bugs, so be sure to make use of the issue reporting system on Git so the bugs can be squished.



Aside: zanix has been added as a contributor - if anyone else wants in, please let me know!

Quote from zanix

I think the ability to allow only certain worlds to run on RAM disk would be a good idea.
As for beta testing, I usually do all my edits on a virtual box with roughly the same setup as my live server. Makes for a great beta testing environment.

I usually do virtuals for development but my principal development environment is Windows, and thus I don't have the setup to do so in Linux. The only box I have with Linux on it is the live server.

On a side note, I moved mirroring to per-server and added another command: scheduled-restart. Cron it and it'll simply do a scheduled restart of a given server instance, announcing the pending restart to players at 10 & 5 minutes, then at 60, 30, 15, 10, and 5 seconds before. IOW it's just "restart" with a longer pre-restart delay and more announcements, and is intended specifically to be used to regularly restart a server that gets laggy when run too long.