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.

Sumghai, I salute your amazing responsiveness to user requests of this nature. Thank you for looking into the lights.

Ooh, yes please -- I've been thinking about that on and off for a while, but didn't feel like it was a big enough problem to say anything. I just recently built a large station with a lot of IACBMs and noticed a considerable performance hit. I've also noticed that all the lights seem to be angled into the IACBM itself and not project any light outward to get a look at what I'm trying to dock with, so my tugs typically have additional lights augmenting their IACBMs. Also, when I'm assembling something more complicated, I can't just hit U to use those lights, because it makes every IACBM on the vessel light up like a christmas tree and drop my framerate. I'd be perfectly content if the built-in Light action group didn't include IACBMs at all and I just had to rightclick the one I wanted to toggle, because I don't think I've ever wanted to light up all my docking ports at once.

Asset reuse of this nature would also offer some additional memory savings to those of us who play with both FusTek and ALCOR.

I wouldn't have thought so but apparently yes; I had a Goodspeed directory (containing Scale.dll) which I didn't remember was related to TweakScale when removing old versions. Its replacement in my GameData folder made the problem reappear. After removing it, replacing all other mods I was using caused no problems. Thank you both for the prompt attention to what turned out to be my own fault.

Rework_TweakScale.cfg does indeed contain IR_TelescopicRobotic with 9 values, and part.cfg for the stackable extendatron refers to it with 9 separate translateMax values. Edit for update: With the legacy telescopic pistons, I have the same five scale options, with scales 0 and 2 exhibiting the same "translateMax not being scaled" effect, scale 3 undergoing a slight rotation, and scale 4 doing nothing. The legacy hydraulic cylinders simply don't scale translateMax at all scales. I am going to temporarily remove all other mods and see if the effect persists. Edit 2: With all other mods removed, the stackable extendatrons now have all 9 scales, all scales work properly, robotics parts' scales now have names and not just numbers. Will be trying to isolate the conflict.

Yes, the directory structure is as prescribed in the download: https://i.imgur.com/UG0wsUH.png I have, however, removed the legacy parts.

I have just freshly reinstalled IR 0.16 and these parts (taking care to remove old versions of TweakScale), and I only have 5 possible scales, numbered 0, 1, 2, 3, 4. The translation limits are not scaled along with the parts. This screenshot shows all five scales completely extended: https://i.imgur.com/8Gp6vzJ.png The same is true for the basic extendatron: https://i.imgur.com/mbKD9AP.png The right-angle extendatron exhibits more complicated behavior: Scale 1 works correctly and scale 0 fails to scale the limits in a similar fashion to the other two extendatrons, but scales 2 and 3 seem to do nothing at all and scale 4 appears to rotate slightly. https://i.imgur.com/0LDE0E7.png

I have altered my copy of KarmonyPayloadBayModule.cfg to insert the following two lines: node_stack_bottom_inner = 0.0, -1.6875, 0.0, 0.0, 1.0, 0.0, 1 node_stack_top_inner = 0.0, 1.6875, 0.0, 0.0, -1.0, 0.0, 1 This gives me attachment nodes inside the payload bay, so that the payload can be perfectly centered within the bay. The only shortcoming is that any part capable of surface-attaching to the inside of the bay will do so aggressively, to the exclusion of attaching to the nodes.

I'd also enjoy a config option to disable the "closed hatch" function, as I do not use the random crew movement mod and thus have no need to close any hatches. I do, however, like to build large structures from many small modules, so I wind up spending a lot of time opening hatches.

Nice! Does that right-angle extendatron allow attachments on both ends?