cakepie

At long last: v0.0.10 for KSP 1.7.x - 1.3.x Requires Module Manager (please obtain separately.) Localizations available:　中文　・　日本語　・　español　・　русский　・　français　・　Deutsch　・　italiano　・　português (Brasil)

Modder looking to ensure compatibility rather than end-user / player. Zero prior knowledge about details of this mod, hope someone can save me some time by answering these quick questions so I don't have to spend too much time digging. - I heard this mod has parts that are inflatable or otherwise changes crew capacity. Which are they? - Have these parts (especially their PartModule plugin code handling animation / dynamic crew capacity) changed significantly between KSP 1.3 to present? - Which is authoritative/maintained fork at this point in time? Is it @Kerbas_ad_astra's https://github.com/Kerbas-ad-astra/Stock-Revamp? Thanks in advance.

This doesn't look like an input lock issue caused by mods actually using input locks and conflicting. You have a cascade of null reference exceptions. The game gets so overwhelmed that the flight simulation part of the code does not progress, and by extension, seems to stop processing inputs. Below is what I can decipher from your posted log snippet, but you should really post the full log for inspection. ----- The first exception in your list is It looks like you were using some kind of input field, and it lost focus, e.g. you clicked outside of it. This fired TMPro.TMP_InputField.OnDeselect() and so on. ManeuverNodeEditorTabVectorInput.OnNormalValueChanged() suggests that you had just been modifying the normal component of a maneuver using the new maneuver node editor feature. NullReferenceException occured in ManeuverNodeEditorManager.UpdateDeltaVInNodeComponents(). We don't have access to that code so we can't know for sure what was null. The root cause may not necessarily lie in the maneuver node editor. Something else in your modded install may be interfering with it. Also, this may not actually be the actual error that started the cascade of other errors that are present in your log, it could be totally unrelated ----- 30 seconds later a vessel changed SOI ----- In rapid succession, several of these: You clicked some button, from the log looks like Kerbalism's monitor dialog, this button or this button. This triggers an attempt to save a backup of the game state. Things break down because there is/are contract(s) in your game that don't have agent information, so when the contracts system gets asked to save its data, ConfigNode.AddValue() chokes. This repeats again when Kerbalism switches vessel because that too triggers the contracts system to save its data. I would look into what mods you have that provide or modify contracts. ----- The vessel switch requested via Kerbalism occurs: ----- And then back to choking on contracts data Until you intervene and use the button to return to space center. ----- So as a good starting point I suggest you look at what mods provide contracts and check their contract configs, and look into any mods that programmatically manipulate contracts data, or otherwise manipulate saves. Or your save may just be stuck with some invalid (or rather, lacking) data. Is it carried over from an older KSP version by any chance?

GitHub wiki has been populated, and all of the info for other modders previously found in thread OP has now been moved there instead.

Better Sandbox Specializations v0.0.2 for KSP 1.7.x (backward compatible with KSP 1.6.x - 1.3.x) WARNING: Dev build. Use with caution. Backup your saves before proceeding. Requires Module Manager (please obtain separately.) Download includes the Harmony library, version 1.2.0.1. v0.0.2 ~ 2019-04-17 ~ KSP 1.7.x - 1.3.x Dev Build - Harmony 1.2.0.1 included - Refactored code, improved robustness, optimizations - Backward compatibility for KSP < 1.6.x

@Nightside use this one instead, it's newer.

Out of scope. Right now, I am only focused on a narrow and well-defined problem definition, which I have outlined right at the top of OP: Which cheapens specializations far too much. If you mean having to gain experience and level up, this is already possible in stock. You need to look under "Advanced" in the difficulty options when starting a new game, and turn on "Enable Kerbal Experience". It is on by default for career and off by default for science and sandbox, but you can adjust it. There is also the option to have them level up immediately once required XP is reached. For autopilot/SAS functionality: I don't have any problem with how things work when the "Enable Kerbal Experience" setting is "on". I also respect the "All SAS Modes on all probes" stock setting if the player turned that on. ( = all SAS available all the time without prerequisites. ) What I've done is provide a bit more depth of choice when both of those are turned off. Stock gives any crewmember* full SAS abilities. With this mod, that can be changed to specifically require a pilot. * oversimplification. based on testing, stock behavior is not completely robust in modded installs.

It is a C# patching library. In layman's terms (or at least, anyone with some fundamental experience and understanding of using mods in KSP) it can be thought of like Module Manager, but for code rather than configs. Just as Module Manager lets you write configs that patch other configs at runtime without having to actually modify the original files, Harmony provides modders a way to write code that patches other code at runtime without actually modifying the originals. Not a perfect analogy, but hopefully should help most people understand what it is.

