podbaydoor

The tab is being captured by Unity. It just focuses the next available data entry UI element, which happens to be the group naming box.

Glad to see more processes being adding. I think we desperately need more ways to get LqdFuel from somewhere. Right now we only have Sabatier which is CO2-hungry, and there's no way to really generate that much CO2. Industrial CO2 is produced from kilning limestone (among other rocks), so I suggest that the molten regolith electrolysis include a CO2 output too. Just for balance reasons, I think it's a good idea to make sure there's always a viable <drill-able material> + EC => LqdFuel + <Oxygen/Oxidizer> process that players can concoct from sub-processes. One more idea: I believe NASA planned on doing aluminum oxide electrolysis on Moon rocks. The aluminum could be reacted with ammonium perchlorate (we can almost synthesize this in Kerbalism already) and you get the solid rocket fuel APCP (without binding agents)! This way we'd have (approximately) an ore + EC + ammonium => SolidFuel process, which could be useful and something not even in the stock game. It makes for interesting gameplay too because you have to lug empty SRBs to your refueling station, and then you get a fuel that's not particularly efficient, so you have to evaluate when mining solid fuel is worthwhile.

Quick note on some suggestions for the malfunctions system I saw earlier while scanning the thread: I'm not a fan of adding more resources just so players have to remember something else before launching. If a "spare parts" resource could make unfixable failures fixable, that seems like a real feature!

I've run into issues with consumption transients and the estimated time until empty a few times. It would really help demystify these sorts of situations if hovering over the resource to give the rate of change also broke that down into sources of production/consumption. I believe you can see the breakdown in the VAB, but not on a mission.

Figured that out and seems to work. Still not the behavior I expect though. Crossfeed is disabled at takeoff, probe's engine is disabled, probe's tanks are full. Not sure why you mean by "mode". I have Kerbalism and CRP installed which I know provide lots of fuel flow behavior definitions, but none of those should be interfering with the stock LF/Ox behavior.

I've got a space plane and probe both burning LF/O. I designed the plane so it burns through all its fuel just before making orbit, and switches to monoprop engines for the last few m/s. When I go to deploy the probe, I find the plane has burnt through the probe's LF/O. I had "disable crossfeed" set in the SPH (it's disabled, so "enable crossfeed" is what's displayed. Messing with priority won't solve things here because the plane will attempt to burn all available fuel. I just need to isolate the probe, and it seems like the crossfeed rules are being ignored. This doesn't happen on rockets for some reason. On rockets I don't need to mess with fuel flow or crossfeed rules at all. It works out of the box as I would expect. Anyone else seeing this? Is there another setting I need to mess with? A mod? Does root part matter? KSP 1.2.2

I play with my own set of self-imposed realism constraints, so I'm curious what the new super high-efficiency monoprop orbital engines are supposed to be modeled after. Is there a new type of vacuum rocket engine being developed in the... near future?

Thanks for the explanation. Out of curiosity, does Remote Tech handle things better? I submitted an issue for this to Squad. Let's see what happens.

I noticed that actions taken by a running script don't take effect if the vessel loses connection (stock comms system, using either comms manager). E.g. if I run my "execute_node" script before losing connection, but pass behind a planet and lose connection while burning, the `lock throttle to 0.` at the end doesn't happen. The graphical throttle actually goes to zero, so I know the script is working, but the engine stays on. I'm not sure what subset of commands won't work when out of comms - kOS seems to be able to unlock steering while out of comms, for example. I get why this behavior makes sense in some cases - you don't want people controlling their ship through the terminal to get around lack of connection, but in my situation this functionality kinda defeats the purpose of scripting. Wouldn't being able to hold attitude or burn through comms blackouts be a huge motivation to use kOS? Isn't that (and communication delay) why space probes can run autonomously IRL?

No error in Player.log either. I tried removing a few of my most recently added mods to no avail. I checked for corrupted files via Steam so my stock game files are intact, but it hasn't helped. Targeting now pretty much works only in the first 5 minutes of gameplay.

I was playing a bit today and discovered this issue is more insidious than it appeared at first. Launching new vessels, I was still having less scrubber capacity than I should. It turns out the scrubber capacity is specified in the .craft file so not only do you have to change the amount of the _scrubber pseudoresource to 1.67 * [part crew capacity] in your save file, you need to do this to your .craft files as well. Or just remove the part in the VAB and replace it with a new version of itself.

It seems like collecting a sample from an asteroid doesn't do anything now. Scientist on EVA tries to collect a sample, but after clicking the "collect sample" button nothing happens. All necessary building upgrades done. Maybe a problem with how Kerbalism intercepts the stock science system?

I'm getting a freeze nearly every time I select a target. I've tried doing this several ways: rendezvous menu in KER, `set target to "<some ship>"` in kOS, and good old click in orbit view. Particularly likely to happen when I've been in the game for more than a few minutes. No error gets logged in KSP.log. Lots of mods, very capable PC running Linux. Started happening a few days ago, so I figure it was introduced by a mod update, but with nothing in the .log I don't know what to do next. Too many mods to eliminate them one at a time (assuming it's not a mod interaction).

This mod is a fantastic idea. I've been using it for a few missions, but noticed that if I switch to a rover with control lock active, I get extreme Unity stutter until I restart the game. Like every 25 seconds I'll get a bout of less than 1fps, lasting for 5 seconds. This only happens after switching to a control-locked rover. Anything Bon Voyage might be doing to trigger massive garbage collection? Nothing suspicious in KSP.log. Anyone else seeing this? Any additional logs or debug stuff I should check out? KSP 1.2.2, latest ckan Boy Voyage, and more-than-capable PC/gfx.

I can confirm this. Any docking seems to delete the data on both vessels. You can grab the data on EVA to get around this temporarily on manned missions.