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

[AlphaMensae]

On 7/20/2016 at 8:49 AM, NecroBones said:

 

OK, I probably misunderstood what you were asking for then. I thought you wanted to add additional appearances to the tanks (from another mod or something), rather than single one out. So instead, what you'd need is to have a patch that works more like the non-switcher configs in CCC, where it assigns all of the "unused" appearances to the "disabled" attachment node. All of the appearances except the one you want would go in there.

@NecroBones, yes, I just want to use the FTP textures the way CCC does with the stock tanks with my own modded cloned stock tanks.  I do have specific textures in mind, but the CCC/FTP general mesh-switching would also work.  I thought it would be sorta simple to do, but maybe not.

This is the patch I made, based on my understanding of what you said, and I tried it in both my own custom parts folder and the CCC folder.  It didn't work in either case, just left me with a stock FLT-100 instead of the black mesh I wanted, and oddly with fuel-switching.

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

    MODULE
    {
        name = ModuleJettison
        jettisonName = CCtank1m-Stock
        bottomNodeName = disabled
        isFairing = True
        jettisonedObjectMass = 0.1
        jettisonForce = 0.1
        jettisonDirection = 0 0 1
    }

    MODULE
    {
        name = ModuleJettison
        jettisonName = CCtank1m-White
        bottomNodeName = disabled
        isFairing = True
        jettisonedObjectMass = 0.1
        jettisonForce = 0.1
        jettisonDirection = 0 0 1
    }
    MODULE
    {
        name = ModuleJettison
        jettisonName = CCtank1m-Checkered
        bottomNodeName = disabled
        isFairing = True
        jettisonedObjectMass = 0.1
        jettisonForce = 0.1
        jettisonDirection = 0 0 1
    }
    MODULE
    {
        name = ModuleJettison
        jettisonName = CCtank1m-Green
        bottomNodeName = disabled
        isFairing = True
        jettisonedObjectMass = 0.1
        jettisonForce = 0.1
        jettisonDirection = 0 0 1
    }
    MODULE
    {
        name = ModuleJettison
        jettisonName = CCtank1m-Blue
        bottomNodeName = disabled
        isFairing = True
        jettisonedObjectMass = 0.1
        jettisonForce = 0.1
        jettisonDirection = 0 0 1
    }
}

Edited July 23, 2016 by Laguna

[Deimos Rast]

@NecroBones

I *think* the 2m B9PartSwitch patch for FTP is missing the @MODEL portion and a couple patches seems to have double :NEEDS[FuelTanksPlus] unless I'm misreading things. Doubt that matters though.

Cheers.

//@PART[OscarB]:NEEDS[FuelTanksPlus]:NEEDS[B9PartSwitch&!Firespitter&!InterstellarFuelSwitch&FuelTanksPlus]:AFTER[ZColorCodedCans]

---

@Laguna That patch is for if you don't have FTP, it disables all the tank butts that other patches add. As it says in the patches "Appearance switching turned off, when FTP is absent." I'm actually doing exactly what you're trying to do: use CCC & FTP for cloned parts.

Below is what you need. Put in the part name of the cloned part, and you should be good to go with just that, unless you want to do something fancier. The textures corespond to the physical out of game texture files; the objects are the internal names of the meshes you're manipulating (at least that's my understanding). Probably best to stick to what you see in CCC already.

 

@PART[partnamehere]:NEEDS[Firespitter|InterstellarFuelSwitch&FuelTanksPlus]:AFTER[ZColorCodedCans]
{
	@MODEL 
	{
		texture = TPtank3m-Specular, FuelTanksPlus/Size3/TPtank3m-Specular
		texture = orange-jumbo-0, Squad/Parts/FuelTank/fuelTankJumbo-64/model000
		texture = orange-jumbo-1, Squad/Parts/FuelTank/fuelTankJumbo-64/model001
	}

	MODULE
	{
		name:NEEDS[!InterstellarFuelSwitch] = FSmeshSwitch
		name:NEEDS[InterstellarFuelSwitch] = InterstellarMeshSwitch
		objects = CCtank3m-Stock;CCtank3m-White;CCtank3m-Black;CCtank3m-Silver,CCtank3m-SilverShine;CCtank3m-Orange,CCtank3m-Orange2;CCtank3m-Tan
		objectDisplayNames = Saturn;Falcon;Black;Titan;STS;Ariane
		affectColliders = false
		buttonName = Next Color Scheme
		previousButtonName = Previous Color Scheme
	}
}

 

[Stone Blue]

@Deimos Rast , are you needing to make and put a placeholder texture in the same folder as the part .cfg, using those texture switching patches?

[Deimos Rast]

18 minutes ago, Stone Blue said:

@Deimos Rast , are you needing to make and put a placeholder texture in the same folder as the part .cfg, using those texture switching patches?