Better Specialization Settings v0.0.4 @ 2019-05-22 This mod provides a bunch of settings to allow finer customization of gameplay revolving around crew specializations (i.e. Pilot, Engineer, Scientist). The bulk of its functionality is focused on making crew specializations more relevant and meaningful in sandbox and science sandbox play. There are also settings to allow customization of the level requirements needed to perform certain tasks in career mode. Oversimplified tl;dr: Make autopilot/SAS require a pilot in science/sandbox Make wheel/leg repairs require an engineer in science/sandbox Allow adjusting engineer level required for wheel/leg repairs in career Make parachute repacking require an engineer in science/sandbox Allow adjusting engineer level required for parachute repacking in career ~ ~ ~ ~ ~ Preface: stock KSP settings In stock KSP, the primary setting affecting gameplay behavior related to crew specializations is the "Enable Kerbal Experience" setting found under "Advanced" in the difficulty options for new games: In Career mode, this setting is turned on by default, which means that kerbals need to gain experience in order to level up and unlock more abilities, such as different SAS stability modes for pilots, or wheel repair skills for engineers. In the Science or Sandbox modes, it is turned off by default, and all kerbals start with their level already maxed out. This option can be changed at the start of a new game (but not for existing saves), which means it is actually possible to play a Career game without having to level up your kerbals, or play Science or Sandbox modes with the experience system turned on. However, this setting is very coarse-grained and has other side effects. Consider: When the setting is on, certain tasks can only be performed by specialized kerbals of a particular skill level, e.g. a pilot of particular skill level is needed to access various SAS stability modes like normal/anti-normal and radial/anti-radial. But with the setting turned off, many of these tasks can suddenly be performed by all kerbals regardless of specialization. Scientists and engineers can fly vessels with full SAS and all stability mode options. Pilots and scientists can repack parachutes and perform repairs. You can do almost everything with just a scientist, etc. This behavior cheapens the specializations, so the specialization type of a crew member does not matter as much anymore. And because this is the default setting for Science and Sandbox games, it can contribute to the gameplay in those modes feeling more shallow. Now, I'm not actually opposed to having an "easy mode" option where the skill levels and specializations do not matter very much. The real problem here is that there is a lack of a middle ground between the "on" and "off" settings. Why can't we have a setting where we don't have to deal with the XP and leveling up aspects, but where the different specializations are still meaningful in terms of needing certain types of crew to fill different roles and do different tasks? This mod was born to address that flaw. ~ ~ ~ ~ ~ Autopilot/SAS For players with mods that add other crew specialization types: when "pilot" is mentioned here, it includes any modded crew specialization that has the "Autopilot" skill. Stock behavior: If Enable Kerbal Experience is on, SAS and the stability modes available to a vessel depends on having a command module with a pilot of adequate skill level for crewed vessels. For uncrewed probes, a part with the required SAS service level is needed. (SAS service level is analogous to pilot experience level: cheaper, simpler probe cores have lower level than the more expensive and advanced models. For example, the QBE is equivalent to a Level 0 pilot and only has stability assist, whereas an OKTO2 is equal to a Level 2 pilot.) For KSP versions before KSP 1.6, if experience system is turned off, then none of the above crew skill requirements and part SAS service level requirements are respected. SAS and all stability modes are available with any type of crewmember in a command module, or any probe core. This actually makes it pointless to use more expensive, "better" probe cores when a cheaper one would still give full SAS. To fix the issue, since KSP 1.6+ an additional option called "All SAS Modes on all probes" is available in the "Advanced" tab of the difficulty options when the game mode is Science or Sandbox: If the option is turned on, the behavior is the same as having experience system turned off in earlier versions, as already described above. If it is turned off, then the intended behavior is for any type of crewmember to be able to provide all SAS stability modes on crewed vessels, but uncrewed probes would still need to have a part with the required SAS service level. However, testing has shown that when "All SAS Modes on all probes" is off, SAS availability for crewed vessels actually depends on having a crewmember with either Autopilot Skill, Repair Skill, or Science Skill, i.e. these are being used as a proxy to test if there is a Pilot, Engineer, or Scientist on board the vessel. This works for stock KSP, but if you use any mod that adds crew specialization types that don't have any of these skills, then it is no longer true that "any crewmember" is able to give full SAS control. What this mod provides: If "Enable Kerbal Experience" is on, stock behavior as described in the previous section will be used. Full requirements are imposed for SAS availability. If "Enable Kerbal Experience" is off, but "All SAS Modes on all probes" is on, stock behavior will be used: none of the SAS requirements are imposed. For backwards compatibility, this mod adds the "All SAS Modes on all probes" option to older KSP versions before KSP 1.6. This option is located under the "Better Specialization Settings" tab of difficulty settings dialog, rather than under the stock "Advanced" tab. If both "Enable Kerbal Experience" and "All SAS Modes on all probes" settings are off, then custom behavior of this mod will be used. This is governed by a setting called "Require pilot for SAS": (KSP 1.6+) (KSP < 1.6) When "Require pilot for SAS" is on, SAS and the stability modes available to a crewed vessel will depend on having a command module with a pilot. Crew level is irrelevant as it is always maxed out. Other crew types will not be able to provide SAS. Uncrewed probes will need to have a part with the required SAS service level. If the setting is off, then any type of crewmember will be able to provide all SAS stability modes on crewed vessels. Uncrewed probes will still need to have a part with the required SAS service level. This is a bugfixed version of the KSP 1.6+ behavior when "All SAS Modes on all probes" is off, in that truly (almost) all crew types will provide SAS. (Tourists, and the modded specialization type "Civilian" don't count.) ~ ~ ~ ~ ~ Wheel/leg repair For players with mods that add other crew specialization types: when "engineer" is mentioned here, it includes any modded crew specialization that has the "Repair" skill. Stock behavior: If Enable Kerbal Experience is on, an engineer of level 3 or above will be required to repair damaged wheels and landing legs. Much, much older versions of KSP needed only level 2 to repair legs, but that has not been the case since around KSP 1.1 when the old ModuleWheel, ModuleLandingLeg and ModuleLandingGear were replaced by ModuleWheelBase and its submodules. If Enable Kerbal Experience is off, any type of crewmember can perform repairs. What this mod provides: If Enable Kerbal Experience is off, an option "Require engineer to repair legs/wheels" is available. When this option is on, it will limit the ability to perform repairs to engineers only. Turning this option off will cause stock behavior to be used instead. If Enable Kerbal Experience is on, an option is provided to override the engineer level required to perform repairs. If this option is not used, then the stock reqirement of level 3 will be followed. ~ ~ ~ ~ ~ Parachute repacking For players with mods that add other crew specialization types: when "engineer" is mentioned here, it includes any modded crew specialization that has the "Repair" skill. Stock behavior: If Enable Kerbal Experience is on, an engineer of level 1 or above will be required to repack parachutes. If Enable Kerbal Experience is off, any type of crewmember can repack parachutes. What this mod provides: If Enable Kerbal Experience is off, an option "Require engineer to repack parachutes" is available. When this option is on, it will limit the ability to repack parachutes to engineers only. Turning this option off will cause stock behavior to be used instead. If Enable Kerbal Experience is on, an option is provided to override the engineer level required to repack parachutes. If this option is not used, then the stock reqirement of level 1 will be followed. ~ ~ ~ ~ ~ License All rights reserved. Download Better Specialization Settings v0.0.4 for KSP 1.7.x (backward compatible with KSP 1.6.x - 1.3.x) Caution: Dev build. Backup your saves before proceeding. Requires Module Manager (please obtain separately.) Download includes the Harmony library, version 1.2.0.1. See this comment for explanation. Installation: Delete older version, if any. Place contents of GameData into your installation's GameData folder. Source: GitHub Changelog: v0.0.4 ~ 2019-05-22 ~ KSP 1.7.x - 1.3.x Dev Build - Harmony 1.2.0.1 included Add restrict parachute repacking to engineers Add adjust level requirement for parachute repacking Fix bug in engineer (repair skill) requirement check for wheel repair v0.0.3 ~ 2019-05-13 ~ KSP 1.7.x - 1.3.x Dev Build - Harmony 1.2.0.1 included - Add restrict wheel/leg repair to engineers - Add adjust level requirement for wheel/leg repair - Rename mod due to feature for career mode - Refactored code v0.0.2 ~ 2019-04-17 ~ KSP 1.7.x - 1.3.x Dev Build - Harmony 1.2.0.1 included - Refactored code, improved robustness, optimizations - Backward compatibility for KSP < 1.6.x v0.0.1 ~ 2019-04-15 ~ KSP 1.7.x - 1.6.x Dev Build - Harmony 1.2.0.1 included - Prototype autopilot/SAS restricted to pilots

@garwel Besides stuff already mentioned in the OP above there is also some additional guidance that I offered to wile1411 for Duty Roster over at this PR. It should be sufficient to bootstrap any implementation of a touristification alternative. Other than that I haven't gotten around to any documentation beyond comments in my source code. Look in KSE's dev branch. If you care about what you can put in your status effect definition and how it will get parsed, check StatusEffect.cs. Public-Facing API is in a clearly marked region in KSEAddon.cs, though it's most likely more convenient to use extension methods provided in KSExtensions.cs. Again, I strongly recommend doing any implementation in a feature branch -- not even dev branch -- so as not to contaminate your existing workflow for an existing released mod. It may take a while for Kerbal Status Effects to get properly fleshed out, in its current state I'd consider it more like a tech demo, not even a beta build.

Kerbal Status Effects v0.1.0 @ 2019-04-13 Kerbal Status Effects is an addon that provides a framework for applying status effects that temporarily modify the skills (ExperienceEffects) of affected Kerbals. This mod is currently WIP and is not feature complete. See roadmap below for development plans. The current release is a dev build, intended to enable other modders to review, test, and serve as a starting point for using/integrating it in their own mods. Nothing for end-user consumption yet. (That means you, players. Come back later!) ~ ~ ~ ~ ~ Rationale A number of mods currently exist that change a kerbal's class to Tourist in order to render them "useless" or "unable to work". This is the most convenient way to achieve that goal, since the KSP API just doesn't provide any straightforward means of doing so. However, this is less than optimal, for several reasons: Mod incompatibilities If more than one mod is installed that utilizes "touristification", they may step on each others' toes and leave things in an incorrect or invalid state. This generally means that such mods are mutually incompatible with one another, so players cannot use them together. This was less of a problem when the only mods that performed "touristification" were life-support mods: such mods are typically intended to be mutually exclusive, and (despite being a less punishing alternative to outright death) "touristification" is an undesirable outcome that players are supposed to avoid, so it shouldn't occur very frequently. However, there are also mods such as Duty Roster and Kerbal Health that do not fit into this category of "life-support mods", so it is desirable to move toward an approach that will allow different mods to play well with one another, e.g. see this user request. Brittle, potentially save-breaking The process of "touristification" involves saving a copy of the kerbal's original specialization, then changing it to "tourist". This is error-prone (e.g. saving the wrong data) and can lead to saves being left in an invalid state if the mod is uninstalled (e.g. concerns voiced here by the maintainer of Snacks!) Loss of information / contradictory information from player POV Players may be interested in what the original specialization of a "touristified" Kerbal was, but only the mod responsible for the "touristification" knows this information. Furthermore, it might not even provide that information to the player via UI anywhere. For all intents and purposes, the Kerbal will be shown as a tourist by stock KSP UI (e.g. astronaut complex, tracking station, map view) and other mods (e.g. Portrait Stats) and treated as such for logic purposes. If the "touristification" mod shows the original specialization in its UI, this will conflict with all other information available elsewhere. One might argue that the fact that a crewmember became a tourist is intended to provide feedback to the player (e.g. that life support requirements were not met, etc). However this is not obvious and isn't sufficiently informative, as evidenced by players asking via forums or other social media why their kerbal became a tourist. There is also no way to distinguish between a "touristified" crewmember vs an actual tourist. We all know that Jeb is obviously a pilot and not supposed to be a tourist, but other randomly-generated kerbals are not likely to be as memorable. Unintended effects and consequences Turning crewmembers into tourists is a sledgehammer-style approach, in that it does not just remove their specialization-related skills. It will also: Downgrade GeeForceTolerance to 0.75 This may make some sense in some situations, e.g. weakened by lack of food or other life support. But it is not always applicable. Remove EVAChuteSkill May preclude life-saving use of parachute in dire circumstances. Prevent EVA Could be a massive unintentional inconvenience, e.g. kerbals who ran out of life support in a vessel without docking ports will not be able to EVA to board a rescue ship. Kerbal Status Effects remedies all of the above, providing assurances of: Mod interoperability Kerbal Status Effects serves as a common clearinghouse for all changes to kerbal skills, and will maintain consistency even when multiple mods apply status effects that touch the same skill. Robust, will not break saves Kerbal Status Effects does not touch any of the stock KSP crew roster data, and will not lead to broken saves under any circumstances. If a downstream mod is uninstalled, Kerbal Status Effects will notice that it is gone, and remove its associated status effects from all affected kerbals. If Kerbal Status Effects itself is uninstalled, no status effects will be applied and all kerbals effectively revert to their stock behavior. Clear and informative Information about kerbals and the status effects they are affected by will be clearly provided in UI. (Not implemented yet.) Precise impacts Kerbal Status Effects permits precise changes to the skills of individual kerbals, with no unintended consequences. ~ ~ ~ ~ ~ For Players There is nothing here for you yet. Come back later! This mod is currently not feature complete, please don't bother me with questions or feature requests. ~ ~ ~ ~ ~ For Modders The mod is not fully feature complete yet, but it is in a functional enough state to be released for review and testing. You should be able to start work on integration into your mod, but please treat as a feature branch for now. You may release test builds, but please include clear warnings re: backing up saves, etc. Kerbal Status Effects can currently parse definitions of status effects from config files, and the API for other mods to request for a status effect to be applied to/removed from kerbals is in place. Only skill deletions are possible at the moment, but this should suffice for any mod that currently turns crewmembers into tourists for the purpose of rendering them "useless" or "unable to do any work". Skill additions and modifications will come later; they're trickier to get right because of the need to enforce some kind of consistency when multiple mods apply status effects that touch the same skill. Integration: only available as a hard dependency for now. This shouldn't be a massive deal-breaker, most use cases should not treat the dependency as optional. Nonetheless, wrapper code will be made available later™. A fully-fledged inspection and debugging tool is available by typing /kse in the Ctrl-Alt-F12 console. Caveat: this command may be limited to debug builds only in the future. It might be a bit too dangerous in the hands of end-users. See roadmap below for development plans. ~ ~ ~ ~ ~ Roadmap Things that are in the pipeline: Adding skills; modifying existing skills These are trickier to get right because of the need to enforce some kind of consistency when multiple mods apply status effects that touch the same skill. But I do have some ideas for how it can be done. UI Provide better information to the player. Note: Not a substitute for downstream mods having their own UI. Status pane (per kerbal) to display all status effects they are affected by Listing of kerbals affected by status effects, with sort/filter by: Kerbal name Kerbal specialization / class (Trait) Show current vessel or EVA only RosterStatus (Assigned, Available) Status effect (also by source mod if it has multiple effects) Net impact on kerbal ( buff / debuff / incapacitated ) Notification when kerbal gains a status effect Allow suppression for routine (e.g. shift change) or pseudo-permanent (e.g. trained skill) statuses Toolbar integration (stock + blizzy) Wrapper code To avoid requiring a hard dependency. Better / consolidated documentation for modders The source code is already heavily commented but it'd probably be more convenient to consolidate all guidance into once place. ~ ~ ~ ~ ~ License The Kerbal Status Effects plugin is released under the MIT License. ~ ~ ~ ~ ~ Download Kerbal Status Effects v0.1.0 for KSP 1.7.x WARNING: dev build for testing and integration purposes. Not intended for end-users. This has not been tested for backward compatibility with older versions of KSP. CKAN: Not supported. Do not ask, and do not add. This is not in a state that is suitable for general release to the CKAN masses. Installation: Delete older version, if any. Place contents of GameData into your installation's GameData folder. Source: GitHub Changelog: v0.1.0 ~ 2019-04-13 ~ KSP 1.7.0 Initial Dev Build - skeletal functionality, no UI - supports only deletion of skills, no addition/modification - has not been tested for backward compatibility with older versions of KSP

Community Trait Icons v1.1.1 for KSP 1.7.x (backward compatible with KSP 1.6.x - 1.3.x) v1.1.1 ~ 2019-04-10 ~ KSP 1.7.x - 1.3.x General Release - Recompiled for KSP 1.7.x; backward compatibility tested for 1.6.x thru 1.3.x

If you wrote/maintain any plugin that tests or manipulates kerbal's class/specialization, this is a thing you need to know about. Credit goes to DMagic, IIRC, who was the first to point this out to me a couple of years ago, I think it was shortly after 1.3 dropped. Came up again because I recently saw this crop up in USI-LS, and happened to be working on related stuff myself so ended up thoroughly re-testing it (to see if was fixed in subsequent releases, but nope) A crude search on GitHub found quite a lot of code using these properties. It's not really feasible to trawl through all of them to identify which are actual issues and then notify the maintainers, so hopefully this PSA will suffice. Overview In the ExperienceTrait class (API link) that represents each Kerbal's specialization/class there are properties Title and TypeName. You'd normally expect one of them (Title) to be a localized string, for display purposes, and the other (TypeName) to be the internal identifier for that Trait type. But no! Both of these strings are localized. It's fine if you're just pulling them to display in the UI somewhere, but neither of them should be used in logic or persistence, e.g.: Testing if a kerbal is of a certain class/specialization if (pcm.experienceTrait.TypeName == "Engineer") or backing up the original trait (before temporarily replacing it) originalTrait = pcm.experienceTrait.TypeName; If your mod has code similar to this, using either of the abovementioned properties, there will be problems for players using any language other than English. (Even if your mod hasn't been localized, keep in mind that it can still be used in together with localized KSP.) Recommendation: use only unlocalized for non-display, such as ExperienceTrait.Config.Name Please don't: I saw some code that resorted to testing against localized strings, similar to the following. It works, but yikes. *cringe* if (pcm.experienceTrait.TypeName == Localizer.Format("#autoLOC_XXXXXX")) Full list of related properties These are unlocalized: ProtoCrewMember.trait ExperienceTrait.Config.Name Per above, ExperienceTrait.TypeName is localized, although it seems like it shouldn't be. These are localized, and working as intended: ProtoCrewMember.GetLocalizedTrait() ExperienceTrait.Title ExperienceTrait.Config.Title The lists GameDatabase.Instance.ExperienceConfigs.TraitNames / .TraitNamesNoTourist are also the unlocalized ids, if you're not working with specific kerbals. Test Code and Results Here is some debug code that you can run for yourself to verify. It adds the command /etdt to the debug console in spacecenter. using System; using UnityEngine; using KSP.UI.Screens.DebugToolbar; namespace ExperienceTraitDebug { [KSPAddon(KSPAddon.Startup.SpaceCentre, false)] public class DebugConsole : MonoBehaviour { private const string Command = "etdt"; private const string HelpString = "ExperienceTrait debug tool."; private void Awake() { DebugScreenConsole.AddConsoleCommand(Command, OnCommand, HelpString); } private void OnDestroy() { DebugScreenConsole.RemoveConsoleCommand(Command); } private void OnCommand(string argStr) { ProtoCrewMember pcm = HighLogic.CurrentGame.CrewRoster[0]; Log("Trait Variables in {0}: \r\n pcm.t {1}\r\n pcm.glt {2}\r\n et.tn {3}\r\n et.t {4}\r\n et.c.n {5}\r\n et.c.t {6}\r\n gd.ec.tn {7}\r\n gd.ec.tnnt {8}", Versioning.GetVersionStringFull(), pcm.trait, pcm.GetLocalizedTrait(), // note: will throw MissingMethodException in KSP 1.3.X, remove to avoid pcm.experienceTrait.TypeName, pcm.experienceTrait.Title, pcm.experienceTrait.Config.Name, pcm.experienceTrait.Config.Title, GameDatabase.Instance.ExperienceConfigs.TraitNames[0], GameDatabase.Instance.ExperienceConfigs.TraitNamesNoTourist[0] ); } private void Log(string msg, params object[] args) { Debug.LogFormat($"[DEBUG] {msg}", args); } } } Sample results on various KSP versions (Japanese localization) [DEBUG] Trait Variables in 1.3.1.1891 (WindowsPlayer x64): pcm.t Pilot pcm.glt // n/a et.tn パイロット et.t パイロット et.c.n Pilot et.c.t パイロット gd.ec.tn Pilot gd.ec.tnnt Pilot [DEBUG] Trait Variables in 1.4.5.2243 (WindowsPlayer x64): pcm.t Pilot pcm.glt パイロット et.tn パイロット et.t パイロット et.c.n Pilot et.c.t パイロット gd.ec.tn Pilot gd.ec.tnnt Pilot [DEBUG] Trait Variables in 1.5.1.2335 (WindowsPlayer x64): pcm.t Pilot pcm.glt パイロット et.tn パイロット et.t パイロット et.c.n Pilot et.c.t パイロット gd.ec.tn Pilot gd.ec.tnnt Pilot [DEBUG] Trait Variables in 1.6.1.2401 (WindowsPlayer x64): pcm.t Pilot pcm.glt パイロット et.tn パイロット et.t パイロット et.c.n Pilot et.c.t パイロット gd.ec.tn Pilot gd.ec.tnnt Pilot

@ioresult My bad, the bug might not actually be fixed by #280. I will PR a fix soon.

Community Trait Icons v1.1.0 for KSP 1.6.x (backward compatible with KSP 1.5.x - 1.3.x) v1.1.0 ~ 2019-04-07 ~ KSP 1.6.x - 1.3.x General Release - Add handling for GameDatabase reloading; other internal refactoring. - Functionality unchanged, contract with downstream mods unaffected. - Compiled for KSP 1.6.x; backward compatibility tested for 1.5.x thru 1.3.x

@blowfish Makes sense (your explanation, not the behavior). Thanks!

devbuild v1.0.99 available here for the adventurous, since I haven't had the opportunity to test it as thoroughly as I'd like yet. change list is mostly little tweaks to innards. no impact for downstream mods.

I’m writing a new plugin mod, and encountered some strange behavior with respect to the KSPAddon attribute. I have a workaround for it, but also wanted to see what other more experienced modders thought re: whether this is a bug of some sort that ought to be filed in the bugtracker. It is my understanding that the boolean arg once in [KSPAddon(Startup startup, bool once)] is used to specify that the addon should only ever be started once, e.g.: [KSPAddon(KSPAddon.Startup.MainMenu, true)] public class MyAddon : MonoBehaviour { ... } I am aware that this used to be [KSPAddon(Startup startup, bool Dont_Destroy)] and Dont_Destroy was bugged, but IIRC that was supposed to have been fixed a few versions ago. So, I write an addon that should start only once, at the first moment that the game loads into the main menu. In Awake() it sets itself up as a singleton and tells Unity not to destroy it between scene changes, so it’ll stay loaded. I register for OnGameDatabaseLoaded to allow me to react to any modifications in the reloaded configs. onLevelWasLoaded is for debug/illustrative purposes. Code: [KSPAddon(KSPAddon.Startup.MainMenu, true)] public class MyAddon : MonoBehaviour { public static MyAddon Instance; private void Awake() { Debug.Log("[MyAddon] [DEBUG] MyAddon AWAKE"); Instance = this; DontDestroyOnLoad(gameObject); GameEvents.OnGameDatabaseLoaded.Add(OnGameDatabaseLoadedHandler); GameEvents.onLevelWasLoaded.Add(OnLevelWasLoadedHandler); // ... } private void OnLevelWasLoadedHandler(GameScenes gs) { Debug.Log("[MyAddon] [DEBUG] MyAddon OnLevelWasLoadedHandler"); // ... } } This behaves correctly most of the time. However, when the game database has been reloaded (either via the stock debug menu or module manager), KSPAddon's once is no longer respected. Or rather, KSP forgets whatever flag it used to keep track of whether the addon has already been created or not. At the next occurrence of main menu loading, a fresh instance of the addon will be created. Is this the expected / intended / intuitive behavior? I certainly got caught out by it. Log snippets: // < game start, loading screen > ... [LOG 23:25:18.329] [HighLogic]: =========================== Scene Change : From LOADING to MAINMENU ===================== ... [LOG 23:25:19.451] [AddonLoader]: Instantiating addon 'MyAddon' from assembly 'MyAddon' [LOG 23:25:19.456] [MyAddon] [DEBUG] MyAddon AWAKE ... [LOG 23:25:21.710] [MyAddon] [DEBUG] MyAddon OnLevelWasLoadedHandler ... // < reload game database via debug menu (Alt-F12) > ... [LOG 23:34:16.000] [HighLogic]: =========================== Scene Change : From MAINMENU to CREDITS ===================== [LOG 23:34:17.038] [UIMasterController]: ShowUI [LOG 23:34:17.670] [MyAddon] [DEBUG] MyAddon OnLevelWasLoadedHandler [LOG 23:34:17.670] [ApplicationLauncher] OnSceneLoadedGUIReady: scene CREDITS ShouldBeVisible() False ShouldBeOnTop() False iIsPositionedAtTop True [LOG 23:34:19.886] [UIMasterController]: HideUI [LOG 23:34:19.887] [HighLogic]: =========================== Scene Change : From CREDITS to MAINMENU ===================== [LOG 23:34:20.828] [AddonLoader]: Instantiating addon 'MyAddon' from assembly 'MyAddon' [LOG 23:34:20.829] [MyAddon] [DEBUG] MyAddon AWAKE ... [LOG 23:34:21.613] [MyAddon] [DEBUG] MyAddon OnLevelWasLoadedHandler [LOG 23:34:21.613] [MyAddon] [DEBUG] MyAddon OnLevelWasLoadedHandler ... // < reload game database via module manager (Alt-F11) > ... [LOG 23:37:22.978] [HighLogic]: =========================== Scene Change : From MAINMENU to CREDITS ===================== [LOG 23:37:23.946] [UIMasterController]: ShowUI [LOG 23:37:24.474] [MyAddon] [DEBUG] MyAddon OnLevelWasLoadedHandler [LOG 23:37:24.474] [MyAddon] [DEBUG] MyAddon OnLevelWasLoadedHandler [LOG 23:37:24.474] [ApplicationLauncher] OnSceneLoadedGUIReady: scene CREDITS ShouldBeVisible() False ShouldBeOnTop() False iIsPositionedAtTop True [LOG 23:37:25.477] [UIMasterController]: HideUI [LOG 23:37:25.478] [HighLogic]: =========================== Scene Change : From CREDITS to MAINMENU ===================== [LOG 23:37:26.421] [AddonLoader]: Instantiating addon 'MyAddon' from assembly 'MyAddon' [LOG 23:37:26.421] [MyAddon] [DEBUG] MyAddon AWAKE ... [LOG 23:37:27.242] [MyAddon] [DEBUG] MyAddon OnLevelWasLoadedHandler [LOG 23:37:27.242] [MyAddon] [DEBUG] MyAddon OnLevelWasLoadedHandler [LOG 23:37:27.242] [MyAddon] [DEBUG] MyAddon OnLevelWasLoadedHandler ... The workaround, of course, is to kill any subsequent instances of the addon when they surface: private void Awake() { Debug.Log("[MyAddon] [DEBUG] MyAddon AWAKE"); if (Instance != null) { Debug.Log("[MyAddon] [DEBUG] kill me!"); Destroy(gameObject); return; } Instance = this; DontDestroyOnLoad(gameObject); // ... }

Upon further consideration, this isn't completely correct. If you've already pushed back the on-duty time, you should be able to bring it back forward again as long as you don't go under the minimum rest time. Likewise for off-duty times.

Should already have been fixed by PR 280 so it should behave correctly for new starving kerbals as long you're using a recent version. However any previously stored OldTrait value in the persistence file will have to be fixed manually I think.

This is pretty cool, but there's a bit of a problem I foresee: Changing the kerbal class to Tourist is an easy and convenient way to render them unable to do anything useful while off duty, but there are a couple of issues that arise from that. Only Duty Roster is aware that the kerbal is not actually a tourist, and knows what their original class is. This can lead to various unintended consequences. 1. Loss of information / contradictory information from player POV Basically, you can lose track of what class a kerbal is when they are off duty, i.e: Duty Roster knows their original class, and can add this to its GUI (so that it states the class e.g. "Off Duty (Pilot)" rather than just "Off Duty"). However, this is going to be contradicted by KSP itself, and any other mod that displays the kerbal's class e.g.: KSP Tracking station / map view Portrait stats, and other mods: Obviously, we all know Jeb is a pilot, but it can be much harder to keep track of other kerbals in a large roster. 2. Unintended stats (ExperienceEffect) changes Okay, so while Jeb is on break he's not going to apply any AutopilotSkill or FullVesselControlSkill, no problem there. But should it really mean that his GeeForceTolerance suddenly gets downgraded from 2.0 to 0.75? Or affect his EVAChuteSkill? 3. Unintended consequences Ability to EVA: tourists cannot go on EVA. If you have an off-duty "tourist" occupying a seat that is intended for someone else, that could be an unwelcome delay. e.g. You have a permanent facility on the Mun and a craft visits to effect a crew change, but the incoming crew just happens to be on break and refuse to get out. Or you accidentally pick the wrong kerbal (who went EVA while on-duty but is now on break) to board the craft, and now he won't get out until break time is over.  To be constructive, here are some possible ways to tackle this: 1. Off-duty classes Here is a MM patch I cooked up: Localization { en-us { #LOC_DUTY_ROSTER_0001 = (Off-Duty) } ja { #LOC_DUTY_ROSTER_0001 = (休憩中) } } DUTY_ROSTER { title_offduty_suffix = #LOC_DUTY_ROSTER_0001 } $EXPERIENCE_TRAIT:HAS[~name[Tourist]]:FINAL { @name = #offduty_$name$ @title = #$title$ $@DUTY_ROSTER/title_offduty_suffix$ @EFFECT[GeeForceTolerance] { passive = true } @EFFECT[EVAChuteSkill] { passive = true } !EFFECT:HAS[~passive[true]],* {} } This patch creates "off duty" versions of all kerbal classes (except Tourist), so in terms of name (internal ID) "Pilot" has the counterpart "offduty_Pilot", etc. This includes modded classes (e.g. those from MKS). The trait title (display text) is modified by suffix, and is fully localizable, so title = #autoLOC_500101 //#autoLOC_500101 = Pilot becomes Pilot (Off-Duty) Certain EFFECTs are marked as passive, all others are deleted. So this gives the ability to switch out any class for the "off-duty" version. There's one minor quibble I have where this doesn't quite work, which is that all these "off duty" classes are also eligible to be generated as applicants in the Astronaut Center. Which is kind of weird and could maybe lead to strange behavior? Other possible avenues to investigate: 2. inactivation? ProtoCrewMember.inactive <-- perhaps this can be used? You can apparently inactivate a PCM for a set duration using ProtoCrewMember.SetInactive ( double time, bool additive ). ProtoCrewMember.outDueToG suggests that this is used for high-G blackouts, among other things. 3a. Programmatic editing of ExperienceTraits It is possible to fetch ProtoCrewMember.experienceTrait and then obtain the list of Effects from that. Not sure if tampering with that list (to remove/disable certain effects while off-duty) will work, but could be worth a shot, since this: static ExperienceTrait Create (System.Type type, ExperienceTraitConfig config, ProtoCrewMember pcm) appears to suggest that there is a distinct ExperienceTrait for each kerbal, rather than shared between all kerbals of the same class. Even if this works, the changes will likely not be persisted in the save file, because rather than a config node for all of this for each kerbal, the save file just contains the trait as a string. Presumably that is used to lookup the ExperienceTraitConfig and re-instantiate ExperienceTrait as needed upon loading. So some OnLoad machinery will be needed to check if the kerbal is off-duty, and then re-do the edits to the effects list as needed. Downside of this is that while we might be able to deactivate the ExperienceEffects, it doesn't look like we can modify the ExperienceTrait's typeName, title (display string) or description. Unless... 3b. Programmatic creation of ExperienceTraits Completely replace ProtoCrewMember.experienceTrait with one that is crafted programmatically, from scratch, via ExperienceTraitConfig.Create() and then ExperienceTrait.Create(). This would basically be equivalent to enacting all the changes from the MM patch (approach 1). However, by doing this in code, the modified "off duty" version won't be in GameDatabase.Instance.ExperienceConfigs and can't be generated as applicants. This is the most involved option, by far, but probably the "correct" way to do it.  Re: shift / overtime mechanics, you could also consider taking inspiration from automobile endurance racing. For instance, the rules for the 24 Hours Nurburgring limit drivers to a maximum stint of 150 mins of continuous driving, and enforces at least 2 hours of rest between stints in the car. So, when changing the on/off-duty timings, you'd be allowed to push back the on-duty time or bring forward the off-duty time, but not the other way round. Maximum on-duty duration and minimum off-duty duration could vary according to kerbal experience level (number of stars) To encourage careful planning ahead and strongly discourage flippant use of "overtime", it should come at a steep cost, and perhaps even carry some risk: - "fatigue" ticks up when on duty and ticks back down when resting - grows faster than linearly, probably exponential. decreases slower (linear should be ok) - fatigue doesn't normally need to be tracked as a variable when not doing overtime, just treat the max on-duty time as "generally allowable 100% fatigue" and the min off-duty time as sufficient to recover fully from that; extrapolate accordingly - when overtime commences by prematurely ending rest time, initialize with 0% < fatigue < 100% - when overtime commences by going over max working duration, initialize at 100% fatigue - once overtime has ended, kerbal will be forced to rest for a much longer duration according to fatigue value, with overtime strictly disabled (think sleep debt) - when fatigue exceeds a certain value, say, 200%, introduce a chance of the kerbal passing out; risk grows with fatigue level. (probably make this an option that can be turned off)

Cool, let me know when. edit: nevermind, misunderstood Cetera's Suit Pack did this, but it already "hardcoded" its own icons/colors in its replacement textures for the kerbal models. So rather than getting the icons/colors from CTI, it instead had to modified CTI's config to point to its own icons and colors. This results in all CTI downstream mods follow the suit pack icons/colors. There are other texture packs that do icon/color coding according to kerbal classes but none that I know of that actually integrate with CTI.

v1.0.2 released; is a simple recompile for KSP 1.6.x.

CTI 1.0.1 does indeed still work in KSP 1.6.x, so you can continue to use that. Thought I'd updated my earlier post to reflect that, but apparently not. Whoops.

Will look at KSP 1.6 compat over the weekend. Edit: CTI 1.0.1 works in KSP 1.6.x, so you can continue to use it without any issues.