SpacedInvader

Reinstalling GPU drivers now and then I'll run the windows check

I actually already tried that and you're correct, it didn't do anything to help the issue

Hadn't tried deleting the settings.cfg, but doing so didn't change anything just now sadly. This really feels like unity broke somehow in the crash and some part of it that resides outside of the KSP directory is corrupted, but I can't find any information about what it could be. As I said, this is something that affects all three KSP installs I've got right now and only one of them crashed.

Nope, quitting and reloading doesn't do anything and I'm using a fresh test save each time. The one thing that appears to help is entering the vab and returning, but then if I attempt to reload a save after that, KSC will be underground again.

The log files I'd linked yesterday were from a completely fresh install of KSP (i.e. redownloaded both KSP and Kopernicus and installed into a separate folder from my main install) where I was getting the depicted behavior. I've just downloaded release 29 and tried again, with the same results. Here are the Kopernicus generated logs from this: Logs EDIT: This is the line that keeps popping out at me in the logs as appearing to be the issue: [ERR 17:45:31.552] [SurfaceObject]: Cannot return to original parent, it no longer exists. It seems to occur every time the issue crops up. Also, the problem doesn't seem to be that KSC is moving, but that the terrain is moving up and down with each load around KSC. When KSC is floating, sometimes the land has moved below water level so KSC is over water, and when KSC is underground, you can see the shoreline looks more like cliffs than a beach.

I've already posted this to all of the different Kopernicus threads, but I'm also putting this here because I'm not entirely sure this is a Kopernicus specific issue due to its presence in a completely fresh install of both KSP and Kopernicus. I'm really hoping someone can point me to any instances of files that KSP might create / use so I can investigate them for corruption / replace them. I'm running into a serious issue with Kopernicus and I've got no idea how to fix it. Things were working fine until last night, running the most recent stable version of Kopernicus on KSP 1.11.1. Then after an 8 hour session the game crashed... hard... I got some blank error messages with progress bars that did nothing except show that they were from Unity and one notification that there had been an overflow of some type before finally forcing me to alt-f4 / end processes to get rid of the messages. Anyway, ever since then, whenever I try to load a save from within the game, this is what I'm presented with: The first image where KSC is underground is what always happens on the first reload, the second is usually what happens if I try to reload a second time, though sometimes the terrain is so low that you can see water below the floating space center. Anyway, these are from a bare bones install with just Kopernicus, ModularFlightIntegrator, and Module Manager and KSP installed. I've tried reinstalling all of them, including KSP more than once, always with the same result. Additionally, I get the same results if I try to roll back Kopernicus and MFI to the bleeding edge version I'd been using before the stable release. That all said, whats more interesting / frustrating about this is that it doesn't seem to be restricted to my main KSP install, but instead it affects all KSP installs on my system, even a completely fresh install made after all of this started with freshly downloaded KSP and Kopernicus archives. And that's where I'm fresh out of ideas on how to fix this... I'm not familiar with anything other than logs that KSP stores outside of its home directory and I don't know of anything at all that Kopernicus might store elsewhere that could have become corrupted, so I'm really hoping someone who knows more about the way Kopernicus / KSP works can help me sort out what might be going wrong here because its preventing me from playing my main save as I'm both afraid it could further corrupt if I try to press forward and the mission I was about to launch was a rover to drive around KSC... Logs Kopernicus Generated Logs EDIT: Just to be clear, I only get these results when Kopernicus is installed

Posting this in multiple places in the hopes of finding someone to help sort it out... I'm running into a serious issue with Kopernicus and I've got no idea how to fix it. Things were working fine until last night, running the most recent stable version of Kopernicus on KSP 1.11.1. Then after an 8 hour session the game crashed... hard... I got some blank error messages with progress bars that did nothing except show that they were from Unity and one notification that there had been an overflow of some type before finally forcing me to alt-f4 / end processes to get rid of the messages. Anyway, ever since then, whenever I try to load a save from within the game, this is what I'm presented with: The first image where KSC is underground is what always happens on the first reload, the second is usually what happens if I try to reload a second time, though sometimes the terrain is so low that you can see water below the floating space center. Anyway, these are from a bare bones install with just Kopernicus, ModularFlightIntegrator, and Module Manager and KSP installed. I've tried reinstalling all of them, including KSP more than once, always with the same result. Additionally, I get the same results if I try to roll back Kopernicus and MFI to the bleeding edge version I'd been using before the stable release. That all said, whats more interesting / frustrating about this is that it doesn't seem to be restricted to my main KSP install, but instead it affects all KSP installs on my system, even a completely fresh install made after all of this started with freshly downloaded KSP and Kopernicus archives. And that's where I'm fresh out of ideas on how to fix this... I'm not familiar with anything other than logs that KSP stores outside of its home directory and I don't know of anything at all that Kopernicus might store elsewhere that could have become corrupted, so I'm really hoping someone who knows more about the way Kopernicus / KSP works can help me sort out what might be going wrong here because its preventing me from playing my main save as I'm both afraid it could further corrupt if I try to press forward and the mission I was about to launch was a rover to drive around KSC... Logs Kopernicus Generated Logs EDIT: Just to be clear, I only get these results when Kopernicus is installed

