wookiee_goldberg

Where do they show up in the tech tree? If it's earlier than jets then maybe worthwhile in career/science mode. And also can be used (with rotors instead of turboshafts) in Eve's atmo, which jets cannot.

The consumption when torque is limited to perfectly maintain RPM is totally fine - that's where it ought to be. Only the excessive consumption when the torque is set to 100% (but RPM is already maxed out) would need to change. I had a thing that could max out the RPM in flight with just 3% torque, and the consumption was great - increasing torque slider to 100% caused 33x as much fuel consumption with no change in the flight of the vessel.

Yeah that's weird too. Both of those things should be based on the current RPM and torque, not the maximum RPM and torque. The way those things are currently kind of bypasses the law of conservation of energy (maybe this is what feeds the Kraken).

Yeah overall it's much better than before (now that i've been able to play with it some this morning). The "current torque usage" is still kind of broken though.. when current_rpm is less than target_rpm then it's fine for current_torque to equal max_torque because you're making best-effort to spin your thing up to speed. But once current_rpm >= target_rpm, then a PID controller should kick in and manage the torque output (and resource usage) below the "max torque %" setting to govern the current_rpm as closely as possible to the target_rpm - after all, max torque is only supposed to specify the MAX torque available, not the current torque demanded. So if you can hit peak RPM with 2% of max torque then having the "max torque" slider on 100% should still only use 2% until the situation requires more. The max torque% slider should just affect how quickly/violently the motor will try to respond to being under-speed.

Back in 1.7.1 / initial BG release, i did notice that the concept of "how much torque is needed to do this thing" was just following the maximum setting rather than using a smaller number based on actual needs... so maybe that's still in-play here. Like as if you were driving around with your gas pedal floored, and using your brakes to moderate your speed. I was asleep when the update dropped and then at work, so I haven't gotten any play-time with the new stuff (and updated old stuff) just yet.

I think it was already like that before - i remember seeing those things commented out even in 1.7.1 when BG was just released. Looks like something they thought about doing, but decided against. Torque-based fuel consumption is correct even for combustion engines. If you have something that's spinning at a certain RPM but doesn't need much torque to sustain it, then that shouldn't use much fuel (coasting downhill in a car). If you need to add torque to sustain your RPM, that should use more fuel (climbing a hill in a car). If you have a manual transmission car with cruise control on and a loud enough engine, you can hear the volume of the engine getting louder and quieter as you go up and down hills with varying torque demand, while the RPM of it (and the car's speed) remain constant.

It might have implications on whether or not "Undock" action in an action group is allowed to do its job. And also maybe if you have a docking port that's buried inside a surface and hard to click, this makes it so you can easily click Undock on another docking port that is more visible and easier to get to. I think it's more like the "Kanadarm" situation, and docked-part-loop behavior (same-vessel connections). If you are in a MK3-based spaceplane docked to a space station through the shielded nose docking port, that is a "real" docking connection. When you use your Kanadarm to grab a payload from your cargo bay, that would be a "fake" docking connection. But then when you decouple the payload from the rear wall of the cargo bay, the fake connection becomes a real one, so that it's securely attached to the end-effector of your Kanadarm with all the normal functionality of a docked connection. It should be possible for a craft with 10 docking ports connected to stuff to all use "real" docking connections as long as there are no loops created by the docking ports - just imagine a station core with 10 docking ports and 10 capsules docked to those ports, those would all be "real" docking connections.

Forked a branch to do some more CLSStock* config file updating. Branch is here (commits are in 'master') if anyone wants to try it before I do a pull request: https://github.com/wookieegoldberg/ConnectedLivingSpace I tried this out in 1.3.1, 1.4.3, 1.4.5, and 1.5, since different versions use different part names. I'm thinking of consolidating some entries into single entries since it seems possible that comma-separated part names read as "this OR that", so things like @PART[stackSeparatorBig] and @PART[Separator_3] could possibly be combined into a single @PART[stackSeparatorBig,Separator_3] entry... I'll try doing this tomorrow. Changes are as follows: added to "CLSStock.cfg" mk1pod_v2 (for 1.5, updated "@PART[mk1pod]" to say "@PART[mk1pod,mk1pod_v2]") adapterSmallMiniShort (since config already included the 2 Rockomax brand adapters) adapterSmallMiniTall (since config already included the 2 Rockomax brand adapters) Size3to2Adapter (since config already included the 2 Rockomax brand adapters) added to "CLSStockFreedomAddon.txt" stackSeparatorMini (since config already contained all the other decouplers) stackDecouplerMini (since config already contained all the other decouplers) size3Decoupler (since config already contained all the other decouplers) stackBiCoupler (since config already contained adapterLargeSmallBi) stackTriCoupler (since config already contained adapterLargeSmallTri) stackQuadCoupler (since config already contained adapterLargeSmallQuad) Size1to0ServiceModule (MH only: to allow ApolloCSM-like "docking tunnel" surrounded by parachutes) removed from "CLSStockMakingHistory.cfg" (still present, but commented out) fairingSize1p5 (no stock fairings were included, so this won't be either) fairingSize4 (no stock fairings were included, so this won't be either) changed from "CLSStockMakingHistory.cfg" kv1Pod (changed "impassable node" from "top" to "bottom" - the inflatable airlock is meant to go on the top, the bottom is an impermeable decoupler) kv2Pod (changed "impassable node" from "top" to "bottom" - the inflatable airlock is meant to go on the top, the bottom is an impermeable decoupler) kv3Pod (changed "impassable node" from "top" to "bottom" - the inflatable airlock is meant to go on the top, the bottom is an impermeable decoupler)

It's cuz you are using the cupola. The mod's CLSStock.cfg config file says the top node of the cupola is impassable, so I assume the same would be true for any other cupola you might be using. @PART[cupola]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true impassablenodes = top } }

This is the link to the new thread by linuxgurugamer

I made a video with this mod's parts a while back showing a pretty compact way to handle multi-stage chute deployment that doesn't require burying the chutes inside the capsule itself. It also demonstrates nominal in-flight jettison of the towers at around 35-40km altitude.

you can go back to 1.4.3 within steam if you want, if you right click on KSP in your Library, then go to Properties > Betas > pick the version you want.

1.3 Changelog - Making History DLC ONLY +++ Improvements * Add SPH camera panning to the GAP when SPH camera controls are set. * Added GAP camera settings and canvas zoom setting to game settings. -- +++ Bugfixes * Fix mouse scroll in the GAP to work when mouseover GAP, and not require a click first. what's the "GAP" thing referring to?

the "Dessert" launch facility is (as pointed out in a recent video by Scott Manley) at just the right latitude for a once-daily due-east launch to put you on a perfect relative inclination with Minmus... the dessert moon

such is the trouble of shooting in the dark