NecroBones

[1.4.1] Color Coded Canisters 2.0.1 (2018-03-14)

Recommended Posts

@NecroBones,

Is there a way to have only specific meshes from Fuel Tanks Plus show up as options, or even use just one texture, e.g. the Black and Soyuz ones or just the Saturn one? I'm making some custom parts using the stock fuel tanks models, and I'd like to to have only certain FTP textures be used for them. Simply deleting the unwanted ones from the "objects = " and "objectDisplayNames =" lines in the MM patch files I've made didn't work, the mesh is broken, with the Z-fighting result of what appears to be all the textures trying to be displayed at once.  Restoring the lines to the orginals, with all the mesh options, made things work again.

Edited by Laguna

Share this post


Link to post
Share on other sites
17 hours ago, Laguna said:

@NecroBones,

Is there a way to have only specific meshes from Fuel Tanks Plus show up as options, or even use just one texture, e.g. the Black and Soyuz ones or just the Saturn one? I'm making some custom parts using the stock fuel tanks models, and I'd like to to have only certain FTP textures be used for them. Simply deleting the unwanted ones from the "objects = " and "objectDisplayNames =" lines in the MM patch files I've made didn't work, the mesh is broken, with the Z-fighting result of what appears to be all the textures trying to be displayed at once.  Restoring the lines to the orginals, with all the mesh options, made things work again.

 

Yep, there is a way, but it's not pretty. If you look in the color-changing patches for CCC, it has rules in there that FTP doesn't. The only stock-alike way that I know of for disabling meshes by name, is to turn them into shrouds and associate them with an unusable attachment node.

 

For example, in CCC, in "ColorCodedCanisters-MM-FTP-size0.cfg":

// Appearance switching turned off, when FTP is absent:

@PART[miniFuelTank]:FOR[ZColorCodedCans]:NEEDS[!FuelTanksPlus]
{
	node_stack_disabled = 0.0, -1000.0, 0.0, 0.0, -1.0, 0.0, 0

	MODULE
	{
		name = ModuleJettison
		jettisonName = CCtank0m-White
		bottomNodeName = disabled
		isFairing = True
		jettisonedObjectMass = 0.1
		jettisonForce = 0.1
		jettisonDirection = 0 0 1
	}
	MODULE
	{
		name = ModuleJettison
		jettisonName = CCtank0m-Checkered
		bottomNodeName = disabled
		isFairing = True
		jettisonedObjectMass = 0.1
		jettisonForce = 0.1
		jettisonDirection = 0 0 1
	}
	MODULE
	{
		name = ModuleJettison
		jettisonName = CCtank0m-Black
		bottomNodeName = disabled
		isFairing = True
		jettisonedObjectMass = 0.1
		jettisonForce = 0.1
		jettisonDirection = 0 0 1
	}
	MODULE
	{
		name = ModuleJettison
		jettisonName = CCtank0m-Red
		bottomNodeName = disabled
		isFairing = True
		jettisonedObjectMass = 0.1
		jettisonForce = 0.1
		jettisonDirection = 0 0 1
	}
}


 

It creates a "disabled" attachment node. The node is actually a real attachment node, but it's placed a kilometer away, so you can't connect anything to it. Then each mesh gets its own ModuleJettison that points to that node.

 

  • Like 1

Share this post


Link to post
Share on other sites

@NecroBones,

Ah, thank you, so that's what that section does!  Never really looked that far. :wink:

So I just need to copy the ones I don't want into the part where FTP is present and appearance switching is turned on?

Share this post


Link to post
Share on other sites
13 hours ago, Helbrecht said:

Do I need Firespitter to make the textures not flicker?

Normally (using ModuleManager) it should be able to detect if you don't have Firespitter or InterstellarFuelSwitch installed, and just use the default appearances only. But if that's not happening, make sure you have a valid/current copy of MudleManager, and then yes, probably install FS or IFS. Either MM is broken, or something else is tricking it into thinking you have those mods, so you might as well use one of them if that's the case.

 

