Search the Community

What it does When you choose a "default variant" in the editor (by clicking the little "teardrop" icon), this mod automatically saves that preference in the .sfs game file. That way, the next time you play KSP, your choices will still be there, and you don't have to go around re-setting them every single time you play. There's no UI, and nothing for you to do. It's silent, invisible, and automatic. (Your choices are saved per-game, so if you're running multiple games, each one starts "fresh" and your choices are remembered in each one separately.) Download from SpaceDock License: MIT Source code Why would anyone want this? I have definite preferences about which part variants I like best. Mk1 command pod? I want the white-with-gray-stripe look, every time. Hammer SRB? I want the one with the orange stripe. And so forth. I like that the game has the ability for me to pick my "preferred default" (the little teardrop icon in the part panel in the VAB or SPH) so that I don't have to set it for every single part, every single time I place a part. However... the game doesn't remember my choices between play sessions! Oh, it remembers my choices if I exit and re-enter the VAB. It even remembers them if I exit to the main menu and then load my game again. But as soon as I exit KSP, it forgets all my preferences and I have to re-do them the next time I play. It's downright aggravating to have to go through that every time. So, I wrote this little mod so that it'll just automatically do what I wish the game did by default, which is to remember my darn choices. How to install Unzip the contents of "GameData" to your GameData folder, same as with most mods. But what about <mumble mumble editor themes mumble mumble> ? KSP has an editor feature called "themes", which you can access via the "advanced" menu in the vehicle editor. I gather that the idea is that it allows you to set an overall "theme" so that you can make your whole rocket be white, or your whole rocket be gray/orange, or what-have-you. IMPORTANT: I have made no attempt whatsoever to make this mod play nice with the "themes" feature. Haven't coded it, haven't tested it, haven't even looked at it. The "theme" feature in KSP is one of those ideas that sounds kinda cool "on paper", I suppose... but I find that in practice, it's absolutely useless to me. I find the UI confusing, and the in-game behavior counter-intuitive; I've tried tinkering with the feature in the game and it ended up merely confusing and frustrating me. Furthermore... I don't actually have any use for the feature. "Themes" are not how I play KSP. I think in terms of parts, not "themes": that is, for each part, I have one particular variant that's my favorite "look" for that part, and I usually want that part to have that look. So a feature that goes through and sets all the parts to have the same theme is useless to me. Therefore, in my own gameplay, I basically just pretend that that feature doesn't exist. So I wrote this mod to make the game do what I want it to do. I have no idea what this mod will do if you also use the "themes" feature-- maybe it's fine, or maybe they interfere with each other. Don't know, don't care. Therefore: if you are a player who likes to use the editor's "themes" feature, then this mod may not be for you.

In 1.4 now, you can change the design and model of certain parts (variants). Most parts have 2-3 basic stock variants, but I see some people on here, and on the internet, using much more. How can I add additional part variants to certain parts? I see in the VAB and SPH, when clicking on the arrow in the top left corner to open the sort parts page (not sure if this is the right name sorry), there's a tab with other variants, though I don't know how to add them to parts, or add more variants. Thanks!

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.