assuming I'm understanding you right...nope, everything lives in the CCC folder (I'm assuming you meant put a small dummy file in the part folder to be replacing?). I don't really understand the in's and out's of MeshSwitching (yet), but I think that's only necessary (if it even is) for...well actually I don't know when. I can think of examples (IR for instance), just not sure why they do it that way. I know it's multiple parts using the same texture, but I don't think every mod does it that way. *shrug*

[Stone Blue]

I'm thinking it might be because the textures are baked, or packed in with the models... I've seen mods where placeholder textures are not necessary at all, but I've run into a couple where they are... I'm just learning basic texturing & UV mapping, so i'm guessing its something that I'm not getting changed with the models, which seem to be expecting the textures to be in the same folder, when the textures get moved out to another folder...

EDIT: Ok, this may help a bit...

Anyway, sorry for starting to derail the thread...
I guess we can return to our regular scheduled programming now... lol

Edited July 25, 2016 by Stone Blue

[NecroBones]

14 hours ago, Deimos Rast said:

@NecroBones

I *think* the 2m B9PartSwitch patch for FTP is missing the @MODEL portion and a couple patches seems to have double :NEEDS[FuelTanksPlus] unless I'm misreading things. Doubt that matters though.

Cheers.

//@PART[OscarB]:NEEDS[FuelTanksPlus]:NEEDS[B9PartSwitch&!Firespitter&!InterstellarFuelSwitch&FuelTanksPlus]:AFTER[ZColorCodedCans]

 

 

Ah, I see what you're talking about. I consolidated the MODEL section a while back and it looks like it still has the module-specific conditionals on it. I can fix that.

The multiple "NEEDS" sections were done to keep the logic simple, at a time when MM interpreted those as "AND", which it doesn't seem to do anymore, so I started rewriting those a while back. I probably missed a few, so it's worth cleaning those up too. Thanks!

 

13 hours ago, Deimos Rast said:

assuming I'm understanding you right...nope, everything lives in the CCC folder (I'm assuming you meant put a small dummy file in the part folder to be replacing?). I don't really understand the in's and out's of MeshSwitching (yet), but I think that's only necessary (if it even is) for...well actually I don't know when. I can think of examples (IR for instance), just not sure why they do it that way. I know it's multiple parts using the same texture, but I don't think every mod does it that way. *shrug*

 

12 hours ago, Stone Blue said:

I'm thinking it might be because the textures are baked, or packed in with the models... I've seen mods where placeholder textures are not necessary at all, but I've run into a couple where they are... I'm just learning basic texturing & UV mapping, so i'm guessing its something that I'm not getting changed with the models, which seem to be expecting the textures to be in the same folder, when the textures get moved out to another folder...

EDIT: Ok, this may help a bit...

Anyway, sorry for starting to derail the thread...
I guess we can return to our regular scheduled programming now... lol

 

No worries. Textures don't get baked into the models at all, but the texture names do. If there is no texture file with the correct name in the same folder as the model, then the texture load will fail altogether, even if you reassign it in the "MODEL" section. This is because KSP checks for the existence of the textures first, and then reassigns in a later pass. So if the texture reassignment in the "MODEL" section is referencing a texture in another folder, it will then require a dummy texture to be present so that it passes the existence check first. A texture with the original filename that the model is expecting always has to exist in the same folder as the model, whether it's actually used or not.

 

[Stone Blue]

37 minutes ago, NecroBones said:

No worries. Textures don't get baked into the models at all, but the texture names do. If there is no texture file with the correct name in the same folder as the model, then the texture load will fail altogether, even if you reassign it in the "MODEL" section. This is because KSP checks for the existence of the textures first, and then reassigns in a later pass. So if the texture reassignment in the "MODEL" section is referencing a texture in another folder, it will then require a dummy texture to be present so that it passes the existence check first. A texture with the original filename that the model is expecting always has to exist in the same folder as the model, whether it's actually used or not.

Ahhh... THANK YOU!... Yeah, I figured it was something like that... I noticed loading issues as soon as I started changing texture/material names both in the models & filenames... that also explains why I have seen mods done both ways: some needing placeholders, some not...

So is there a way to fix it in the models, so that you dont have to mess with 1Kb placeholder textures?

Edited July 25, 2016 by Stone Blue

[AlphaMensae]

17 hours ago, Deimos Rast said:

 

@Laguna That patch is for if you don't have FTP, it disables all the tank butts that other patches add. As it says in the patches "Appearance switching turned off, when FTP is absent." I'm actually doing exactly what you're trying to do: use CCC & FTP for cloned parts.

Below is what you need. Put in the part name of the cloned part, and you should be good to go with just that, unless you want to do something fancier. The textures corespond to the physical out of game texture files; the objects are the internal names of the meshes you're manipulating (at least that's my understanding). Probably best to stick to what you see in CCC already.

 

