Minecraft Intercontinental Railway III is posted.
Over 1.4 million blocks long. Over Mach one.
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:
Have questions? Check the FAQ over at Wrecked Gamers:
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:
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".
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...
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).
Found the current version info url.
We could probably even use this to notify when there is an update or even perform auto-updates.
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.
Script output should be as minimal as possible, so the return values can be parsed for web control.
I'm not sure what to think about force-start...
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.
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 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.
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.
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.
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.
I'll need a snippet of the log from when a user logs in/out.
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).
I assume this is a site specific modification.
+ # 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.
+ 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.
- 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.
- 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):
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!
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...
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...
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.
After this, a normal-speed cart ride feels like it's on a potato...
Anyway, 49 hours at 8 m/s, and given that the minimally-compressed video (720p60, CBR H264 @ 20mbps) was 7.5GB, let's say about 380GB for a rough guesstimate if it were a normal cart ride. (Youtube would likely mash it down to like 100GB after transcoding to grainy 4mbps VBR, but still.)
The Ride is slightly longer than Texas at its widest point.
I have a FAQ page up with more details, including mod info, how it was built, etc. Linky: http://www.wreckedgamers.com/?cid=the_ride
As for a downloadable map, the save file set is just a touch over 60GB. I haven't found a host for something that big that doesn't want crazy coin for the bandwidth, but I am open to suggestions.
Pretty close on those calculations - 1,414,213 blocks / 8 blocks per second / 3600 seconds in an hour works out to 49 hours at 8m/s. It took just over a week to ride-test the track from beginning to end and fix issues. (Track cutting under lakes + running water washes off tracks = ugh...)
This could not be built by hand by one person. The time requirements stretch well into multiple tens of years to do it by hand. If one were to mine and smelt the iron for the rails, it would take eight furnaces running nonstop for just under a year to smelt the million iron bars the tracks would require.
Oh, also, air wasn't pasted or it'd have cut a giant square out of the terrain since the track runs diagonally. Additional trickery was needed to coax WorldEdit into cutting out or boring through only what needed to be cut or bored.
The track was laid by using AutoHotKey to automate commands sent to WorldEdit, coupled with custom WorldEdit scripting to add pitch and rotation to 1.7.x's /teleport command. (Pitch/rotation were added in I believe the third 1.8 snapshot.) Even with automation, it took almost a month to lay the track segments, in large part because it took Minecraft 30-40 seconds to load all visible chunks and render the world.
This is a solo project. Only one person worked on it and everything except the actual recording was performed on one PC in single-player. (The map was copied over to two other PCs to accelerate the video recording process.)
Finding the sweet spot between fast, too fast, and not fast enough was not easy. 360m/s was eventually the winner because it kept the total length under an hour while not being so fast that everything zipped by in a blur.