Operations Summary – Week of 2/24/20

Written on 2/14/20

Yup another giant wall of text incoming, still so much to talk about from the Kerbin I mission. I’d like to start by again making it clear that this mission was conducted and planned in chronological order. At no point did I try something, time warp ahead to see what would happen, then revert and work up plans based on that. I could have done this, the mission was short enough, but it’s not a way of doing things that would hold up well as my missions continue to get longer and more complex. I only kept a single save file I could revert with, back to the last major mission event. Any longer and it would have just taken too much time to also roll back the command logs and telemetry.

Pretty much everything stated by @KSA_MissionCtrl in regards to mission planning is exactly how it was done. As I mentioned in the previous week’s Desk Notes there was a bit of “hand waviness” involved with waking the probe up from hibernation manually in some instances but regardless I always used wake timings based on older trajectory data that was available before the probe went into hibernation and couldn’t receive any more commands. When I planned the end mission it wasn’t done near the real end of the mission it was done exactly when it was said it was done, prior to even inserting into orbit. At no point did I work ahead then go back and change things to get any kind of desired outcome. How it all played out was based on how things in the game itself played out.

That doesn’t mean there aren’t times I have to hit the rewind button. The video showing the vessel being knocked around in the atmosphere was indeed done through the built-in real-time system that comes with KSPTOT however I unfortunately didn’t think ahead to do this during the actual passage so I reloaded the save before hand, made the recording and jumped back to the state I left at. In this case though this had nothing to do with mission planning and was just a nice way to visually communicate what was happening with the spacecraft. It’s hard sometimes when you treat the game itself as “real” so showing off actual gameplay doesn’t make sense.

One hilarious event during the mission was when I was literally in the process of composing the tweet about how the orbital insertion maneuver couldn’t fail because the vessel wasn’t programmed to point in the wrong direction – and then I realized… wait… did I actually tell it to point in the right direction??? I checked the code I had uploaded to the vessel and sure enough it was still telling it to point retrograde from the first maneuver!! I couldn’t believe I had cued myself onto a real problem while jokingly writing about it /facepalm. This is why real missions are never run by just one person…

Of course this led to the problem of having to revert to before I sent up the commands which would mean having to clean up log data and telemetry data and since this was still during the aerobrake period things wouldn’t go quite the same as they did the first time I did it, which bothered me a bit. So what I ended up doing instead is using a test save to load the commands onto the kOS unit – the file binaries are saved in the SFS file. Then I could just overwrite the file binary data of the actual Kerbin I probe with the proper maneuver instructions and not need to revert. It took a bit more effort to get right than I would have liked but in the end it worked.

When I move up to 1.8.x (or even maybe 1.9 now yeesh) I will be dropping RemoteTech in favor of the stock CommNet since that works better with Kerbalism. Right now for example the data rate for transmitting science is bugged abysmally low and it no longer costs extra EC to transmit science data. So I had to come up with my own method, using the generator part module, to add some extra EC cost to sending down photos.

Speaking of communication I was considering having a radio beacon like Sputnik did, but really didn’t want to copy off real life too much, plus I didn’t think of it in time to include it as a separate transmitter that would draw extra power. I also wanted to see if anyone would comment to KSA with the suggestion for something like it.

I’m also wondering if anyone will bring up the topic of orbital decay. I did try to use the latest compile of the orbital decay mod that would function in 1.5.1 and although I though it seemed to be working (it was giving me a “negligible” amount of decay for Kerbin I) when I modeled Kerbin I’s orbit using the decay option in KSPTOT I got a wildly different result. As much as I do want to play with orbital decay, if I can’t use KSPTOT to plan my missions properly then I will not use it. Plus it’s been almost five years since it first came out and no one has been able to pick it up and seriously make it work well, so I’m not holding out hope that it will ever happen. I was careful though not to say anywhere that decay was not a factor, I’m just treating it as something that didn’t hugely affect the spacecraft’s trajectory. So there’s some room for me to retcon and put it in at a later date – to a point. Eventually I will have to decide for good whether to have it in the game or not but still have some time.

