UltraJohn

So there is definetely a bug with the latest version. When you switch to a different vessel during flight, the toolbar button will disappear and the trajectories window will open by itself, and there is no way to close it again, since the toolbar button is gone. Should be fairly easy to reproduce. KSP.log

A config pack for TAC Life Support. Requirements: Stock recolour config. https://github.com/UltraJohn/TURD-TACLS/releases License: GNU General Public License v3.0

I think there might be a typo here on line 62. it says 'ize3' instead of 'size3'

Hello! Here is my contribution to this wonderful mod: A RealChute config. Requirements: Stock recolour config. https://github.com/UltraJohn/TURD-RealChute/releases License: GNU General Public License v3.0

Better Screen Messages This is a small plugin that allows you to move the screen message boxes. This is quite useful if you're having the problem of the messages being obscured by other UI elements, or if you're playing at ultrawide resolutions and don't want to break your neck trying to read the text. You can also change the font size used. Keep in mind that both the position and size are dependent on UI scale value as well! The position and font size is configurable via settings.cfg file. Before/After preview: Download: or Source code: GitHub License: GNU General Public License v3.0

Hi, there's a problem with the newest version of Trajectories v2.4.5, where it's locking out the mouse when the mouse is occupying the same location as the GUI, despite the GUI being toggled off. I noticed this because whenever I created a maneuver node and zoom out a bit, the node would auto collapse when the mouse was over it. I can see in the input locks on the debug screen that TrajectoriesGUILockout is active whenever the mouse is over the same spot as the hidden GUI. Video examples of the issue: https://streamable.com/xcps99 and https://streamable.com/mtz4g6

Hi @linuxgurugamer @kurgut I've been looking at this issue and it seems to come from the ScienceContext.cs file at method UpdateExperiments(). From my testing, it is finding this "ROCScience" experiment on the EVA parts, (which I think comes from Breaking Ground dlc?) Looking through the code, shows that on line 244 we are checking the list of AvailablePart's and on line 261 we are grabbing the science module ModuleScienceExperiment that this part contains. Below is a list of all of the parts and their attached modules referencing ROCScience that I grabbed through the Visual Studio Debugger: As we can see, every part referencing a ROCScience experiment are all either a kerbalEVA or a RobotArmScanner part. The problem here is that on line 266 when we are running ResearchAndDevelopment.GetExperiment(Module.experimentID) it is returning null because a ScienceExperiment is not defined for these "ROCScience" experiments. I'm assuming that this experiment type is supposed to be the Breaking Ground specific experiments, that probably does not function as the normal type of experiment. Therefore I think that there may be reason to have a check to skip these modules in the code. Although I don't think this is actually what is causing the freezes. That's probably due to the method UpdateExperiments() iterating over PartLoader.LoadedPartsList, which at stock already consists of about 490 entries. This gets majorly escalated as you install more mods and thus have more parts to iterate through, causing this freezing every time the call to do a full refresh happens. In fact that's easily reproducible whenever you open up the X Science window for the first time on a new scene load, as it has to repopulate the windows with fresh data. I believe it could use a refactoring to increase the efficiency of this method.

Stock Alarm Clock Disabler This is a small plugin that disables the stock alarm clock, perfect for those who prefer to use the popular mod Kerbal Alarm Clock. I created this because I was getting tired of accidentally creating an alarm due to the buttons overlapping on the maneuvers nodes. With this installed, it should no longer be an issue! Dependencies: HarmonyKSP Download: or Source code: GitHub License: GNU General Public License v3.0

Hi there, bit late with a reply as you've probably moved on by now, but I just took at look at this because I was getting the same issue. I can say that the issue is quite easy to solve. The problem is due to the code using FixedUpdate() instead of Update(). In short: user input is refreshed on every Update cycle, so when you're reading the input on a FixedUpdate interval the input will sometimes not get registered, because they are not in sync. This causes the problem of having to seemingly press the buttons a random amount of times before it eventually happens on the same frame. @linuxgurugamer will have to recompile the dll.

Yeah I don't see it in there in any of the files. Maybe I'm blind? Ahhh, CommunityResourcePack then! So these are LOC controlled as well. #LOC_CRP_LqdHydrogen_DisplayName = Liquid Hydrogen #LOC_CRP_LqdHydrogen_Abbreviation = LH2 I'm tempted to edit these as well to just use the full display name, unless the abbreviation keyword is also used in other GUI displays where it might pose an issue having a longer name. In which case I think it could be a possible solution to just modify the VAB part menu instead with a Harmony patch.. Thinking out loud here.. Edit: Also used for the Propellant gauge in flight. Maybe others. On further contemplation I think I'll keep the abbreviation keywords as is for now.

