Fraz86

I'd love to see a change from the current "per module" qualitative system to a "total vessel" quantitative system. For example, each module could be assigned a "comfortLevel" ranging 1 to 30 (with "1" being a mk2 cockpit and "30" being a large inflato). Then add up the total comfortLevel for the whole vessel, and divide that by the number of Kerbals on the vessel to determine the "meanComfortLevel". From there, an algorithm could be used to determine the fitness loss per day. This algorithm could be as simple as: fitnessLoss = 0.5 * (10 - meanComfortLevel) [if fitnessLoss <0, then fitnessLoss = 0], yielding a range of 0% to 4.5%, with a requirement of at least 10 comfortLevel per Kerbal to remain fitness neutral. Even more ideally, I would change that if/then to "if fitnessLoss <0.5, then fitnessLoss = 0.5," yielding a range of 0.5% to 4.5% fitness loss per day, and make it such that only the presence of gravity can allow a neutral/positive fitness level (and allow centrifuge parts to provided a limited amount of gravity, divided among the Kerbals on the vessel).

Are you planning to include a built-in crew transfer capability (between contiguous modules), or do you plan to leave this to other modders utilizing your plugin? I certainly understand your desire to keep your plugin minimal, but transfer functionality seems pretty much intrinsic to the concept of your mod...

I'd argue that this whole plugin serves to increase immersiveness, because, as you point out, defining a contiguous habitable area has minimal implications for gameplay. So, my proposal is based on what seems most immersive to me, which would be only allowing habitable areas to connect in places where they appear to have been designed to do so.

Basically, it allows you to easily edit the content of part cfg files (from stock or mods), without actually messing around with the individual files. So, you could use a single cfg file to add all of your node definitions. It would look like this: @PART[mk1pod] { [passable node definition here] } @PART[mk1-2pod] { [passable node definition here] } etc.

Upon further consideration, I'd like to argue in favor of completely disallowing surface attachments as passable nodes. It's simply too abusable, allowing players to slap on Radial Attachments to create passable nodes anywhere they desire, including clearly impassable parts of a module. Surface attachments would also be immersion-breaking in regard to consistency with the IVA view. Along similar lines, when deciding which nodes are passable or not, it seems to me the most intuitive and immersive solution is simply: does the node visually appear intended to function as a passable hatch? I understand this is impossible to code as a heuristic, but I don't think it's necessary to have a perfect heuristic, given how easy it will be to add the needed config definitions via a ModuleManager file.

I would suggest that surface attachments should not function as passable nodes by default behavior. Only a few specific parts should have that functionality, such as the BZ-62 Radial Attachment Point and the Clamp-O-Tron Docking Port.

The mk1-2 pod actually does visually have hatches on both the top and bottom nodes (and it does not have a heatshield).

I think something odd happened to the model for the small fission reactors. I could have sworn they used to have vertical brackets on both sides (like the larger model), but now they only have a bracket on one side.

I think that's an acceptable number of tris. Obviously on the high side, but shouldn't be a problem unless you're using quite a few of them on one ship. And again, I really like that texture. In that picture, comparing the texture of the tank inside the truss versus the texture of the tank attached to the engines, I feel that the one inside the truss looks much more "Kerbal," which in my opinion is a good thing.

As you said, the truss is a large, complex part, so a high poly count is expected. Just how high is it? Regarding textures, I actually really like the look of the tank inside the truss in your second picture above. Looks like texture #4 from the 5 possibilities you presented earlier, right? I understand the desire to use a more foil-appearing texture, but I think the aforementioned texture would fit in well with stock parts (whereas more "realistic" textures might look a bit more out of place, perhaps).

I noticed that the OP now states, "Realism Mode: Solid fuels cannot be moved." Has this feature already been implemented? Does it apply to other non-transferable resouces (added by mods)? Secondly, I realize this is a somewhat silly request, but in general I prefer not to have in-game access to "cheaty" settings options (such as realism vs casual mode), as I find it to be slightly immersion-breaking if I know that I can turn off realism mode in mid-flight. Thus, I'd prefer for mode to be configured via an external config file (or to have an external config file with a lockRealismMode option). Obviously not highly important, though, so I only request this if it's easy to implement.

I've been wanting something like this for a long time. In fact, I've been using a modified version of TAC life support to roughly implement habitation requirements, with resources named "Health", "CabinFever", and "Deconditioning". A few brief comments regarding your implementation: -I'd prefer that a Kerbal's comfort level be calculated entirely based on the ship as a whole, not taking into account the module in which they happen to be located. I think it should be assumed that Kerbals are taking breaks and using all available space naturally without needing to be micro-managed. Manually rotating crew members between modules so each of them gets rest/exercise on a long interplanetary voyage sounds like an unpleasant hassle. -Exercise can only compensate for the effects of weightlessness to a limited extent. Adequate living space should be the primary concern for medium-length voyages, but fitness should continue to gradually decrease unless the Kerbals have some form of gravity (e.g., centrifuge module, continuous acceleration, or being on a planet).

Any news regarding disabling the ability to transfer resources who's resource definition includes "transfer = NONE"?

You could make a Porkworks/Textures folder containing all the texture files used by more than one parts folder, then have all the relevant parts refer to that folder. That way you avoid loading redundant copies of the same texture AND nothing breaks if some parts folders are deleted.

Is it possible to configure a TacGenericConverter to be turned on by default or "always on"?

Presumably I also need to replace "extractionRateLandPerTon" and "extractionRateOceanPerTon" with a field appropriate for the atmosphere. I've tried "extractionRateAtmospherePerTon" and simply "extractionRatePerTon", neither of which seem to work. Also, is there an easy way to activate a part animation when extracting?

I understand that ORSModuleResourceExtraction can be used to extract crust or ocean resources. Does this plugin come with a built-in module for extracting atmospheric resources?

This looks great! Do you plan to incorporate orbital resources as well (e.g., like antimatter in KSPI)?

The centrifuge IVA is incredible; easily my favorite IVA. Great work, Porkjet!

That will probably work for the wetworks mod, I think. Will the config allow us to define different animation states to monitor for different modules (e.g., inflated/deflated for porkjet's modules versus ejected/nonejected coverings for Lunaran's wetworks)?

That's excellent! Can't wait for your next release! Also, I imagine the plugin would be of use for Lunaran's wetworks plugin as well.

What does it do?

Why would it be cheating? There's plenty of Kethane on Kerbin (and it's very easy to mine), so it should be readily available to the space program. Moreover, given that kethane has a worse delta-V to mass ratio than any other fuel, I can't imagine many scenario's in which it would be desirable to build rockets with full kethane tanks.

Perhaps this has already been answered, but where should a mod include its custom textures in order to be loaded by KSPARP?

It seems to me that resources defined as "NO_FLOW" in the resource config (e.g., solid fuel) should certainly not be transferable. I love the idea of your mod, but if it allows transferring resources that clearly aren't meant to be transferable, then it's just plain cheating.