NecroBones

This screenshot isn't centered on the interface, but I have the top of the mesh brought down just a tad, to match the attachment node. The rest of the mesh is unchanged, so basically that upper portion (the engine base) is just slightly squashed. It's a very subtle change, but it's more accurate now:

Actually there's a reason for the "flat" appearance. The patterning within the textures is kept simple and homogenous, because of the tiling and sharing that's used, to keep the textures very small and reusable among the parts. Any scratches or other noticeable marks would get repeated all the way around the tank, and draw your eye to how the texture is tiled. The efficient texture sharing was more important prior to the 64-bit versions of KSP becoming viable, and now it's less of an issue, but people still routinely install enormous amounts of memory-eating mods, so I try to stick to my old way of keeping the memory footprint low. Texture swapping on the cones and adapters is probably doable. I can think about adding that. Emu clipping? Huh, I might need to take a look. There's very little that should be clipping by design, in general. EDIT: OK, I think I see what you're talking about. The wide (default) base extends about 0.075m above the attachment node. That should be pretty fixable. I just need to decide if I'm moving the node up, or bringing the mesh down.

Probably not, unfortunately. The color switching in FTP works with mesh-switching, rather than texture-switching. So it would somehow need to be able to switch between both in order to accept outside textures, and I don't think any of the switcher mods allow for combinations of both mesh and texture switching on the same parts.

It's possible. I'd just need examples of what to add to the parts, unless Kerbalism wants to add it from their side.

Wow, yes indeed! We could all use some nice IVA work, I'm sure.

Everything lines up for me, so I'm afraid I'd need to see a screenshot to do anything further.

Yeah, the tanks were probably just rotated a little if they were in asparagus configuration. I'll be that's all it was.

Doh! OK. Yeah, I'll take a look at your logs when I get some time next week. I was going to ask if you used the right MM patch set, since each diameter has a different set of rules and mesh names, and the adapter tanks are based on the lower (larger) diameter. But it looks like you took that part into account already.

