UltraJohn

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

@OnlyLightMatters Wow, congratz! Best of luck to you!

Heya, just checking in to see if there's any news on the VAB buttons? I'm not sure if @OnlyLightMatters forgot about it or is busy with other matters (pun not intended but oh well )

I'm getting this error spammed nonstop: [ERR 16:44:58.240] kOS: kOSVesselModule.CacheControllable called with null parentVessel, contact kOS developers [ERR 16:44:58.347] kOS: kOSVesselModule.CacheControllable called with null parentVessel, contact kOS developers [ERR 16:44:58.349] kOS: kOSVesselModule.CacheControllable called with null parentVessel, contact kOS developers [ERR 16:44:58.468] kOS: kOSVesselModule.CacheControllable called with null parentVessel, contact kOS developers [ERR 16:44:58.470] kOS: kOSVesselModule.CacheControllable called with null parentVessel, contact kOS developers [ERR 16:44:58.606] kOS: kOSVesselModule.CacheControllable called with null parentVessel, contact kOS developers KSP.log

Your best option is probably to set up two individual instances of your game each with their own set of mods. You could do this by copy pasting your KSP folder and renaming it. Then you can use CKAN to mod each instance separately.

I've noticed that the option for auto-throttle doesn't seem to work until you toggle on the PID option at the top left atleast once during flight. Otherwise it just throttles down your plane to 0% until you click it, no matter what velocity you try to set.

Same here, still getting this after the update. Edit: I'm guessing this line of code and also this one needs to be commented out and then recompiled. Edit 2: After doing a local recompile myself I can confirm that this fixes the issue.

I'm wondering then, how is it that Community Part Titles can edit the localization of all the stock parts? It seems like they just add a new localization config and it overwrites the stock ones. Another example is Mk2Expansion patch where they also add a new localization config, but also patch some existing parts that were not using it to point to the new one. But maybe I'm just understanding it incorrectly. In any case, I suppose I could just manually edit the CryoTanks loc file to the names I want, but that's not exactly a good long term solution. Not that CryoTanks receives updates often anyway, so it probably wouldn't matter.

Ah so it's CryoTanks that have the abbreviations then? I'd much prefer to have the long names like the way yours are currently. Looking at the configs for CryoTanks, it's using localization to set their display names. It should be fairly simple to just add a patch that modifies this, like what Community Part Titles does and get their full names instead. It's mainly just line 18 to line 24 that needs to be patched, I think.

This is probably a similar issue like you've explained with SMX about stock parts and modded parts, but it would be a nice QoL feature if there was a better consistency between the names of fuel switches. For example, the stock parts having the fuel name as "LiquidFuel" but the parts from Mk2 Expansion being "LF" instead. I've noticed this happening with many different types of fuel. Not a big deal, but it does lead to some minor confusion once in a while when I'm trying to find what I'm looking for!

Ah yes I see what you mean. His forum page does link to github, but also there's a link further up in the description back to this page. On github you can also navigate back to the repository's front page and/or open the readme from the downloaded zip to see the dependencies. Alternatively you can also install the mod via CKAN and get all of the dependencies installed automatically. That'll save you future headaches!

@JadeOfMaar Yeah I do know about the USI stuff, but if I remember correctly it's mainly just connecting stuff within some determined range? My idea is more focused on the roleplay aspect of it, having to actually build a physical connection between bases, although probably not so feasible in KSP to its full potential. Well it is possible to use Kerbal Konstructs to place statics on planets, so perhaps it would be possible to incorporate that code logic somehow into the part placements. But yeah that's a pretty big project. Also that mini jump gate thing sounds kinda cool, I'll have to check out that mod for fun I don't really think I have any other ideas that wouldn't require a dll to function unfortunately.

Seems to be working fine. I checked a few different ISRU's both stock and SMX and the ratio scaling looks good. Thank you! Sorry, I honestly have no idea I did have a random thought yesterday about how someone would be able to add supply lines to KSP, so as to be able to combine multiple bases scattered around a planet, with each harvesting its own type of resource. I was thinking something along the lines of conveyor belts or pipes from Factorio/Satisfactory. The gameplay mechanic for setting up the connection would basically be having a special type of port on your base that you plug into, then drive a rover over to the other base and plug into that port as well. Then it would calculate the cost of resources (like metal pipes would use metal and maybe some other things) depending on the distance. Once you "pay" those resources the link gets created and activates. The rover is there to simulate laying the foundation, conveyors/pipes along the ground while you drive, so as to avoid you just changing vessel from the tracking station to skip the drive. Graphically it might be a bit troublesome to create physical parts that follow along the ground of the planets between bases, so it could just be created "underground." Sooo if anyone gets inspired by this, feel free to steal my idea and improve upon it!

It's a bit hard to see in daylight, but check this video so you can confirm. https://streamable.com/67d7cb

Ah right right, I totally forgot to check! Yes it does look like it works Middle engine has a nice effect, and the two outer ones are more of a faint shockwave effect. That should be correct?

I think it would be cool to have it included, since as you say "Ore into anything" is not really rational, so making it part of this mod using Metals and Minerals would make it more rational! I've tried making a very basic patch just basically copy pasting the setup from the omniconverter, putting it into this cfg, and while it does show up ingame, it's still only showing up on stock parts, and somehow is having two inputs for ElectricCharge. Also the ratios need to be tuned properly! Edit: oh I see why there's double EC, it's copying the one from Basic as well. // Global Construction MaterialKits +MODULE[ModuleResourceConverter]:HAS[#ConverterName[Basic]]:NEEDS[GroundConstruction] { @ConverterName = MaterialKits // using moles @StartActionName = Start ISRU [MaterialKits] @StopActionName = Stop ISRU [MaterialKits] @ToggleActionName = Toggle ISRU [MaterialKits] INPUT_RESOURCE { ResourceName = ElectricCharge Ratio = 90 FlowMode = STAGE_PRIORITY_FLOW } INPUT_RESOURCE { ResourceName = Minerals Ratio = 0.16 FlowMode = STAGE_PRIORITY_FLOW } INPUT_RESOURCE { ResourceName = Metals Ratio = 0.16 FlowMode = STAGE_PRIORITY_FLOW } OUTPUT_RESOURCE { ResourceName = MaterialKits Ratio = 0.4 // 23.8% useful output by mass; prefering less decimal precision FlowMode = STAGE_PRIORITY_FLOW } }

@JadeOfMaar Thanks for the explanation. So it is the intended behavior then. I personally would prefer the consistency of having all parts have the same options, to avoid accidentally not realizing the part I added to a vessel doesn't have the stock/GC options, but I can accept this decision by you, and thus I will just try and remember that. Ok so I did see the patch for the Omniconverter, but it does require WildBlueTools to work. I've actually been removing some mods lately due to the longer and longer loading times and lag, so I'd prefer to avoid installing more. I was thinking of taking your MaterialKits patch for the Omniconverter and patching that into the ISRU parts themselves, replacing the existing Ore smelter option with this. Since I don't like the Ore to MaterialKits option anyway, that's fine. It should in theory be possible to add this into to your existing Opt-In Convert-O-Tron patch and take advantage of the already set RRPower config for the ratio scaling, yes? Only problem I can see is that it doesn't scale ElectricCharge? What are your thoughts on this?