JebIsDeadBaby

@Starwaster - I thought about it but issues are for problems that are expected to be fixed and closed and there's nothing to fix here. The mod itself isn't broken because of this and won't be fixed if they reverted this change. This would be an unclosable issue. So I decided not to, just to avoid creating a mess. A discussion page on mod's github page would be perfect for things like this. Another project I follow has it, so I guess it's build-in into github and all it takes is to enable it? Maybe you could ask devs to consider this, if you know how to reach them?

Dear devs, please remember that kOS scripts may use the string stored in the Propellant field. Since propellant stability is crucial for successful ignition I'd say most, if not all, kOS users access this field often. Whenever you change anything in either descriptive or numerical part of the propellant stability string, this may cause problems with kOS scripts that expect some specific strings. In the latest update you removed one zero from the decimal part of stability percentage and it took me quite a while to figure out what's going on. Would be nice if any changes to these strings were documented in a changelog. Many thanks.

Yeah, it may have something to do with it. I just remembered that there were cases where the heat shield looked cylindrical in FAR Debug window during my tests. Now I narrowed this case down. As you may know, a heat shield usually has two bottom attach nodes. If you use the lower one to attach a decoupler for example, a model of a fairing will appear to close the gap. The fairing model is part of heat shield mesh. If you use the higher attach node, there will be no gap between the heat shield and the decoupler and the model of a fairing will not appear. Now get this - if you use this "no gap" solution, the fairing will appear after detachment in FAR Debug window but (obviously) not in the game (see picture below). I guess some fairing jettison event is not triggered in case when there is no fairing to jettison and some underlying, invisible structure (a collider?) remains attached to the model and FAR sees it. As you can see on the picture, there is no yawing moment in this case and the attitude indicator is dead center on the retrograde marker. I guess this should be considered a bug in FAR but ironically it counters a bug in Restock (or another bug in FAR) and for now may serve as a working solution to my problem (doesn't solve pod pitching though but for obvious reasons this problem is less... burning <- Ba Dum Tss! ) . To sum it up - whatever FAR sees is probably messed up in pods and heatshields. I also added this little patch to check if it helps but it changes nothing. @PART[restock-heatshield-1875-1]:AFTER[FerramAerospaceResearch] { @MODULE[GeometryPartModule] { %ignoreIfNoRenderer = true %forceUseMeshes = True } } @PART[restock-mk2-pod]:AFTER[FerramAerospaceResearch] { @MODULE[GeometryPartModule] { %ignoreIfNoRenderer = true %forceUseMeshes = True } }

@Poodmund - many thanks. I'll also point out that your 3rd picture (Restock pod+hs) shows yawing I mentioned. It's not as severe as pitching moment of the pod alone, but with Deadly Reentry it can be, well... deadly.

Do you mean Private Division launcher that pops-up when you launch via Steam? Then no, I don't use any workaround, since the launcher doesn't bother me. As for two MM's - this was a one time screw up on my side. I didn't notice I have two copies when prepping Game Data folder for this minimal set up. All previous testing was done with MM 4.2.3 in my main modded set up, as well as all minimal set up testing after Poodmund pointed this out. As for physics - bear in mind that stock heat shields and pods work fine in the same game, so under the same physics rules, wrong or not. I preserved original heat shields by whitelisting models and removing Restock hs patch. So now I have stock heat shields and Restock's 1,8 m heatshiled available. Mk2 pod with 2,5 m stock heat shield is stable during reentry but once you jettison the hs, the pod immediately pitches up. So it really looks like something with Restock models, not physics. I tested this a moment ago with this trimmed set up: Mod DLLs found: Stock assembly: Assembly-CSharp v0.0.0.0 ModuleManager v4.2.3.0 KSPBurst v1.5.5.1 Microsoft.Extensions.FileSystemGlobbing v6.0.0.0 / v6.0.0-preview.2.21154.6+3eaf1f316b8b1da73fdb98e9cca43c0ddaa12f45 / v6.0.21.15406 System.IO.Compression v4.0.0.0 / v4.6.57.0 System.IO.Compression.FileSystem v4.0.0.0 / v4.6.57.0 System.Runtime.CompilerServices.Unsafe v4.0.6.0 / v3.1.3+8a3ffed558ddf943c1efa87d693227722d6af094 / v4.700.20.12001 System.Runtime v4.1.0.0 / v4.0.0.0 Unity.Burst v0.0.0.0 Unity.Burst.Unsafe v4.0.5.0 / v1.0.0.0 Unity.Collections v0.0.0.0 Unity.Jobs v0.0.0.0 Unity.Mathematics v1.0.0.0 FerramAerospaceResearch.Base v0.16.1.2 ModularFlightIntegrator v1.0.0.0 / v1.2.10.0 FerramAerospaceResearch v0.16.1.2 ferramGraph v1.3.0.0 Scale_Redist v1.0.0.0 Restock v0.1.0.0 Stock assembly: KSPSteamCtrlr v0.0.1.35 Folders and files in GameData: 000_KSPBurst FerramAerospaceResearch ModularFlightIntegrator ReStock ReStockPlus Stock folder: Squad Custom_FARAeroData.cfg Custom_FARConfig.cfg ModuleManager.4.2.3.dll ModuleManager.ConfigCache ModuleManager.ConfigSHA ModuleManager.Physics ModuleManager.TechTree

@Poodmund - didn't help. I dunno if you could try this setup to verify my claims? Maybe it's still something on my side. I use Mk2 pod with 1.8 m heat shield for testing ATM. You can use Mk2 pod only, it should pitch to about +25 deg on reentry. As for Custom_FARAeroData.cfg - it's not mine. I think FAR creates it whenever you access one of it's config windows while in game. I didn't tweak anything.

@JonnyOThan - the problem occurs in the simplest setup possible: KSP 1.12 + FAR (w/dependencies) + Restock Stock assembly: Assembly-CSharp v0.0.0.0 ModuleManagerWatchDog v1.0.1.1 ModuleManager v4.2.2.0 ModuleManager v4.2.2.0 KSPBurst v1.5.5.1 Microsoft.Extensions.FileSystemGlobbing v6.0.0.0 / v6.0.0-preview.2.21154.6+3eaf1f316b8b1da73fdb98e9cca43c0ddaa12f45 / v6.0.21.15406 System.IO.Compression v4.0.0.0 / v4.6.57.0 System.IO.Compression.FileSystem v4.0.0.0 / v4.6.57.0 System.Runtime.CompilerServices.Unsafe v4.0.6.0 / v3.1.3+8a3ffed558ddf943c1efa87d693227722d6af094 / v4.700.20.12001 System.Runtime v4.1.0.0 / v4.0.0.0 Unity.Burst v0.0.0.0 Unity.Burst.Unsafe v4.0.5.0 / v1.0.0.0 Unity.Collections v0.0.0.0 Unity.Jobs v0.0.0.0 Unity.Mathematics v1.0.0.0 FerramAerospaceResearch.Base v0.16.1.2 ModularFlightIntegrator v1.0.0.0 / v1.2.10.0 FerramAerospaceResearch v0.16.1.2 ferramGraph v1.3.0.0 Scale_Redist v1.0.0.0 WatchDogForInterstellarRedist v1.0.1.1 WatchDogForScaleRedist v1.0.1.1 Restock v0.1.0.0 Stock assembly: KSPSteamCtrlr v0.0.1.35 Folders and files in GameData: 000_KSPBurst FerramAerospaceResearch ModularFlightIntegrator ModuleManagerWatchDog ReStock ReStockPlus Stock folder: Squad 666_ModuleManagerWatchDog.dll Custom_FARAeroData.cfg ModuleManager.4.2.2.dll ModuleManager.4.2.3.dll ModuleManager.ConfigCache ModuleManager.ConfigSHA ModuleManager.Physics ModuleManager.TechTree

@softweir - I don't expect him to solve or even to work on my problem, that's why I don't throw mod lists and logs at him. I want him to take a look at the original mesh files to check if there is anything that could be related to heat shield yawing (or capsule pitching). I kinda don't buy FAR simulation rate idea. Original 2,5 m heat shield and Restock replacement are almost identical in shape. They should behave equally bad or good with FAR. Unless my understanding of what FAR actually does is wrong, which it seems it is. But I have two almost identical shapes that behave completely different, so my guess is that there is something not visible in-game about Restock model that may be the cause of this and I'd like to know his opinion. EDIT: an observation I made after some further testing - I use DecouplerShroud mod that comes with a custom decoupler. I use the custom one when I want to have a conical shroud instead of cylindrical one but sometimes I use it for standard cylindrical shrouds as well. I just noticed that both decouplers affect the way FAR sees the part that was attached to them AFTER decoupling, in my case - the heat shield. I use FAR's Exposure feature from the FAR debug tab for a preview. After decoupling from the standard restock decoupler, a shape of the heat shield is visible in Exposure preview. After decoupling from the DecouplerShroud's custom decoupler the heat shield appears cylindrical, as if FAR was still seeing the shroud from the decoupler. This affects the behaviour of the vessel on reentry. WITH this phantom shroud Restock heat shield IS STABLE (no yawing moment). WITHOUT it, so when the original geometry of the heat shield is preserved, Restock heat shield is unstable. Stock heat shield is stable in both cases. Which again leads me to the conclusion that it has something to do with Restock part mesh or config. But I know too little about this game to say if this phantom shroud is a drag cube, a collider, or whatever the hell it is... I'll try to test tomorrow is pods are affected by this in the same way.

@Nertea - hey, since you're the OG dev, maybe you will be able to help me. I have a problem with Restock pods and heatshields when using FAR. I'm researching this problem for 2 days now and although I could test a thing or two more, I'm pretty sure at this stage that the problem lies with Restock. The problem: Restock heatshields generate a strong yawing moment, while pods an even stronger pitching moment. I'm pretty sure all pods and heatshields are affected but I'm mostly focused on Mk1-3 pod and 2.5 m heatshield. The bigger pod or heatshield, the stronger the moment. Stock models do not have this problem. What boggles me is that this particular pod and this particular heatshield use virtually the same config files as Restock parts, since Restock more or less only patches the model and doesn't tweak other settings (or does it?). Besides I made sure that CoL's, CoP's and CoM's are not the problem. Yet, for a reason I can't figure out, FAR sees Restock parts differently enough to introduce these moments. It must be something about geometry, maybe some invisible parts of the model? I should add that FAR voxeling detects model shapes correctly but I'm not sure if this is the only thing FAR uses to determine forces acting on a body. So my question to you as the dev: is there something about these models not clearly visible to a player that in your opinion could cause this behaviour? Some misaligned points of origin or sth?

Anyone here remembers how gimbal tech levels are supposed to work? Default RF config adds gimbals to solid boosters and I assume that the value that comes with each entry is gimbal range. So TL0 and TL1 should have no gimbal but TL2 should add gimbal one with 3 deg range and so on. However my solid boosters don't seem to be affected by this. Does this feature works?

@Juba - came here to ask literally the same thing. I use JNSQ but I checked it with minimal required mod configuration on the stock Kerbin and have the same problem. Also with JNSQ I get some wired sunrises, where the sun is already quite high above the horizon and the ground is still dark and the ground that comes with the buildings is even darker (on the stock system this may also be a thing although is it is, it's not that pronounced). Does Parallax mess with Scatterer somehow?

No, I'm 100% positive that it's Scatterer in my case. The reason your files where not altered by Scatterer is because autosavePlanetSettingsOnSceneChange is set to FALSE by default and Scatterer does not overwrite atmo files in this case. You can find this key in Scatterer's config file and check it out. My guess is it will overwrite atmo file of every planet you'll visit in-game and delete JNSQTag in effect. Also I use 0.0834 version of Scatterer and just checked that Jool is green in my game (well, it's actually Uranus blue with visible atmospheric bands). So I'd say there is something more going on in your set-up.

I kid you not, JNSQTag is missing from Kerbin atmo.cfg for Scatterer again. I decided to check it out of curiosity before launching the game now. And it's gone. I can see that the file was modified at the exactly same time as the last entry in the KSP.log. I can also see (and remember) that the atmosphere config was there to the very end - just 7 sec before the game closed there is this entry in the log: [LOG 21:05:33.254] [Scatterer][Debug] Atmosphere config found for: Kerbin This is from loading the main menu scene just before I quit. The log ends at 21:05:40.702 after a few more entries, including this exception: [EXC 21:05:40.694] NullReferenceException: Object reference not set to an instance of an object KerbalChangelog.ChangelogAddonMainMenu.OnDisable () (at <3df0e8f79e4f4c60b17db000dc0cdeca>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) I dunno if this may be related to my file being reverted. EDIT: I added the JNSQTag = True again and launched the game. Loaded the save, changed a scene to TRACKSTATION, went back to KSC, quit the game. The file get reverted again when the game was closing. This time the log looks a bit different with this smoking gun: [LOG 19:56:24.767] [Scatterer][Debug] saving Kerbin atmo config to: JNSQ/JNSQ_Configs/Scatterer/Planets/Kerbin/atmo So it's Scatterer but why? There was no entry like this in the previous log. EDIT2: Solved by @HebaruSan! Turns out it's because of Scatterer's autosavePlanetSettingsOnSceneChange config entry. When set to TRUE it applies any changes to Scatterer's settings made with Scatterer's in-game menu (ALT+F10) whenever the scene is changed. I set it to TRUE since I was tweaking AA settings and did not fancy restarting the game every 30 secs. @HebaruSan figured out by checking the code on GitHub that this entry also makes Scatterer to overwrite atmo config file with current in-game settings. One does not need to edit anything or even open the in-game menu - Scatterer will overwrite the file anyway just to be sure. What's even most interesting, it seems that it only saves entries it recognises from it's own atmo config file and skips all that are specific to JNSQ's configs. I compared my current JNSQ's atmo config for Scatterer with one on GitHub and it's missing some entries, like experimentalAtmoScale, Rg, Rt, RL and of course JNSQTag. I had autosavePlanetSettingsOnSceneChange set to TRUE for quite some time now but usually I quit the game by ALT+F4, so Scatterer didn't have a chance to overwrite any files. Until two days ago, when I closed the game in a civilised manner.

Huh, I checked on GitHub and you're right. However, it's at least the second time I have to add this line manually. The first time was like a year ago so I had to figure out what the problem is all over again. Why it happened again I really can't tell. I didn't touch JNSQ since the last update. The only mods I updated recently were Kopernicus and Scatterer. I wonder if this is somehow related to the Jool problem @squeaker0704and @caipihave experienced (I'm guessing that Jool without the atmosphere is just black void). The symptoms are pretty similar - the planet loads without the atmosphere, there is a Scatterer debug entry in KSP.log that says that the atmosphere config could not be found. Reinstalling JNSQ helps but only for one game, after restart the problem reappears. It's like something deleted JNSQTag from the config file but it shouldn't be (and probably isn't) possible.

Hello, is pixelated Kerbin as viewed from a low orbit the way it should be ? Also I believe that atmo.cfg for Kerbin in ...\GameData\JNSQ\JNSQ_Configs\Scatterer\Planets\Kerbin \ is still missing JNSQTag = True key. Without it the atmosphere config gets deleted by another JNSQ patch.

Failed antennas keep working. Is it just me? I have this bug for quite some time now and I don't see anyone else complaining... Not that it's game breaking or anything, I just want to suffer more. EDIT: parachutes also deploy even when failed, although I dunno if I want to suffer that much... Or maybe I want...

KSP 1.12 with the latest PF - upgrades in career does not seem to work. Interestingly, I wrote a patch to add 1.875 m base and this upgrade works. It's a simple copy of FairingBaseMax2_75m +PARTUPGRADE[FairingBaseMax2_75m]:NEEDS[ProceduralFairings] { @name = FairingBaseMax1_875m @techRequired = aerodynamicSystems @title = Procedural Fairings Max Diameter 1.875m @description = Allows fairings bases up to 1.875 meters. } @PART:HAS[@MODULE[ProceduralFairingBase]:HAS[#mode]]:AFTER[ProceduralFairings] { @MODULE[ProceduralFairingBase] { @UPGRADES { UPGRADE { name__ = FairingBaseMax1_875m maxSize = 1.875 } } } } However, none of the original upgrades work. BTW, 2.75 m and 4 m base upgrades seem to have tech levels swapped, which puts 2.75 m upgrade further down the tech tree than 4 m upgrade. It's advConstruction for 4 m and specializedConstruction for 2.75 m. Pretty sure it was meant to be the other way. EDIT: OK, I believe I figured this one out. My patch as it is adds my upgrade to the end of the list of upgrades. So I guess that KSP gets the list of unlocked upgrades and goes through them in just one go, updating all keys whenever it finds a matching upgrade. So since mine was the last on the list, maxSize = 1.875 was always applied last, regardless of any other unlocked upgrades. Changing UPGRADE to UPGRADE,1 did the trick by putting my upgrade before 2.75 one (not the most elegant solution but it works for me).

Hi, I believe HG-5 High Gain Antenna model has a doubled dish. This is what the antenna fell apart into after my botched Mun landing: EDIT: in the next, equally successfull landing it fell apart into 4 dishes. It's like a matryoshka doll.

Here is my list from KSP.log, maybe it will help to narrow down the offending mod. We both must have it I guess: Mod DLLs found: Stock assembly: Assembly-CSharp v0.0.0.0 Scale_Redist v1.0.0.0 / v2.4.5.7 ModuleManager v4.2.1.0 ClickThroughBlocker v0.1.10.17 0Harmony v2.0.4.0 HarmonyInstallChecker v1.0.0.0 ToolbarControl v0.1.9.6 KSPe.Light.Recall v2.3.0.4 Attached v0.2.0.6 ChillingOut v0.2.0.6 Driftless v0.2.0.6 KSP-Recall v0.2.0.6 LetsStayTogether v0.2.0.4 Refunding v0.2.0.6 Resourceful v0.2.0.6 SolverEngines v3.3.0.0 / v3.10.0.0 AJE v2.18.0.0 Bureaucracy v1.0.0.0 CLSInterfaces v2.0.0.6 ConnectedLivingSpace v2.0.0.6 CrewQueueTwo v1.1.11.2 CustomBarnKit v1.1.21.0 DeadlyReentry v8.1.2.0 DecouplerShroud v1.0.0.0 DistantObject v2.0.3.0 DMagic v1.4.3.0 / vv1.4.3.0 DMModuleScienceAnimateGeneric v0.23.0.0 FlightTracker v1.0.0.0 EarnYourStripes v1.0.0.0 EngineLightRelit v1.6.3.0 / v1.0.0.0 FerramAerospaceResearch.Base v0.16.0.3 ModularFlightIntegrator v1.0.0.0 / v1.2.10.0 FerramAerospaceResearch v0.16.0.3 ferramGraph v1.3.0.0 Scale_Redist v1.0.0.0 / v2.4.5.7 Kopernicus.Parser v1.0.0.0 Kopernicus v1.0.0.0 MyRocksAreBiggerThanYours v1.0.0.0 SigmaTweakChutes v1.0.0.0 Sigma88LoadingScreens v0.4.0.0 KerbalChangelog v1.4.2.0 KerbalConstructionTime v1.4.11.0 KerbalismBootstrap v3.14.7846.20388 / v3.14 ICSharpCode.SharpZipLib v0.86.0.518 / v0.86.0 kOS v1.3.2.0 kOS.Safe v1.3.2.0 Kronometer v1.12.0.1 KSPRescueContractFix v1.1.0.0 MagiCore v1.3.2.3 / v1.0.0.0 / v1.3.1.0 MandatoryRCS v1.6.0.0 OhScrap v2.2.0.0 / v2.2.0.3 ProceduralFairings v6.0.0.0 / v6.1.0.0 RCSBuildAid v1.0.6.35359 RealChute v1.4.7845.29741 / v1.4.8.3 RealFuels v13.3.0.0 / v13.3.0 Restock v0.1.0.0 scatterer v0.772.0.0 ScrapYard v2.1.1.0 SmokeScreen v2.8.14.0 KSP_Log v0.1.1.7 ButtonManager v0.0.1.1 KSP_ColorPicker v0.1.0.4 KSP_PartHighlighter v0.1.0.9 SpaceTuxUtility v0.0.3.1 VesselModuleSave v0.0.1.2 Stock assembly: KSPSteamCtrlr v0.0.1.35 TextureReplacer v4.5.1.34170 KSPe.Light.TweakScale v2.3.0.4 Scale v2.4.5.7 KSP-AVC v0.0.0.1 ZeroMiniAVC v1.1.1.1 Folders and files in GameData: 000_ClickThroughBlocker 000_Harmony 001_ToolbarControl 999_KSP-Recall AJE Bureaucracy CommunityResourcePack ConnectedLivingSpace CrewRandR CustomBarnKit DeadlyReentry DecouplerShroud DistantObject DMagicOrbitalScience DMagicScienceAnimate EarnYourStripes EngineLightRelit FerramAerospaceResearch FlightTracker JNSQ KerbalChangelog KerbalConstructionTime Kerbalism KerbalismConfig Kopernicus kOS Kronometer KSPRescueContractFix MagiCore MandatoryRCS ModularFlightIntegrator OhScrap ProceduralFairings RCSBuildAid RealChute RealFuels RealFuels-Stock RealPlume ReStock ReStockPlus scatterer ScrapYard SmokeScreen SolverEngines SpaceTuxLibrary Stock folder: Squad Stock folder: SquadExpansion TextureReplacer TweakScale TweakScaleLimited ZeroMiniAVC 999_Scale_Redist.dll Custom_FARAeroData.cfg ModuleManager.4.2.1.dll ModuleManager.ConfigCache ModuleManager.ConfigSHA ModuleManager.Physics ModuleManager.TechTree

@Lisias Believe it or not but with 2.4.5.7 I still have the same problem and the very same exception. I can do fine with the previous version alright, so it's no biggie but I thought you may want to know.

Here ya go: https://ufile.io/n49g2cz6 Steps taken: 1. game launched with the current full mod setup 2. loaded my latest save 3. entered VAB 4. loaded one of my crafts 5. added the craft to KCT building queue by pressing LAUNCH 6. pressed EXIT (nothing happened as I said earlier) 7. ALT+F4 So the exception is literally at the very end of the log. I can't exit only if there is a vessel in the building queue. If I remove all vessels using KCT menu from the queue, I can again exit the VAB/SPH.

Dunno if it's Tweak Scale problem or Kerbal Contruction Time problem but with the latest Tweak Scale I can't leave VAB/SPH after adding a vessel to the building queue. I get this exception: [EXC 11:39:26.270] NullReferenceException: Object reference not set to an instance of an object ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) (at <cd473063d3a2482f8d93d388d0c95035>:0) ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) (at <cd473063d3a2482f8d93d388d0c95035>:0) ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) (at <cd473063d3a2482f8d93d388d0c95035>:0) ConfigNode.CopyTo (ConfigNode node) (at <cd473063d3a2482f8d93d388d0c95035>:0) KerbalConstructionTime.KCT_KSC.AsConfigNode () (at <27327b2825ca4e69a9d134bb5cd0383e>:0) KerbalConstructionTime.KerbalConstructionTimeData.OnSave (ConfigNode node) (at <27327b2825ca4e69a9d134bb5cd0383e>:0) ScenarioModule.Save (ConfigNode node) (at <cd473063d3a2482f8d93d388d0c95035>:0) ProtoScenarioModule..ctor (ScenarioModule module) (at <cd473063d3a2482f8d93d388d0c95035>:0) ScenarioRunner.UpdateModules () (at <cd473063d3a2482f8d93d388d0c95035>:0) ScenarioRunner.GetUpdatedProtoModules () (at <cd473063d3a2482f8d93d388d0c95035>:0) Game.Updated (GameScenes startSceneOverride) (at <cd473063d3a2482f8d93d388d0c95035>:0) GamePersistence.SaveGame (System.String saveFileName, System.String saveFolder, SaveMode saveMode, GameScenes startScene) (at <cd473063d3a2482f8d93d388d0c95035>:0) GamePersistence.SaveGame (System.String saveFileName, System.String saveFolder, SaveMode saveMode) (at <cd473063d3a2482f8d93d388d0c95035>:0) EditorLogic.onExitConfirm () (at <cd473063d3a2482f8d93d388d0c95035>:0) EditorLogic.onExitContinue () (at <cd473063d3a2482f8d93d388d0c95035>:0) EditorLogic.exitEditor () (at <cd473063d3a2482f8d93d388d0c95035>:0) UnityEngine.Events.InvokableCall.Invoke () (at <12e76cd50cc64cf19e759e981cb725af>:0) UnityEngine.Events.UnityEvent.Invoke () (at <12e76cd50cc64cf19e759e981cb725af>:0) UnityEngine.UI.Button.Press () (at <aa3a227ee8664797a8194ab8e2ed2249>:0) UnityEngine.UI.Button.OnPointerClick (UnityEngine.EventSystems.PointerEventData eventData) (at <aa3a227ee8664797a8194ab8e2ed2249>:0) UnityEngine.EventSystems.ExecuteEvents.Execute (UnityEngine.EventSystems.IPointerClickHandler handler, UnityEngine.EventSystems.BaseEventData eventData) (at <aa3a227ee8664797a8194ab8e2ed2249>:0) UnityEngine.EventSystems.ExecuteEvents.Execute[T] (UnityEngine.GameObject target, UnityEngine.EventSystems.BaseEventData eventData, UnityEngine.EventSystems.ExecuteEvents+EventFunction`1[T1] functor) (at <aa3a227ee8664797a8194ab8e2ed2249>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.EventSystems.EventSystem:Update() Does this say anything to anyone? KCT seems to not like some change introduced in the latest Tweak Scale.

Something adds some 0.5-1 Science Points when the game is loaded and I think it's Bureaucracy. I remember saving the game with 49.x Science Points (I think it was 49.9 but can't remember exactly) but after loading today I have 50.3. And I found these entries in the KSP.log just a fraction of a second after Awake entries, which I think mark game start: [LOG 19:27:18.835] [UiApp] Awake: Contracts [LOG 19:27:18.835] [UiApp] Awake: KSPedia [LOG 19:27:18.835] [UiApp] Awake: Missions App [LOG 19:27:18.835] [UiApp] Awake: AlarmClock (...) [LOG 19:27:19.092] [Bureaucracy]: kerbalism_SITE@KerbinInSpaceHighAridMidlands completed. Adding 0.05036978 science [LOG 19:27:19.093] [Bureaucracy]: Science Event SITE (Kerbin space high Arid Midlands) completed [LOG 19:27:19.093] [Bureaucracy]: kerbalism_SITE@KerbinInSpaceLow completed. Adding 0.55467 science [LOG 19:27:19.094] [Bureaucracy]: Science Event SITE (Kerbin space low) completed [LOG 19:27:19.094] [Bureaucracy]: Adding 0.209728 for kerbalism_TELEMETRY@KerbinFlyingHighNorthernSea What are these?

OhScrap (both latest and pre-release) does not track part generations in 1.12 for me. Part's are always Generation 1. Anyone has the same problem? I disabled Scrap Yard as Inventory still does not work, is some part of Scrap Yard necessary for generation fracking in OhScrap to work? EDIT: NVM, SY's part tracker must by enabled...

@Starwaster Last question - you suggested lowering reentry heating slider to 75%. Will this affect shields only or heating of all parts? Assuming I properly understand lossExp, lossConst and pyrolysisLossFactor, would tweaking these settings make more sense than just lowering heating or would it be more or less the same thing? Is heating at 100% somewhat realistic (in regard to reentry speed, air density and whatever else matters) or is it pumped up for Kerbol system?