Gaius

Just to add, if encryption is desired for the connection for some reason, this can be done at the firewall level via VPN or something similar. This particular library/mod itself is precisely the wrong place to attempt to implement encryption. Insofar as it is desirable, it should be done on a different level, and where it is desirable, having it properly at the level it should be and in this library too would be taxing and overkill -- right idea, but wrong place for it. Not every single library should attempt to solve every security issue on its own -- that's precisely the kind of piecemeal approach that leads to bugs that cause security breaches, as every program relies on its own possibly buggy ad hoc methods, rather than having a specific purpose-built library or piece of hardware doing the one job its designed to do well.

... which it cannot do, unless the client inside your private network initiated the connection. If the connection is coming from the outside, with no information about which internal IP address it wants to connect to, there's no way for the NAT device to figure out which of the possibly many machines on the internal network you want to connect to. NAT does filter such connections, not as a matter of security, but simply by virtue of the fact that it cannot resolve them if you haven't explicitly provided the NAT with information on how to route them. Without port forwarding explicitly enabled, NAT cannot do what you appear to be claiming it will do above.

New download has fixed the issue. Given your patch notes, I suspect the fact that the probe on the surface was 80m away from a flag might have been what was causing the problem. EDIT: Noticed one problem remains -- newly docked/undocked vessels can have bizarre ideas for their current transmission distance. A quicksave and reload fixes the problem.

Ooo nifty. Does it accept only connections from the local machine, or could I run a script on another computer on my LAN (or presumably anywhere on the 'net, if I expose/forward the right port on my firewall)?

That's actually a pretty tricky question, and no matter which answer you pick, it makes some of the stock parts seem either overpowered or underpowered (they don't appear to be entirely consistent on the question). But for what it's worth, I think both NearFuture and Interstellar run with the notion that ElectricCharge rate = 1 is equivalent to about 1 kW (or in Interstellar's case, 1000 Ec = 1 megawatt -- they deal in REAL BIG energy requirements there).

You are wrong. In their rule for things you can't redistribute from the program, they specifically make an exception for the stuff in the Parts folder. See this thread for more info.

do want!

Okay, I have a lander on Minmus with a Communotron 16, and a satellite in a 250km orbit over Minmus with a Communotron 88-88. The lander refuses to transmit, correctly noting it's too far from Kerbin, but... shouldn't it be able to use the satellite as a relay? I'm confused...

Yeah, unfortunately real ion/plasma drives operate at far too low thrust levels to be useful for gameplay reasons, at least while we can't time accelerate with engines on. To have ion engines in the game at all, they have to be "kerbalized" into something usable in the game. On the flip side, KSP's regular rocket engines are actually underpowered compared to real-world rockets. For game purposes, they downscale the power of normal rockets, and upscale the power of electric engines. At some point, realism has to give way to make the game playable.

I think personally, I'd cut the reactor down to about half its current weight, then increase the power output to something reasonably close to the SAFE-400's kW/ton ratio. It used to be (back when this pack came out) that there was just no point in that, nothing used that much power, but these days several mods include incredibly energy-hungry plasma drives, VASIMR, and the like, so there's actually a use for something that outputs hundreds of kilowatts of power nowadays. Say, maybe 4t and 800kW, or maybe keep it 8t and output 1600kW.

Thanks for posting this. One quick reality check, though... It's a full-on nuclear fission reactor, not a giant RTG; of course its watts per kilogram is significantly better. Considering that it's an actual nuclear reactor, it's actually very underpowered with its current stats. Compare to reality. At its current power output, it ought to mass about a ton and a half (basing that on the SAFE-400 being about half a ton, and outputting 100 kW of electrical power, about a third of this reactor's output). Alternately, at the sixteen tons you've increased it to, it ought to output at least an order of magnitude more power than it currently does... And yes, the only thing GavinZac is distributing is his own ModuleManager config file. As the sole author of it, that's perfectly within his legal rights to do.

I believe it's actually due to the defined orientation of the nodes. Each node has a vector defining its orientation, in addition to its position. If you redefine the four side nodes on the hub to share the same orientation as the top and bottom, you could attach just fine exactly as shown in the picture -- however, that orientation would be undesirable for just about anything else you might want to attach to those nodes, since you normally want things attaching to the side nodes sideways, not upright. Note that you can attach the hubs to those four nodes by rotating the hubs onto their sides.

You might find this post useful.

Yeah. Originally, the hybrids fell into the gap between nuclear engines and ion engines in terms of Isp, but they got rebalanced at some point to be so much closer to nuclear engines in Isp that, once you added in the extra weight needed for xenon and electricity generation, they are strictly worse than just using a nuclear engine in almost all cases, the hybrid's Isp advantage isn't large enough to compensate for the delta-V lost to the extra weight. Personally, I just took all the hybrid engines in the pack and made them into plasma thrusters of unspecified type that simply used xenon gas and fell betwen nuclear and ion engines in terms of performance. Gave me an excuse to keep using the pretty engines, because these parts are simply too beautiful to not use.

