Jan 29 2021

Operations Summary – Weeks of 1/18 & 1/25/21

View post on imgur.com

Progeny Mk6 Retired After Final Mission Failure

While it was even more disappointing to see the Mk6 Block II fail at a mission given that up until this point the variant had a 100% success rate, it did drive home the fact that it is time to move beyond unguided rockets. In the mission analysis posted yesterday it was clear that had we been able to steer the rocket it could have reached up just as high as previous missions that carried lighter payloads. This greater flexibility in mission design is another plus for rockets that can guide themselves more precisely. But even had the rocket flown higher this doesn’t change the fact that it still somehow completely missed passing through the inner belt. The mission analysis posits two theories as to why and the upcoming Kerbin III mission should help us get some answers sooner rather than later.

So ends service for our longest-working rocket with 21 missions carried out over the course of 3 years. The overall success rate of the Mk6, taking into account both variants, is 71%. This beats the average success rate across all rockets, which stands at 62%. Some additional stats not available on the rocket’s page, given as [combined] (Block I/Block II):

  • Total Missions: 21 (17/4)
  • Total MET: 12h24m18s (5h17m29s/7h6m49s)
  • Average MET: 35m26s (18m40s/1h46m42s)
  • Total Payload Mass: 465kg (400kg/65kg)
  • Average Payload Mass: 12kg (12kg/10kg)
  • Total Distance Traveled: 36,328.417km (17,047.328km/19,281.089km)
  • Average Distance Traveled: 1,730km (1,002km/4,820km)
  • Longest Downrange Re-entry: 1,521km (432km/1,521km)

Progeny Mk8 & Ascension Mk3 Prepare for Debut

We have finally revealed the full blueprint for the Progeny Mk8, showing off its sleek lines and efficient, cheaper design. All the major components for the rocket are already here at KSC waiting to undergo final assembly. The static-firing of the 7 lift engines has gone well over the past two months with an incremental increase in the amount of engines in the cluster. One of the major issues with the Mk8 design was how we were going to launch it. Without being able to use fins to rest the rocket on the standard engine clamp normally used, a new system would have to be developed. Thankfully Luciole was prepared to tackle this and came up with a new launch base that could be mounted atop the Mobile Launch Platform with very little modification from use with the Ascension Mk3. Although it could only reach high enough to use one service tower, that tower plugs into the launch base’s own service structure to feed both propellant tanks on the rocket as well as provide power to the payload. Everyone is excited to see it launch later next month!

Over at the Ascension program, final preparations are now underway for the upcoming debut launch of the Mk3, with all major components of this mission also now at KSC. The rocket will be stacked vertically up to its orbital stage then roll out to the launch pad for a wet dress rehearsal. Fuel will then be offloaded and it will return to the VAB to receive its Kerbin III payload, which will then have the RTG installed and be encapsulated in its fairings. The rocket will roll out once more so the probe can go through its own checkouts and while hooked to the crew access tower it will receive thermal management to prevent the heat of the RTG from damaging components inside the enclosed fairing.

Kerbin II Mission Reaches Final Conclusion

We are happy to report that this week the RTG lost during the Kerbin II mission has at last been successfully recovered from the ocean floor, intact as expected. The power unit was finally located east of the original search area, which was designated based on working backwards from when the probe lost power to determine where the RTG fell off. Not finding it there, we next assumed that the cabling to the RTG was burned away first to cut power to the probe, then the RTG fell off sometime later. Locating it is great news not just because we don’t want to leave potential radioactive contamination lying around in the environment but that the kuudite powering these units is still a rare and expensive resource. It will be good to be able to re-use the pellets from this mission on future missions until radioactive decay renders them unusable over the next 15-20 years.

You can also now read a full analysis of the Kerbin II mission, which was published last week.

ATN Database

The latest update for the Asteroid Tracking Network database is available here, containing 6,361 asteroids and 0 updated with new observation data. Here are the 36 asteroids that were discovered this past week.

