«

»

Mar 13 2020

Operations Summary – Week of 3/9/20

View post on imgur.com

Engine Swap Reschedules Kerbed Mission for Next Week

Captain Jebediah, much to his frustration, saw further setbacks on his attempts to reach space this week when the K2-X engine failed to throttle up properly to lift off thrust of 1.2 TWR. Coming up short at 1.18, the rocket would have had enough thrust to clear the pad but the lack of throttle control could be a hint of a larger problem, one that could have affected throttle later in flight and potentially failed to allow for enough thrust to push the rocket out of the atmosphere. So although the malfunction was not life-threatening we certainly don’t want to waste an entire rocket in failing to achieve the primary mission goal of putting another kerbal in space.

A second attempt was made with similar results and the launch then had to be scrubbed due to the capsule having remained on battery power for too long by that point and it did not have enough power to carry out the mission within safety margins. The rocket was drained of propellant, lowered and returned to the VAB so that the engine could be inspected. Lead Engineer Simon reported today that they will have to break it down for a closer look, which could delay the mission by as much as a month. Thankfully we already have the engine slated for Bob’s mission in April, which was test fired just last week. Simon feels confident that his VAB crew can swap the engines out in time for another attempt at the end of next week, so launch has been rescheduled to 3/20 @ 16:10 UTC.

Alaba Encounters Mun for 34th Time

The encounter of Alaba with Mun this past week was significant because last month updated trajectory analysis moved the date of this encounter from the original prediction of 3/17 made late last year to 3/10 instead. The new 3/10 prediction held true and confirmed that the updated modeling now in use with the latest version of KSPTOT is accurate. This is great news because astronomers are now tasked with making a new long-term encounter prediction of the moonlet and have greater confidence in propagating the orbit out to the end of this year. We’ll see their results later this month. Meanwhile the next scheduled encounter of Mun and Alaba is set to occur on 4/4.

Commercial Expansion Project Reaches Milestone

Work continues apace for the commercial expansion project that will turn KSC into a regional hub for cargo air traffic serving Umbarg. The vital link that will allow freight to be shipped to/from KSC was completed today after 4 months of digging through 45km of soft ground. The railway tunnel (see gallery above) will allow for a higher volume than the road tunnel and the rail station is now the next thing that will begin construction. Also currently being worked on are the new taxiways, runway and inner tarmac. These should all be completed by May, at which time the tarmacs adjacent to KSC will already be under construction as well. The entire project’s main construction phase is scheduled to wrap up by August with facilities set to be fully operational by the end of the year.

ATN Database

The latest update for the Asteroid Tracking Network database is available here, containing 4,857 asteroids and 2 updated with new observation data. Here are the 28 asteroids that were discovered this past week.

From the Desk of Drew Kerman

Out of Character Behind the Scenes stuff

Written on 3/6/20

Three days from my last Desk Notes? That’s more like it. Altho….

Deuce weather flight

I actually intended to fly this myself but KSP v1.8.1 was giving me so much trouble I decided it wasn’t worth it yet, then I also realized I can’t take Jeb out of quarantine and Val has no additional flight crew to work with. I considered having her make the flight solo since the aircraft can be piloted solo but given it’s a kind of dangerous flight over water into a storm (well, over I guess now that dropsondes are a thing but still) I didn’t consider that a prudent decision. I did consider having Helta happen to be at KSC for some reason but ultimately just decided to forego the whole thing to focus more time on the Mk1 mission. (Edit 3/12: good decision!)

Mk1 mission prep

Okay so, here come all the trials and tribulations getting KSP v1.8.1 up and running after spending almost a week just getting it installed. First up – rebuild the entire Ascension Mk1 craft in v1.8.1 – that actually wasn’t too hard as it’s not a very complicated rocket but my decision to install Restock did lead to some annoyances in that the visual style of the stock parts I was using had changed enough that I had to go create MM patches that would still load the stock-style parts as well. I also had to spend time hunting down parts to whitelist.

One of the good things to Restock is that it redid that horrible heat shield shroud into something much nicer. This did of course also cause me to have to come up with a reasonable explanation for why the shroud is now being used but that wasn’t too hard. Of course while I now no longer have to clip the heatshield into the decoupler, turns out I do have to clip the heat shield into the Mk1 capsule. The Restock version does not wrap itself to the bottom as flush as the stock version and when I translate it flush to the bottom the clipping prevents any ablation from happening during re-entry. So the rocket still doesn’t actually fly in-game exactly as it is pictured. Ah well. Also since I don’t have Restock for v1.5.1 where photos are being taken I’m instead using Decoupler Shroud, which looks similar enough from a distance.