Share this post


Link to post
Share on other sites

I have IFS and the most recent MM installed, I installed FS this morning and the problem persisted after, so idk what is causing it.

Share this post


Link to post
Share on other sites

Minor issue I came across: The Oscar-B tank is getting two mesh/texture switching options rather than just one. I checked the CCC cfg for it and noticed it checks for IFS, FS, and B9PS. I seems to be applying the IFS/FS function and the B9 one. All the other parts seem to work properly, so I compared the configs. The Oscar-B is the only one that has a specific NEEDS[FuelTanksPlus] entry along with the combination one (which includes FTP anyway). Feels like MM is taking EITHER NEEDS as true and applying the changes rather than requiring BOTH to be true.

It's not a big deal, though it did confuse me the first time I came across it. I have all three switcher plug-ins installed to support all my various mods. (I kinda wish all the modders would get together and just settle on one switcher plugin rather than having 3. Though I admit that several big mods seem to agree on B9PS, switching over from IFS.)

Share this post


Link to post
Share on other sites
On 3/25/2017 at 9:22 AM, StahnAileron said:

Minor issue I came across: The Oscar-B tank is getting two mesh/texture switching options rather than just one. I checked the CCC cfg for it and noticed it checks for IFS, FS, and B9PS. I seems to be applying the IFS/FS function and the B9 one. All the other parts seem to work properly, so I compared the configs. The Oscar-B is the only one that has a specific NEEDS[FuelTanksPlus] entry along with the combination one (which includes FTP anyway). Feels like MM is taking EITHER NEEDS as true and applying the changes rather than requiring BOTH to be true.

It's not a big deal, though it did confuse me the first time I came across it. I have all three switcher plug-ins installed to support all my various mods. (I kinda wish all the modders would get together and just settle on one switcher plugin rather than having 3. Though I admit that several big mods seem to agree on B9PS, switching over from IFS.)

 

The amusing thing is that this is already fixed. On my side. And I've been sitting on it for a few months. Heh. :) I've sometimes not pushed out changes if they're really small, and I don't have anything more pressing to push out with it. But this has been sitting for a while now, so I should probably just update it.

 

  • Like 2

Share this post


Link to post
Share on other sites

So exuse the stupid question, but:

Colorswitching is only possible with fueltanks+ installed?

Share this post


Link to post
Share on other sites
On 4/27/2017 at 8:16 PM, maculator said:

So exuse the stupid question, but:

Colorswitching is only possible with fueltanks+ installed?

 

Sorry for the late reply. But yes, it relies on the textures provided by FTP.

Share this post


Link to post
Share on other sites

For some reason the mod isn't working for me. I know it's worked for me in the past but I can't get this latest version to work. I put the file in the GameData folder and the game seems to read it when it boots up but when I get into the game the fuel tanks don't change.

Share this post


Link to post
Share on other sites

@NecroBones

Thank you for the great work!

But, I actually like some of the stock colors/themes. is it possible to have them as an option in selection menu? Of course with the shroud ability.

I would like to see the original textures tweakable on the other stock tanks, like the all white cones or the gray with bolts around.

Edited by Casper_83

Share this post


Link to post
Share on other sites

I'm not sure if this is intentional or not, but the 3.75m tanks don't have as many texture choices as the 1.25m and the 2.5m ones, I'm trying to use some of the red Atlas or Titan tanks for a 3.75m rocket and I can't. :c

Edited by yorshee

Share this post


Link to post
Share on other sites

@NecroBones

Can you explain what the shrouds are used for on the tanks? 

For the life of me, I can't see any use for them, no matter what I do, I can't see any difference with them enabled or disabled.

For example, the FL-T800 has three shrouds.  What are they, and how are they used?

Share this post


Link to post
Share on other sites
45 minutes ago, linuxgurugamer said:

Can you explain what the shrouds are used for on the tanks?

I think those are the end caps that appear when the tanks' attachment nodes are occupied:

prGrlNe.jpg

