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.