Jump to content

Jim DiGriz

Members
  • Posts

    429
  • Joined

  • Last visited

Everything posted by Jim DiGriz

  1. I had a refueling rescue mission end horribly with the rescuer winding up out of fuel and going into a spin over the ocean, and since then have included decouplers and parachutes. I did a return trip from a space station using a two-seater and when that went into a spin I ejected and the parachutes deploying ripped the capsules apart and had another fatality, so now that configuration gets parachutes on both capsules.
  2. From Kerbin's reference frame (again not assuming game physics, but assuming special relativity), it really does take 130 Kerbin years for it to get there. It is *also* going to take another 130 years for any signal to get back to Kerbin, so the round trip would be 260 years for anyone who waiting on Kerbin. Assuming the decoupler instantly turns around and comes back, though, then it will have only taken the decoupler another 17 seconds to travel back to Kerbin. In special relativity, the shortest distance between two points isn't a straight line, the *longest* distance between two points is an unaccelerated reference frame (straight line). Here, though, "longest" is the time spent getting between those two points in seconds, not distance in meters. If you graph the two trajectories out: time | B | |\ | | \ | | \ | | / | | / | |/ | A +--------------- space We look at that and it looks like the crooked path is clearly longer. But in SR, rulers are wonky and there's only 17 ticks on the two legs out and back, while there are 260 * 86400 * 365, roughly, ticks on the straight line between A and B. The "ruler" here, though, is a clock making those two trips. And the difference is that one of the clocks goes out and back and the path is not straight. If the decoupler never decelerated then you've got two straight lines and the situation is symmetric and Kerbal observes clocks on the decoupler as running slow as it goes away at nearly light speed, while the decoupler observes clocks on Kerbin as running slow as Kerbin retreats at nearly light speed.
  3. If you pretend the 17 seconds is in the accelerated reference frame (in other words, the decoupler experienced 17 seconds of time getting from point A to while it took 130 years back on Kerbal for the decoupler to travel that far (which doesn't work because I'm sure you can shift the view back to Kerbal and only 17 seconds have gone by there -- but lets pretend), then the Lorentz factor is going to be that ratio, or 241317470. Solving for velocity it would be 0.9999999979c. If I've got it right, a super-duper collider accelerating protons that fast would have 226 PeV (226,000 TeV) per beam. Compare to the LHCs 4 TeV beams in 2012 and the coming upgrade to 6.5 TeV... If you point two of those things at each other maybe you can discover if string theory is correct or not...
  4. Ran into this issue tonight and a stupid f9 lost me a few days -- although I kinda was thinking of cleaning house anyway... Anyway, I use Linux and wrote this script to run every 5 minutes out of cron and commit any changes to a git repository. I even set up a remote git repo on my cloud server (which is then backed up to s3) so that I've now even got offsite backups in case my apartment burns down or something. If you need to ask what git is, or how to restore from git, or how to make it work on Mac or Windows this probably isn't for you... I tried creating a git repo directly in the kerbal save folder, but the .git directory made KSP confused, so I had to use the approach of rsync'ing the changes to a mirror directory which is a git repo. Since all the save files are text this approach should work reasonably well, but it will grow without bounds, and you'd need to google how to prune and garbage collect your git history to get rid of really old save files, I can never remember how to do that... I suppose you could get corrupted checkpoints as well if you happen to take a rsync snapshot right in the middle of KSP doing a save, but chances of that are low and you'll have snapshots on either side that you could restore from. I've tested this for about 20 minutes, so wear a helmet... Hope it helps out anyone who hits this problem and had a similar idea, though.. #!/bin/bash # # drop this script into ~/bin/kerbal-autocommit # # 1. apt-get install git rsync # 2. mkdir ~/.kerbalbackups # 3. git init ~/.kerbalbackups # 3. crontab -e # # append the following line for once-per-five-minute backups # # */5 * * * * $HOME/bin/kerbal-autocommit # set -e set -x GIT_DIR="$HOME/.kerbalbackups" KERBAL_DIR="$HOME/.local/share/Steam/SteamApps/common/Kerbal Space Program/saves" function has_untracked_files { git status --porcelain 2>/dev/null | grep "^??" } function is_dirty { [[ $(git diff --shortstat 2> /dev/null | tail -n1) != "" ]] } cd "$GIT_DIR" rsync -av --delete "$KERBAL_DIR" "$GIT_DIR" || true if has_untracked_files || is_dirty; then git add . git commit -m "update for $(date)" # comment out this next line if you haven't setup a repo on github or wherever and # only want to keep local history git push origin master || true fi
×
×
  • Create New...