Electrocutor

Which part pack adds rounded riveted tanks?

https://bugs.kerbalspaceprogram.com/issues/18378

Not that I or blowfish have found. If you can find a way, let me know. The fact that the Engine Plates have their own additional PartModule for adding/removing nodes makes me think that it isn't possible.

Thank you.

I know you can add more than one, but it's been my experience that after you launch, it will only use the lowest one in the list. I'll do a more controlled test to verify that this is true and not just some other factors that affected my result. [Edit] Confirmed that multiple PartModules can stack, merely you need to be aware of which properties are being overridden. [Edit] After testing, themes do not apply to any parts of your craft. Instead it changes the baseTheme of all parts so that they default to that theme when added to the craft. I do not see this behavior on any of the stock parts with sizeGroup specified or if I add it myself. Do you know the specifics of how to make this do something?

If anyone can figure out what use there is in themes and sizegroups, please let me know and I'll update it.

You can use DebugStuff (the mod) to find out what it's called for different parts. You could hard-code a TEXTURE to update the flag material, but it would not be the dynamic one that was selected for the game. Since it is indeed a game bug, and fairly noticeable, I would hope they fix it.

what you're looking for is materialName = xxx, but even if you only replace a single mesh/material with the texture, the flags will still be white. So far as I have found, simply by having the ModulePartVariants module added, it automatically breaks flags.

Okay... I'll move forward with it then as time allows. I'm simultaneously working on a KSP-UnofficialPatch mod that does all sorts of random stuff that is missing or needs fixed. Like adding an orange foam variant to the Rockomax Nosecone, fixing the mis-sized fairing, adding missing tank sizes like Oscar 2 and 4, changing any parts cfgs that use mesh into using MODEL, adding all previous Squad models/textures as variants to their replacements, etc. In response to @Manwith Noname I have Category "Command" broken into sub-categories "Cockpit", "Pod", and "Probe". So your parts would be: 1.25m Cockpit, 1.25m Pod, 1.25m Probe. I'd thought about also sub-categorizing capsules, but decided that most capsules should be their own part due to them being very different in size and properties (i.e. Cupola vs Cabin). It makes me think that a more technical term for my sub-categories is probably silhouette. Some of them will need to be broken up a bit due to Variants not allowing property changes. For example, the Mk1-2 and Mk1-3 Pods are both the same silhouette, but have differing crew counts. I've made a small mod for allowing property changes, but I think for the sake of more people using it, I should keep this MM-only; but keep swaying on the issue due to it being really handy to be able to change a property or two between variants. [Edit] I'm also trying to see if there is a way to relate Variants to Upgrades as well, as this would allow a progressive unlock of better looking variants through the career. Imagine starting off with the cardboard box from Bargain Parts, then making your way through stock, proot, porkjet, and finally ending on Ven's for the mk1pod. I have a partial mod locally that I made, but cannot release:

*cries while looking for the outlet to unplug the vacuum cleaner*

I think some people don't know that you can opt-in to previous versions of KSP via Steam Beta.