I totally forgot that I had the possibility of part failure enabled through Kerbalism. I’m still a bit wary of the idea of game-based part failures, which is why I never installed any of the stand-alone failure mods. I see part failures more of a story-side thing rather than a gameplay thing. In other words I’ll decide when it makes sense that something should break in order to spice up the story or alter the pacing of things. The reminder came when kerbalism posted an in-game message about the antenna failing and getting fixed, this time (when it was switched off and out of range of KSC but, minor details). It did cue me into thinking about what effects the radiation belt would have on the camera’s image sensors and I actually went back and dirtied up the sunset photo I had taken prior to thinking about this.

On the topic of failures, I mistakenly sent the wrong file name for the apokee raising maneuver three times but decided to leave the command failures in the log and chalk it up as radiation damage. Similarly, I made a small mistake when uploading the deorbit burn commands that caused the probe to go straight into hibernation and used this as inspiration for a bit of mission end tension in making it seem like perhaps a fatal error had finally hit the probe. So yea, I don’t really plan this stuff ahead of time I really just write based off actions in the game most of the time.

The final mission photos were captured without me having to reload the save – which is nice because it keeps my actual cold gas usage. If I leave RCS enabled, even without connection to KSC I can manually control the probe’s orientation. I could have also left SAS on but I didn’t need to point and hold in any of the main orbital directions and using the default “stability” option was inefficient because it would attempt to stop any movement I made, so I would be fighting against it expending more RCS fuel rather than just using small puffs to start moving and letting the probe slowly drift towards the orientation I want. To help me glitch out the photos I found an aptly-named plugin for Paint.NET.

That 30s launch video I made? Yea took me about 3 hours, and that’s not because I don’t know what I’m doing by now. I had a clear plan in my head and knew how to get it done but that didn’t make it any easier. I had to work around a lot of game issues including getting the smoke particles to behave underneath the MLP for engine ignition and also the “stationary camera” in camera tools is infuriatingly not stationary at all when a vehicle is in motion. Random jitters in the rocket caused by putting lights near the towers or using the MLP caused a lot of retakes as well. I actually did not use the MLP for the shots from atop the service tower and in the wide-view after lift off. I also had to restart the game to add sound to the SRBs – never noticed since I usually play with game audio muted as I listen to music. Then after getting the takes I wanted there was the usual time-consuming process of smoothing out the stutters and time-compressing to account for slow game clock due to exacting physics calculations. As always, this is why I don’t do many videos. Still, came out nice at least.

So where’s the Viklun stage? Not saying. If it came down or comes down in an area that doesn’t have a surface installation, it will not be found – at least not anytime soon. What I will say is that I did use actual game trajectory data to see if it would have passed over Arekibo and found that it in fact did not during the time I said it was being search for with the radio telescope. I’ve also set an alarm for every single aerobrake pass so its orbital degradation has been properly handled. I’ll also say that yes, the estimated return I made was indeed wrong, but I still think it was a well-reasoned best-guess.

Overall this mission and all its accompanying necessities took way longer than I had thought it would and I’m not sure just how much of it was from learning to do a lot of new things for the first time. I wish I had kept an exact log of all my activities during the days I spent working on this mission so I could go back and determine how much time was actually spent working on it to get an idea of how difficult it might be to keep ahead on my lead time during future missions. I came into the mission with nearly 3 weeks lead time and I’m still holding at 2 weeks so even though that’s not great for a mission that only actually takes place over 4 days, I don’t think it’s too bad either. At the same time tho during this mission I did mostly nothing else besides KSP and that’s not something I’d want to always have to do.

I’m actually still stuck doing nothing but KSP because now the challenge is to get the Ops Tracker whipped up into shape to actually handle all the new demands this mission makes on it, but I’ll save all that hardship for another entry…