I've been thinking about patching them out, because they tend to trigger KSP's bug where shrouds are displayed in the wrong position:

dvQKTFu.jpg

(This isn't specific to CCC; it happens with the stock heatshield shrouds too.  Seems to occur after timewarping.)

  • Like 1

Share this post


Link to post
Share on other sites

@NecroBones

I've been trying out B9 Part Switch for mesh-switching in the custom-welded parts I'm making, and there is an issue with it and disabling meshes (yes, B9PS has a ModuleB9DisableTransform to disable individual meshes) from CCC and FTP.  If the default mesh (e.g. CCtank1m-Stock) is disabled, B9PS also removes it from the part's thumbnail in the part selector.  The default mesh has to remain enabled and be listed as the first SUBTYPE in B9PS's ModuleB9PartSwitch, or else it's removed from the thumbnail.  It might be a minor issue, but for reasons I won't explain here I'd like to switch to using B9PS, and for some of the parts I'm making having the default mesh remain enabled is unacceptable, and having the whole tank model being deleted from the thumbnail is a BIG problem.

@blowfish explained that it has something to do with how you use the icon_hidden tag in your models.

Share this post


Link to post
Share on other sites
3 hours ago, AlphaMensae said:

@NecroBones

I've been trying out B9 Part Switch for mesh-switching in the custom-welded parts I'm making, and there is an issue with it and disabling meshes (yes, B9PS has a ModuleB9DisableTransform to disable individual meshes) from CCC and FTP.  If the default mesh (e.g. CCtank1m-Stock) is disabled, B9PS also removes it from the part's thumbnail in the part selector.  The default mesh has to remain enabled and be listed as the first SUBTYPE in B9PS's ModuleB9PartSwitch, or else it's removed from the thumbnail.  It might be a minor issue, but for reasons I won't explain here I'd like to switch to using B9PS, and for some of the parts I'm making having the default mesh remain enabled is unacceptable, and having the whole tank model being deleted from the thumbnail is a BIG problem.

@blowfish explained that it has something to do with how you use the icon_hidden tag in your models.

Just to clarify what's going on here, the problem is that B9 Part Switch does its own icon setup, i.e. enabling objects on the default subtype and disabling them on every other subtype.  But then KSP also looks for transforms with the Icon_Hidden tag and removes them.  So if the transforms associated withthe default subtype has the Icon_Hidden tag, they won't show up.

Share this post


Link to post
Share on other sites
On 9/30/2017 at 10:30 AM, Wyzard said:

I've been thinking about patching them out, because they tend to trigger KSP's bug where shrouds are displayed in the wrong position:

dvQKTFu.jpg

(This isn't specific to CCC; it happens with the stock heatshield shrouds too.  Seems to occur after timewarping.

Can you share your steps if you've found a way to prevent this from happening. It's getting quite distracting and I'd like to get rid of those weird disks floating everywhere.

Share this post


Link to post
Share on other sites
On 12/3/2017 at 1:55 AM, JedTech said:

Can you share your steps if you've found a way to prevent this from happening. It's getting quite distracting and I'd like to get rid of those weird disks floating everywhere.

I've been using this MM patch:

// Remove end-cap shrouds added by ColorCodedCans, since they trigger the
// shroud positioning bug.
@PART[*]:HAS[@MODULE[ModuleJettison]]:AFTER[ZColorCodedCans]
{
        // Make the shrouds conditional on a node that doesn't exist, so they
        // don't appear.
        @MODULE[ModuleJettison]:HAS[#jettisonName[CCtankShroud*]]
        {
                @bottomNodeName = none
        }
}

It's intended to remove the end caps entirely, but it doesn't quite accomplish that — they still appear sometimes.  I haven't investigated why, or under what circumstances.  But I don't think I've ever seen them floating out of position while using this patch, which is all I really wanted (which is why I haven't bothered trying to figure out why they still appear sometimes).

Edit:  It turns out that this can cause NullRef spam which slows down the game significantly, so it's probably better to not use this patch.  Try this one instead.

Edited by Wyzard
  • Like 1

Share this post


Link to post
Share on other sites
10 hours ago, Wyzard said:

But I don't think I've ever seen them floating out of position while using this patch, which is all I really wanted

That's why I'm wanting to remove them as well. Thanks so much, I will try this out.

Edit: The MM patch solved the problem for me. Also the fix didn't cause any problems with the crafts I had already in flight.

Edited by JedTech

Share this post


Link to post
Share on other sites

Hi there, I'm getting a small conflict with GPOSpeedFuelPump and Color Coded Canisters. With both installed the Rockomax fuel tanks don't have their GPOSpeed pump controls any more. Removing Color Coded Canisters restores the GPOSpeed controls to those tanks. As far as I can tell it only affects the Rockomax tanks, but this includes the ones added by Fuel Tanks Plus.

Edit: Fuel Tanks Plus is also having the same problem.

Edited by BoilingCold

Share this post


Link to post
Share on other sites

It turns out, after some troubleshooting in @linuxgurugamer's Twitch stream, that my earlier patch to fix the end-cap positioning bug sometimes causes NullReferenceException spam.

Here's an alternate solution that utilizes a module from B9PartSwitch:

// Remove end-cap shrouds added by ColorCodedCans, since they trigger the
// shroud positioning bug.
@PART[*]:HAS[@MODULE[ModuleJettison]]:AFTER[ZColorCodedCans]
{
	@MODULE[ModuleJettison]:HAS[#jettisonName[CCtankShroud*]]
	{
		// Change ModuleJettison to ModuleB9DisableTransform, to hide
		// the shrouds unconditionally (instead of based on an
		// attachment node).
		@name = ModuleB9DisableTransform
		transform = #$jettisonName$

		// Delete the ModuleJettison attributes
		// (though it shouldn't really hurt to have them there)
		!jettisonName = deleted
		!bottomNodeName = deleted
		!isFairing = deleted
		!jettisonedObjectMass = deleted
		!jettisonForce = deleted
		!jettisonDirection = deleted
	}
}

The idea for this came from @AlphaMensae's earlier post which mentioned the ModuleB9DisableTransform module.  I haven't tested it extensively, but it's at least using ModuleB9DisableTransform for its intended purpose, instead of abusing ModuleJettison for something it wasn't really meant to do, so it's less likely to be problematic.

Edited by Wyzard
  • Like 1

Share this post


Link to post
Share on other sites
10 hours ago, Wyzard said:

It turns out, after some troubleshooting in @linuxgurugamer's Twitch stream, that my earlier patch to fix the end-cap positioning bug sometimes causes NullReferenceException spam.

Here's an alternate solution that utilizes a module from B9PartSwitch:


// Remove end-cap shrouds added by ColorCodedCans, since they trigger the
// shroud positioning bug.
@PART[*]:HAS[@MODULE[ModuleJettison]]:AFTER[ZColorCodedCans]
{
	@MODULE[ModuleJettison]:HAS[#jettisonName[CCtankShroud*]]
	{
		// Change ModuleJettison to ModuleB9DisableTransform, to hide
		// the shrouds unconditionally (instead of based on an
		// attachment node).
		@name = ModuleB9DisableTransform
		transform = #$jettisonName$

		// Delete the ModuleJettison attributes
		// (though it shouldn't really hurt to have them there)
		!jettisonName = deleted
		!bottomNodeName = deleted
		!isFairing = deleted
		!jettisonedObjectMass = deleted
		!jettisonForce = deleted
		!jettisonDirection = deleted
	}
}

The idea for this came from @AlphaMensae's earlier post which mentioned the ModuleB9DisableTransform module.  I haven't tested it extensively, but it's at least using ModuleB9DisableTransform for its intended purpose, instead of abusing ModuleJettison for something it wasn't really meant to do, so it's less likely to be problematic.

Just tested, seems to work well.

ThumbsUp for finding a good solution

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now