Search the Community

I'd like to gauge if there is interest in creating a community curated list of VARIANTTHEMEs, which would serve a function similar to Community Tech Tree, Comm. Resource Pack, Comm. Category Kit. The aims would be to prevent redundancy, avoid name collisions, ensure that different mods play well together, and present an overall consistent, well-organized categorization of modded variant themes to players, to achieve a better user experience. What are variant themes? With 1.4+ KSP has gained texture switching as part of the stock game, and the new VARIANTTHEME config node to go with that. Variant themes serve to group together the part variants of different parts, that have the same design theme (i.e. "look-and-feel"). This makes it convenient and user friendly for players to switch multiple parts at the same time, to achieve a particular look-and-feel for the craft they are building. With one click in the "Variant Themes" tab in advanced mode in the editor, the player can apply a theme to all applicable parts on the craft currently being edited, or to set that theme as the default for applicable parts when picked out from in the part palette -- rather than have to adjust each part one by one. These are variant themes. They can be accessed in advanced mode in the editor. The variant themes that are built-into stock KSP are defined in GameData/Squad/Parts/VariantThemes.cfg As an example: these panel parts from the Making History expansion each have three part variants. The part variants are defined in ModulePartVariants of the respective part's cfg files. Using the part action window in the editor, you can switch a part between its variants, but doing it this way only works for one individual part at a time. But each of the available part variants are also associated with a variant theme -- this is themeName or baseThemeName value in ModulePartVariants in the part cfg. Being associated with variant themes allows you to click on these icons: And it will "apply" the selected theme -- all the parts on the craft that have such a variant will be switched to that variant. It is optional to associate a part variant with a variant theme. But doing so is useful and user friendly when multiple parts have variants of the same "theme" (hence the name). Why should I care? If you reskin existing parts from stock or other mods. e.g. Back In Black You would obviously like to have a VARIANTTHEME that corresponds to the look-and-feel that you are creating in your mod. So, you set that up. Great! But wait, you're not done yet! What about the original look of the parts that you have modified? When you added your version, a "base" part variant was also automatically created for the original version of the part. You could just leave that as-is , but then the player won't have an easy way to revert multiple parts en masse to their original design. Okay, so let's create a VARIANTTHEME for that... what should it be called? Reasonable choices might include: "stock", "default", "original", etc. If different mods use different names/themes for the same purpose, it could result in a clutter of redundant themes in the UI, messy and potentially confusing. We should standardize. Furthermore, due to a technical limitation of Module Manager we cannot use a clever MM patch that will "add the 'default' VARIANTTHEME if it doesn't already exist". So, for multiple mods to be able to use the same "default" VARIANTTHEME for resetting parts to the original version, we need that to be defined in a community standardized config that gets included by the various mods as a dependency. Additionally, from a technical standpoint, how to ensure that your mod plays well with other mods? In particular, what if someone else also makes a reskin mod that touches the same parts? How can we prevent "Back In Black" and "Racy Red" from stomping on one another's MM patches? We should explore and develop best practices for how to do this. Electrocutor's guide is a good starting point. If you make (a) part(s) that have different textures to choose from. e.g. Hawkspeed Airstairs You might have different textures that are designed to fit in with stock parts, or various other mods. What should you name the different variants? For starters, do we say "stockalike", "stock-alike", or "stock-like"? Standardizing on a common set of VARIANTTHEMEs would avoid redundancy and confusion. Even if your mod has just one part -- since you don't have a natural "collection" of multiple parts to group together, it might seem pointless to set up your part config to use themes. But that's not true -- it is useful to be part of a standard set of themes, that groups different parts from different mods together if they offer the same "look" -- it enables easy texture switching by the player. And when it comes to textures for matching with other mods, there are further considerations. Consider my airstair part -- in addition to stockalike option, it comes with an alternate texture that matches the unique look of Firespitter bomber parts. Those parts aren't shipped with any variants, so okay, I go ahead and label my texture "Firespitter". ... but what if a reskin mod comes along and adds a new variant on top of the original Firespitter parts? They can call their new variant whatever they want, but if they file the original Firespitter look under "default", then we have one theme (the "look") split into two different themes (VARIANTTHEME) -- a player would have to pick "default" to reset the Firespitter parts back from the reskinned version, whereas for the airstair it is the "Firespitter" option. Not very intuitive. If you make parts that don't have alternative textures, but come "in a set" -- stockalike, or your own unique design. You might think this is none of your business, but hang on. If other modders create additional textures to reskin your parts, wouldn't you like to have a say over what the original look of your parts should be filed under? For instance, stockalike mods (e.g. Airplane Plus) may prefer to be grouped with other mods' parts under "stockalike" rather than a meaningless, generic "default". Whereas in the case of a mod whose parts have a unique aesthetic (e.g. keptin's original KAX textures) it may be appropriate to specify its own VARIANTTHEME. Although the mod itself doesn't ship with any variants, and thus doesn't initially have any use for the theme, it provides: a) a target theme for other mods to group their "compatible" variants under, and b) if someone else makes a reskin, then the original look can be placed under this theme, along with those from (a). - * - * - * - To kick things off, pinging a few people that this might be relevant or interesting to (based on threads/conversations I've seen elsewhere in the forum) @Electrocutor @XLjedi @Rodger Please discuss, etc etc.

Taking a step back from the "Basic Parts" tutorial which makes the assumption that I wish to add new parts... Is anyone else doing anything with just painting the existing parts by modifying the .dde texture files? It seems apparent to me that I'm coloring something (a texture file) maybe not meant to be colored? ...and wondering if I'm taking the wrong approach or if this is frowned upon as infringing on other people's work? I like to work with the stock parts... but had this idea for a cute Green Cherubs flight team and just had to paint them accordingly. I would like to release a mod for my Green Cherubs flight team which is basically just repainting the stock parts, but I also don't want to offend the Squad devs and/or original authors (PorkJet, NovaSilisko) by releasing a mod that is just their parts with a painted .dde file. Any thoughts? I have not tried to reverse-engineer my way back thru Unity by attempting to reload a .mu file, not even sure if that's possible? Anyone know if the underlying parts already allow for a base color layer? ...if I could get the mesh outline of the part file that would be wonderful. My preference would be to have a clean color map layer for livery and leave the texture file either untouched or maybe polished up a bit for a glossier airshow finish. This is basically what I'm doing: