[1.4.1] Fuel Tanks Plus 2.0.2 (2018-03-14)

[NecroBones]

 

@AccidentalDisassembly, @ttbs,

It's possible it's relating to the mesh switching, I don't really know. Does it do this with InterstellarFuelSwitch, or Firespitter, or both? The most likely thing is the switching, since I can't think of anything else that could possibly cause that on a per-tank basis.

 

 

[FreeThinker]

1 hour ago, NecroBones said:

 

@AccidentalDisassembly, @ttbs,

It's possible it's relating to the mesh switching, I don't really know. Does it do this with InterstellarFuelSwitch, or Firespitter, or both? The most likely thing is the switching, since I can't think of anything else that could possibly cause that on a per-tank basis.

 

 

What might happen, is that an internal exception causes other partmodules to mal function. What is important to find out is what version what used and what exception were thrown (if any) in the Log

[AccidentalDisassembly]

Can report at least this: in my testing directory, if I have ONLY firespitter installed, the error does not occur.

If I have Firespitter AND B9PartSwitch installed, placement is impossible.

I am thinking your (very complicated) fuel-switching patch has some issue in it where multiple modules are being applied to parts.

I am also wondering why in that patch you've got all of this conditional stuff set up - why not, for FTP or other parts, simply choose one fuel/part switcher that does everything you need, then simply use the patch to delete ALL fuel switching modules from your parts and apply that one? Wouldn't that simplify the patch a lot?

Otherwise, if having two different switchers is really necessary for some reason, maybe there's a conflict between FS and B9 (and/or Interstellar too)...

Edited May 4, 2016 by AccidentalDisassembly

[NecroBones]

 

 

 

It's set up conditionally like that so that you can use whichever of those switchers you want. It only applies the modules for one of them, even if you have all three installed. There is never a case where it actually uses more than one at a time (except I have some of the fuel switching moved over to B9, but not all, so if that one is in the mix, some parts will use B9 for the mesh switching, but one of the others for fuel switching).

 

The only way to truly simplify the configuration is to remove support for other switchers and only support one, which people would be forced to use if they want to use FTP. I've been trying to avoid that, for the sake of compatibility and user friendliness.

 

If it's breaking with B9 in there, then I'm inclined to think B9 doesn't play nice when it's being used for mesh switching, but with IFS or Firespitter handling the fuel switching. I can try to address that part by building out the rest of the B9 configs that aren't there yet, but if the incompatibility comes from having B9 and FS/IFS installed together, whether or not their modules are applied, then there's nothing I can do about that part.

 

The attachment nodes never change at all, and the part placement should only care about those. So why there are attachment problems at all, must be related to the switchers themselves.

 

Someone over in the IFS thread did some tests with part placement with IFS, and other IFS-based fuel switcher packs are having similar issues, not just FTP.

 

[blowfish]

@NecroBones Yeah, B9PartSwitch doesn't check that it actually manages resources before declaring incompatibility with FSFuelSwitch or InterstellarFuelSwitch.  That's another enhancement I could make.  The whole incompatibility system is really a relic of some pre-1.1 issues anyway, so replacing it with more targeted logic is probably a good thing

[FreeThinker]

Version 1.30 for Kerbal Space Program 1.1.2

Released on 2016-05-04

• Fixed exceptions while switching to Liquid Fuel in radially attached tanks

Edited May 4, 2016 by FreeThinker

[NecroBones]

51 minutes ago, blowfish said:

@NecroBones Yeah, B9PartSwitch doesn't check that it actually manages resources before declaring incompatibility with FSFuelSwitch or InterstellarFuelSwitch.  That's another enhancement I could make.  The whole incompatibility system is really a relic of some pre-1.1 issues anyway, so replacing it with more targeted logic is probably a good thing

 

Cool yeah. It's also just taking me some time to get some B9-only patches working too, since they layout is different and I'm going to calculate things a little differently.

[NecroBones]

 

Also, @blowfish, is there a tutorial or listing of the various variables for B9PartSwitch? I want to make sure I'm using things like the tank mass/cast and addedMass values correctly, or at least sensibly. Does it also have texture switching? One set of my tanks is doing that instead of mesh switching.

 

[AccidentalDisassembly]

4 hours ago, NecroBones said:

It's set up conditionally like that so that you can use whichever of those switchers you want. It only applies the modules for one of them, even if you have all three installed. There is never a case where it actually uses more than one at a time (except I have some of the fuel switching moved over to B9, but not all, so if that one is in the mix, some parts will use B9 for the mesh switching, but one of the others for fuel switching).

