Fraz86

These look great! Would you consider making a matching adapter piece for the trusses (7.5m to 5m for RSS, which would rescale to 3.75m to 2.5m for vanilla)?

Porkjet, would you happen to have any preview pics for your upcoming inflatable hab update?

Can't wait for CLS integration! I hope those bugs aren't giving you too much trouble. Thanks for your hard work!

The "Final" tag is supported by MM 1.5.6. Also, to follow up on jmanidb's suggestion, I believe you could at least safely restrict your module to parts that already have a module (I don't think there are any parts, stock or otherwise, that have actions associated with them but no module). I believe this could be accomplished with the following: @PART[*]:HAS[@MODULE[*]]:Final { MODULE { name = ModuleAGExtData AGXData = Empty AGXNames = Empty AGXKeySet = 0 AGXActivated = 0 } }

I believe I've managed to fix the RemoteTech compatibility issue. All you need to do is add the "Final" tag in your ModuleManager file, like this: @PART[*]:Final { [INDENT]MODULE { [INDENT]name = ModuleAGExtData AGXData = Empty AGXNames = Empty AGXKeySet = 0 AGXActivated = 0 [/INDENT] } [/INDENT] }

I agree with BigD. I understand this is really RT2's fault, not yours, but RT2 is a very commonly used mod, and the author has made it clear they don't intend to release any updates until 0.24 (not 23.5). If the only consequence of fixing compatibility from your end is breaking backward compatibility for stored action groups, I would consider that a completely acceptable tradeoff, especially given that your mod has only been out for a day (so people haven't invested tons of time into it yet, and they should expect the possibility of compatibility breaking updates anyway).

As I previously reported, this function seems to work fine, except that parts for which CLS is added in this manner are missing the CLS text box on the parts' tooltip in the VAB.

I fixed my first issue by adding "@passable = false" to the ModuleManager config for the parts in question. I had previously assumed that setting impassablenodes as desired would be sufficient (and it was sufficient in terms of in-game function, but just not for the VAB tooltip thing). The Hitchhiker module, however, continues to lack a tooltip. Moreover, I can't seem to find a config for it in any of your included CLSStock ModuleManager file, and yet it functions correctly in game. I'm using CLS version 1.0.3.0.

It seems that weird stuff happens if you attach a FissionGenerator to a part containing a regular ModuleEngine (such as the LV-N). However, ModuleEngineFX does not seem to share these problems. Perhaps you could try deleting the LV-N's ModukeEngine and replacing it with a ModuleEngineFX?

I've found a bug regarding the CLS module descriptions that show up in the VAB. Their descriptions in terms of which nodes are passable/impassable appear to reflect only the default settings. For instance, I changed the lander cans to be passable only through the top node, and this functions as intended in game, but the description still says they're passable through all nodes. Also, for whatever reason, the Hitchhiker module seems to lack a CLS description altogether (though it still function as intended).

Can I delete TacLifeSupport.dll (in the MKS folder) if I already have TAC-LS installed?

Awesome. I don't quite understand the idea behind a ring-shaped solar panel (wouldn't that just result in most of the surface of the panel receiving suboptimal sunlight?), but the craft in that picture looks really cool, so I'm all for anything that allows me to build something that looks like that. An observation module and "control center" style command pod would also be great, but as you point out, IVAs would be critical for these modules. Excellent. Perfect. Yeah, that's certainly understandable. I hope so, however, I have my doubts regarding the sanity/fitness mods currently in development. KeepFit is the only one with an actual release (I've seen little evidence that the others have progressed beyond the "concept"/early development phase), and unfortunately I'm rather disappointed with several aspects of Timmer's mod. It considers only the spaciousness of the module in which the Kerbal is located rather than the craft as a whole, it uses fixed qualitative rather than quantitative variables to define spaciousness, and there is no consideration of the number of Kerbals sharing a given space. The other mods (seemingly stalled in early development) appear to be plagued by overly complicated ideas and un-fun gameplay mechanics. Anyway, for the time being, I've crafted a hacked up version of TAC Life Support that serves my purposes (a resource named "CrewHealth" is consumed and converted to "CabinFever", which can be recycled to CrewHealth with sufficient "Living Space" modules, which I have added to Porkjet's inflatable habs). I certainly understand that you'd rather not dabble too much in the coding side of things, and I don't blame you, but I hope that one of these days someone with good gameplay instincts decides to tackle the issue.

Some thoughts: NTRs: NTRs synergize very well with the existing NFP pack. However, attractive stock-alike NTR models are already available in Kommit's pack, and it's easy enough to configure them to use NFP's resources (see my ModuleManager config in your other thread), so I would only rate this as a moderate priority. Structural Trusses: I already use "TurboNisu aesthetic parts pack" for additional small and mid-sized stock-alike truss pieces/adapters, which I feel provides a reasonably complete set. However, I would love to see just a few more variations on your large octagonal truss set. For example, a version with a crew-containing tube down the middle (for integration with Connected Living Space) and a "truss bay" with opening doors (similar to Porkjet's). Deep Space Ship Parts: I think I like this idea, but I'd like to hear more about specifically what you have in mind. Station Parts: I definitely like this idea, and there is particularly a deficit of good stock-alike modules intended for use on planetary surfaces. ORS Integration: I've actually already done a bit of this using ORS, BahamutoD's Drills, and a ModuleManager file. However, I would advise caution, as I believe many people (myself included) prefer NFP over KSPI largely because NFP does not dramatically alter the "feel" of vanilla gameplay. If you go for ORS integration, I recommend two things: (1) keep it simple, (2) limit it such that ISRU is only useful/practical in a select few situations. Tech Tree: Well it's not a bad idea, but I use my own custom tech tree, so I can't say I'm particularly interested. Compatibility Integration: Meh. Keep Making SEP/NEP Parts: Sure, why not. In particular, I'd love to get a couple more large hydrogen tanks. A couple additional ideas: Microwave Power Transmitters/Receivers: Months ago I believe you indicated an interest in creating such parts. Given how exceptional your solar panel models are, I'm sure you could make some wonderful transmitters & receivers. I also believe the gameplay mechanics involved would synergize very well with the rest of the NFP pack. In Regard to Station Modules, Surface Base Parts, & Connected Living Space: I appreciate that this may be well outside the scope of what you're interested in taking on yourself, but I would love it if someone would give us a reason to care about having sufficient living space for crew, and, moreover, a reason to have a crew of >1 Kerbal in the first place. In my opinion this is the single biggest "unfilled niche" in the KSP mod community.

Sounds great. Any updates?

I was wondering the same thing. Anyone know the answer?

FlexRack has been stuck in development purgatory for months, and to my knowledge the portable payload rack has never been released. And regardless, more options is always good! I would love to have the Big Bag as a part; you could release it with a totally generic config file and allow people to configure it as they see fit (for their life support mod of choice) for personal use.

Looks great! I can't wait to try it out!

Porkjet, I'm trying to put together a ModuleManager file to add a DeadlyReentry ModuleHeatShield to your Mk2 parts. However, doing so requires that I know which "direction" (in regard to the x/y/z axes of the model) corresponds to the bottom. Unfortunately, this seems to vary quite a bit from one module to another among stock parts (e.g., direction = 0, 0, 1 for the stock mk2Fuselage, whereas direction = 0, 0, -1 for the mk3Fuselage, and direction = 0, -1, 0 for the bottom of the mk1pod). Could you tell me the correct "direction" for the bottom of your Mk2 parts?

There are a lot of cool ideas, but I'd also caution against bloat. I really enjoy addons with a smallish number of high quality parts that share a cohesive concept and fill a clear niche. Your inflatables pack is a perfect example of this, and this Mk2 pack seems to developing along these lines as well, but I think 20-30+ parts would likely be excessive. I think your priorities (i.e., wings, adapters, and maybe intakes) are perfect, and you probably don't need to add much beyond that in order to have a pack that feels "complete."

I can't speak for starstrider, but I support the idea that, if the model does not visibly depict a hatch at the node in question (such as the bottom nodes of the lander cans), the node should not be passable. I would extend this logic to prohibit the use of docking ports at any location other than passable nodes (including disallowing radial attacments). I understand other people may prefer more liberal parameters, but fortunately it's rather easy for me to create a ModuleManager file to configure everything as I see fit.

What pack is that adapter truss from (right side of the second image)?

I'd like to second this request. I never use AGM's context menu feature, so it just adds to the clutter of the context menu. I'd love to have a version without it, or an option to disable it.

It's mostly about immersiveness. I agree that the gameplay implications are minimal, though I would point out that EVA transfers require a small amount of monopropellant, and there is a small risk of a bad outcome (e.g., flying off into space). Mostly, though, I would just enjoy the roleplay of being forced to EVA if I'm transferring between unconnected modules.

I like that approach. Agreed, having a common interface for all transferable entities (i.e., resources, crew, and science) seems elegant and intuitive. I am a bit skeptical about the science transfer function (mostly concerned regarding how it might be abusable), but I admit I haven't really played with it yet. Does transferring data allow the science model to reset and repeat the experiment? Because that would seem like cheating to me... In my opinion, multi-part transfers and other complex transfer operations ought to be outside the scope of this mod. Honestly, even the "Empty" and "Fill" functions seem a bit superfluous, and they would even be cheating in the context of certain mods (e.g., with a life support mod, using "Empty" to magically remove CO2, or, with MissionController, using "Fill" to give yourself free fuel on the launchpad instead of paying for it). Might you allow these functions to be disabled in the config file? Your Checklists concept sounds interesting, but it seems to me that it would make more sense as a separate mod. It seems that ShipManifest has a cohesive purpose as a "transfer utility" and, while vaguely related, your Checklists concept serves a separate purpose. I can certainly imagine some players wanting one or the other (i.e., ShipManifest or Checklists) without wanting both. Alternatively, simply allowing features to be disabled in the config would also be reasonable and appreciated. Last but not least, if you would consider integration with the new Connected Living Space API, you would be my hero. You could make it optional via the config file, of course, for those who don't want it.

Papa_Joe, I think it's admirable how responsive you've been to players' requests, but I'd also like to voice concern regarding feature creep. This mod started out as a lightweight alternative to the TAC FB + CrewManifest combo; an uncomplicated tool to move Kerbals and resources from one module to another. This was exactly what I was looking for. However, this mod continues to add additional features, with plans to add even more, to the point that I'm considering switching back to CrewManifest + TAC FB, because it's starting to look like that combination might actually contain less bloat than what ShipManifest is headed toward. Of course it's your mod, and thus entirely up to you what you want to do with it, but I just wanted to speak up - in a thread largely filled with players requesting features - as someone who hopes you *don't* add more features.