Kanddak

A gas-core nuclear thermal rocket is supposed to have vastly better performance in every way than a solid-core -- it's just a much harder engineering challenge to build one.

Just updated to affect cost and mass! Same download link above. I didn't bother to deduct the cost of the end rings from the base cost of the modules, though. Correct. The two end rings are toggled independently from each other as well; the Karmony nodes each get six instances of the PartModule, with each one independently controlling a different MODEL node.

Not presently, but I can add that. Since we're already able to patch over the node recesses anyway, we may as well be able to do it without adding to the part count. The main use case I've come across is in the use of a Karmony node parallel to the ground as a junction in a surface base; the recesses on the floor and roof should be covered. We don't want a hatch in a trapdoor orientation in our hallways -- if the Karmony node had an IVA we'd want to remove the interior hatch, too. I've also stacked two compact nodes together and then blocked all four recesses on one of them in order to create a node with an off-center layout more similar to the real Harmony and Tranquility nodes. I usually use them that way, but I often prefer to use flat variants with the 2.5m IACBM for greater structural stability, especially when modules are going to be under thrust together (for stations beyond LKO, manned segments of interplanetary vessels, etc), and because my tugs are usually standardized on 2.5m docking ports for other reasons. But the Kupola does look pretty nice stacked on top of the compact Karmony node. That might make a good hub for a surface base.

Hi Sumghai & FusTek fans, Here's a plugin I wrote this weekend as an exercise in learning to write plugins: https://www.dropbox.com/s/3mwchh46pfpzeyb/ToggleModel.zip?dl=0 It toggles entire MODEL nodes on and off, rather than individual mesh objects like FSmeshSwitch. It can optionally toggle an attachment node as well. The accompanying modulemanager file does the following: Allows the top & bottom end rings to be toggled independently on each of the tapered Karmony module variants. Hides all of the flat-ended module variants. On the Karmony node and its compact variant, adds the KarmonyNodeCover model over each of the side recesses, and allows each node cover to be toggled independently along with the associated attachment node. Allows the bottom end ring to be toggled on the two airlocks and the Kupola... revealing that these three models don't actually have bottom surfaces. Known to work with station parts downloaded 2015-04-15 in KSP 0.90. My hope is that after some testing, this can be distributed with the station parts and the tapered & flat-ended variants can be consolidated. License: CC BY-SA 4.0 (selected to deliberately match FusTek).

Take a look at https://github.com/taraniselsu/TacExamples/blob/master/03-PartRightClicking/Source/PartRightClick.cs ; that's an example of a partmodule that defines two events for the part's action menu, where each event deactivates itself and activates the other event. I'm new at this myself so I don't know if there's a good way to activate and deactivate events belonging to other partmodules, so if that's what you're hoping to do, hopefully someone more experienced than me will come tell us about it.

Update after much experimentation, with some information about the component hierarchy I wish I'd seen documented somewhere: part.GetComponents<Component>() basically seems to be the highest-level way to explore all of a part's inner workings and returns an array of various stuff, including a Transform which is the only thing that's interesting to the present purpose. part.GetComponent<Transform>() is one of the elements of that array, and still isn't very interesting. It just has another Transform called "model" as a child. "model" is part.GetComponent<Transform>().GetChild(0), but part has another method that lets us skip all that; we can also get "model" via part.FindModelComponent<Transform>(). "model" is interesting because its direct children correspond to MODEL nodes from the cfg. Transforms don't seem to offer up an array of their children, but we can call Transform.childCount() to find out how many there are and then Transform.GetChild(i) to access the i'th child. Transform parent-child relationships aren't the same as object-component relationships; "model" is its own component, so that part.FindModelComponent<Transform>().FindModelComponents<Transform>() just returns an array with only "model" in it, not the array of its children that I initially hoped for. The Transforms corresponding to the MODEL nodes each have children corresponding to the hierarchy of meshes within each model. If we call part.FindModelComponents<Transform>(), the result is the entire model hierarchy flattened into a list. It seems to follow the order in which the MODEL nodes are declared in the cfg. part.FindModelTransform(s) gets a Transform by name, but the name for each MODEL node has "(Clone)" appended to it, so if your MODEL node had "model = YourMod/model" then you'd get its associated Transform by part.FindModelTransform("YourMod/model(Clone)"). You can also directly use the name of a mesh within a model. part.FindModelTransforms(s) gets all the Transforms that share a name, which might be useful when you're reusing a model repeatedly. We can also call Transform.FindChild(s) to look one up by name from the transform instead of from the part; again, Transform doesn't seem to be very friendly to retrieving an array of it children.

Hi folks, I've been trying my hand at plugin programming this weekend, and I've mostly been able to make progress by studying API documentation and the source of other plugins, but I'm having no luck figuring out how a partmodule can get access to its part's MODEL nodes, or to whatever Unity objects those get turned into when KSP parses cfg files. Does anyone know what I might be missing or where I should be looking for it?

As much as I love to see heat management as an important element of spacecraft design, a nuclear-thermal rocket is basically the most ridiculous possible part to create a heat problem. The basic principle of its operation is that the propellant absorbs heat from the nuclear reactor and is then expelled from the spacecraft, carrying that heat with it. The whole thing is an open-cycle cooling system. Save the difficult heat management for the ISRU equipment for now. Give us nuclear-electric VASIMR or MPD later and we can revisit this.

This is correct. In vacuum you want no less than 90 degrees between radiators to keep them from radiating back onto each other. Not necessary. Your problem in space is getting rid of all the heat generated by astronauts' bodies.

Great to know you're on the case!

I've always had to play with texture quality at eighth res to get acceptable performance, so I'm used to everything being a bit pixelated and there's no discernable difference for me. I wonder if there's some way you could satisfy those of us with tight RAM constraints while still making higher-quality textures available for those who can handle them? I imagine maintaining seperate high- and low-resolution releases would be too much of a gigantic hassle.

Current issues for me: Parts' positions don't persist when picked up and moved in editor "Invert Axis" toggle doesn't persist from editor to launchpad Rotation limits don't persist from editor to launchpad "Apply Symmetry" doesn't seem to do anything & nothing (positions, axis inversion) persists across part symmetry Part movement in editor doesn't respect parts' speed settings & is therefore not useful to preview how parts will move relative to each other Reset buttons set parts to their original orientations and not to the orientations I'd tried to set as their default These might have been around before, but they've become really irritating due to the removal of the alternate versions of the pivotrons. I almost never place hinges in the closed orientation, so it now requires an enormous amount of fiddling to initialize things the way I want them and then keep them there while iterating on a design.

The COMoffset parameter in the cfg should do the trick. But there was a reason for that offset to be there: a bug in KSP where airlocks don't work properly if they're more than a certain distance from the part's COM. That bug might have been fixed at some point, but I didn't pay very close attention, because sumghai removed all the offsets concurrently with the removal of the airlocks from non-airlock modules in more recent versions of the mod.

I'll be very happy to finally have stack-attaching wheels, but I'd be even happier if I could drive normally instead of using IR for steering.

If you ever go down this road, this reminds me of a wild blue-sky idea I had a while ago: Develop a plugin that allows one part to have several possible IVAs, chosen by a tweakable. That would allow the creation of a lot of different mission modules without flooding the part menu. For another example besides surface-base variants, a very large station might want further specialization of modules, like a dorm module with 8 sleep stations, a dedicated sickbay, etc -- I'm thinking of http://www.nmstarg.com/2012/09/the-city-in-sky.html . The modular nature of the panels you're making now seem to be a good foundation for eventually doing this.