After the craft was rebuilt I also noticed a ridiculous amount of EC usage and realized the antenna I was using was taking up to 60EC/s to transmit science data or even 0.8EC/s just at idle. Holy hell not even the largest solar panels can handle that. Reverting to stock showed proper 0.04EC/min so I tried to do a search for the MM config that was editing antenna transmission properties but came up empty so it had to be a generic patch. Ugh, so I just had to do batch re-install of mods to figure out which was the culprit. Surprisingly it was RemoteTech, which was confusing at first because I’m not actually using RT anymore, just keeping the parts. Then I realized having the RemoteTech folder in GameData was probably triggering the generic patch looking for RT to be installed. So I moved the parts to the deprecated parts folder within the KSA folder I have in GameData for my own stuff and the EC issue was resolved.

Next was transitioning from using RemoteTech to the stock CommNet, since Kerbalism is no longer compatible with RT (there may be a resolution to this soon but at this point I’d rather just wait for RT2). The main change to this switch was my kOS bootscript that underlies the AFCS. Making the switch to CommNet wasn’t too difficult in theory but in practice having to deal with connection status wasn’t as easy as I’d hoped. I also wanted to support the ability for CommNet to handle plasma blackouts for me, but it was frustrating to have the code properly determine when a blackout was happening since the connection does not drop instantaneously but degrades instead down to 0. I still haven’t gotten it perfect yet – I thought it was good but on the mission attempt I let it fly just to see what other problems might exist besides the TWR issue and crashed the program when just a normal LOS over the horizon occurred.

Speaking of over the horizon comm loss, there’s no way right now for me to edit the stock ground stations or even add my own, which I find to be surprisingly remiss of the KSP developers who always expound upon making the game customizable. This should be a simple config file like in RT and not something a modder should have to code up. Hell I need the CommNet Constellation mod just to be able to see the ground station locations in the Tracking Station. Anyways, for this mission it’s not a big deal since even if in the actual game comm signal drops there’s a kerbal to maintain capsule control and I know it is guaranteed throughout the mission story-wise and don’t have to spend any extra time figuring out if/when signal loss happens.

The issue of signal loss over the horizon was another stumbling point because initially it didn’t seem to happen. I could be in a low-Kerbin orbit and watch the connection line in the map view draw through Kerbin from one ground station to the next and never break contact. So that made me question WTF is the purpose of ground stations then? Some exploring in the Advanced Settings however uncovered sliders for allowing signal to “bend” around the horizon and by default they were set low enough to allow constant comms even in LKO with the default ground station setup. Changing the values for non-atmospheric and atmospheric bodies to 1 made the horizon a hard block on signal and losses then occurred as expected. Yes I could allow slight attenuation of the signal over the horizon for atmospheric bodies but since it’s a general setting for the whole Kerbol system I didn’t like that and decided to just switch it off by setting it to 1.

Getting the hang of the new Kerbalism science system sent me chasing after what I thought was a bug, but was actually just me drawing poor conclusions without looking deeper in the Kerbalism behavior. In my defense I was still in full-on bug hunting mode with all the other issues that had cropped up before this that were in fact bugs. Still, I probably let my general frustration with v1.8.1 come through a bit too strongly in that post.

One last annoyance with CommNet and Kerbalism is that when science data is being transmitted the PAW for the antenna still says “Idle” for its status. It’s not entirely Kerbalism at fault here either as even when an antenna is retracted and thus should be disabled the status field still says “Idle”. This is annoying because it would have been an easy way for kOS code to better track what’s going on with the comms system.

Finally getting into mission code testing at this point, I realize after a few restarts to launch that doing so tends to tank performance to the point where eventually the clock is full yellow and time dilation is up to like 50-60%. So it’s a slight bit more hassle to always have to revert to VAB and relaunch but at least doing that doesn’t seem to affect performance in the same way.

As the capsule came back down into the atmosphere the game would hang up for literally like over a minute before carrying on like nothing had happened. Checking the log revealed some spam from Physics Range Extender and removing it resolved the issue. Thankfully it’s not a mod I really need at this time.

I didn’t take the time to look into it further because I was also getting a lot of instances where the AFCS would crash when the capsule began re-entry. This was similar to what happened during an aerobrake in the Kerbin I mission which I didn’t investigate since it only occurred once but here it was happening repeatedly so I dug into the logging code and found that in some cases I could be comparing string values to integer values. Thankfully kOS lets you check variable types so now before assigning values I checked their type property. This issue has likely been present since I put the atmospheric logging code in last year there just never happened to be the right situation for it to trigger on past missions.

Sometimes when switching KSP versions things that worked perfectly well in previous versions just decide to behave differently. For some reason now the launch clamp that attaches to the engine overheats and explodes on lift off. I tried to buff the max temperature with a MM patch and confirmed the patch was taking effect in the final config loaded into the game and yet despite this the Overheat warning would still appear next to the clamp icon in the staging menu and the bar would shoot up at lift off and blow the part up. I’m not entirely sure if this has a large effect on lift off, whether the rocket drops slightly at first because of this, but regardless I just make sure to enable the Ignore Max Temp cheat before launch. I watched the temperature in the PAW and it did not reach anywhere near the max temp so this is likely a mod issue somewhere I’ll have to track down at some point.