Oh, one other idea, is that you can copy an existing part and make changes, using MM. For instance, if you wanted to save yourself the trouble of figuring out all the MM magic and just duplicate (as an example) the "X200-08-FTP Adapter Tank", and add some things to it, you could do something like this.. It's an untested example below, but it should give you an idea. It copies the part, removes the fuel, and adds all the command pod components from the Mk1-2 pod. It doesn't try to change the fuel-switcher config though, so it probably needs something for that: +PART[TPtank2m1mA]:FINAL { // "FINAL" means execute at after all the mods. Don't distribute mods with this. @name = myNewPodTank // or whatever @title = Pod based on X200-08-FTP Adapter Tank @description = whatever @tags = capsule cmg control ?eva fly gyro ?iva moment pilot react rocket space stab steer torque !RESOURCE[LiquidFuel] { } !RESOURCE[Oxidizer] { } INTERNAL { name = PodCockpit } MODULE { name = ModuleCommand minimumCrew = 1 } RESOURCE { name = ElectricCharge amount = 150 maxAmount = 150 } MODULE { name = ModuleReactionWheel PitchTorque = 15 YawTorque = 15 RollTorque = 15 RESOURCE { name = ElectricCharge rate = 1.2 } } MODULE { name = ModuleScienceExperiment experimentID = crewReport experimentActionName = Crew Report resetActionName = Discard Crew Report reviewActionName = Review Report useStaging = False useActionGroups = True hideUIwhenUnavailable = True rerunnable = True xmitDataScalar = 1.0 usageReqMaskInternal = 5 usageReqMaskExternal = -1 } MODULE { name = ModuleScienceContainer reviewActionName = Review Stored Data storeActionName = Store Experiments evaOnlyStorage = True storageRange = 2.0 } MODULE { name = ModuleConductionMultiplier modifiedConductionFactor = 0.003 convectionFluxThreshold = 3000 } }

Screenshot? Were you placing it on top of a radially mounted tank? Sometimes if they're not aligned radially, placing something on top will give it a slightly different rotation. If building in a straight stack, things should line up pretty well.

Pretty close, the RSB one starts at the full 10.1m diameter, but the optional stockification patches give it a multiplier of "0.5681818", which brings the first stage to a diameter of 5.7386m. This is so that the third stage, the S-IVB, comes to a nice stock diameter of 3.75m (normally 6.6m at full scale).

Dunno, I've never tried it. But I think you're probably fine to leave the module off. It's just that it won't activate and deactivate via the animation, so Kerbals will still be able to grab it if they can get to it, even when it's stowed. The only possible caveat I can think of is if KSP has a problem with animated ladder colliders that are moved by something other than that retraction module. I guess you'd just have to try it and see if it works.

Correction: Landing legs made in 4.2.2 work just fine (probably wheels too, but I haven't tried them). However Unity 5 is needed if you want to import the newer "internal" assets for making IVAs or make use of the new IVA shaders.

You mean the "RetractableLadder" module? Only if it's deployed via animation. If the ladder is static, then you won't need that module.

OK cool, I'll take a look. I probably won't have time until next week though, since I'll be offline for a few days. Heh, I think what I was thinking was more that they would be probe "instrument platforms" which just happened to also contain some fuel. If I remember correctly, the fuel quantities were all set before the Oscar-B got rebalanced. So yeah, I can probably rework their stats. But again, probably not til next week.

This is a really good point. I avoid making anything 100% opaque, or 100% transparent, and only use the range of values from 1-254 (no 0 or 255) in the alpha channel, for this very reason. Sometimes you get some strange all-black or all-white effects.

OK, yeah then it's probably invalidating the cache as it should. I wasn't sure when Sarbian added that capability. I started deleting the cache automatically for my mod testing quite a long time ago, back when it was throwing off my tests pretty frequently. Anyway, at this point we probably need to look at your KSP.log to see what's going on. Since I don't have a view into how it's working on your side, I'm out of general suggestions and can't get more specific.

If that's the case, that's good to know. My hope would have been to use that NEEDS/FOR combination to optionally enable something for another NEEDS, but now that I'm thinking about it, I can see how that turns into a "chicken and egg" problem, so I think you both are right. The method I've been favoring for optionally enabling/disabling features for other parts is to do it with variables in those parts, that can then be referenced with HAS instead. That's a pretty reliable method.

I think it only looks white because of the PNG transparency over the forum's white background.

Yeah, hard to say. You might need to pull out the KSP.log and take a look at what it's doing. Oh, another thought-- are you deleting ModuleManager.ConfigCache between tests? MM supposedly will invalidate the cache on its own these days, but I prefer not to take any chances. And if you're using 1.0.5 and its version of MM, I suspect you're getting stale cache data. I would delete " ModuleManager.ConfigCache" (in GameData) before each run of KSP when testing your changes. Otherwise you'll fire up KSP to run a test, but see a previous test's results. CCC/FTP use mesh-switching only, rather than texture switching. That way all the texture information can be in the same texture files, and highly compact. So if it's z-fighting, it comes down to mesh names that aren't properly getting included in the switching config for some reason. It's possible you had the config right, but it was still broken due to cached configs.

I'm not 100% sure either, but I thought it was the other way around. Theoretically, you'd want the conditional to determine whether or not the "x" in the "FOR" gets added or not. I have a rule in SpaceY that works this way, but I don't rely on it. The other rules in SpaceY that reference the "x" also reference "y" in their own "NEEDS" statements, just to be sure (I didn't spend the time to experiment with it). MM has gotten so wonderfully complex that it's a bit of a learning curve to figure out what works and what doesn't.

The RF configs probably are just failing to add fuel. You might need to ask them how it's handling parts that have both monopropellant and LFO. I suspect it's detecting just the monoprop first, and only reconfiguring that.

Sort of. Here's what they do: FOR[something] - Basically says "a mod now exists called 'something', and this patch belongs to it". Because it creates this name in the list, you never want to use it unless the name belongs to your mod. So don't say "FOR[RP-0]" unless the patch is actually included with RP-0. But you can make up a new name associated with it, and do something like "FOR[RP0andH0yer]" or whatever. Make sure to pick names that are unlikely to be used by other mods. The reason you need to be careful here, is that anything added with a "FOR" will also trigger the "NEEDS" in other mods that check for the same name. AFTER[something] and BEFORE[something] - These will make the patches apply before or after "something", but only if "something" exists in the list (having been created by a "FOR" somewhere else, or being the name of a mod's folder or DLL). These are great for adding rules before or after another mod, but since your patches only apply once, you need to be sure the mod name that you're referencing actually exists, and is before/after all of the other mods you're depending on. This is why it's sometimes better to use a "FOR", but again, "FOR" really needs you to use a name that doesn't exist for other mods. If you're making the patches for yourself (not to be distributed with a mod), and you want them to apply after everything else, you can instead put a ":FINAL" on your patches and not use BEFORE/FOR/AFTER.

@h0yer, those ":AFTER[RealismOverhaul&RP-0]" parts probably need to be editing. "AFTER" specifies a specific point in the list, as to when to apply the patches. If you want to make sure it executes after both of those mods, you just need to go later in the alphabetical sequence, so something like ":FOR[zMyPatches]" (notice the "z" there) could do it. I don't think you can specify two mods with in the AFTER.

@pap1723, I just noticed your question in the MM thread too. I didn't add an exclusion to tech node additions themselves, but it looks like you probably want that too. They gave a good answer about how to delete them, though. The reason I've been leaving those in, even if other mods are detected, is so that they still exist to hook into for the Sea Dragon, and for Real Scale Boosters, if those are installed too. But I can probably tweak the settings some more if it still causes problems.