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.
0
Minecraft Intercontinental Railway III is posted.
Over 1.4 million blocks long. Over Mach one.
Thread link!
0
Minecraft Intercontinental Railway III is posted.
Over 1.4 million blocks long. Over Mach one.
Thread link!
0
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
0
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".
0
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...
0
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.
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...
0
0
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.
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.
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.)
Wow, everyone seems to be hung up on that one, hehehe...
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.
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...
0
The runlevel changes can be reversed out - it's not a critical change.
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.
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.
Like I said, that command can be removed.
Same - I wanted to play around with it some more but work keeps interfering with my gaming...
I'll check the server log when I have a spare moment and see how MCPC+ reports joins/disconnects.
0
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!
It is, I simply left it in place since I live-deploy this thing.
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.
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.
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.
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.
You're the one whose work needs some more love - all i did was make a mess outta your and zanix's code!
0
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.
0
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.
0
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?
0
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:
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!
0
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.