The only way to truly simplify the configuration is to remove support for other switchers and only support one, which people would be forced to use if they want to use FTP. I've been trying to avoid that, for the sake of compatibility and user friendliness.

If it's breaking with B9 in there, then I'm inclined to think B9 doesn't play nice when it's being used for mesh switching, but with IFS or Firespitter handling the fuel switching. I can try to address that part by building out the rest of the B9 configs that aren't there yet, but if the incompatibility comes from having B9 and FS/IFS installed together, whether or not their modules are applied, then there's nothing I can do about that part.

The attachment nodes never change at all, and the part placement should only care about those. So why there are attachment problems at all, must be related to the switchers themselves.

Someone over in the IFS thread did some tests with part placement with IFS, and other IFS-based fuel switcher packs are having similar issues, not just FTP.

OK, that makes total sense, thanks!

Edited May 4, 2016 by AccidentalDisassembly

[blowfish]

43 minutes ago, NecroBones said:

Also, @blowfish, is there a tutorial or listing of the various variables for B9PartSwitch? I want to make sure I'm using things like the tank mass/cast and addedMass values correctly, or at least sensibly. Does it also have texture switching? One set of my tanks is doing that instead of mesh switching.

I haven't created one yet.  At this point I think it's time, given that it's seeing a lot of usage outside of B9.  I'll create a real thread and a wiki at some point but for now here's just a quick rundown.  Feel free to ask me directly if you have any questions (either here, or via private message, or on IRC)

Spoiler

ModuleB9PartSwitch

• moduleID: A unique identifier that is used to identify the module to ModuleManager patches and for symmetry purposes.  It can be blank if there's only one ModuleB9PartSwitch on a part, but I usually fill it anyway
• baseVolume: Amount of tank volume this switcher has (can but is usually not modified by the subtype)
• switcherDescription: A string that goes in the part action window (e.g. "Tank Type").  Defaults to "Subtype" (note: the pluralized form that appears in the part catalog isn't yet editable but I will make it at some point)
• currentSubtypeIndex: Used to keep track of the current subtype.  Set in the config if you want the default to be something other than the first.
• affectDragCubes: Whether drag cubes should be re-rendered on switching.  Defaults to true.  Drag cubes will never be re-rendered if no transforms (i.e. meshes/objects) are managed by this switcher
• affectFARVoxels: Whether to trigger FAR (if installed) to re-voxelize the craft when the subtype is switched.  Defaults to true.  Won't trigger if no transforms are managed regardless
• SUBTYPE: each node represents a subtype
  • name: A name for this subtype.  No restrictions, but good practice is to have it ModuleManager readable (i.e. no spaces)
  • title: Human readable name that appears on the GUI.  Will be auto filled from name if blank.
  • transform: name of Unity transform(s) which should be enabled on this subtype (it will be disabled on all others unless they also have it).  Multiple are allowed, so you can have transform = a and transform = b on separate lines.  If multiple transforms have the same name they will all be included.
  • node: Attach node id for stack nodes that should be enabled.  Couple of points here: (1) KSP strips out the node_stack part when creating the node id, so node_stack_top01 will be come top01 (2) This is done as a partial text search, so top will match top01 and top02
  • addedMass: Mass that is added by this subtype in addition to tank mass
  • addedCost: Cost added to the subtype (in addition to tank cost and resource cost)
  • tankType: name of the B9_TANK_TYPE this subtype should use
  • volumeMultiplier: Multiplies the base volume
  • volumeAdded: Adds to the base volume (I usually use this over the multiplier)
  • maxTemp: Will set the part's max temp to this when the subtype is active.  If not set it will use the prefab's
  • skinMaxTemp: Will set the part's skin max temp to this when the subtype is active.  If not set it will use the prefab's
  • attachNode: If set, will change the part's surface attachment node to this.  Only works if the part is already surface attachable.  Subtypes that don't have this defined will use the prefab's.  Follows the usual node format of position x, y, z, normal x, y, z, size

There are a few uniqueness constraints between different ModuleB9PartSwitch modules on the same part.  As above, moduleID must be unique between them.  Two cannot modify the same resource, transform, or node.  Only one can manage the maxTemp, skinMaxTemp, or attachNode.  If these collisions occur, an error will be logged and one of the modules will be removed.

Note about the resource switching: ModuleB9PartSwitch will only modify resources that it "owns," i.e. ones that are on the tank type of one of its subtypes.

Tank Types

Tank types are top level nodes that define tanks for part subtypes to use.  The nodes are named B9_TANK_TYPE and have the following parameters:

• name: Name of the tank type.  If you're making your own, try to make them somewhat descriptive and unique.
• tankMass: Mass per volume that is added by this tank
• tankCost: Cost per volume that is added by this tank
• RESOURCE: each node represents a resource that this tank contains
  • name: Name of the resource (same as the name of the resource everywhere else in KSP)
  • unitsPerVolume: Number of units of this resource that the tank will have for each unit of volume.  So if the tank has 500 units and this resource has unitsPerVolume = 0.5, then the tank will get 250 units of the resource

Total mass and cost

All masses and costs are additive.  So the total mass will be

(part prefab mass) + (added mass of the subtype) + ( (tank type unit mass) * (volume) ) + (mass of any other modules) + (mass of resources - added by KSP)

and the total cost will be 

(part prefab cost) + (added cost of the subtype) + ( (tank type unit cost) * (volume) ) + (mass of switched resources - added by B9PartSwitch) + (mass of other modules)

Included tank types

I've included a couple of tank types for some of the stock resources (don't have ore or xenon yet).  You can use these if you wish, but can also make your own.  Note that the masses and costs on these assume that the part already has its "structural" mass baked in.  I created some odd MM script to create a consistent mass and cost based on volume for some parts in B9.  You could also do something similar to subtract the tank mass and cost from the part's initial mass.