Actually this is how Community Part Titles patches all of the stock parts and mods with LOC files already. I got the idea from this file here. For other parts that don't have LOC already, they either patch the name directly to a different name, or add their own reference to a LOC file. Another way of patching the names without overwriting the existing LOC data, would be to patch the subtypes of the tanks and then edit the @title parameter to point to your own LOC file. I think this might be more trouble than it's worth though, considering the first option. And yeah having it as an optional download would (probably) be fine in terms of compatibility between the two mods. Right, well I think yours are already good as it is, so I'm not sure how much actually needs to change here, if anything. It's mainly the issue of CryoTanks abbreviating a lot of their titles. Let's take a look at the stock tank vs CryoTanks tank On the left it already looks pretty good, apart from the top one being abbreviated to "LF + Ox" rather than being "LiquidFuel + Oxidizer." I don't think this is from RR or CryoTanks, as I can't locate the cfg where this subtype is defined. On the right is where the CryoTanks definitions are. The top 5 needs to be changed to the same as the left side. That can be fixed by using this LOC file: So basically the naming convention I'd follow is this: 1. Using the shorthand for Liquid fuels aka "LqdMethane", "LqdHydrogen", etc, with the exception of the stock "LiquidFuel" which keeps its long name, since this isn't a real world fuel anyway. 2. two or more fuels are kept separate using " + " (space plus space) e.g. "LqdCO + Oxidixer." 3. Either keep "Hydrolox" and "Methalox" as it is, or separate them into "LqdHydrogen + Oxidizer" and "LqdMethane + Oxidizer". As the game still considers these two fuels as separate entities in a tank I think the second option would be better? It makes sense because the VAB part list shows engine fuels as separate. Also, I've yet to figure out how to modify the Propellants display to also use the Full name rather than like "LH2." Perhaps you know?

There's an issue with the part Advanced Sub-Satellite, where just putting this part on any craft will cause the stock deltaV and KER to completely break, rendering them unusable. As well as other mods depending on the engine modules, such as Throttle Controlled Avionics. I've been able to narrow down the issue to be caused by the part module USMeshSwitch. The problem is when a part cfg is using the this specific parameter for that module: DeleteUnused = True Will make it call Destroy() on the transforms. However the list is never reset to account for the now null references, which is what makes stock and KER break on this line. This needs to be fixed. For anyone coming across this issue, the current workaround for now would be to set DeleteUnused = False in the Advanced Sub-Satellite cfg, and it *should* in theory work fine until a proper fix is out.

There's a problem with one of your configs. Specifically SIMPLEXResources - CryoTanks.cfg on line 40 contains a misuse of the keyword :FOR

Yes it's planned, but not till the free version of volumetrics is available.

A followup for the discussion about the naming convention of the fuel types. Turns out it IS possible to "patch" the localization files, with a small caveat. In order to do so you must have your modified LOC load before the original and it will take priority. For example I've set the cfg file path to 'GameData/000a/Localization.cfg' to make it load before CryoTanks. See example picture: Which is done with a simple cfg file like this: Localization { en-us { #LOC_CryoTanks_switcher_fuel_lh2 = LiquidHydrogen #LOC_CryoTanks_switcher_fuel_lh2ox = Hydrolox #LOC_CryoTanks_switcher_fuel_ox = Oxidizer #LOC_CryoTanks_switcher_fuel_lf = LiquidFuel #LOC_CryoTanks_switcher_fuel_lfox = LiquidFuel + Oxidizer #LOC_CryoTanks_switcher_fuel_methane = LiquidMethane #LOC_CryoTanks_switcher_fuel_methalox = Methalox } } This means that we can better unify the naming convention across RR and CryoTanks. I have a few variations in mind for the naming of all the tanks: 1. Abbreviations vs full name, for example: LqdFuel vs LiquidFuel 2. Spacing, for example: LiquidFuel vs Liquid Fuel 3. Combinations, for example: Liquid Hydrogen + Oxidizer vs Hydrolox I think it would make sense to stick to one specific naming convention, as currently it's all over the place. Like currently we have "LF + Ox" on some parts and "LF/Ox" on others (abbreviations, with '+', '/' and spacing on one but not the other), then "LiquidFuel" (Full name), but then also "LqdHydrogen" (again abbreviation). Personally I would like to see them displayed as in my example cfg, with maybe the exception of Hydrolox/Methalox. If we were to keep it unified it would have to display as LiquidHydrogen + Oxidizer to keep it similar to something like LiquidFuel + Oxidizer, which does not have a bespoke name. Although I think using "Lqd" instead of "Liquid" would be great too! I'd like to hear your thoughts on this