cakepie

Hi! Yes, this is still here. Unfortunately, it just seems to keep getting relegated to the back burner because of other stuff -- there are many things I wish to do, but only so little time. The good news is, I'm in the process of looking into the stock part variant feature over this weekend, and I believe it's definitely possible to move this over to stock-only for KSP 1.4+ -- though there may be some minor shortcomings as compared to using the firespitter plugin.

Thought so, thanks for the confirmation. Will file feature request on github.

There isn't a way to test KSP version, is there? If for instance I'd like to use a new feature like ModulePartVariants for texture switching in 1.4+ but fall back on something else otherwise.

(Updated May 14 with additional gotchas) The InflatableAirlock in Making History has dynamic crew capacity, implemented using the new ModuleAnimateGeneric.CrewCapacity field To detect when the crew capacity has changed, you can register for ModuleAnimateGeneric.OnStop ; however, there are a couple of quirks/caveats to be aware of. - * - * - * - * - * - First, there is a bit of a quirk in the response when in editor, as opposed to flight. To demonstrate, here's a PartModule that cares if the part it is attached to has dynamic crew capacity public class ModuleAnimateGenericNotify : PartModule { public override void OnStart(StartState state) { IEnumerator<ModuleAnimateGeneric> mags = part.FindModulesImplementing<ModuleAnimateGeneric>().Where(mag => mag.CrewCapacity > 0).GetEnumerator(); while (mags.MoveNext()) { mags.Current.OnMoving.Add(OnMovingHandler); mags.Current.OnStop.Add(OnStopHandler); } mags.Dispose(); } private void OnDestroy() { IEnumerator<ModuleAnimateGeneric> mags = part.FindModulesImplementing<ModuleAnimateGeneric>().Where(mag => mag.CrewCapacity > 0).GetEnumerator(); while (mags.MoveNext()) { mags.Current.OnMoving.Remove(OnMovingHandler); mags.Current.OnStop.Remove(OnStopHandler); } mags.Dispose(); } private void OnStopHandler (float param) { Debug.Log($"OnStopHandler({param}) triggered for part {part.partInfo.name}; capacity: {part.CrewCapacity}."); } private void OnMovingHandler (float param1, float param2) { Debug.Log($"OnMovingHandler({param1},{param2}) triggered for part {part.partInfo.name}; capacity: {part.CrewCapacity}."); } } In flight mode, it behaves as expected: // FLIGHT, Open Airlock [LOG 12:13:37.289] OnMovingHandler(0,1) triggered for part InflatableAirlock; capacity: 0. [LOG 12:13:39.686] OnStopHandler(1) triggered for part InflatableAirlock; capacity: 1. // FLIGHT, Close Airlock [LOG 12:13:41.435] OnMovingHandler(1,0) triggered for part InflatableAirlock; capacity: 1. [LOG 12:13:43.930] OnStopHandler(0) triggered for part InflatableAirlock; capacity: 0. But in the editor, the crew capacity isn't updated yet when OnStop occurs for airlock opening: // EDITOR, Open Airlock [LOG 12:12:59.081] OnMovingHandler(0,1) triggered for part InflatableAirlock; capacity: 0. [LOG 12:12:59.330] OnStopHandler(1) triggered for part InflatableAirlock; capacity: 0. // welp! // EDITOR, Close Airlock [LOG 12:13:01.168] OnMovingHandler(1,0) triggered for part InflatableAirlock; capacity: 1. [LOG 12:13:01.502] OnStopHandler(0) triggered for part InflatableAirlock; capacity: 0. To get the correct behavior, wait until the end of the frame before checking capacity: private void OnStopHandler (float param) { Debug.Log($"OnStopHandler({param}) triggered for part {part.partInfo.name}; capacity: {part.CrewCapacity}."); if (HighLogic.LoadedSceneIsEditor) StartCoroutine(EditorOnStopDelay()); } private IEnumerator EditorOnStopDelay() { yield return new WaitForEndOfFrame(); Debug.Log($"EditorOnStopDelay for part {part.partInfo.name}; capacity: {part.CrewCapacity}."); // this will report the correct capacity } Not sure if this counts as a bug or if there is some rational reason for it to behave like this. In any case, the tiny delay in reporting capacity change from zero to non-zero is not likely to cause any serious logical errors. - * - * - * - * - * - The second gotcha is a bit more serious -- it could lead to buggy behavior on rare occasions. If we expand our code to actually monitor the crew capacity throughout the entire animation process: private void OnMovingHandler(float start, float end) { Debug.Log("DEBUG: OnMovingHandler("+start+","+end+") progress = "+ mag.Progress + "; crew capacity = " + part.CrewCapacity); monitor = true; } private void OnStopHandler(float progress) { Debug.Log("DEBUG: OnStopHandler("+progress+") progress = "+ mag.Progress + "; crew capacity = " + part.CrewCapacity); monitor = false; } public override void OnUpdate() { if (monitor) Debug.Log("DEBUG: OnUpdate() crew capacity = " + part.CrewCapacity); } Here is what the log output (in FLIGHT) looks like: // Deploying [LOG 13:08:27.833] DEBUG: OnMovingHandler(0,1) progress = 0; crew capacity = 0 [LOG 13:08:27.834] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:27.921] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:28.014] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:28.100] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:28.197] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:28.288] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:28.381] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:28.480] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:28.565] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:28.655] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:28.749] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:28.835] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:28.931] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:29.022] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:29.116] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:29.200] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:29.299] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:29.390] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:29.485] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:29.583] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:29.668] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:29.773] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:29.853] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:29.974] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:30.039] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:30.159] DEBUG: OnUpdate() crew capacity = 1 [LOG 13:08:30.225] DEBUG: OnStopHandler(1) progress = 1; crew capacity = 1 // Retracting [LOG 13:08:50.368] DEBUG: OnMovingHandler(1,0) progress = 1; crew capacity = 1 [LOG 13:08:50.369] DEBUG: OnUpdate() crew capacity = 1 // !!! [LOG 13:08:50.462] DEBUG: OnUpdate() crew capacity = 1 // !!! [LOG 13:08:50.565] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:50.646] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:50.736] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:50.820] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:50.914] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:51.001] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:51.174] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:51.290] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:51.305] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:51.381] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:51.471] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:51.553] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:51.649] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:51.734] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:51.838] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:51.918] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:52.016] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:52.100] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:52.191] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:52.288] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:52.384] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:52.484] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:52.574] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:52.656] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:52.752] DEBUG: OnUpdate() crew capacity = 0 [LOG 13:08:52.833] DEBUG: OnStopHandler(0) progress = 0; crew capacity = 0 Notice that when retracting the airlock, the crew capacity can remain at >0 for a couple of OnUpdate() cycles after the retract animation has started playing. If we consider plugin mods with functionality that moves Kerbals into / between parts, it is common to test for space available using: if (part.protoModuleCrew.Count < part.CrewCapacity) ... There is thus a very small possibility that, if this test occurs within those couple of frames, the mod will erroneously consider the inflatable airlock to have an open seat available. If the mod then moves a Kerbal into the part (while crew capacity > 0), it will actually succeed: private void OnMovingHandler(float start, float end) { ... if (start == 1f) StartCoroutine(MoveKerbal()); } private IEnumerator MoveKerbal() { yield return 0; // wait one frame ProtoCrewMember victim = part.vessel.GetVesselCrew()[0]; // grab an arbitrary kerbal in the vessel Debug.Log("DEBUG: " + victim.name + " has been \"volunteered\" to enter the retracting airlock..."); Part fromPart = victim.KerbalRef.InPart; fromPart.RemoveCrewmember(victim); part.AddCrewmember(victim); Debug.Log("DEBUG: " + victim.name + " moved from " + fromPart.name + " to " + part.name); } Although KSP will check for available crew capacity when part.AddCrewmember(victim); is called, the test will erroneously pass. [LOG 15:15:45.120] DEBUG: OnMovingHandler(1,0) progress = 1; crew capacity = 1 [LOG 15:15:45.121] DEBUG: OnUpdate() crew capacity = 1 [LOG 15:15:45.212] DEBUG: OnUpdate() crew capacity = 1 [LOG 15:15:45.213] DEBUG: Bill Kerman has been "volunteered" to enter the retracting airlock... [LOG 15:15:45.213] DEBUG: Bill Kerman moved from mk1-3pod to InflatableAirlock [LOG 15:15:45.325] DEBUG: OnUpdate() crew capacity = 0 [LOG 15:15:45.413] DEBUG: OnUpdate() crew capacity = 0 ... This leads to a kerbal sitting inside the retracted airlock, which then has crew capacity = 0 and crew count = 1. Due to the presence of crew in the part, it cannot be deployed -- animation is disabled thanks to a check that was intended to prevent retraction of an occupied airlock.