@PART[partnamehere]:NEEDS[Firespitter|InterstellarFuelSwitch&FuelTanksPlus]:AFTER[ZColorCodedCans]
{
	@MODEL 
	{
		texture = TPtank3m-Specular, FuelTanksPlus/Size3/TPtank3m-Specular
		texture = orange-jumbo-0, Squad/Parts/FuelTank/fuelTankJumbo-64/model000
		texture = orange-jumbo-1, Squad/Parts/FuelTank/fuelTankJumbo-64/model001
	}

	MODULE
	{
		name:NEEDS[!InterstellarFuelSwitch] = FSmeshSwitch
		name:NEEDS[InterstellarFuelSwitch] = InterstellarMeshSwitch
		objects = CCtank3m-Stock;CCtank3m-White;CCtank3m-Black;CCtank3m-Silver,CCtank3m-SilverShine;CCtank3m-Orange,CCtank3m-Orange2;CCtank3m-Tan
		objectDisplayNames = Saturn;Falcon;Black;Titan;STS;Ariane
		affectColliders = false
		buttonName = Next Color Scheme
		previousButtonName = Previous Color Scheme
	}
}

 

@Deimos Rast, Thank you!  I knew there had to be a way, I don't know much how CCC and FTP do what they do with the stock tanks, so that will save me a lot of work.

Oh, I also figured out why my cloned and altered tanks kept getting the original fuel amounts and switching added--CCC must be doing its thing to the stock tanks before I clone them, so they were no longer pure stock anymore.  I then remembered the MM "BEFORE" command (?), so now my part patches read "AFTER[Squad]:BEFORE[ColorCodedCans]", and that solved the problem, my altered tanks stay the same way I set them up.

 

[NecroBones]

16 hours ago, Laguna said:

Oh, I also figured out why my cloned and altered tanks kept getting the original fuel amounts and switching added--CCC must be doing its thing to the stock tanks before I clone them, so they were no longer pure stock anymore.  I then remembered the MM "BEFORE" command (?), so now my part patches read "AFTER[Squad]:BEFORE[ColorCodedCans]", and that solved the problem, my altered tanks stay the same way I set them up.

 

 

