Search the Community

I know like half a year ago it was in dark mode, but now it's light mode code blocks that are unreadable (yes I still use light mode). Proof: I believe this is caused by the themes engine using dark mode color for light mode code blocks.

I usually go with Greek gods and other ancient mythologies for rocket and/or spacecraft names. Here are some: - Artemis II Heavy Rocket - Osiris IV Medium Rocket - Hercules Crew Pod - Phoenix Mun Lander - Icarus Rescue Capsule - Atlas Duna Landing Vehicle - Capricorn Eve Ascent Rocket Anybody got something better? I'd like to hear them.

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.