AlphaMensae

No, I want to use some of the FTP adapter tanks as pods, as they have textures I want to use (I like the blue and Soyuz ones with the stripes ) . First one, the 2m1m one, is having problems getting the mesh-switching applied, even though I used the FTP 2m tank MM mesh-switch patch as a template. I'll try altering the adapter tanks directly (i.e. @PART) , not going to use the adapter tanks anyway in the customized career I'm setting up.

@NecroBones, ok, I've created a Dropbox page and put the two log files in it: https://www.dropbox.com/s/sh7mtpxjszh552b/KSP.log?dl=0 https://www.dropbox.com/s/ntnk1evtvb5gnqa/output_log.txt?dl=0

@NecroBones, deleting the MM cache didn't do anything; in fact, I've never noticed it loading anything from the cache, all the patches go through the full loading sequence.

Yes, the stock tree IS a mess. See this tech tree by @pap1723 to see a tech tree that does make sense...that is how the stock tree should have been done in the first place...but wait, "gameplay balancing".... I don't use the stock multi-couplers and stack adapters either. At a minimum, I use the cubic struts or radial attachment points to attach multiple engines to a fuel tank (like, you know, in reality), but I usually use the thrust plates from SpaceY more often now.

I didn't think this mattered, but I'm using v1.7 of FTP, the last one you released before KSP 1.1 came out (for reasons I'm using 1.0.5). Using the mesh-switching patch above, I think what's happening is all the textures are trying to be displayed at once, resulting in the Z-fighting type glitch. The checkered mesh seems most stable, and if I look carefully I think I can see one or two of the others. I must be missing something, maybe I don't need the "ZFuelTanksPlus"; it was done for CCC, so I figured it would be needed for FTP as well.

@NecroBones, I need some help again, this time it's some of the adapter tanks in FTP that I want to clone and change into some more of my simple command pods (they sorta have the capsule shape already ). The first one I've tried is the Rockomax X200-08-FTP Adapter Tank, followed the CCC+FTP template I used for the FL-T100 conversion, but the the mesh switching isn't working, I get the usual Z-fighting type glitchiness. The part MM patch begins with "+PART[TPtank2m1mA]:AFTER[FuelTanksPlus]:BEFORE[ColorCodedCans]", the rest is standard MM stuff. And yes, I do need to add the "AFTER[ColorCodedCans] or else I get fuel-switching added, even though FTP seems to do its own end-caps color coding. The mesh-switching patch was copied straight from the FTP one: @PART[KoyuzKMAPod]:NEEDS[InterstellarFuelSwitch&FuelTanksPlus]:AFTER[ZFuelTanksPlus] @MODEL { texture = orange-jumbo-0, Squad/Parts/FuelTank/fuelTankJumbo-64/model000 texture = orange-jumbo-1, Squad/Parts/FuelTank/fuelTankJumbo-64/model001 texture = TPtank1m-Specular, FuelTanksPlus/Size1/TPtank1m-Specular } MODULE { name:NEEDS[!InterstellarFuelSwitch] = FSmeshSwitch name:NEEDS[InterstellarFuelSwitch] = InterstellarMeshSwitch objects = TPtank2m-Orange,TPtank2m-Orange2;TPtank2m-White;TPtank2m-Checkered;TPtank2m-Black;TPtank2m-Blue;TPtank2m-Red objectDisplayNames = Delta;Antares;Gemini;Black;Blue;Atlas affectColliders = false buttonName = Next Color Scheme previousButtonName = Previous Color Scheme } } Any help will be appreciated.

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

@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, 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 } }

Well, that attempt didn't do anything. I inadvertently ran that patch with the changes I made to two of the CCC configs, the -MM-FTP-size1 and -MM-tanks patches ( I inserted the my part name into the list of the former and added another "@part" section for my part into the latter). The result was no change from before. Then I removed my changes to the CCC configs and I ended up with a stock T100 tank that had fuel switching but no mesh switching.