Making History's InflatableAirlock part is a real troublemaker: Issue #99 (and causing other issues with my mods too )

For folks who love to live on the cutting bleeding edge, here is a dev build AirlockPlus.0.0.9-temp-patch-2 for KSP 1.4.x / 1.3.x This patch is to be applied on top of an existing 0.0.9 install. It includes the bugfixes in AirlockPlus.0.0.9-temp-patch-1, so there is no need to apply both patches. Changes are mostly under the hood; not going to enumerate them here; anyone who's interested can go read here. Please be aware that there are currently still a couple outstanding known issues (which also affect other existing releases/patches): 1. Special handling required for InflatableAirlock from Making History DLC. Known to cause error messages in logfile -- no need to report this, I am aware of it. Not expected to be game breaking, but it'd be best to steer clear of using AirlockPlus with that part for the time being. 2. (Connected Living Spaces compatibility) a) If you also use CLS, you may encounter incorrect behavior of AirlockPlus, such as denied entry to a living space that should have enough room. This is due to a bug in CLS where part/space occupancy accounting is incorrect. b) The InflatableAirlock from Making History DLC causes issues for CLS, leading to incorrect behavior in AirlockPlus. This is due to CLS not being able to register when the airlock is deployed/retracted. Fixes for these issues have been submitted to CLS [a,b] and are expected to be included in the next CLS release. Workaround for CLS-related issues: temporarily turn on the "Allow Unrestricted Transfers" option in CLS.