Probably some things I've forgotten here, let me know if you have any questions

 

[NecroBones]

4 minutes ago, blowfish said:

I haven't created one yet.  At this point I think it's time, given that it's seeing a lot of usage outside of B9.  I'll create a real thread and a wiki at some point but for now here's just a quick rundown.  Feel free to ask me directly if you have any questions (either here, or via private message, or on IRC)

 

 

Awesome, thanks. Am I right that tankMass and tankCost both are per-unit-volume. That is, multiplied by the part's volume?

 

[blowfish]

4 minutes ago, NecroBones said:

Am I right that tankMass and tankCost both are per-unit-volume. That is, multiplied by the part's volume?

Correct (and that includes any multiplier or adding on the subtype).

Oh @NecroBones I forgot, no it does not currently support texture switching.  This is for a couple of reasons: (1) To encourage fewer textures to be used and (2) Because a workaround already exists in Unity.  If there's enough push I might add it though.  I acknowledge that this might make things difficult if you want to modify a part that's in another mod (though you can also include another model in the part and then switch transforms).

[NecroBones]

38 minutes ago, blowfish said:

 

Oh @NecroBones I forgot, no it does not currently support texture switching.  This is for a couple of reasons: (1) To encourage fewer textures to be used and (2) Because a workaround already exists in Unity.  If there's enough push I might add it though.  I acknowledge that this might make things difficult if you want to modify a part that's in another mod (though you can also include another model in the part and then switch transforms).

 

Ah OK. In this case the radial tanks switch out a small stripe texture to match the fuel they're being set to. So for now when using B9, it'll have to have static colors.

 

[Soviet03]

The textures on all my takes are flickering like crazy again (previously this was solved by updating interstellar Fuel switch after every KSP update) but now several updates have been made for 1.1.2 and the problem persists, is this somehow a problem with Fuel tanks plus? Is it a known issue for everyone?

EDIT: SOLVED, I was under the illusion that the latest version of Module manager was packaged with either this mod or Interstellar Fuel switch, that turns out to have been false. After getting the latest version separately here everything seems to be working nicely together.

 

Edited May 5, 2016 by Soviet03

[NecroBones]

5 minutes ago, Soviet03 said:

The textures on all my takes are flickering like crazy again (previously this was solved by updating interstellar Fuel switch after every KSP update) but now several updates have been made for 1.1.2 and the problem persists, is this somehow a problem with Fuel tanks plus? Is it a known issue for everyone? I tried the fixed posted on the OP such as deleting my cache etc.

 

Nope, just make sure you have the latest ModuleManager, FTP, and IFS. And maybe delete ModuleManager.ConfigCache.

[NecroBones]

 

I'm adding more fuel-switching support to FTP/CCC to eliminate the mixed-module configurations, so it will try to use just one switcher mod for both the meshes and fuel, instead of IFS for one and B9 for the other. I'll get that update out pretty soon now.

 

@blowfish, Right now it looks like some of the weird attachment stuff still happens with just B9 doing both the mesh+fuel switching, without IFS modules applying. If I uninstall B9 and let it use IFS instead, it works. I haven't tried it with IFS completely uninstalled yet. Even surface attaching a tank like the FL-T200 (with CCC) is laggy. Strange.

 

 

