Bring Part Count Down: Switch Mod

[danfarnsy]

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.

[cherrydev]

I've seen really good results with IFS and also have seen the folks who maintain it are active and knowledgable.

[james3838]

Part count is a great thing to address! Let me know if you need help.

[keyspace]

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. TacLifeSupportMFTContainer. This should allow vessels with non-MFT parts to operate after installing MFT/RF.

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 MODEL definition.

---

P.S. Providing this functionality via "integrated plugin" or "hard mod dependency" rather than "optional mod dependency" is still better for many reasons (IMO).

[keyspace]

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 B9PartSwitch / IFS instead. (IFS seems to have a superset of Firespitter's properties BTW.)

If someone's done a similar review, that'd be nice to see.

[keyspace]

...Actually, played around with Firespitter Core (which I already had a DLL of as USI's dependency), and got it to work pretty well. Here's a LifeSupportTest part that's derived from LifeSupport (the flat inline one). All the changes are two MODULEs at the end.

I now think that Firespitter Core is the best way to go, since it's:

• used by many mods, and therefore likely to be on many installations already;
• simple and fills the requirements (simultaneous switching of textures and cargo);
• won't change other facets of gameplay, or parts not belonging to TAC-LS.

I'll go work on a PR for this, if no one minds.

[keyspace]

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 Legacy directories so that vessels don't get broken due to missing parts, but this also requires being careful with texture locations.

EDIT: done with HexCans, will test a tiny bit now and continue next week (I hope).

[JPLRepo]

@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.

[keyspace]

Background

Not 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 RO and am not in touch with the general vision and development plan of RO's community.

However, since I first installed TAC-LS (a year ago?.. two?..) I was annoyed by the clutter it introduced in the parts list.

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 grep instead to find the parts and nodes I want, because it's faster.)

Tried Community Tech Tree, but a lot of mods don't use that, including TAC-LS. There's a disabled unpopulated config, which I intended to populate; but that would be useless mechanical work if most of the containers were to be removed, - work adding now and work removing later; technical debt, in other words.

It makes more sense for me to bring the part count down first, and then add CTT compatibility (because a Large Snack Can among heavy rockets makes no sense either way).

I've been thinking about it previously, but was always stopped by the fact that TAC-LS has a C# solution that's not tailored to my setup (MonoDevelop on Linux). Seeing how @taraniselsu stopped maintaining a while ago, and not much development happening now, I decided I'll step in and do the things I need done.

This is why I'm here.

Motivation

Reusing 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 Firespitter called FStextureSwitch. The latter didn't have capability to switch both fuel types and textures simultaneously, which the other mods went on to implement. Now Firespitter has FStextureSwitch2, which does have this capability.

Another approach, I guess a simpler one, would be to "rip" the relevant code out (texture, fuel).

[keyspace]

... I'm rarely this verbose. Was about to submit that PR, but you're right, this can wait.

Actually, here it is to aid review.

[JPLRepo]

Can continue the discussion after KSP 1.2 release. Too many changes to test this close to a major release change. I'm not saying I don't agree and don't see it as blocking. My background is from I.T. and I am not into implementing changes without rigorous testing and this close to a release. I've been busy bringing the code up to date and testing it. This change would mean I'd have to re-do testing. Given no one has come forward to help with that testing (I put out a request when I took over) it's just me so with the limited resources this has to wait. If you are volunteering to become part of the team then can certainly discuss that.

[keyspace]

I am not into implementing changes without rigorous testing and this close to a release.

That's perfectly understood (and agreed on).

If you are volunteering to become part of the team then can certainly discuss that.

Can't guarantee I'll stick at all - time constraints. This was a one-off for me to address old personal "grudges".