Posting this in multiple places in the hopes of finding someone who could help figure this out... I'm running into a serious issue with Kopernicus and I've got no idea how to fix it. Things were working fine until last night, running the most recent stable version of Kopernicus on KSP 1.11.1. Then after an 8 hour session the game crashed... hard... I got some blank error messages with progress bars that did nothing except show that they were from Unity and one notification that there had been an overflow of some type before finally forcing me to alt-f4 / end processes to get rid of the messages. Anyway, ever since then, whenever I try to load a save from within the game, this is what I'm presented with: The first image where KSC is underground is what always happens on the first reload, the second is usually what happens if I try to reload a second time, though sometimes the terrain is so low that you can see water below the floating space center. Anyway, these are from a bare bones install with just Kopernicus, ModularFlightIntegrator, and Module Manager and KSP installed. I've tried reinstalling all of them, including KSP more than once, always with the same result. Additionally, I get the same results if I try to roll back Kopernicus and MFI to the bleeding edge version I'd been using before the stable release. That all said, whats more interesting / frustrating about this is that it doesn't seem to be restricted to my main KSP install, but instead it affects all KSP installs on my system, even a completely fresh install made after all of this started with freshly downloaded KSP and Kopernicus archives. And that's where I'm fresh out of ideas on how to fix this... I'm not familiar with anything other than logs that KSP stores outside of its home directory and I don't know of anything at all that Kopernicus might store elsewhere that could have become corrupted, so I'm really hoping someone who knows more about the way Kopernicus / KSP works can help me sort out what might be going wrong here because its preventing me from playing my main save as I'm both afraid it could further corrupt if I try to press forward and the mission I was about to launch was a rover to drive around KSC... Logs Kopernicus Generated Logs EDIT: Just to be clear, I only get these results when Kopernicus is installed

This is great! It clearly lays out what applications work best for each vehicle combination. Thanks for putting in the work to show this! Not sure how long ago that was, but if you're thinking of the older FASA stuff, IIRC yeah, those old configs were really inflexible. So far my experience with the newer configs is that they are about as flexible as the BDB parts themselves. I've swapped plenty of parts around without issue... in fact, I'd say the most trouble I've had is from using the correct builds because of the aforementioned problems with over / under power for my payloads.

I'm running into a serious issue with Kopernicus and I've got no idea how to fix it. Things were working fine until last night, running the most recent stable version of Kopernicus on KSP 1.11.1. Then after an 8 hour session the game crashed... hard... I got some blank error messages with progress bars that did nothing except show that they were from Unity and one notification that there had been an overflow of some type before finally forcing me to alt-f4 / end processes to get rid of the messages. Anyway, ever since then, whenever I try to load a save from within the game, this is what I'm presented with: The first image where KSC is underground is what always happens on the first reload, the second is usually what happens if I try to reload a second time, though sometimes the terrain is so low that you can see water below the floating space center. Anyway, these are from a bare bones install with just Kopernicus, ModularFlightIntegrator, and Module Manager and KSP installed. I've tried reinstalling all of them, including KSP more than once, always with the same result. Additionally, I get the same results if I try to roll back Kopernicus and MFI to the bleeding edge version I'd been using before the stable release. That all said, whats more interesting / frustrating about this is that it doesn't seem to be restricted to my main KSP install, but instead it affects all KSP installs on my system, even a completely fresh install made after all of this started with freshly downloaded KSP and Kopernicus archives. And that's where I'm fresh out of ideas on how to fix this... I'm not familiar with anything other than logs that KSP stores outside of its home directory and I don't know of anything at all that Kopernicus might store elsewhere that could have become corrupted, so I'm really hoping someone who knows more about the way Kopernicus / KSP works can help me sort out what might be going wrong here because its preventing me from playing my main save as I'm both afraid it could further corrupt if I try to press forward and the mission I was about to launch was a rover to drive around KSC... Logs Kopernicus Generated Logs EDIT: Just to be clear, I only get these results when Kopernicus is installed