From the Desk of Drew Kerman

Out of Character Behind the Scenes stuff

Written on 1/25/21

I had a baaaad stint of procrastination recently that I thought was just de-motivation or depression as I tried to work up the urge to work on the Kerbin II mission analysis. It was all like “why bother” and “who reads this” and “it’s going to take so much time”… blah blah blah. Some of this was a bit true, I mean I have been forgetting that I need to go back and look at these mission reviews to stay on track with some of my original visions. Enough time can pass between missions that when I go to design and implement the next ones I can almost forget to do some things I said I was going to do. Certainly if I had read the Block II analysis from past missions I probably would have done this latest mission a bit differently.

The hardest thing to overcome though was having to re-create the entire mission in detail, and I was even more annoyed when I looked back at the Kerbin I analysis and realized I failed to bother doing this. If I didn’t do that for a days-long mission how was I going to handle a weeks-long mission?? Then I finally realized the difference between analysis of a mission and that of a launch, which up until now have been how all my analysis have been styled. Lots of things happen during a rocket launch that are not captured in full by the minute-to-minute tweets in the mission timeline. On the other hand, missions playing out over days and weeks progress at a slow enough pace that the tweet timelines do just fine conveying the entire story.

So while I remain committed to loading a lot of detail into The Flight section of analysis targeted at launches, for missions just an overview of the goals along with a link to the twitter timeline and Ops Summaries tagged for that mission will suffice to allow people to do their own research into how the mission played out. Then I can focus on details in the Analysis section, which is a much narrower focus on the mission requiring much less time to write about.

With that block out of the way, I managed to finish writing the Kerbin II analysis early Friday morning and I’ve now blazed through the entire next week over the following two days since. This is more the pace I’m hoping to achieve over the next few months.

Mk6 flight

For my first mission conducted in KSP 1.10.1 I was very pleased to not come across any serious issues! The only real trouble came from getting the rocket to not mass an unreasonable amount more than the last two missions due to some changes between KSP versions. Along the way doing this I discovered that the duplicate FAR wing mass settings showing up in the PAW, which prompted me to toss my 1.9.1 install at the end of last year, were actually just some double patching.

The flight failure was not planned, I was really aiming to hit the inner radiation belt at least, but it did allow me to explore in the roleplay some interesting theories on why the rocket missed. I was annoyed however at the time I spent, after realizing the rocket wouldn’t be going that high during testing, making the code more robust at handling only crossing one belt or not making it all the way through the inner belt and not have to use any of it! A pox on unguided rockets! 😛

Looking forward to conducting more operations in 1.10.1.

ATN notes

I mentioned at the end of last year I would write up more details about how the ATN operates, something I’ve been saying I would do for years, because I would soon have to get back to asteroid hunting as the six month lead time I built up when the pandemic hit last spring was about to expire. Well, turns out I almost completely forgot for the second time how I managed this aspect of the KSA roleplay. It was so bad I actually came close to considering just tossing the ATN aspect out altogether rather than try to figure out how I did it. But I persisted and gradually it all came back to me. I made copious notes this time I can reference if needed in the future, but the time it took me to get back on track and write everything down used up whatever time I would have put towards actually explaining it all. So now I’m going to have to say maybe someday I will elaborate 🙂

Update: 1/28 (this addendum is so long because I was writing it as I was doing it!)

I had to track down a persistent issue in KSP 1.5.1 in regards to SmokeScreen that I’ve been ignoring for some time now. In a previous Desk Notes I mentioned how I had to get SmokeScreen to even work properly again after it decided to stop showing the main window or particles for some reason. I got it back to the point where it would at least produce plumes that I could use for launch photos. Thankfully the rockets launching after this point were Progeny with SRBs which meant I didn’t need the full functionality of the SmokeScreen GUI to turn off smoke shortly after launch like I do for LF/O engines that don’t make smoke (the smoke is instead meant to be steam from water suppression on liftoff and is not supposed to follow the rocket up into the air).

