awang

Isn't that what already happens? I feel I'm misunderstanding something here... Eh, I suppose there are worse things to worry about. I suppose in theory you shouldn't be seeing buildings being demolished all that often either, unless most people play a heck of a lot more destructively than I think they do.

What would "destroyed by heat and pressure" look like? And to be fair, the way KSP destroys things probably isn't realistic for most situations.

To be pedantic, the net torque required from z1 and z2 to balance x1's deceleration is the same magnitude as the torque produced by the deceleration, with an opposite sign More seriously, though... If y1 and y2 are operating at the same RPM in opposite directions, shouldn't they cancel *each other* out, leaving no net effect on the system? So you still have the torque from x1 to deal with. z1 and z2 can cancel the torque, but at the cost of having to change their rotation rate(s), so in the end the momentum from x1 was split across z1 and z2, leaving the total the same. It's been too long since I've had to deal with off-center angular momentum/torque problems...

I would assume that if such a method existed NASA and other space agencies would be all over it... In addition, you can't just "[divide] the momentum by 10 every time you transfer the momentum". Angular momentum has to be conserved, so you can't just magic away 90% of it using one maneuver or another. Reaction wheels have more states than "on" and "off", too; I'm more than a little rusty on my physics, but I would imagine that in order to cancel the torque from X1, Y2 would have to spin at a *different* speed due to differing distances from the center of mass. Craft in real life aren't operating in a closed system, either. There's drag, uneven gravity gradients, etc. which all constantly produce a torque on the craft, so no matter how you transfer momentum between wheels the overall amount of momentum will change to a point that you have to use RCS. And r.e. the patent: Being granted a patent does not prove correctness. Perpetual motion machines have been patented.

Ah, that clears things up. Thanks!

For example, here are the tags for the LV-909 Terrier: tags = lander orbit propuls rocket (terrier vacuum What is the opening parenthesis before "terrier" supposed to mean? I've seen it in other parts for other tags, too. I *think* I understand how the tagging system works otherwise (matching words or start of word). Are there any other features I may have missed? @Arsonide

Quick question: Is the KOPO4E based on a RL engine?

Yep, seems the probe cores have a ModuleCommand module. Guessing that's what's triggering the ~0.4kW TACLS drain in Fusebox? Is it not possible to get electricity usage from TACLS on the fly?

Oh, so Fusebox is counting the probe core as using TACLS charge? Never would have thought... I'll take a look and see what I can find.

Hmmm, didn't know about TACLS. Haven't gotten to Kerbal spaceflight yet, but that'll be useful when I start. Anything I can do to figure out what's going on?

Hello! Just updated to 1.3, since I didn't realize the version on CKAN was outdated, and for the most part it seems to be working just fine. So thank you for writing this mod! Makes planning a heck of a lot easier. Only thing I've noticed is that 1.3 seems to massively overestimate the amount of electricity probe cores use; I'm playing with the RO/RP-0 set of mods, though, so I'm not sure if that's playing into it. I have a OKTO2 on one of my satellites, which is stated to consume 3.6EC/hour. Fusebox 1.2 correctly calculated that as 0.001EC/second, but 1.3 thinks that it consumes 0.05EC/second. As a result, it predicts the satellite batteries draining within a half hour, when in reality the batteries are charging just fine. Is there something I'm missing? I very much prefer overstating consumption rate instead of understating (which 1.2 did), but perfect accuracy would be ideal...