[blowfish]

@NecroBones what specifically is happening?  I'll try to investigate.

[NecroBones]

30 minutes ago, blowfish said:

@NecroBones what specifically is happening?  I'll try to investigate.

 

Easy steps to reproduce: With CCC and FTP installed (since FTP is needed for CCC to use mesh switching, since it provides the textures), place one FL-T200 tank as the root part. Then place another FL-T200 radially with symmetry on (I've been using 4-way). Then add a third FL-T200 tank onto the stack nodes of the surface-attached ones. They'll refuse to connect, and flicker in and out of position, with some lag.

 

I'll get the FTP and CCC updates out that use just B9 without mixing switchers, but it didn't seem to change anything. The current copy of CCC (which will only use B9 for the mesh switching) should be sufficient for testing too. Both mods still consider IFS to be prerequisite, so I haven't tested with it uninstalled yet. I may not have much time for it tonight though.

[blowfish]

2 hours ago, NecroBones said:

 

Easy steps to reproduce: With CCC and FTP installed (since FTP is needed for CCC to use mesh switching, since it provides the textures), place one FL-T200 tank as the root part. Then place another FL-T200 radially with symmetry on (I've been using 4-way). Then add a third FL-T200 tank onto the stack nodes of the surface-attached ones. They'll refuse to connect, and flicker in and out of position, with some lag.

 

I'll get the FTP and CCC updates out that use just B9 without mixing switchers, but it didn't seem to change anything. The current copy of CCC (which will only use B9 for the mesh switching) should be sufficient for testing too. Both mods still consider IFS to be prerequisite, so I haven't tested with it uninstalled yet. I may not have much time for it tonight though.

This one probably would have escaped me, but fortunately someone else already discovered the cause.  Anyway, confirmed.  I'll think about how to fix this, in the mean time you can just set affectDragCubes = false and it won't happen.  That should really be set for every part switcher that doesn't significantly change the shape of the part.

[blowfish]

Aaaaand fixed.  Turns out it's pretty easy to defer drag cube rendering until the part is actually attached.  I'll try to release a new version tonight with a fix for this and destroying InterstellarFuelSwitch when it shouldn't.

[NecroBones]

1 hour ago, blowfish said:

This one probably would have escaped me, but fortunately someone else already discovered the cause.  Anyway, confirmed.  I'll think about how to fix this, in the mean time you can just set affectDragCubes = false and it won't happen.  That should really be set for every part switcher that doesn't significantly change the shape of the part.

 

37 minutes ago, blowfish said:

Aaaaand fixed.  Turns out it's pretty easy to defer drag cube rendering until the part is actually attached.  I'll try to release a new version tonight with a fix for this and destroying InterstellarFuelSwitch when it shouldn't.

 

Awesome! I'll also go ahead and add the "affectDragCubes = false" too, since there's no need in the case of my fuel tanks to regenerate the cubes. They're really paint schemes, just with some variation in the shape of rims and pipes in some cases.

 

[blowfish]

Aaaand fix released.

[Alewx]

19 minutes ago, blowfish said:

Aaaand fix released.

Great, I just made my MM file to handle no longer FSFuelswitch but InterstellarFuelswitch.

[NecroBones]

 

Updated:

 

1.9 (2016-05-06) - Update.
 - Nuclear (single-propellant) tanks capacity increased to match total units for LFO tanks. Names updated accordingly.
 - B9PartSwitch fuel-switching enabled for most tanks, Switching config overhauled:
   - Firespitter and InterstellarFuelSwitch support still included, of course.
   - Calculated values will differ somewhat from the FS/IFS values, for cost, capacity, etc. This is normal.
   - Radial tanks with texture-switching still rely on FS/IFS for now. Non-switching if only B9 is installed.
   - B9 mesh switching has been set not to regenerate drag cubes while attaching in the editors.
 - Crossfeed available (globally!) for radially attached parts, enable button added to radial tanks.

 

 

[NecroBones]

 

Updated again:

 

1.9.1 (2016-05-06) - Fuel Switching Tweaks.
 - Added minimum tech requirements for some fuels in the fuel switchers, when using InterstellarFuelSwitch 2.0.1+.
 - InterstellarFuelSwitch GUI names updated for IFS 2.0.1.
 - InterstellarFuelSwitch prioritized ahead of B9PartSwitch to take advantage of tech levels.