SpacedInvader

I'm getting back into KSP and as usual I'm busy loading about 100 too many mods onto the pile. That said, I'm curious which of these two part failure mods is better these days? I've played with the old version of DangIt! (pre-continued) a decent amount, but back then OhScrap! was either not a thing yet or had just barely been released so I never had a chance to play around with it. Anyway, normally I'd start with a search on the topic, but apparently all of the relevant results are on the reddit and, well, right now is not a good time to be looking for information that's only on the reddit sadly, so I'm hoping to get a least a few opinions about which people like and why so that I can make an informed decision. Thanks EDIT: So it turns out that I haven't actually played with either of these because the failure mod I used the last time I played was BARIS. That said, I'm still interested in people's opinions on these two as BARIS is no longer supported and its successor doesn't interest me.

It sounds from previous posts that JPLRepo has already solved this and other issues, but the update is still in testing. The only reason I'd asked about its status is that its been nearly a month since the last communication.

I really hate to ask about the status of an update, but I've reached a point in my career playthrough where if I advance time at all, I'm hit with the bug where I go from the initial bodies being visible to all bodies being visible. I've been able to roll back to a backup made prior to the bug kicking in, but I'm basically stopped from playing now because advancing time at all reveals all of the bodies. I'm not trying to pressure for a quick update release, but rather trying to ascertain if said update is coming soon enough to justify setting KSP aside for a little while or if I should just accept that all CB's are now going to be visible and I should just press forward without being able to discover them gradually. Sorry again, but thanks if you reply

No parts had both modules, but oddly enough, somewhere in the intervening time between the posts, the issue worked itself out. Don't know when as I was using PF instead, but when I went back to try to replicate the issue, I couldn't get it to happen anymore, so it might have been a 3-way compatibility issue that was worked out when the third mod updated sometime in there. My best guess was modular flight integrator as that had a couple of updates, but I can't be sure if that would even affect either of the other two mods. Whatever the case, this seems to be a "nevermind" situation. Thanks for the reply though,

Hmm, I'll check it out. Thanks

As I've been progressing through my current career, I've found more than once that I've needed to re-run a mission for a contract because I've gotten my craft all the way to the target location only to find that I'd forgotten to put one experiment on to fulfill the contract objectives. Is there a mod or perhaps a vanilla mechanism to see a list of the experiments that a craft has already on board before committing to launch? I've tried a few times just going through each part and checking to make sure I've got the necessary parts, but several of the mods I'm using place experiments inside of non-science parts (i.e. I use Bluedog and only just today realized that the mod includes a set of solar panels which have RPWS experiments embedded in them...) which can lead to confusing mix-ups. Anyway, any help would be appreciated. Thanks

@Zorg I've done a balance pass on my RT configs now that I've had a chance to play a little with them. Mostly I've improved energy draw since the craft from BDB are designed with the vanilla CommNet in mind which doesn't have running costs for its antennas, but I've also tweaked some of the ranges as well and included configs for the as yet unreleased antennas found in the master branch for when they are released. The one issue I've still got with these configs is that many of the omni antennas feel somewhat overpowered, so I may yet do another balance pass on them, but at the same time, each is expected to fill a certain roll within a limited power budget, so I'm not sure how much wiggle room there really is. With that all said, if anyone other than me is actually using these, I'd really love some feedback for future balancing decisions. The files EDIT: I've also given quite a few of the antennas an unpowered mode to give greater flexibility for on-pad control.

@Bealeso I've found something that might deserve a little attention. As it turns out, a fair percentage of the configs for Tantares have a lower-case 'T' in the author line, while the rest have it capitalized. Its nothing critical of course, but its what caused my patches to fail in some cases since I was identifying parts using the author line and MM needs separate patches for each version of the author. I'm guessing it should be as simple as doing a find / replace in the files in the directory should you decided to fix it as I'm sure I'm not the only one who will ever use the author line to identify the parts in need of patching in the future. With that said, I've gone ahead and updated my configs to handle both versions of the configs and also done a balance pass to draw down the power consumption of the antenna and convert several to allow on-pad control with an unpowered short-range mode. Anyway, here they are:

Just in case anyone was already using my RemoteTech configs and was running into issues, I've updated the config to fix a capitalization error that was invalidating the edits. Here it is to save you from searching for the previous post:

Has anyone tried this in 1.11 yet? I'd actually forgotten about this mod, but remembered it when I realized I couldn't tweak rover wheels in the way I used to. Will probably give it a try, but still worth asking just in casesomeone has tried it and its a no-go... EDIT: Apparently I'd gotten this mod mixed up with Steering Tweaker for wheel tweaks, though for some reason I really feel like an older version of this mod allowed tweaking things like suspension since Steering Tweaker doesn't do that and I specifically remember being able to stiffen my rover's suspension settings... EDIT2: I went ahead and tested the mod and the answer for KSP 1.11 is that is sort of works... There is an error message saying that "TweakableDeployablePanels.dll is not compatible with this version of KSP" and then the game hangs on a full loading screen bar and never makes it to the main menu. Renaming that DLL to .BAK allows the game to load to the main menu, and then the rest of the mod appears to work correctly, but there are many thousands of the following NRE in the log: [EXC 19:51:56.587] NullReferenceException: Object reference not set to an instance of an object TweakableEverything.ModuleTweakableDockingNode.FixedUpdate () (at <a73916ddc84c4aad97c4602d57fff7ce>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) @linuxgurugamer sorry for the ping and I know its not super high on your list, but maybe you could add this to the bottom of your "Needs updated for KSP 1.11" list? Logs

I know... I actually thought I'd popped in here to mention that it seemed to work fine a couple of weeks ago, but I guess I never did.

Ahh, the joys of inheriting a plate of spaghetti

I don't know if this is still being developed at all, but I'd like to make a suggestion that any part that's selected to fail during a staging event should have a secondary failure check against it. I'm finding that my engines tend to fail the most after a staging event even if they are the most reliable part on my whole craft because the staging even only checks against the overall reliability of the whole craft and doesn't care about the individual part reliability. Adding a secondary check would allow for high reliability parts on a lower reliability craft to have more of an impact and would also mean using a reliable engine could save a launch that would otherwise fail. It would also be nice if there was a severity check based on how badly a part failed rather than what appears to be just a random failure. Seeing in the debug that my part missed a reliability check by 2 points and then it fails completely rather than developing a leak or getting something more minor like getting stuck seems off, while adding a severity system would add depth. Just some thoughts.

Makes sense that would lead to bad results... I'm actually kind of surprised that hasn't been in the code for years since checking for a prior config before applying another config seems like a must have component. Either way, thats a nice addition that's likely going to save headaches down the road in addition to the immediate benefits.

Did you work on this all night or something? When you called it last night it seemed like it would be a couple of days before you had something new, but here it is, first thing in the morning... That said, the bug appears to be gone, so that was some quick bugstomping on your part and I appreciate it for sure.

I don't suppose you might have some links to those old discussions? I searched for about an hour before posting my original messages and found basically nothing which is why I posted my initial question in like 4 places in the hopes of finding someone who might be able to help. I'm hoping there might be some information / solutions there that might be helpful in this current situation. You're probably right, but it still seemed like too sudden of a change to have happened without some sort of cause. That said, I have hope that you'll be able to figure something out with the underlying bug eventually and at least you've clued me in on a decent workaround for the time being. Thanks again for the help and putting in the effort to try to sort it out.

I see, though I'm still concerned about the crash that triggered all of this since it was working fine for about two weeks prior to this and then suddenly the bug has manifested everywhere for me. I'm still trying to search for information about whether or not the unity player stores some temporary files anywhere that could have gotten corrupted or "stuck" when the crash occurred, but finding information about that is proving difficult. I'm actually considering trying to join a unity developer forum to ask there in the hopes someone might be willing to help. That said though, I'm very appreciative of the effort you're putting in here and if a solution can be found to a long standing bug as a result of all of this, then I suppose its an overall positive result.

Ahh yes, I suppose I wasn't clear in my original description of the issue... loading the save from the main menu would always place KSC back on the surface. My concern is that there is something deeper going on and I'm hesitant to use this going forward, especially since I use KCT and KRASH together in my main career save which results in lots of short term reloading and I'm not sure what effect that would have on the save file overall. EDIT: The moving terrain with repeated reloads was the result of attempting to load the save from the KSC multiple times

Sounds good, I've got my fingers crossed By escape do you mean accessing the escape menu, or do you mean getting KSC back above ground?

Direct downloads from Squad. I've tried both the installer version and the zip version.

Cleaning the registry and doing a full reinstall of KSP + BG had no affect on the issue

I appreciate everyone putting effort into this, really hoping we can get it figured out and it doesn't mean I have to reinstall windows or something drastic like that. For the record, I'd had the idea that maybe there was some registry value that was trying to tell KSP that I had Making History installed as well and since I don't own it, things were going haywire so I cleaned out the registry of KSP entries and am trying a fresh install of KSP + BG to see if that has any effect on the issue.

Something to note here is that I do have the Breaking Ground DLC, but I didn't install it into my test installs to keep them as clean as possible. I don't know if this is the source of the issue however as I've had it installed into my main instance of the game the whole time and it still suffers from the issue. That said, I did try installing it into one of my test installs to see if that would at least get rid of the missing part references in the log and it did not. Currently investigating deeper to see what the source of those really is. EDIT: I've tried using both manual installs and CKAN for the test installs and gotten the same results. I have also installed OPM into the test install to see if that would affect the issue at all and it didn't. EDIT2: Installing BG into my test instance did not fix the issue. Uninstalling all instances of BG (main install included) through the included uninstaller had no effect as well.

Missing parts? Can you highlight the lines you're talking about? Honestly didn't even notice that Something interesting here that might be relevant, or might not, is that things seem to get worse when I try to reload a save on my main install. On the second load, instead of just floating a little over the surface, the terrain has gone all the way to the surface of the water:

No joy on either. Windows didn't detect any errors and GPU driver reinstall didn't fix the issue