DELETE

This is great, thanks! IDK why, but it never occurred to me to look down the list on your wiki to find this on my own, instead I've been pouring over the individual entries to see what they were used to launch and then try to infer from that what I should try using. EDIT: As for hand flying, part of the issue for me is that hand controlling a rocket going up hill feels tedious and twitchy to me... tap one of the direction keys a little too long and you're at least going off of peak efficiency and potentially going tumbling. I also get more enjoyment from letting the machine do the work while I have fun designing the vehicles. I do hand fly most maneuvers and all landings though.

That's what took me up to the Atlas orginally and the new issue of having too much power / dV for the payload. Is there a middle ground between the two that I'm just missing due to lack of knowledge? I guess I could swap out the engine for something different, just have to keep playing lego-rocket until I can find something middle ground. I tend to rely on Gravity Turn for my launches, though I've been playing around a little with MJ's prime vector guidance as I've always loved the idea of doing a more realistic single burn to orbit but have always had trouble doing it by hand or with ascent guidance from other sources. I also generally avoid hand flying anything other than maneuvers these days because even without this difficulty I've been experiencing recently, I tend to only give myself a relatively small spare dV budget because it doesn't feel very realistic to build a rocket with 8k dV when my mission only needs ~6k just so I can have room to bork the ascent. That all said, I know that different rockets need different ascent paths, I'm just spoiled by being able to build something with enough dV and too much TWR and then dial the TWR down to make it flyable. On the RF configs issue, what do you mean by "lock" in this case? Did it mean you couldn't adjust the TWR like I was experiencing, or was it something else?

Not the probe per se, but the dV needed for the upper stage / probe to do what I want with it and have extra left over for maneuvering if needed. With this specific mission I'm trying to orbit the mun and getting that dV uphill is proving tricky with my current tech level of engines. I think that's the other half of this problem, between the limited ignitions and limited early performance of engines imparted by RF, I'm kinda stuck in a situation where the Redstone can just barely lift enough weight into orbit to finish the mission, but there's essentially zero room for error. I'm using an Ablestar upper stage and I'm able to get my probe onto an intercept with the mun with ~75dV leftover in the stage after its two burns, so not much room for error there. I'm still playing lego-rocket to see if I can tweak a few hundred extra dV out of it though.

Personally this is one area that I tend to prefer less realism... IDK why, but I often find myself stuck in a launch vehicle gap, where the payloads I'm launching are too light for larger launch vehicles, but still require more dV than the smaller LVs can manage for its weight. My perennial solution is to overbuild and then dial back the thrust limiter until I get into the 1.2-1.5 SLT range. That's why this whole thing came up for me... I'm at a place where smaller rockets didn't seem to cut it, so I stepped up to an Atlas and ended up being so overpowered that it either overshot the target altitude by hundreds of km or burned up in the atmosphere. Currently I'm fiddling with stage dV on a Redstone to try to put my payload on a mun intercept, but my dV budget is getting razor thin and I really hate trying to fly without some decent reserves so I'm getting more tempted just to go back to the Atlas and use my now-throttleable engine configs to make it work. This all said, I'm genuinely curious what the correct approach to this situation would be if the engines were truly unthrottleable and you had to carry a mass too small and too big at the same time. Start shaving off parts to save weight? Carry ballast to make the larger LV work?

So I've actually figured out what's going on with these engines and need to confirm that its an error and not something done on purpose. From what I've found, many of the engines in the Bluedog-DB patches have had their minimum and maximum thrust values set to the same number through these lines: minThrust = #$/MODULE[ModuleEnginesRF]/maxThrust$ maxThrust = #$/MODULE[ModuleEnginesRF]/maxThrust$ Which completely disables any form of throttling, including reducing the thrust limiter. To me this seemed like a copy/paste oversight rather than being intentional, but Zorg over at BDB mentioned that it could have been intentional due to the fact that many of the engines represented by their work were in fact not throttleable. The thing is that I wasn't able to find any discussion about this one way or the other, so I went ahead and made myself a set of configs with the correct placement of min vs max, but I'm curious still if this was actually intentional or accidental. Anyway, sorry for the ping here, but @Bellabong, since these are your patches, could you comment? Thanks EDIT: Just for the record, one of the reasons I believed this to be in error is because these are the only engines I've found in all my years of using RF that didn't at least allow for the use of the throttle limiter function.

For the time being, that's what I've done, and I do plan on bringing it up on the RFS thread as I can't rule out the possibility that it was done on purpose.