You should be able to then remove the "AFTER[Squad]" from that. The patch only executes once, so I think it's honoring the last one in the list. The thing to be careful about with "BEFORE" and "AFTER" is that they'll fail to execute if the thing they're referencing doesn't exist. So if you want to be sure it always executes, and always before the other mods, you could do something like ":FOR[aaaMyPatches]" (they're executed alphabetically), or just do ":FIRST" (which runs before all mods).

[AlphaMensae]

7 hours ago, NecroBones said:

 

You should be able to then remove the "AFTER[Squad]" from that. The patch only executes once, so I think it's honoring the last one in the list. The thing to be careful about with "BEFORE" and "AFTER" is that they'll fail to execute if the thing they're referencing doesn't exist. So if you want to be sure it always executes, and always before the other mods, you could do something like ":FOR[aaaMyPatches]" (they're executed alphabetically), or just do ":FIRST" (which runs before all mods).

@NecroBones, maybe there is another way of doing it (this whole thing is also partly a MM learning exercise of mine), but I've found I need to add "AFTER[Squad]" (or any other mod's parts, like some of the MRS parts I've been using too) if I'm cloning, altering or moving the stock parts (in the tech tree); they don't show up or appear in their new tech nodes otherwise.

That alone was sufficient, until I got to the fuel tanks; something like "+PART[SquadTankPartName]:AFTER[Squad] {stuff}" gave me the new part I wanted but with the original stock fuel types and amounts re-added, and IFS fuel-switching as well.

Anyway, @Deimos Rast's config help worked perfectly, my new parts have the CCC-FTP texture-switching ability and no fuel-switching.

 

[NecroBones]

17 hours ago, Laguna said:

@NecroBones, maybe there is another way of doing it (this whole thing is also partly a MM learning exercise of mine), but I've found I need to add "AFTER[Squad]" (or any other mod's parts, like some of the MRS parts I've been using too) if I'm cloning, altering or moving the stock parts (in the tech tree); they don't show up or appear in their new tech nodes otherwise.

That alone was sufficient, until I got to the fuel tanks; something like "+PART[SquadTankPartName]:AFTER[Squad] {stuff}" gave me the new part I wanted but with the original stock fuel types and amounts re-added, and IFS fuel-switching as well.

Anyway, @Deimos Rast's config help worked perfectly, my new parts have the CCC-FTP texture-switching ability and no fuel-switching.

 

 

OK great. Actually then you could probably remove the ":BEFORE[ColorCodedCans]".  Ultimately, it's going to run the patch in only one place, so it's a matter of running it where it'll either run before or after other patches that influence it (in this case the fuel configuration). Keying off of "Squad" is pretty safe, in that it will always exist.

[Chiron0224]

Anyone else having their fuel tanks flicker with all the meshes simultaneously?

[Starslinger999]

Is this comaptible with 1.2 Yet?

[NecroBones]

2 hours ago, Starslinger999 said:

Is this comaptible with 1.2 Yet?

 

Yep, it should be, as long as you have your other mods up to date for 1.2 (Module Manager, Interstellar Fuel Switch, etc).

[void_error]

On 8/27/2016 at 5:46 AM, Chiron0224 said:

Anyone else having their fuel tanks flicker with all the meshes simultaneously?

I seem to have that problem... will try to trace it to something as I currently have more than this mod installed.

[NecroBones]

13 minutes ago, void_error said:

I seem to have that problem... will try to trace it to something as I currently have more than this mod installed.

 

Make sure you're using up-to-date versions of IFS and MM if you're on KSP 1.2.

 

[void_error]

7 minutes ago, NecroBones said:

 

Make sure you're using up-to-date versions of IFS and MM if you're on KSP 1.2.

 

I do now... and everything works.

On the other hand I'm cursing at CurseForge for having two download buttons on the same page, one which is obvious and the other one not so obvious. The obvious blue one points to the KSP 1.1.3 compatible version, the grey one below is the one to click for IFS. Why does it have to look like it's greyed out? Rant over.

MM was installed using CKAN because I can't be bothered to manually check/add all the mods I use anymore, been doing that since 0.24.

[NecroBones]

3 minutes ago, void_error said:

I do now... and everything works.

On the other hand I'm cursing at CurseForge for having two download buttons on the same page, one which is obvious and the other one not so obvious. The obvious blue one points to the KSP 1.1.3 compatible version, the grey one below is the one to click for IFS. Why does it have to look like it's greyed out? Rant over.

MM was installed using CKAN because I can't be bothered to manually check/add all the mods I use anymore, been doing that since 0.24.

 

Yep, it'll all smooth out in a few days, probably. Spacedock and CKAN should be aware of 1.2 now, so once the mods get pushed out, it all should flow through CKAN properly again.

 

[septemberWaves]

Several 2.5m tanks appear to have issues loading textures correctly. I have so far only encountered the problem with cylindrical 2.5m tanks that have stock equivalents; FTP tanks appear to be unaffected. Below, the launch stage tank has the correct texture, but the tank above the SpaceY interstage is broken. It should be loading the black texture. The same error occurs for every texture added to that part by CCC. I will try reinstalling both FTP and CCC, and hopefully that will fix the problem.

Edit: solved the issue. I had B9 part switch but I was lacking Interstellar Fuel Switch and Firespitter (I don't know which one fixed the problem but having both means it's solved.)

Edited October 28, 2016 by eloquentJane

[NecroBones]

5 hours ago, eloquentJane said:

 

Edit: solved the issue. I had B9 part switch but I was lacking Interstellar Fuel Switch and Firespitter (I don't know which one fixed the problem but having both means it's solved.)

 

Awesome. Yeah, as long as one of them is working correctly, then you're good to go.

 

[ModZero]

So, uh, I know about the disappearing end-caps bug, but this is something I've seen for the first time:

Not sure if it's the mods fault (if it's anything like the old end caps bug, it's not), just wondering if it's known/anyone else has seen it.

Edited November 1, 2016 by ModZero

[NecroBones]

4 minutes ago, ModZero said:

So, uh, I know about the disappearing end-caps bug, but this is something I've seen for the first time:

Not sure if it's the mods fault (if it's anything like the old end caps bug, it's not), just wondering if it's known/anyone else has seen it.

 

No idea on that one. There's nothing in the mod that should put them out of position.

[ModZero]

14 minutes ago, NecroBones said:

No idea on that one. There's nothing in the mod that should put them out of position.

It's similar to the disappearing shrouds thing in that it happened after a scene change. Probably a fault of a conflict, but I'm kinda hoping others hit it, as it's not 100% reproducible and thus a real pain to track down, and this mod introduces A Lot Of Shrouds that seem to trigger it.

EDIT: ah, nevermind. It's a stock bug: http://bugs.kerbalspaceprogram.com/issues/12329.

Edited November 1, 2016 by ModZero

[Tyko]

On 11/1/2016 at 11:59 AM, NecroBones said:

 

No idea on that one. There's nothing in the mod that should put them out of position.

I'm seeing the same end caps out of position on many of my craft. Sometimes going back to the tracking center and reloading them works to get them back in place. Anything I can check?

[NecroBones]

12 hours ago, tjt said:

I'm seeing the same end caps out of position on many of my craft. Sometimes going back to the tracking center and reloading them works to get them back in place. Anything I can check?

 

Yeah, it's a known stock bug. That's really the only fix we have for now, I think.