Just to clear up a misconception (it's in your greyed out text, but it's still there, and worth addressing I think): the tank selection issue wasn't my main issue with TACFB. What TACFB doesn't do that I most wanted is fill my tanks automatically as soon as I dock with my refueling station, or fill the fueling station automatically when I dock my tanker, or let me set up balancing in the SPH and have it saved with the craft so I don't have to remember to monkey with it. In short, this is designed to be used by the kind of person who forgets what he was doing after chasing kids off his lawn and doesn't notice until he's stranded another poor kerbal somewhere that he forgot to fill his tanks before undocking (for the umpteenth time today). I wrote this to do that for me automatically, and, as I noted previously, I still have TACFB installed and I still use that as well. For me personally, this is meant to augment TACFB, not necessarily entirely replace it, although for some people it might do that, if the only things they were using TACFB for are things this does as well. Fine by me either way, but it's not a goal of mine to make this a complete TACFB replacement. Should TAC add these features to TACFB, I'll be overjoyed and stop using my own mod. TAC has permission to merge my code into TACFB, but I can't say for certain when or even if TAC will incorporate these features. Just sayin'... not my goal to do everything TACFB does, there were just a couple things I wished TACFB did that it doesn't, so this handled that. I've since added some configuration options to make different use cases easier, and plan to add at least one more, but ultimately I'm not interested in extending the functionality of this mod beyond what it currently does, just in refinements that make sure it does what it does as well as possible without overly complicating it. Being a complete TACFB replacement is outside of my scope, and pointless since I still have TACFB installed and quite like it, I just wish it did a couple more things that it doesn't (currently) do. That's where this comes in, and probably where it goes out, if/when TACFB gains these features, hopefully making my own mod entirely obsolete.

Yes, but... there are two different numbers relating to crew in a config, and the number you're looking at there is the "minimumCrew = 0", meaning the command module will work unmanned. However, the config also has "CrewCapacity = 2", meaning it normally takes two crew, even though it doesn't require any. There are similar situations with some stock parts (e.g. the Mk1-2 command pod takes three crew, but only requires one). When the game fills your primary command pod, it fills it to capacity, not simply to the minimum.

Hey, welcome back! Good to see you're still kickin'

Yes. This is why I wear a pointy hat with the word "WIZZARD" emblazoned across it in sequins. Cool. Enjoy, and feel free to peruse the (poorly commented ) source code.

Um, no, definitely not their only work, unless by "work" you mean software. They were primarily a marketing company that specializes in installation pieces, "capstone events to larger advertising campaigns", and apparently going forward are going to continue to diversify, working on producing a movie and starting a record label, among other things. Check out this recent article for a bit more info behind how an interactive marketing company gets into the software business because one crazy employee wants to write a game about little green men...

Personally, I'm interested in cool rockets. The idea that the nationality of the people who made them matters is patently absurd. Someone who suggests my interest in a particular mod will be determined by my nationality is being obviously racist, no matter how badly you might want to pretend otherwise. Are you next going to argue that the reason why I love Scott Manley's videos is because I'm part Scottish, and non-Scotsmen shouldn't be interested in them? If you think that's absurd, ask yourself why you didn't recognize jacobgong's question about why non-Chinese would be interested in this mod as being equally absurd? "Second, nothing he's said has been remotely ethnocentric"?! Please. The entire premise behind every single thing he has said or asked is that all people are extremely ethnocentric, and he doesn't quite understand how anyone wouldn't be. "Third, as an American (is this reddit?) the idea that the Chinese deserve admiration for their space program is an absurd one." Whether the Chinese deserve admiration or not is a matter of opinion, but the notion that whether you're American or not should be in any way influential of that opinion is again accepting an absurd premise. If they deserve admiration, they deserve it regardless of your nationality. If they don't, then they don't, and likewise your nationality has no impact on their deservedness.

Cool, glad you like it! Yes, the pumps treat tanks without the pump module installed as level 0 tanks. This is by design, and as you note, this is usually a Good Thing. However, now that I've figured out how to make things configurable in the config files or options window, I will add a flag to disable that behavior, just in case its not desired in some situations, but the current behavior will be the default. This isn't an issue for balancing, since balancing only ever occurs between tanks that have the "Balance" option ticked as well as being on the same level, and you can't tick it on for tanks without the module installed.

Did you include a "node_collider" model (the invisible model that defines the physics shape of the part)? When you pick up parts in the editor, I think you grab them by their physics model, so if there isn't one, maybe that would cause what you're describing here. EDIT: ninja'd

Thanks again for all the kind words! NEW VERSION RELEASED! Spaceport has been updated to v1.29.1. New in this version: you can now disable the pumping or balancing of certain resources while leaving it enabled for others, as requested above. Right-click the part, select "Pump Options", and enable/disable to your heart's content. "Pics or it didn't happen!" Right, right... Here we see The Forge orbital construction space station showing off the lovely Pump Options window. You can also have tanks start with certain resources disabled by default by messing with the default options in the MODULE section in the config. By default, tanks pump all resources they actually contain. To disable a particular resource, add lines to the MODULE section that read something like: LiquidFuelFlags = 0 ...replacing "LiquidFuel" as appropriate, of course. This will make the pump ignore LiquidFuel entirely. Setting the flags to 1 pumps the resource but excludes it from balancing, 2 balances the resource by excludes it from pumping, and 3 is the default: both pump and balance the resource. Enjoy! In the VAB, setting options on any tank in a symmetry group sets the option for all tanks in the group. Once in flight, however, each tank needs to be set individually. I'll add the ability to link the options of tanks in-flight to the wish list, but no promises. I'm not sure how easy it is to detect that parts were part of a symmetry group once you leave the VAB. Hmm. Yeah, I can see how that could be quite useful too. The wishlist grows...

Awesome, I can't wait!

I haven't checked personally, but my understanding was that we can't just slap textures on these models because the models lack UV-mapping.