It is possible that they were set to be non-throttleable for realism, but I've not been able to find any discussion of that on either thread as of yet. Also, those would be the only engines I've found in the entire RFS config library that were set up like this. And I'd also point out that, while I know relatively little about realistic engine configs, I've learned from using RF for years that most engines are at least somewhat throttleable, though the deep throttle control the game gives us is very unrealistic. From what it seems like, the most likely explanation is that the person making the configs might have mis-copied some lines instead. In many places they used this code block: minThrust = #$/MODULE[ModuleEnginesRF]/maxThrust$ maxThrust = #$/MODULE[ModuleEnginesRF]/maxThrust$ Which then set the engines to only allow for a single thrust output, even preventing the thrust limiter function from working. Instead I think this is just the result of the author pasting the same "#$/MODULE[ModuleEnginesRF]/maxThrust$" line over and over for the configs and failing to change half of them to "#$/MODULE[ModuleEnginesRF]/minThrust$". After all, there are more than 150 instances so it might have been easy to get into a groove and just keep going. To be fair, I could be wrong and they were intentionally set to zero throttleability, but if not, fixing the issue is as simple as doing a find and replace to swap "minThrust = #$/MODULE[ModuleEnginesRF]/maxThrust$" with "minThrust = #$/MODULE[ModuleEnginesRF]/minThrust$" in the BDB config files. EDIT: Beyond those lines, it seems pretty much everything else in the configs is working correctly except for some incorrect references to ModuleRCSFX instances that don't exist.

I did ask over there before asking here, but as that thread isn't very active, I'd hoped to find someone here who uses RF who might have run into the same problem. That said, I've managed to find the error in the configs that caused the issue and I'm working on a solution right now. I'll try to get it into RFS, but I might also post it here in case anyone else runs into the same issue.

Is there a way to see what the final incarnation of a part's config looks like after all MM patches are applied? There used to be a way to get at it through the database in the console menu, but the option to view the configs seems to have disappeared. Is there any way to get access to it again?

Did you actually try the RF configs and weren't able to get them to work, or did you just skip RF entirely? I saw earlier in this thread you said you weren't really a fan of RF so you use your own configs. I'm specifically trying to see if anyone who does use RF was able to get them to work...

Has anyone here managed to get the RealFuels-Stock engine configs to work with BDB? I'm running into a serious issue where any engine that had multiple configs defined by BDB gets "stuck" when using the RF configs and I can't throttle it at all or adjust its throttle limiter. I've been working on it on my own for a day now and have already asked on the RFS thread, but I'm hoping someone here also uses those configs and has figured out a way to make them work correctly.

I"m running into a fairly serious issue with the Bluedog-DB configs. They do function properly in selecting engine configs through the RF dialog and also in using the fuel types, but I can't throttle many of them and the throttle limiter doesn't work at all for any affected. It appears to be any engine that had multiple configs applied through the B9 part switch by the BDB authors that's affected. I've been trying to tweak the RFS configs to get them to work, but so far they refuse to work correctly and I'm starting to run out of ideas. I'm curious if anyone here has managed to get them to work correctly?

I've got an odd incompatibility that's cropping up with Real Fuels. When I have both mods installed, I get the following message in my log and then the fairings don't work to protect parts within them at all: [LOG 00:12:05.339] RealFuels.Tanks.TankWindow:HideGUI() RealFuels.Tanks.ModuleFuelTanks:OnDestroy() UnityEngine.Object:DestroyImmediate(Object, Boolean) UnityEngine.Object:DestroyImmediate(Object) DragCubeSystem:SetupPartForRender(Part, GameObject) <RenderDragCubesCoroutine>d__31:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) UnityEngine.MonoBehaviour:StartCoroutineManaged2(IEnumerator) UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) <SetupDragCubeCoroutine>d__47:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) UnityEngine.MonoBehaviour:StartCoroutineManaged2(IEnumerator) UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) SimpleAdjustableFairings.ModuleSimpleAdjustableFairing:RecalculateDragCubes() SimpleAdjustableFairings.ModuleSimpleAdjustableFairing:OnStartFinished(StartState) Part:ModulesOnStartFinished() <Start>d__322:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) Without Real Fuels installed, the fairings work correctly and I don't get these messages. Is this an issue on the Real Fuels side or on the Simple Adjustable Fairings side? The two seem like they shouldn't affect each other at all, but that's just from a layman's perspective... EDIT: To be clear, all other fairing types work (vanilla + procedural), so its definitely something between these two mods

If you'd like to, that'd be great. Like I'd mentioned, there could be issues that need to be ironed out, but if its on the front page, at least it might save some people from having to search for it.