cakepie

v1.0.1 released. This is a simple recompile for KSP 1.5.x; it has also been backward compatibility tested to work for 1.4.x and 1.3.x

Existing version has been tested and works fine in KSP 1.5.0 / 1.5.1, so you should be able to disregard any version warnings and continue using it for now.

Everything appears to be in order -- KSP 1.4.4

Can't argue with that!

You're exactly right, that is the necessary workaround to avoid this gotcha. But it feels rather like we're compensating for shortcomings in the stock implementation. (To be precise: not all animated parts, just specifically those ModuleAnimateGeneric modules that alter CrewCapacity.) Programmatic access to Part.CrewCapacity is functional, with minor caveat as described in OP. Are you referring the the "crew" tab {build, actions, crew} for seating? Nope, that doesn't update automatically to reflect extra seat added/removed when deploying/retracting the Making History inflatable airlock.

Added new findings to the OP, related to crew transfers into the inflatable airlock. tl;dr: The inflatable airlock's Part.CrewCapacity remains nonzero for a couple of frames after the airlock starts retracting. It is possible to successfully perform a crew transfer into the inflatable airlock within these couple of frames, while the part is animating. This will lead to buggy behavior subsequently.

Fair enough. Give a holler whenever you're ready.

No reason to let perfect be the enemy of the good: - The parts with flags do work, they're just unsightly thanks to the flag glitch. - It's still useful to be able to convert all the parts that you do have variants for with one click Or do you mean that it's not a pressing concern, because you're not planning to release your texture/livery pack until that bug is fixed?

Ah, you mean "existing" as in "stock" and "new" as in "KSP 1.4+". Okay. Strictly speaking, part variants don't have to be associated with a variant theme -- it is technically optional. This is because part variants are used for different purposes, and it doesn't always make sense to tie-in a variant with a visual theme. For instance, the MH structural tubes come in 5 variants (Short, Medium-Short, Medium, Medium-Long, Long). But this is a size change, so it isn't meaningful to specify themes for these variants. On the other hand, for stock parts that use variants for alternate textures, each and every variant is associated with a theme. E.g. MH structural panels use {White, Dark, Gold} themes, and Rockomax tanks use {Black and White, Orange} These stock parts don't need to reference a "default" theme, since their alternate texture variants were specifically designed according to the stock variant themes in GameData/Squad/Parts/VariantThemes.cfg (and vice versa) Thus, every single pre-existing stock variant already maps to a named theme. So, following this precedent, when we add alternate texture variant(s) to a existing parts that did not previously have variants, we want each variant to be associated with a theme -- i.e. your "XL_Stealth" theme on the variants that you added, so that the player can switch all relevant parts to that design with one click; but also "default" theme for the original design of the parts, so that they player can revert to the original / stock look with one click. Does that make sense?

I don't understand the situation you're trying to describe. What do you mean by "existing new part" ? In your particular use case, you are using MM patch to add ModulePartVariants to existing -- not new -- parts that don't already have variants. These parts didn't have variants originally, so it's not possible for them to be associated to any theme to begin with.

Yeah, we'd put CCVT_default and other such standardized VARIANTTHEMEs in their own config file. Localization for each language are better off in their own respective files. All of this packed as a mod, with its own mod folder. Similar mods like Community Resource Pack, Community Tech Tree, etc have been doing it this way for a while, should be workable. I think we should be okay as long as mods that bundle it make sure to keep updated with new versions. (i.e. avoid users overwriting existing copy with an older one.)

Um, no, not quite. 1. You do want every part that has a relevant part variant to be associated with the VARIANTTHEME. 2. The set of standard VARIANTTHEMEs is put in a standalone config -- no MM syntax, so not considered a patch. 3. The standard VARIANTTHEMEs are then shared by multiple mods. We have to do it this way, because we cannot use a MM patch to do "add this VARIANTTHEME if it doesn't already exist" Don't you have a VARIANTTHEME named "XL_Stealth"? (This is different from having VARIANTs on each part that you're reskinning, also named "XL_Stealth".) Do let me know if I've lost you / what you didn't understand and I'll try to explain better. You sure it's just that one and not all air intakes? All air intakes have a transform used for intakeTransformName in ModuleResourceIntake; texturing that could be the cause -- similar to the issue you had with landing gear / lights, you might not want to disturb that transform.

Edit: false alarm

Tested and properly functioning in KSP 1.4.3.

