New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bring Part Count Down: Switch Mod #12
Comments
I've seen really good results with IFS and also have seen the folks who maintain it are active and knowledgable. |
Part count is a great thing to address! Let me know if you need help. |
Note there is the TacLifeSupportMFT dir that has some overrides if Modular Fuel Tanks or Real Fuels is installed. Those are then used for "fuel switching". Basically, this confdir hides all the usual containers (inline/hexcan), then adds special new "MFT" parts, e.g. I've not tested with either of these, though, so not sure it still works. The MFT-type inline containers (but not hexcans) seem to be lacking a P.S. Providing this functionality via "integrated plugin" or "hard mod dependency" rather than "optional mod dependency" is still better for many reasons (IMO). |
BTW, I intended to add support for Community Tech Tree back today (and submit a PR), but that'd be a lot of tech debt when integrating a "fuel switch". So I'm currently looking into the differences between and examples of If someone's done a similar review, that'd be nice to see. |
...Actually, played around with I now think that
I'll go work on a PR for this, if no one minds. |
Working in this branch ATM. Done with inline containers. HexCans might be trickier due to different directory structure. I'm moving the "one-resource-one-part" parts to EDIT: done with HexCans, will test a tiny bit now and continue next week (I hope). |
@keyspace I'm not sure I totally agree with this approach and would like to understand your motivation, background, etc? I don't agree with the approach of adding a key hard mod dependency. |
BackgroundNot sure what you mean, maybe the following is relevant. I've done no large-scale mod development, and am not closely familiar with the available choices and trade-offs in this case. I'm not using However, since I first installed I also play career-only; the part clutter in Tech Tree's unresearched nodes is even more annoying, since it makes finding those wanted parts very difficult. (I've actually use Tried It makes more sense for me to bring the part count down first, and then add I've been thinking about it previously, but was always stopped by the fact that This is why I'm here. MotivationReusing available code from a (reasonably) well-maintained project seemed to me like a better option than re-implementing a fuel/texture switch from scratch. Probably because I only really use C# for KSP's mods, and could never find complete API documentation from Squad. That, and the original post suggested this is a valid approach. I've reviewed several, and they were all derived (source-wise or ideologically) from an earlier implementation in Another approach, I guess a simpler one, would be to "rip" the relevant code out (texture, fuel). |
... I'm rarely this verbose. Actually, here it is to aid review. |
Can continue the discussion after KSP 1.2 release. |
That's perfectly understood (and agreed on).
Can't guarantee I'll stick at all - time constraints. This was a one-off for me to address old personal "grudges". |
I've made no decisions about which switch mod to integrate: B9partswitch, IFS, Firespitter, etc. Using our newfangled beautiful textures, I'd like to integrate some sort of switching on a much smaller list of parts so the small container can have editor selectable variants: food, water, oxygen, waste products, etc. We can cut the container part count by 75% if we have single parts with switch behavior for each size profile.
The text was updated successfully, but these errors were encountered: