[1.12.x] SimpleFuelSwitch v1.4.2: Toggle tanks' fuel type in the editor. Simple and lightweight.

[DStaal]

21 minutes ago, Snark said:

Anyway, that explains it.  Thanks for the investigation, @4x4cheesecake!  I expect I'll just tweak things to move them appropriately as suggested.

Why?  Why move them?  As long as it's understood that they'll unlock at a specific tier level, and that looking for them in the same tier as the LF tanks doesn't work, why make the change?

If you do want to have the parts unlock at the lower tier level, why not just hide the LFO tanks and use the LF tanks instead?

(I never like the idea of a mod changing the properties of stock parts unless it's an explicit feature of the mod - this feels like it's very tangential to the purpose of the mod, which to me is more likely to surprise people than just having the tanks unlock later.)

[Snark]

41 minutes ago, DStaal said:

Why?  Why move them?

Because of exactly the problem that @Behemot ran into.

42 minutes ago, DStaal said:

If you do want to have the parts unlock at the lower tier level, why not just hide the LFO tanks and use the LF tanks instead?

Yes, that's the other option.  If I'd realized this issue from the get-go, that's absolutely what I would have done.  My only concern at this point is that I've already released SimpleFuelSwitch with the hide-the-LF-tanks config in it, and presumably people have already built ships with those in it, so I'd hate to discommode them.

This is something that I literally just found out about within the last hour, and I'm kinda busy (I do have a day job, guys), so I'll need to mull it over.  If folks have opinions on the matter, feel free to weigh in-- this is one of those choices that I'm ambivalent about, because I myself never use those tanks anyway, so I don't have a good feel for how folks would likely prefer it.

[DStaal]

5 minutes ago, Snark said:

Yes, that's the other option.  If I'd realized this issue from the get-go, that's absolutely what I would have done.  My only concern at this point is that I've already released SimpleFuelSwitch with the hide-the-LF-tanks config in it, and presumably people have already built ships with those in it, so I'd hate to discommode them.

I'll freely admit my voice probably shouldn't be your top choice to listen to (I've enough other fuel switchers that there's no benefit to me to install this), but here's my opinion:

Since it's just a 'hide' config, it won't break ships if you change it.  That to me is the least impact on the rest of the game you could have: No parts moved from their tech levels, all options possible.  People's current ships would work fine, and new ships would be built with the new parts.  I believe the parts would even stay unlocked in the same save, so you you wouldn't even get warnings if you open the ships in the VAB/SPH.

The only lower impact on the game would be to leave everything as it is - which would cause the occasional 'huh, where's those parts?' - but wouldn't actually prevent them from being used.  Anything else is more impact, in that you're moving something from where it's expected to be.

[Snark]

6 minutes ago, DStaal said:

<excellent points>

Yeah, when you put it that way, that makes a whole lot of sense. 

Anyone else have an differing viewpoint?

[Behemot]

DStaal: You do, just got whacked by experimental small tank when loading some of my ancient ships, one of the Mk3 removed ones I believe (replaced by FT-400 or FT-800 LF variant).


 

Edited January 24, 2019 by Behemot

[4x4cheesecake]

18 minutes ago, Snark said:

Yes, that's the other option.  If I'd realized this issue from the get-go, that's absolutely what I would have done.  My only concern at this point is that I've already released SimpleFuelSwitch with the hide-the-LF-tanks config in it, and presumably people have already built ships with those in it, so I'd hate to discommode them.

I'm pretty sure that you can add the fuel switch module to every MK3 LF & LFO tank and hide the LFO tanks instead of the LF tanks to keep compatibility with existing crafts since the parts are not removed, just hidden.

On the other hand: While using this mod, there is no point to have the LF and LFO tanks in different nodes, since you will always get both version as soon one is unlocked. There is aboslut no difference in the result: one of both nodes will miss some parts or, if someone doesn't want to hide anything, you will unlock some twin parts without any affect on the gameplay.

There is actually just one little detail that will be affected: the texture. Right now, you'll get the LFO tanks with black stripes. Moving the parts to a different tech node will keep the texture, if you keep the default tech nodes and hide the LFO tanks instead, you will get the clean white texture.

So far the technical site.

Personally, I don't really care since I'm using my own config and don't hide any parts at all, so I'm fine with any decision you'll make, but it is probably a bit more elegant to leave the parts in the nodes where they are

[Snark]

20 minutes ago, 4x4cheesecake said:

There is actually just one little detail that will be affected: the texture. Right now, you'll get the LFO tanks with black stripes. Moving the parts to a different tech node will keep the texture, if you keep the default tech nodes and hide the LFO tanks instead, you will get the clean white texture.

Or I could just define the part as having two variants, one for LFO and one for LF, with the corresponding texture available for each.

I expect I won't do that, since it would be inconsistent with everything else.  But it's nice to know that the system is flexible enough that it would be possible to do with config, if one were so inclined. 

[4x4cheesecake]

1 minute ago, Snark said:

Or I could just define the part as having two variants, one for LFO and one for LF, with the corresponding texture available for each.

Ohhh, I totally forgot about the variants. I'll probably implement that for my install

[theJesuit]

I have added support for this mod to SIMPLEX Resources.

https://spacedock.info/mod/2045/SIMPLEX Resources

Previous SIMPLEX Resources contained a different colour coded Ore tank, based on the stock ones, ie. Large, Small, Radial for each for the SimplexOres.

Using the variant system, these are able to combined into one of each size!  And the colour variants choose which resource.

Thanks @Snark!

Peace.

[Snark]

27 minutes ago, theJesuit said:

I have added support for this mod to SIMPLEX Resources.

Hey, that's great news! 

Added a link to the OP of this thread.

[Snark]

Hi gang,

I've released SimpleFuelSwitch version 1.1.2.  No major new features; here's what it does:

• Bugfix:  don't remove extra "unswitched" resources from parts that have switchable resources.  (e.g. on the conical Soyuz fuel tank from Making History, don't clobber the small amount of SRB fuel for the built-in sepratrons, just because the main fuel tankage is now LF-LFO switchable)
• Bugfix:  there were some edge cases where resources weren't properly getting set up when loading a ship in flight.
• A bit of refactoring for the "hide redundant parts" config, thanks to an issue that @Behemot discovered.  The TL;DR is that instead of hiding the LF tanks, I now hide the LFO ones instead.

Enjoy! 

[EDIT]  Please don't use this version, I introduced a pretty bad bug (see below).    I fixed the bug in 1.2, please use that version or later.

Edited February 1, 2019 by Snark
This version's deprecated, due to the bug.

[theonegalen]

On 1/10/2019 at 4:31 PM, 4x4cheesecake said:

Oh, that's because the mod works just with stock parts and I'm pretty sure that's intended

@Snark adresses the LF tanks by name and not by the resource so no mod part will be affected.

edit: on the other hand, it works with LFO tanks....now I'm confused

That's because he uses a Boolean (?) search (:HAS[RESOURCE[LiquidFuel]]&[RESOURCE[Oxidizer]]) to target the LFO tanks, and deprecated the liquid fuel tanks that the LFO tanks could replace.

@Snark what would you say to adding the deprecated LF airplane styled tanks as a part variant of the non deprecated LFO tanks?

Also, will you accept configs for mod parts?

Edited January 28, 2019 by theonegalen

[4x4cheesecake]

6 minutes ago, theonegalen said:

That's because he uses a Boolean (?) search (:HAS[RESOURCE[LiquidFuel]]&[RESOURCE[Oxidizer]]) to target the LFO tanks, and deprecated the liquid fuel tanks that the LFO tanks could replace. 

I wasn't confused about the method itself, I was confused why LF and LFO tanks are adressed differently (and I actually still don't know why).

It would be easy to adress the LF tanks via :HAS[@RESOURCE[LiquidFuel],!RESOURCE[Oxidizer]] so it will also be applied to every mod part which got LF tanks but instead, it is done by names.

[Snark]

51 minutes ago, theonegalen said:

 

@Snark what would you say to adding the deprecated LF airplane styled tanks as a part variant of the non deprecated LFO tanks?

Well, gosh darn it, why didn't somebody say that before I just released the update? 

Oh well.  Anyway, yeah, that's a nice idea.  I'll do that the next time I release an update (it's not something that seems worth releasing an update for, all by itself).

52 minutes ago, theonegalen said:

Also, will you accept configs for mod parts?

Not quite yet.  My idea is to create a companion "community extensions" mod-- kind of like what I did for IndicatorLights Community Extensions-- that could be a convenient repository for community-supplied mod config.

In the meantime, though, if you've got something you'd like to share, feel free to post links to it here, and then hopefully I can give it a proper home when I get the other mod set up (when time permits, I'm kinda busy).

[RealKerbal3x]

@Snark

Noticed this evening that you added the loading hint ‘Thanking RealKerbal3x’

Cheers, and it’s great that my humble feature request could make its way into your mod

[Snark]

5 minutes ago, RealKerbal3x said:

Noticed this evening that you added the loading hint ‘Thanking RealKerbal3x’

Shhhh!  Don't tell people about the little Easter egg. 

[theJesuit]

Ah was that you @Snark?  Cheers for the shout out too 

Peace.

Edited January 29, 2019 by theJesuit

[ExtremeSquared]

I feel like this issue is new in the past release, I remember this working properly before...

No math is being done to LiquidFuel on switching.

LF-->LFO switch: Proper Ox calculated. LF Remains same

LFO--LF switch: LiquidFuel amount carries over from LFO tank value.

Can anyone else recreate this? Thought Tweakscale may have been messing with it, but verified without TS.

Edit: Verified on pure stock.

Edited February 1, 2019 by ExtremeSquared

[Snark]

18 hours ago, ExtremeSquared said:

I feel like this issue is new in the past release, I remember this working properly before...

No math is being done to LiquidFuel on switching.

LF-->LFO switch: Proper Ox calculated. LF Remains same

LFO--LF switch: LiquidFuel amount carries over from LFO tank value.

Can anyone else recreate this? Thought Tweakscale may have been messing with it, but verified without TS.

Drat.  Yep, you're absolutely right, that appears to have gotten borked.  Sigh.

Anyway, thanks for the report!  Will get right on this.

[Snark]

Howdy folks,

I'm pleased to announce the release of SimpleFuelSwitch version 1.2.  New in this release:

• A compatibility patch to support TAC Life Support.
• The "removed" Mk2 and Mk3 fuel tanks are now available as part variants on the remaining tanks.  (Thanks to @theonegalen for suggesting!)
• Fix a pretty awful bug that I introduced (sigh...) in version1.1.2.  (Thanks to @ExtremeSquared for reporting!)

The TAC Life Support patch greatly reduces part clutter by eliminating a lot of parts, using part variants to switch the resources instead.  For example:

Previously, that would have been four different parts.  Now it's just one part, with four variants.

There are seven different sizes of TAC-LS containers I've done this way-- i.e. reduced 28 parts down to 7, for a net reduction of 21 parts.  (I did this because I love TAC-LS, but I always get lost on the "life support" tab of the vehicle editor, because there are a bazillion parts and they all look nearly identical in the thumbnails.  Always takes me forever, rummaging around to find the one I want.)

Anyway, enjoy!

Hopefully this release will fare a bit better than 1.1.2 did.  Sorry about that bug! 

[theJesuit]

I've been thinking about the engine variants and their lack of mass changing with boat tails and such.

There could be 'mass' resource that is actually hidden and non tweakable.  Then when the boattails are selected they gain this heavy resource.  This could also be added to the new Mk2 landercan as well for the bigger variant.

This would make the stock variant system more realistic IMHO.   Would it work @Snark ?

[Snark]

12 minutes ago, theJesuit said:

There could be 'mass' resource that is actually hidden and non tweakable.  Then when the boattails are selected they gain this heavy resource.  This could also be added to the new Mk2 landercan as well for the bigger variant.

This would make the stock variant system more realistic IMHO.   Would it work @Snark ?

I mean, it would "work", I suppose, though "hidden" is impossible I think.  But it would also be completely unnecessary because the stock variant system supports varying mass.  (Most aspects of a part can't be changed by switching variants, but mass is just about the only thing that can.)  You can see this at work with the engine plates (the different length variants have different masses).

So if anyone wanted to make the different engine variants have different masses, it's just a trivial ModuleManager patch-- there would be no need for SimpleFuelSwitch at all, it simply wouldn't be relevant.

[RealKerbal3x]

@Snark just a thing, you're still packaging MM version 3.1.2 in the download, rather than 4.0.1 (the latest version)

[Snark]

2 hours ago, RealKerbal3x said:

@Snark just a thing, you're still packaging MM version 3.1.2 in the download, rather than 4.0.1 (the latest version)

Sure, and there are a couple of reasons for that.

The first reason is stability. The most likely time to discover bugs in a piece of software is when it's fresh; that's the least stable time. MM 4.0.0 just came out recently, and was apparently a fairly major code upgrade; they've already released 4.0.1 just a few days later, due to some bugs discovered in 4.0.0. Who's to say that 4.0.1 may not have some bugs of its own? If I packaged my mod with a MM version that turns out to be buggy, then I'd feel obliged to release yet another version of my own mod, and I hate "version spam". Better to give the new MM a little time to "bake" so that it can work out any kinks before I package it.

The second reason is that I forgot to check MM's recent release history before I did my own release.

[Tonka Crash]

@Snark I'm ran into a devious little MM issue with the Add_LF_to_LFO_tanks.cfg and Add_LFO_to_LF_tanks.cfg patches.

TLDR: You need to add the directive :FOR[SimpleFuelSwitch] to your patches.

Spoiler

 

I create a few tanks that are rescaled from stock tanks and I also add fuel to several of the hollow aero parts. I used the Missing History patches as templates to do this. These have worked fine until I started using SimpleFuelSwitch. The problem I was seeing was that my tanks weren't patched correctly by the SimpleFuelSwitch patch where the Missing History tanks that I based my patches on were just fine. 

1. The aero parts (nose & tail cones) with added fuel did not have SFS applied at all. SFS seems to have run before they were created
2. The rescaled parts were not getting the correct fuel quantities. It appeared the SFS had run on the original part before my rescaled part was created, so my changes to the stock RESOURCE nodes don't have anything to adjust and I just get the SFS resources of the original part.

Without SFS all my tanks are created just fine. I tracked the problem to patch ordering. 

1. I could move my patches from GameData\ZZZ_Personal_Patches to GameData\AAA_Personal_Patches and SFS patched my tanks correctly 
2. :BEFORE[SimpleFuelSwitch] had no effect and it appears it won't without a :FOR for the mod
3. I ended up adding :FIRST to each of my parts to force the patch to run before SFS, but this feels like a band-aid.
4. I could use :NEEDS[SimpleFuelSwitch]:FINAL to correct the errors introduced by using SFS, but why should I?
5. I found adding :FINAL or :FOR[SimpleFuelSwitch] to the SimpleFuelSwitch allowed SFS to patch my tanks correctly.

From https://github.com/sarbian/ModuleManager/wiki/Patch-Ordering:

1. Nodes with no operator ('insert') are loaded by the KSP GameDatabase first.
2. Patches for modname values in NEEDS, BEFORE, AFTER that don't exist are removed.
3. All patches with :FIRST are applied. (I have to run my patches here, but shouldn't need to)
4. All patches without an ordering directive (:FIRST, :BEFORE, :FOR, :AFTER, :LAST, :FINAL) are applied. (SFS runs it's patches here, before I have a chance to run mine)
5. For each item in the Unicode-sorted list of modname values:
   • All patches with :BEFORE are applied
   • All patches with :FOR are applied (SFS should run here)
   • All patches with :AFTER are applied
6. All patches with :FINAL are applied 

What isn't explicitly stated (but I think I saw this comment somewhere) is that patches without directives are applied in alphabetic order of the directories in GameData. Since my patches are in a directory ZZZ_Personal_Patches they run after SimpleFuelSwitch has its pass, so I wasn't getting the right results. Changing the directory name to AAA_Personal_Patches had the same effect as using :FIRST since it moved my patches ahead of SFS, but this created other problems for me since I'm lazy about using directives if my patches work without them. If you'd named your mod something like LiquidFuelSwap your Missing History tanks would have the same problems I was seeing.

As it is any mods that alphabetically install in the GameData directory after SimpleFuelSwitch may have problems with this mod's patches if they add or change the stock resources after your patches run. I realize adding :FIRST fixed the problem for me, but like I said this feels like a band-aid and I think it should be on the mod author to create patches that work regardless of alphabetic ordering. I didn't even think of using :FOR until I was writing up this bug report and had to go check it. The :FOR directive delays the patches for the named mod from running until everything without a directive has had a chance to run (my patches). Players still have :BEFORE, :AFTER and :FINAL to address patches around your mod if needed. From what I found it looks like :BEFORE and :AFTER can't work unless :FOR is used by the mod.