@XLjedi The aerodynamics impact is odd; unfortunately I don't have any insight into that. As for having to name the meshes to reskin, that's less surprising, but a good catch and a gotcha worth taking note of. (If I recall correctly, firespitter's texture switch also provided for targeting specific meshes only.) Meanwhile, I've been experimenting, and also running into limitations of what part variants can do. But putting aside issues with ModulePartVariants, I'm thinking maybe we can make some progress on VARIANTTHEME configs. E.g.: your config baseThemeName = Default doesn't do much good if there is no corresponding "Default" variant theme. For a start, how does this look for your needs? VARIANTTHEME { name = CCVT_default displayName = #CCVT_default_displayName description = #CCVT_default_description primaryColor = #ffffff secondaryColor = #4c4f47 } Localization { en-us { #CCVT_default_displayName = Default #CCVT_default_description = The original version of parts that have variants added by mods } } You can do: @PART[partName]:HAS[!MODULE[ModulePartVariants]] { MODULE { name = ModulePartVariants baseThemeName = CCVT_default baseDisplayName = #CCVT_default_displayName primaryColor = #ffffff secondaryColor = #4c4f47 } }

True that, but structural tubes appears to only change model, so I was a bit puzzled that I wasn't able to create a separate module to handle texture/color changes. All in all it's a an ongoing process finding the limits of what can be done with part variants, and where the bugs / gotchas are.

@Warezcrawler Thanks, but that wasn't a question. I'd already solved my problem, this was a brief howto for others; in particular highlighting a potential gotcha that I encountered, and provide a workaround for it.

That's one of the use case here -- I'm trying to see if we can patch texture variants (color and/or texture map) onto pre-existing model varants, whether that be from another mod, or already specified in the original part cfg. I'm basically exploring the space of what's possible vs impossible in the space of different mods being able to interoperate. That's something that we could try to achieve community consensus. However, option3 didn't seem to work, so I'm wondering if a) I didn't do that correctly, or b) even with such standardization, it's not guaranteed to work.

I've been trying to wrangle the structural tubes as part of figuring things out, and running into various issues. 1. This works, but things will start getting ridiculous once you go on to add many more colors. @PART[Tube4] { @MODULE[ModulePartVariants] { +VARIANT,* { %name = #$name$ (black) %displayName = #$displayName$ (black) %primaryColor = #2d2e2d %secondaryColor = #2d2e2d %TEXTURE { %_Color = #2d2e2d } } } } 2. This wouldn't work because the last (lowest in PAW) ModulePartVariant will always be the one that takes effect after a save/load @PART[Tube3] { @MODULE[ModulePartVariants],0 { %tag = original } +MODULE[ModulePartVariants]:HAS[#tag[original]] { %tag = black @baseVariant = #$baseVariant$-black @VARIANT,* { %name = #$name$-black %displayName = #$displayName$-black %primaryColor = #2d2e2d %secondaryColor = #2d2e2d %TEXTURE { %_Color = #2d2e2d } } } } 3. I had high hopes for this one, but no joy. @PART[Tube2] { @MODULE[ModulePartVariants] { tag = model @VARIANT,* { !TEXTURE } } MODULE { name = ModulePartVariants tag = color @VARIANT[Basic] { !GAMEOBJECTS !NODES } VARIANT { name = KSP_Black displayName = Black primaryColor = #2d2e2d secondaryColor = #2d2e2d TEXTURE { _Color = #2d2e2d } } } } Any better ideas? - - - Edit: basically, trying to figure out how to get the bolded below to work in the context of MM patching

So, to get back on topic. Sorry I didn't have time to delve into the substantial stuff earlier. Here are my responses: That's indeed very helpful. But from some testing, seems there are gotchas when there is a mix of variants that want to manipulate model/node, and variants that are texture switch. Patch order may become a factor in the interaction between multiple mods patching variants into the same part. VARIANT names aren't the main issue; as you pointed out, avoiding collisions here is easy. The original part author can use whatever they want, and other modders patching the part would use prefixes, so two patches by different people for the same part can avoid any conflict. Yes, I've already noted the MM limitation discussed in the MM thread . A quick elaboration for other readers: Suppose modder A makes a mod that reskins parts in black, whereas modder B makes a mod that provides red textures. Both define their own VARIANTTHEME for their respective variants. They also agree that it makes sense to provide a VARIANTTHEME that lets the player easily reset their parts to the original (no-reskin) look -- we'll name that "default" by consensus. A player could have either one of the reskins installed, or even both. So, if the modders are responsible for including the "default" VARIANTTHEME as part of their patch, they would need to do it in a way that "check if it already exists, then create it if not." But because VARIANTTHEME is a root node, we run into a technical limitation: MM is not able to do what we want -- it might cause other stuff to break. Thus, the only solution for us is to have the "default" VARIANTTHEME defined in a common community consensus patch, and for both the black/red reskin mods to include that as a dependency. I'm pretty sure you know your stuff, but for the benefit of others, let's be careful not to conflate different things together. What you're saying is: When a default variant is not specified from among the available VARIANTS, the original state of the part is automatically treated as the "Base" variant. If no display name is explicitly defined for the Base variant, it will show up as "Basic". In stock parts, a display name is usually provided, which coincides with the name of the VARIANTTHEME ("color scheme") that it is associated with. Lengthier explanation with examples in the spoiler -*-*-*- I've seen your tentative MM patch code here. Is there something elsewhere that I've missed? Using prefix for names is a wise step. If I understand correctly, you're adding a "Default" VARIANTTHEME and setting the parts' original ("basic") variant to that theme? The flag bug is indeed a deterrent. But I like to consider it as buying some time to figure things out too. =)

Here is a patch for players who want to use this mod on KSP 1.4+ without needing firespitter plugin: https://gist.github.com/cake-pie/deb2a1e2b5a39e551d207b9e06cbf1d8 Apply this patch for a preexisting installation of Hawkspeed Airstairs v. 0.8.1 on KSP 1.4+ Stating the obvious: this will not work on older versions of KSP before 1.4.0. If you have no idea what to do with the patch: please do not use it. Properly installed Hawkspeed Airstairs v. 0.8.1 will work perfectly fine on KSP 1.4.x without the need for this patch. Note that when using firespitter, you are able to interrupt the stair deployment animation. i.e. if you tell the stair to deploy, but change your mind while the animation is still playing, you can immediately tell it to retract and it will instantly start closing up. This is no longer possible if you use this patch and switch to stock KSP animation -- i.e. you must wait for the stair to finish deploying before you are allowed to retract it. Holding off on a full official release because I'd like to wait for: - Module Manager updates that would obviate the need for separate releases to target different KSP versions (support for 1.3.1 must continue for now) - see if we can get some community coordination for standardized variant themes etc.

No. We are talking about new features in stock KSP 1.4+ and how best for modders to coordinate with one another when using these new features, so that different mods play nicely together. I am well aware that there are preexisting mods for switching part textures or repainting parts/craft -- but that's not what is being discussed here.

FYI, there's an upcoming MM feature -- not yet released! -- which will allow :NEEDS[SquadExpansion/MakingHistory] rather than just NEEDS[SquadExpansion] This is better since Squad would presumably also put other future DLCs inside SquadExpansion/ and we should thus test for the specific DLC folders rather than the one that contains all of them.

And also @Beale @CobaltWolf who are also interested in this possibility. If I understand correctly, an example of this would be taking these AirplanePlus cockpits -- http://i.imgur.com/XtVdNoE.jpg -- and condensing it into a smaller number of parts. Not to rain on the parade, but if I may, a word of caution -- particularly with respect to @Manwith Noname's interpretation. The API documentation for ModulePartVariants states: For whatever underlying technical or design reasons, that is the recommendation that we have at this time from the existing documentation from the developer. In other words, it's not recommended to go too far with this if it involves model changes between the variants. Using the Making History parts as a rough guideline, these examples are okay: - different lengths of the same structural tube - rocket nozzle attached to the "bottom end" of a tank structure, vs only a bare truss structure But it doesn't look like it is intended or recommended to use Variants as a way to "combine" multiple parts into "one icon" in the part palette in the editor. In AirplanePlus, let's look at the size2 cockpits as an example -- the three on the left -- those are rather quite distinctly different meshes. Not to make a blanket statement about all parts, but in this case, I personally would not be very confident about the model differences being "not too drastic". There are also technical consequences here. Consolidating parts together isn't just combining them into "one icon" -- it is combining them into one part. The original parts do not exist anymore, they have been subsumed. This change is save breaking. You could be extra careful and keep a copy the original part, and set it up so that it is hidden in the editor, which would allow you to continue to load existing .craft files, and keep playing with your already-launched vessels. But, going back from a "consolidated" part to separate ones would require editing existing vessels in your save files. This is fine and well in cases like where a modder wishes to do it for several similar parts in their own mod. There is a transition period, and then the old, separate parts get deprecated. It's all official. However, I'd caution against doing this without permission from the original mod author. In particular, combining parts from stock + different mods together, seems especially ill advised. First, this impacts other mods that rely on MM to patch existing parts. For instance, Connected Living Space may need to patch its partmodules into existing parts of other mods, or Indicator Lights uses MM to add models to existing parts. More importantly, this has the potential to create complications for user support, because that sometimes (often?) relies on users providing .craft files and save files that exhibit a particular bug or issue that they are having. So, a player who is using an "unauthorized" "part combiner" patch encounters a problem with Mod X, and reports it: - Mod X author has trouble loading the provided save file because "combined-part" is not the same as the original parts. - Mod author asks for problem to be replicated on 'out-of-box" install of their mod. - Player is not able to replicate the issue (it may be a complex interaction that is difficult to recreate) - Bug is not found and resolved. This can affect other modders besides the original mod author too. E.g. if a player encounters a problem with plugin Mod Y in conjunction with part Mod X. If I were developer of Mod Y, I'd typically be happy to investigate a mod interaction with Mod X when that has been narrowed down as the cause. But, if the player is using an unofficial, "combined" version of part from Mod X that bundles it with Mods U, V, W, etc ... that could make things more difficult. So, please be careful. It is best that changes of this nature be confined within individual mods, and officially incorporated in the mod, not a third- (fourth?-) party patch.

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.