Good Morning from my Robotics Lab! This is Shadow_8472, and today I am following up on last week’s topic and actually bouncing the game Kerbal Space Program (KSP) back and forth across a couple computers. Let’s get started!
Project Introduction
KSP is a rocket simulator. Rsync is an advanced copy tool. I don’t understand rsync well enough to use it to its full potential, but this week I’m answering three questions in order: 1. Is the project possible? 2. Is the project feasible? 3. Is the project optimizable?
The goal is a smooth transition from one computer to another. When I need to move, I just save/quit my game, move to the other computer, and start/continue playing. To do this, I’m copying them to a network share they both have mounted, as a third workstation would make for a messy network trying to move it around ad-hawk.
Project Possibility
The main goal here is to get my game running on a different computer, regardless of how ugly the process looks or how long it takes, and ugly it looked and long it took! It’s understandable though. First time moving everything will be from scratch, but after that some noticeable speed up should take place because it should only need to copy the changes between files.
Besides taking longer than I’d consider feasible, my game also crashed, locking up Derpy, a workstation I want to play on. The window dressing appeared, but I coldn’t move my mouse or bring up a TTY terminal with CTRL+ALT+<Function keys 1-6>. I had an existing SSH (Secure Shell) connection, and the top command told me KSP was trying to run, even though I kept trying to shut it down with kill, even with sudo. I wasn’t even given an error. I stumbled across using a -9 flag for kill -9. That worked, but I have yet to understand why. Presumably it’s a little more strongly worded way to stop a program.
My exploration an hour or so later was interrupted by an unexpected success. My game launched, I took a rocket to orbit, confirmed it had enough dv to complete its mission, and I saved and quit.
Is the project possible? YES!
Project Feasibility
The next step was to go back and forth a few times. In my previous step, I had difficulty finding my game ended up inside my existing game directory instead of syncing to it. I did the same thing again my first attempt trying to retrieve it from Derpy, and it took just as long as the first time.
My second attempt started with a successful synchronization from Derpy to the network share with the inclusion of the –delete flag in case a file is ever removed. I errered on the side of caution and made a copy of my KSP directory inside another directory I called KSPLand. Good thing I did. The way I set up rsync, the second phase of copying wiped out my backup and stuffed the game directly into KSPLand instead of KSPLand/Kerbal\ Space\ Program/. I’m attributing this to oversight to trailing slashes at the end of file paths. I would have said I just had a lack of caution, but at least I didn’t wipe out my other games!
Attempt 2.1 went much more smoothly. I compared the exact commands and eliminated the offending slash. I briefly got confused looking through my real game directory and saw one of those recursive copies. This back and forth is mentally exhausting, but it eventually went through.
Rsync Sandbox
At this point, I backed out and made a directory where I can practice rsync without it taking half an hour to reset. In it, I made two directories representing my two workstations. In each of those, I made a notKSP directory with files named after the numbers 1-10 as well as an “innocent” game directory I didn’t want messed with.I lined up a dozen possible variations controlling for my file path ending in path/notKSP is followed by nothing, a /, or /* as well as my destination’s path, path/, path/notKSP, and path/notKSP/. I made a chart by using the –dry run flag. About half of them appeared to work, but to my surprise, the actual runs didn’t match up.
All my source path/notKSP/* got the data over, but nothing was ever deleted. Also, trailing /’s on the destination directory didn’t affect my results. The frustrating part is that I had four commands (two if I ignore destination trailing /’s) give me exactly what I want, and they’re each a single / each away from an unsatisfactory command: rsync -avh –delete source/notKSP/ destination/ will add notKSP to destination and make sure it’s the same while rsync -avh –delete source/notKSP destination/ will make sure the final directory in destination/ contains notKSP and nothing else.
In my opinion, the safest form of using rsync is rsync -avh –delete source/notKSP/ destination/notKSP/ because if I mess it up and forget the trailing /, I end up with Russian nesting directories and have to fish a freshly created copy out of the directory it was supposed to update. Furthermore, tab to complete prefers to add those trailing / characters [unless an extended directory name is present] and I can specify an alternate directory name for the destination should I choose as I discovered while conducting another test in my rsync sandbox.
Project Feasibility Cont.
For how useful the –delete flag is for rsync, it oddly doesn’t have a single-character shortcut. Otherwise, I would have written about implementing it here. There exists a –del alias, but I’ll pass for now.
With a properly calibrated rsync command, I ran a dry-run to the network share from my tower to the network share. Where I previously had a wall of text detailing all game files being compared, I now only had a few files –many of which were deleting a test game I had purposely planted for later deletion– totaling to a mere 1.69 megabytes as opposed to the 3 gigabytes of the full game. Even over Wi-Fi, I was done in seconds.
Is the project feasible? YES!
Project Optimizeability
As long as the possibility remains that a single character can blow a hand-entered command, I won’t be comfortable. The plan from here is to curate a set of four commands and plant them in scripts so I don’t have to retype them each time. One thing is for sure: I’ll be keeping the container directories until I have my scripts working.
I’ll probably set each one up in a script and use the appropriate one when I need it. A more complex script might automatically pull any changes from the NAS when I start and push them when I’m done. Once feature creep sets in, I might as well add checks for if the share is down, or if I even need to sync at all. It might even be useful to add a hidden file next to the directory in the share to track who has the game open and error out if I try to open it twice. But then again, those are all dreams. I’d only go to that extent if/when I give the same treatment to my other entries in my offline/LAN compatible Steam library.
Is the project optimizable? The sky’s the limit, and I don’t have a rocket.
Takeaway
As I worked, I learned a bit more about the command line. For example, I discovered how much easier it is working with multiple terminals in the same window. I also learned that ls will let you peer into multiple directories at once. When a directory is deleted and a backup restored, the normally useless command cd . will update your terminal from trying to look at the deleted directory to the new one. I was able to work on my rsync commands in one terminal, view results in another, and use a third one to reset between trials. With a little working, I got my two accessory terminals down to a single line each with a little help from the && operator to run multiple commands at once.
Final Question
While working on the verification step, I was running out of time to post and declared victory a little prematurely. I had trouble with my rsync NAS to Derpy dry run looking like a full loadout. Something I did goofed the metadata. Have you ever declared victory early?