Hold on, where did my Mk1 capsule suddenly pick up 140EC of battery? My MM config for this part, which is set to run :FINAL at the end of the patching sequence, should be resetting the capsule EC to 10. At stock it is set to 50 so something is tampering with it after my patch. My first suspect was Kerbalism and a quick search turned up the generic patch that was applying a 2.8 multiplier to all command capsules with crew capacity. But Kerbalism comes before the KSA folder in which my patch resides so my :FINAL patch should trump theirs. However they cheat and use “zzzz” prefix to force their patch to the end of the :FINAL line. Well I’m not playing the “zzzzzzzzzzzz” game so I just used :FIRST instead to set the capsule to 3.571428571 EC so the Kerbalism patch would modify it to 10.

Why does my capsule only have 10 EC? Because even tho it is actually supposed to have 140 EC the remaining 130 EC comes from a non-rechargeable battery. Which, in KSP v1.5.1 worked automatically to supply power to the EC batteries when no other supply was available and cut off when there was. So when the engine lit with its alternator the nonEC batts would stop draining. However in v1.8.1 that seems to no longer be the case. First thought was it’s a crossfeed issue but testing ruled that out. Thought also it was a mod enforcing some stricter flow control but not that either. No idea. So ultimately I had to switch them back to manual mode and add a bit of extra code to the flight routine for them to be activated/deactivated depending on the state of the engine and service towers providing power. Also, annoyingly, in looking back to see that they were indeed working properly before I discovered that for the Mk1 #11 mission they did not, but all previous missions did. Completely missed that and had to go edit it into the flight analysis report for that mission. It will be addressed again with a resolution in this mission’s analysis report.

Mk1 mission attempt

HAHAHAHA yea so at this point I still haven’t even tried to fly the actual mission yet, y’know – as designed and all that. The code testing I did was not using the actual ascent profile and made assumptions here and there – basically it was not a direct environment test but just basic enough to ensure I wouldn’t get a lot of logic errors or crashes during the actual mission.

In theory. Fucks sake

Well first of all now I actually needed my flight information windows I attempted to show all the VOID windows I usually have and the Vessel window would come up empty and just spam warnings. So I had to strip to stock and confirm it was an actual issue to report it.

Oh look KER also refuses to show data in flight, but I knew it worked fine in the VAB so although my first reaction was to strip to stock again, while it was loading I suddenly remembered that I never went through KER’s options after installing it in v1.8.1. Sure enough, I had to enable partless mode and also disable the career restrictions.

Finally I’ve progressed through my launch checklist to the terminal count, and one of the things is to do a test recording to ensure Fraps is setup properly. It comes out completely blank. Black screen. C’MON!!! I don’t know why,  the only thing I can think of is that I’m not using SweetFX post-processing in v1.8.1 since that’s for DX9 and maybe that’s why? No idea but I do have a backup in BandiCam.

Then I made some stupid mistakes getting the flight code setup for the actual flight and had to restart the countdown checklist over two times – we’re talking about 15-20min of work here leading up to the launch.

And then, finally, LIFT…. WTF

How am I getting a TWR issue?!? The fucking rocket lifted off just fucking fine multiple fucking times off the same fucking launch clamp in fucking testing fuck fuckity fuck FUCK

It reminded me of a previous mission where I still had the tower lights attached to the launch clamp affecting its mass and thus the TWR calculation but I had made sure to remove them for this mission.

It was pretty cool tho that I was actually able to reset the rocket and redo the flight code so that I really did make a second attempt right there without reloading the flight scene at all. The actual error was a TWR of 1.19999992215879 so it wasn’t a huge problem but again – something that had worked just fine in KSP v1.5.1 and even in testing the other day. I fixed it by instead of checking for an exact TWR of 1.2 it will launch with anything better than a TWR of 1.1985.

So yea I decided to write in the launch scrub with a sliiightly more deviant 1.18 because after all this hassle I just wanted to move on with building out my lead time again and also take a bit of a break since I was seriously getting burnt out having to work through issue after issue after issue after issue after issue after issue after issue after issue after issue after issue after issue after issue after issue after issue after issue after issue after issue after issue after issue after issue after issue after issue after issue after issue after issue after issue after issue after issue aft… ok that was for the people who skimmed. If you actually read this far you already get the point.

Bob’s engine being available for use was just happenstance and a thing I realized when I started to consider the implications of deciding to delay the mission the way I was. Nice, because I really wanted the engine issue to turn out to be serious enough that the scrub was warranted but at the same time didn’t want to delay the mission a few weeks.

Now, even though I bought myself a week’s extra time I did also give myself a bit of extra hassle in having to finagle the Ops Tracker a little bit because it’s actually not completely capable of handling this scrub scenario… but I like the whole story concept and character moments that has evolved from this so, whatever.

Hopefully after this weekend I’ll have everything wrapped up and back to attempting the mission again.