Did some repo digging; things still looking a bit jumbled even after the 1.2.6.1 reorg. You have both of these: CLSStockMakingHistory.cfg (originally located in Distribution/GameData/ConnectedLivingSpace/Configs) CLSStockMH.cfg (originally located in plugins/ConnectedLivingSpace/Distribution/GameData/ConnectedLivingSpace/Configs) The only difference between the two is that CLSStockMH.cfg has :NEEDS[SquadExpansion] clauses -- albeit misplaced. Should probably look like @PART[kv2Pod]:HAS[!MODULE[ModuleConnectedLivingSpace]]:NEEDS[SquadExpansion] Instead of @PART[kv2Pod]:HAS[!MODULE[ModuleConnectedLivingSpace]:NEEDS[SquadExpansion]] However, neither of these patches are actually applied, because they are preempted by: CLSMissingHistory.cfg (originally located in Distribution/GameData/ConnectedLivingSpace/Configs) This file is identical to CLSStockMakingHistory.cfg. This is likely a mistake, you probably intended to add configs for Snark's Missing History mod

@Papa_Joe Bugfix PR #98 update CLS state to reflect crew movements, maintain correct occupancy figures for spaces. Got away with not doing this in the past because CLS state was maintained only for active vessel and was recalculated on vessel switching. Bug was exposed after changing to VesselModule approach.

IndicatorLights has just added integration -- it doesn't use icons, but will utilize the same color-coding for crew types as the other Community Trait Icons supported mods. On crewable modules, Indicator Lights provides color-coded LEDs to show what types of crew are on board:

no probs.