@NecroBones, I'm using IFS. If it helps any, two of the stock tanks I'm cloning are the FL-T100 and -200, using the Soyuz texture for them (with those I'm creating my Simple Soyuz, or Koyuz). I could just use the tanks as is and add the extra stuff like normal, but I'd rather have dedicated parts to complete the Soyuz-like configuration. One of the T100 tanks though is for a structural cap piece that goes over the MRS guidance nose cone that I've repurposed for the descent module. My WIP version looks rather nice so far. The other tank I'll be using is the Kerbodyne 7200 tank, I've found that rescaling it down to 2.5m size gives it the perfect length for an Apollo-type Service Module. I think the Vega texture (I think that was an option for the 3.75m tanks) looks better than the stock texture for this purpose. EDIT: I'm going to try this now for the upper cap piece, what exactly do I put for "newTankMeshName" and "TankDisplayName"? I'm guessing the texture object name from CCC (CCtank1m-Black in this case) and the title of the part as used in the part display list (Koyuz Upper Module in this case) and not the internal name (KoyuzUpperPod), so that's what I'm going to try first.

@NecroBones, How do I integrate some modded cloned stock fuel tanks I'm making into CCC to take advantage of the mesh switching with FTP? I'm basically turning some of them into all-in-one service modules (just add engines and RCS!), though one is a parachute/structural module without fuel. My first attempt with the latter one worked mostly okay, except fuel was added back into the part and the external tank texture was that Z-fighting glitchy kind, which went away when I switched textures but reappeared when on the launch pad. Probably missing something in the various config files. I don't actually need fuel-switching, as the parts will have specific fuel setups which I don't want to get messed up. Thanks for any help, I really love CCC with FTP, I don't even use the stock tank textures anymore.

This issue came up during the Das Valdez+EJ_SA console stream from the Intrepid musuem, I think when NathanKell was with them, and yes, the answer is that Unity doesn't support mouse-keyboard on the PS4.

This is probably a related question, but what bit values do you use for "biomeMask" and how does that correspond with the Results messages? In another thread I found, someone said that the "situationMask" values also apply to biomeMask, but just looking at the Crew Report definintion in the ScienceDefs, this doesn't seem to be the case. I'm trying to do the same thing as the OP foe one type of new experiment (a Probe Report, with a very low science base value of 1, but a high cap) I've made, making it non-biome specific when in space or on the surface.

Never mind

Ah, thank you very much, I've had it backwards then--I've been thinking PQSCity was the block of land that hold the KSC, and have been adjusting the absoluteOffset under PQSMod_MapDecalTangent instead.

Thanks, @NathanKell, but I knew about that page, could you please elaborate on a few points? For instance, what exactly is the "decal"? Is that the all the KSC facilities or the "pad" that they sit on? Is PQSCity the whole land area of the KSP? What role does each offset value have on where each is located? And what is "pure black" and "pure white"? Right now I have my varous sites sitting too high, exposing far more of the slope of the "pad" than there is in the stock KSC, and I want to know which values to adjust that brings them down to stock-level.

The Sentinel and the rest of the Asteroid Day pack will probably come in 1.2, but nothing has been confirmed yet.

Over on the 1.1.3 Release devblog thread, I replied to this same question (from someone else), and @NathanKell followed up:

What's the proper way to edit or deletes values within a specific module? For example, editing thrust and ISP values for an engine, or removing the RESOURCE ElectricCharge usage rate from MODULE Command. I had done it like this for the two listed examples: @MODULE { @name = ModuleCommand @minimumCrew = 1 -RESOURCE[ElectricCharge] } This did not actually remove the electric charge usage for what is now a manned pod. @MODULE { @name = ModuleEnginesFX @maxThrust = 125 @atmosphereCurve { @key = 0 345 } } This actually causes KSP to hang on this specifc part loading (the loading tips continue, but nothing else happens, have to Alt-F4 out), which is a cloned adapted stock engine. Sorry if this is too newb, but I'm finally making my first foray into writing MM patches to mod my KSP.

You can get it here: https://github.com/KSP-RO/KSCSwitcher/releases

Further reading on the issue led to the core reason of the problem, which is Unity 5 (or 5.2.4 I think, and probably PhysX as well) does not like wheel colliders being attached to a rigid body via a joint. Simply put, that means all the other parts of a vessel, so KSP's fundamental LEGO-like construction method was incompatible with Unity 5. Squad had to use "middleware" produced by a third-party named Edy, who wrote KSP-style wheel modules (Wheel Physics Plus) that allowed the wheels to be used in Unity 5.2.4. This is what was meant by the wheel code being overhauled for KSP 1.1, because the old wheel modules literally would not work with Unity 5.2.4. I think 5.2.4 has other issues as well with wheel colliders, which were fixed in 5.3 but that version had other issues that made it not useable. 5.4 apparently fixes everything, and the middleware has been updated as well, so 1.2 should see the wheels (and landing legs, which use the same system) finally working correctly.

@Arsonide was in EJ_SA's Twitch stream yesterday, and I asked him this very question. He actually had to run it past @NathanKell, and the explanation was that due to the fix tweaking things deep inside KSP, it was made toggleable in case anything was missed during testing. In other words, if the orbit decay fix ends up breaking something else in a worse way, it can be turned off in a case of "pick your poison".

After the last in-game deletion of the icon, there's no longer a SpaceY category in the PartCategories config. Haven't restarted KSP yet, so I may just delete the whole folder from SpaceY.

@NecroBones, I'm using SpaceY v1.11.2 on KSP 1.0.5 (I have my reasons, and never used 1.0.5 much, stuck with 1.0.4) and am getting a weird issue with the SpaceY custom category--the icon gets added everytime I start KSP, even if there is aleady one there. When I saw two of the icons I deleted them, but they kept reappearing. So next I deleted the custom category folder from SpaceY (I use my own custom categories anyway), and the icon STILL keeps appearing. If this has been already discussed before, just point me to it. Thanks.