Guide: // optional: In Advanced mode in the VAB/SPH, themes change the default theme of all available parts, and allow you to apply the theme en masse to the current craft VARIANTTHEME { // required: name of theme name = <theme name> // required: name of theme as displayed in GUI, can be constant or a #localized reference displayName = <localized name> // optional: description of theme, can be constant or a #localized reference description = <localized description> // required: colors to use in GUI, alpha not supported primaryColor = #rrggbb secondaryColor = #rrggbb } // all <path>'s should not include extension (f.e. MyMod/MyModel.mu would be MyMod/MyModel, MyMod/MyTexture_d.dds would be MyMod/MyTexture_d) PART { // all possible variant models must be added MODEL { model = <variant model> } // multiple ModulePartVariants allowed; lower variants will override node settings from previous ones if they are the same; for example you cannot change TEXTURE.shader in one and TEXTURE._Color in another, but can change GAMEOBJECTS.transform in one and TEXTURE._Color in another. JPLRepo has stated that while it is possible to have multiple ModulePartVariants, it is not recommended or intended. MODULE { name = ModulePartVariants // optional: name of VARIANT to use as default baseVariant = <variant name> // optional: name of default variant to display in GUI, can be constant or a #localized reference // default is 'Basic', only use if not specified a baseVariant baseDisplayName = <localized name> // optional: theme to which the default variant belongs baseThemeName = <theme name> // optional: whether to create multiple procedural drag cubes // default is true useMultipleDragCubes = <true/false> VARIANT { // required: default variant name is Basic, must be unique per part name = <variant name> // required: name of variant to display in GUI, can be constant or a #localized reference displayName = <localized name> // optional: name of theme to which this variant belongs; variants may only belong to one themeName = <theme name> // required: colors to use in right-click GUI, alpha not supported primaryColor = #rrggbb secondaryColor = #rrggbb // optional: allows grouping of like-variants. mostly used to disallow changing a variant to a non-like group while parts attached to surface. // GroupA, GroupB, GroupC sizeGroup = <group name> // optional: may be negative cost = <additional cost> mass = <additional mass> // optional: lists should be comma-delimited (but I haven't tested) disabledAnimations = <list of animations> disabledEvents = <list of module events> // format: <module name>.<event name> // optional: only one GAMEOBJECTS node per VARIANT GAMEOBJECTS { // set which transforms are visible/hidden <transform name> = <true/false> } // optional: arbitrary key,value pairs for use in PartModules/mods EXTRA_INFO { <info name> = <info value> // Known Examples (ModuleProceduralFairing) FairingsTextureURL = <path to _d> FairingsNormalURL = <path to _n> } // optional: only one NODES node per VARIANT, assumes scale=1.0, rescaleFactor=1.0 NODES { // all optional: node adjustments per variant node_attach = x, y, z, angx, angy, angz, size node_stack_top = x, y, z, angx, angy, angz, size node_stack_bottom = x, y, z, angx, angy, angz, size node_stack_bottomXX = x, y, z, angx, angy, angz, size node_stack_connectXX = x, y, z, angx, angy, angz, size } // optional: multiple TEXTURE nodes allowed (for different materialName) TEXTURE { // optional: used to restrict this TEXTURE change to the named material within this part, otherwise all materials in this part // material names are usually the same as the mesh name to which they belong, but not always // note that this parameter automatically includes wildcards, so MyMat and MyMat2 would both change if set to MyMat; this can be worked around by adding an additional TEXTURE materialName = <name of material> // optional: change the existing material shader, only able to find built-in KSP shaders // shader short-list: // KSP/Alpha/Cutoff // KSP/Alpha/Cutoff Bumped // KSP/Alpha/Translucent // KSP/Alpha/Translucent Additive // KSP/Alpha/Translucent Specular // KSP/Alpha/Unlit Transparent // KSP/Bumped // KSP/Bumped Specular // KSP/Bumped Specular (Mapped) // KSP/Diffuse // KSP/Emissive/Bumped Specular // KSP/Emissive/Bumped Specular (Mapped) // KSP/Emissive/Diffuse // KSP/Emissive/Specular // KSP/Specular // KSP/Specular (Transparent) shader = <shader> <texture property> = <path> <color property> = #rrggbb // alpha not supported <float property> = 0.0 // Known Examples _MainTex = <path to _d> _BumpMap = <path to _n> _Color = #rrggbb _SpecColor = #rrggbb _SpecMap = <path to _s> _Shininess = 1.0 _EmissiveColor = #rrggbb _Emissive = <path to _e> _Opacity = 1.0 _RimFalloff = 0.0 _RimColor = #rrggbb _TemperatureColor = #rrggbb _BurnColor = #rrggbb _AmbientMultiplier = 0.2 } } } } *Note: The two (Mapped) shaders are the quasi-pbr shaders available in newer versions of KSP. *Note: If you have multiple models on the same part, and show or hide them for variants, keep in mind that any stock PartModules that affect the visibility of transforms will only apply to the first transform of the given name. For example, if you have two engine models, and both have a fairing mesh named 'fairing', then ModuleJettison will only show or hide the first one it finds. ModuleJettison supports multiple transform names though, so if you named the fairing on model2 as fairing2, then it would work fine so long as you specified both transforms within ModuleJettison. *Note: @linuxgurugamer figured out some specifics of how the cost property affects the overall part cost here.

Does this signify that you think the idea would be too abstract to properly grasp and that most people would just prefer it the current way, where each part is its own part in the list?

Works great. Thank you.

My thoughts are to use a systematic approach to parts based on function, size, and type. For example, function would be storage, type would be solid, liquid, or gas; and size would be 0.625m, 1.25m, 2.5m, 3.75m, mk1, mk2, mk3 So the part you added would just be named "1.25m Liquid Tank" then you could scroll through the visual options by variant; and in this case, there would be an additional setting for Substance (since it is a container). So it would default to LFO, but could be changed to just LF (or others depending on what resources you have enabled in ksp). Another example might be a "Small Radial Gas Tank" with visual options defaulting to look like the xenon or mono radial tanks, and being able to set it to Xenon or Monoprop. ---- If people have an interest in this, I can start with stock parts, then build scripts to convert existing mods into this same system, starting with Ven's, Porkjet's, and Proot's stuff.

This would be nice, but PartVariants don't work that way. You could force this kind of behavior with a mod that intercepts GUI stuff and what not, but this would be very complicated.

for PartVariants, you can specify multiple materials to change: TEXTURE { materialName = name _MainTex = path } TEXTURE { materialName = name2 _MainTex = path2 } and you're right, it's the MeshRenderer and SkinnedMeshRenderer that they are part of; sorry. In most cases, the material name maches the mesh transform name, but not always.

@sarbian Would you be able to add Material.name underneath MeshFilters? It would be very helpful for building PartVariants.

So... I have a question for everyone. For a mod like AirplanePlus, do you prefer its current implementation of having one part per visual (and perhaps some slight changes to properties like mass) or would you prefer there to be a single sized part then scroll through the visuals via variants? So for example, simply have a single part named Mk1 Cockpit or Mk1 Inline Cockpit, then have 3 or four 4 visual options.

@Shadowmage Would you consider allowing wildcards for model=, mesh=, and excludeMesh= ? This would help reduce cfg busywork greatly. For example, mesh = panel* would cover panel00 through panel 32 without having to specify each and every one, and model = MyMod/* would simply enable TU for all models within a mod.

I don't know what you mean by that. since the tinting is just built-in KSP to begin with it works on stock, but also on everything else.

No, Kerbpaint requires a new shader and new textures with masks to allow specific repainting; like what Textures Unlimited allows. This is not even a mod, it's just a config that uses the stuff already in KSP to tint what is already there. It is very generic.

My preferred setting is 75% metallic and 90% gloss for glass, but you may have your own perspective on the matter.

I'd completely forgotten about the rainbow poptart kitty.

If you noticed in the logs: [LOG 07:50:57.750] [PQSCity2]: Height Correction: WoomerangLaunchSite -40.9722595214844 [LOG 07:50:57.750] [PQSCity2]: Failed to Hit surface to place PQSCity: Larkes [LOG 07:50:57.750] [PQSCity2]: Height Correction: Larkes 0 So it would seem there is a new PQSCity.