So I needed to get the GUI working properly again for the upcoming launches. I had to dig around a bit on the SmokeScreen build server cause the author doesn’t stick to GitHub releases but finally found a version that should be fully compatible with KSP 1.5.1 based on the change notes (I had forgotten what version I last installed, and there was no version file included with the mod). I deleted the SmokeScreen folder, installed this version and started up KSP to find the GUI still wouldn’t work to show the available effects or active particle count. Stripped down to stock + RealPlume + SmokeScreen and everything looked good.

Now to figure out what was conflicting. Common practice is to start by installing half of your mods, but this is a bit more complicated because some mods have dependencies so if you just select the first half of all folders you may end up having problems in addition to or even maybe affecting the one you’re trying to track down as a result of missing dependencies. So first I went through and hand picked all the mods and their dependencies, which wasn’t much about 25 or so. Popped those in, ran the game, all good. In fact, more than good – surprisingly I noticed that my in-game performance was really good, like only a bit of yellow flickering the clock in the flight scene despite having extra 3D cloud layers and ground scatter. Usually it’s a permanent yellow clock at around 70% normal time. So a performance drop was another issue I could look into while doing this.

Now I could just batch select half the remaining folders and dump them into GameData to try again. Did so and this time when I loaded into the flight scene to check the SmokeScreen GUI, which was still fine, I found performance to be more as I am used to, with constant yellow clock and slightly stuttery movement as I pan the camera around. Of the mods I had dropped in, I figured it was either PlanetShine, which I had heard on the forums caused performance drops, or Poods OPM Visual Overhaul, which I know for some reason creates an extra EVE cloud layer for Kerbin.

Took out PoodsVO and left in PlanetShine and the performance problem went away. I took a look at why PoodsVO was creating another Kerbin cloud layer and realized that the config file included for EVE clouds was actually not an MM patch, so it wasn’t adding clouds to the existing EVE_Clouds node but adding a separate one. I fixed that and loaded the game with PoodsVO and although it no longer generated the extra Kerbin cloud layer, performance still suffered for some reason. Very odd, as the mod does nothing to Kerbin! But whatever, I don’t need it installed all the time and when it is installed for photos the performance hit won’t be an issue.

Okay cool so I managed to fix a problem I didn’t even know I had! I had always thought the poor performance was just down to EVE’s reputation for not being very efficient at volumetric cloud layers and I generally have two loaded and tweaked to be dense and visible for a large distance. I thought I was just pushing it too hard.

Right so back to SmokeScreen troubleshooting. I already did one half, now to do a second half. This second half did cause the SmokeScreen GUI to bug out. So after killing the game I just pressed Ctrl+Z in Windows Explorer to unload all the mods I had just moved over to the GameData folder from my temp folder. Next step before figuring out which of these mods is causing the problem is now to load the other half of the mods and see if there is a problem there too. No SmokeScreen problem, no performance problem.

I’m now left with just the batch of mods that are causing the issue. I have my suspicions so I take the half that doesn’t include the mods I think could be causing the problem. I was wrong, so undo that and move in the other half. Next result: GUI looks okay but for some reason the SRBs on my test vehicle no longer show particle emitters, so they are back to stock. I suspect ReStock so with the next half of mods I move in (down to just 4 now) I also remove ReStock and reload the game. Getting closer now, all engine effects are back and GUI looks fine.

Finally I narrowed it down to just 5 mods and looked in their folders for any clues. One of them had a SmokeScreen folder inside it. AUUUGGHHH!!! I never even thought about the possibility of a double install (drag & drop oopsie, basically), which would have been very easy to just check for with a folder search or a file search in the output log that records all activated mods. The only thing that makes the hours I just spent hunting this down worthwhile is the performance issue I discovered along the way really does help make using the game better.

But still… *sigh*