I looked into it, the patch would look like: @IndicatorLights:NEEDS[CommunityTraitIcons]:FINAL { @CrewIndicatorDefaultColors { %Pilot = #$@CommunityTraitIcons/Trait[Pilot]/color$ %Engineer = #$@CommunityTraitIcons/Trait[Engineer]/color$ %Scientist = #$@CommunityTraitIcons/Trait[Scientist]/color$ // ...etc... } } This will indeed result in IndicatorLights using the colors specified by CommunityTraitIcons's config. Changes made were: - edit-or-create, rather than insert - change patch order to FINAL, because other patches may modify settings in CommunityTraitIcons (e.g. Cetara's Suit Pack does this) and we want those changes to be reflected However, this is still an incomplete solution, as it requires explicitly enumerating the crew classes. This leads to two issues: 1. Maintenance overhead. Future changes to CommunityTraitIcons's list of included crew classes, e.g. adding an entry for "Plumber", would not be picked up automatically; the patch would require updating. Not a huge deal, just a small bit of extra work for both of us and a slight delay for end users. 2. This solution cannot cope with situations where other patches add their own crew classes to the CommunityTraitIcons list. e.g. someone out there might create their own "Electrician" mod defining a new crew class and include a patch: @CommunityTraitIcons:NEEDS[CommunityTraitIcons] { name = Electrician color = 0,0.75,1,1 icon = ElectricianMod/CTIsupport/ElectricianIcon } This can occur without my knowledge / involvement, and it would still work seamlessly with CommunityTraitIcons and the other mods that make use of its icons/colors. The same would not be true for IndicatorLights -- and that feels less than satisfactory: we haven't truly made IndicatorLights and CommunityTraitIcons "compatible" I've been digging through MM syntax, tried to figure out some way to do it dynamically instead of enumerating every single crew class. No luck so far, been running into MM errors while trying to use advanced syntax such as looping and editing other nodes. Will ask in MM thread to see if anyone there can assist. However, there is one large hurdle against such an approach: if I'm not mistaken, MM can add and edit values, but the keys must be literals; they cannot be variable. Whereas IndicatorLights stores crew classes as keys in its config. So, in order for MM to be able to manipulate the crew classes in IndicatorLights's settings, the config would instead have to be structured like IndicatorLights { CrewIndicatorDefaultColors { Color { class = Pilot color = #F00F00 } Color { class = Engineer color = #C0FFEE } // etc... } } (i.e. not very different from what CommunityTraitIcons currently has.)

Well, I'm glad I asked before putting in the work. I wasn't aware MM could do that. I'll look into it further and get back to you.

@Snark You seem to have misunderstood / missed the point. I am aware that IndicatorLights can be patched using ModuleManager; that is not what I am suggesting. Community Trait Icons is a "framework" mod; the purpose is to provide a single point of configuration for icon/color settings to represent the crew classes. These are specified in a config file -- customizable by the user and patchable using Module Manager, of course -- that is parsed by a lightweight plugin. "Customer" mods such as PortraitStats and AirlockPlus can simply call up and ask "hey, give me the icon/color combination for pilot" etc. -- this provides a common and consistent user interface across mods. Making a patch for IndicatorLights so that it uses the same default colors as Community Trait Icons defeats the purpose -- if the user has customized / patched the settings for Community Trait Icons, those changes would not be reflected in IndicatorLights unless it, too, is separately patched. What I am proposing is that IndicatorLights adds code that checks to see if Community Trait Icons is installed, and if so, ask Community Trait Icons for the colors that should be used, in place of the IndicatorLights defaults. (Wrapper code is available.) Now that I've clarified that I'm asking for source code changes rather than a module manager patch -- are you still open to this? I'm willing to take a shot at it if you're okay with it.

@Snark How do you feel about adding an option to support integration with Community Trait Icons if a player has it installed? Besides icons, Community Trait Icons also provides color settings for each Kerbal class (including support for MKS and other mod classes). Using these same colors for your crew indicator lights would provide UI consistency with other supported mods. Let me know if you're interested or need help with it.

Tested and properly functioning in KSP 1.4.2.

Ah, sorry for not being clearer. My comment was in the context of CKAN users on KSP 1.3.1 being asked by CKAN to switch to DPAI 6.8, only to discover that KSP-AVC would warn that DPAI 6.8 is meant for KSP 1.4.0. NavyFish has confirmed that 6.7 is okay on KSP 1.3.1, so if you're annoyed by the message that says it only supports 1.3.0, you can safely edit the DockingPortAlignmentIndicator.version file -- look for this part (it's right at the end): "KSP_VERSION_MAX":{"MAJOR":1,"MINOR":3,"PATCH":0} And change the last number from "0" to "1"

@MikeO89 ckan should now correctly get 6.7 for you on 1.3.1 and it shouldn't cause any KSP-AVC nagging. If nagging still occurs, give a holler and we can look into it further.

There will be a release when I am ready to release. It is being worked on. The lack of a release on CKAN for KSP 1.4.x is intentional. In the interim, for users who are capable of and willing to do a manual installation, v.0.0.9 plus the patch will function on KSP 1.4.x.

FYI for CKAN users who are still on KSP 1.3.x -- (e.g. @MikeO89) If CKAN offered you DPAI 6.8.0, this is because: seems that for a short time, there was a version of DPAI available that had incorrect KSP compatibility information. CKAN thus believed that DPAI 6.8.0 is good for KSP 1.3.x. But when CKAN ended up fetching the fixed version of DPAI 6.8.0 for you, it contained a KSP-AVC .version file which indicates that it is strictly for KSP 1.4.1 only, causing AVC to nag at you. The offending metadata has been taken out of circulation, and this problem should now be fixed. [ref] You should be able to uninstall DPAI 6.8.0 and have CKAN grab you DPAI 6.7.0 instead, as NavyFish intended: @NavyFish FYI this is why/how you got these questions.

Thanks @Simog, I'll take follow-up questions to PMs, in order not to clog up the thread with detailed discussion.

AirlockPlus now has German, French, Portuguese. Requires Italian proofreader. and Italian.

Hm, that looks like something that should be sent as feedback to Squad to improve their translation. In the stock translation there's "Cette pièce est pleine.", "Le Complexe astronautique est plein !", etc. Thanks for the help!

Since you didn't mention anything about the inflatable airlock -- when deployed, it can dock with a Clamp-o-tron Jr, so don't forget to handle that case! Also, Issue #96 for localization related issues.

@Rezza Goan Thanks for reviewing. I have a couple of follow-up questions: Regarding "plein" vs "complet", I used stock KSP's wording from a related message: #autoLOC_115954 = Impossible d'embarquer dans un module plein. Is there some reason to use "complet" instead of "plein"? Otherwise, I would prefer to conform with stock, so that it looks consistent for the players. For BP002c, this message refers specifically to a "living space" in Connected Living Space (CLS) mod -- which is a collection of multiple crewable parts that are reachable from one another "internally" without going EVA. Because stock KSP widely uses "pièce"/"module" to refer to single "part"/"module", I think "un module de vie" might cause confusion for players. I'll go with "un espace de vie" here, unless you have some other input/feedback?

Gender, it gets me all the time! Thanks @Spricigo!