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.

Really enjoying using this with Kerbalism. The latest version of Kerbalism expanded the life support complexity, so now there are a few things missing from PBS-Kerbalism support: hydrogen tanks need to be enabled (just steal the model from TAC compatibility, I guess), and Kerbalism now has nitrogen, which there are no tanks for. I would just edit the configs myself and PR, but to do this right we should probably have a tank with a little "N2" on the texture. And there I don't have the software or original textures to help out.

I'm trying to call the trajectory prediction functions (`positionat` and `velocityat`) on a landed vessel to do some precision landings. I was hoping this would be a clean way to account the changing absolute position of the landed vessel as the parent body rotates. However I just get NaN vectors back. Am I doing something wrong or does `positionat` not work on unloaded or landed vessels? If trajectory prediction won't work here, does anyone have code for computing the position of a landed vessel in the future, accounting for rotation speed, elevation, latitude, etc?

The pressure control modules are not always running at capacity, so it's not quite using nitrogen that fast necessarily. But I agree with you on the leak rate being too high for stations. I just went into the configs and cut the atmosphere leak process's rate by 5-fold (remember, these numbers are all educated guesses) and that makes things quite reasonable. In fact, I submit that that should go in as a balance update to the actual mod.

Or if it were a Planetary Base Systems modular piece thingy...

Yes, in 1.1.9 the capacity of processes (scrubbers, waste processors, pressurizers) scales with the crew capacity of the part that it's set up on. So for every crew slot on a part, the part's processors cover 5/3 of a Kerbal. The old values were fixed so that a processor always covered 4 kerbals, but people who had big part mods were running into trouble. I ran into the exact same problem as you did and I assumed it was because the capacity of the scrubbers is hardcoded in the save file, and the old 1x capacity scrubbers you have on your vessels now only clears enough CO2 for one Kerbal. Just as I was testing some fixes, it turned out restarting the game fixed it for me. If that voodoo solution fails, you can edit the "amount" of the _Scrubber pseudo-resources in your save.

I think this explains why my "hydrolox battery" was overdrawing its hydrogen and lox! So EC output and hydrogen/oxygen draw would be at max rate even if the batteries were full? On the topic of cool battery alternatives: NearFutureElectrics has these cool capacitors that have high storage density, but dispense charge all at once. It would be cool to be able to control these via automation, so you could trigger them at low EC. Have not found that necessary. One scrubber usually covers 3 habitable parts.

+1 for timewarp issues. However, there is some good news I can share. On the latest release on github, the "Everyone froze/burned but I have tons of EC" bug seems to be gone for me, so if that's your primary issue just try using the newer code. The "Everyone froze/burned and I have no EC... but I should have some EC" bug lives on. For example, I have a Minmus base that makes it through the night without running out of EC about 25% of the time, and it seems to depend on a) how fast I warp (sometimes higher is better!) and b) what ship is in focus during the warp. The fix was lots of quicksave/reload until I managed to send and dock a giant stack of batteries. So until someone figures out a real fix, just double up on EC storage from whatever Kerbalism estimates you'll need, or, if you don't think that's fair, edit down the climatization EC consumption rate in the config. And one more bug I noticed: it seems like linking/docking two crafts via those KAS CC-R2 ports (maybe all docking ports... haven't tried yet) causes all the science data in both ships' drives to be lost. Based on some messages that pop up when I complete the link, I get the sense that KAS deletes both ships and recreates them instantly to make the game engine do the "linking". My guess is that the science data is lost in this process.

I'm seeing about 8 copies of the Vessel Viewer icon in my stock toolbar most of the time, displacing all my other mod buttons. Searching for Vessel Viewer stuff in the log turns up nothing suspicious. VesselView 0.8.3.0 and VesselViewPlugin installed from github, but VesselView-UI-RasterPropMonitor installed from ckan. What might be going on here?

I checked out some volume/SA values and they look fine. It turns out I'm having issues because the nitrogen duration displayed by Kerbalism in the VAB isn't the duration I get in the field. I have a base in the VAB which Kerbalism claims has over a year of nitrogen, but once I land it, Kerbalism tells me I've got 8 days. I've checked to make sure the settings in VAB are identical to what's out there in the field. As always, let me know what I can do to help debug. Other issues I'm noticing now that I have bases: There's no option to disable the waste processor. This looks intentional: toggle = false in the configs. Why was this choice made? I have a base that can't make it through the night unless I can shut this off. In the VAB, probe cores are listed as taking 0.03 EC/s for "command" when you attach one and ask Kerbalism what's using EC. Command pods are listed as taking 0.30 EC/s, but the EC/s usage total comes out as if it were only 0.03 EC/s. Weird bug that doesn't seem to affect gameplay that much, but it would be nice to know why the true and display values differ. There's no K&K container for nitrogen (Planetary Base Systems). All the other Kerbalism life support resources have corresponding parts in PBS. Can the O2/CO2 tanks be made configurable? Should we see if we can get a new texture that uses the O2 tank, but has an N2 label on the outside?

Thanks for getting back to me so quickly about all my nitrogenous problems! I'll check on part surface areas in the VAB next time I get a chance. Ah that makes sense! It looks like the CRP entry for nitrogen has transfer = PUMP, same as all the other transferable resources. flowMode is indeed set to STACK_PRIORITY_SEARCH, but that should have no bearing on pumping. STACK_PRIORITY_FLOW is the one that won't transfer across stages. Anyway, I set flowMode = ALL_VESSEL and now I can transfer nitrogen, even though I'm not sure why. Maybe we should ask @RoverDude about changing this in the official CRP, if it makes sense and is in fact the correct behavior (which I'm not sure it is... what does transfer = PUMP even do then).