radinator

CKAN/KCT + your beta. New game, basic capsule, chute, "Flea" SRB with 3 fins + 2 Mystery Goo. Built the craft with the appropriate delay, launched, did experiments (2x mystery goo + crew report). Recovered with KCT then edited the craft. Filled the tanks (SRB) properly. EC did not fill, which I believe is normal. Mystery Goo containers still open (hadn't closed, which I believe they used to do with previous KSP versions < 1.7.) I closed one of the Mystery Goo containers to see if there would be a difference between the open and closed one later on. Saved the edits via the KCT window. After launch pad is reconditioned, I used KCT window in the corner to rollout the craft, and when done I hit launch in the KCT window. The middle-of-screen KCT popup then happens, asking to 'launch' , 'fill tanks & launch', ..I select launch. Scene jumps to launch pad and immediately fires the engines (I did not stage the engines to fire). The parachute had never reset, so I notice I don't have a chute available to land this time. As it is flying, I try the Mystery Goo containers. Neither will do the experiment, instead asking if I want to reset contains, as they already have data in them. One is open and one is closed, as I left them in the VAB, but neither reset the data/experiment. Likewise, the Crew Report is asking if I want to overwrite the (already existing) data. Rocket then crashes.

Ok. Tabula rasa, I uninstalled and reinstalled the game from Steam, no DLC included. 1.7.2 I unpacked your beta, and put the KCT folder in GameData. Started a basic career game. This time, on startup, the KCT initial startup window (where I believe you spend the initial points) popped up, but it was empty. Image Could go no farther as I could not dismiss the popup. [Correction: If I clicked on the KCT icon in the lower right corner, then another KCT popup frame shows up in the upper right corner (as expected), but that also was empty.]

I'm aware it was being worked on. An earlier report mentioned it was happening since 1.7.1, I was reporting that it was also happening in 1.7.0. I know he was working on it, just helping locate when it started happening, since that helps identify the specific problem. I tried testing the new beta with 1.7.2 and a newly created game. It did not reset/close the goo containers between flights. Although I got credit for the science between flights the experiment still contained the science. It also auto-staged when I hit the launch button, which means that instead of going to the launch pad and waiting for me to stage to start the launch, it went to the launch pad and immediately launched.

Since KSP 1.7.0 I've seen strange new behavior from this mod after recovering/reusing craft. This is one of my must-have mods, so I'm familiar with it. The new issues with recovered craft: Single-use experiments are not reset Parachutes are not reset EC (as others have mentioned) are not reset. Kerbals are not removed from external pilot seats (this one is weird, I have to manually grab them and remove them in the hangar). To put it simply, nothing seems to get reset when a craft is reused.

In my normal save I hadn't been using the stock batteries. Had to test this. The result is that both stock and KW batteries have the same behavior - so it's not KW...looks like Dang It! itself. Since repairs had worked for other parts in the game, I assumed it was an interaction between the two. So, new log file, with only Dang It! Continued installed. Same behavior on two types of stock batteries. First failed and repaired them. Then failed them and switched to Space Center, then went back to the ship and tried to repair - with no success. https://drive.google.com/open?id=0B5EgBvGqWFb4aTVRR0x1MUhPc0U

This is using 0.7.14.1 (I'm using KSP 1.3.0 in my save). 1. Made a virgin KSP_1.3 setup and installed the following mods with CKAN: {DangIt Continued 0.7.14.1, KW Rocketry Redux (& Graduated Power Response) 3.1.4, Module Manager 2.8.1}. 2. Started a hard-mode sandbox game, enabled manual failures. Then made a pod with 3 different KW batteries and put on launchpad. 3. Made failures, EVA'd and repaired all no problem. 4. Made failure of KW-BXL battery, then saved game. Re-entered game by loading save and tried to repair the failure. Got the bug I reported (said the part would last longer now, but inspection revealed that the battery failure is not fixed). This is THAT log file, link goes to file on my Drive. (Only in making the log for this did I learn the save/load requirement for the problem to appear.) https://drive.google.com/open?id=0B5EgBvGqWFb4dURmeHVGNEg3QVU As a test, I went to KSP 1.3.1 and the latest DangIt!, and did the same test (default difficulty mode, enabled manual failures). Got the same bug. Log file here: https://drive.google.com/open?id=0B5EgBvGqWFb4TkJDR0ZtdE55MDg Yet another test: Instead of saving the game and reloading (after failing the battery), I just left the pod on the pad and went to "Space Center", then went back to the pod on the landing pad. I was unable to repair the battery at this point. So the 'scene change' also triggered the problem. Perhaps that does an implicit save&load? Not sure.

I've been finding that KW battery pack will experience failures, but I am unable to repair them. The message is "This should last a little longer now." but the failure stays. Is this expected/known behavior?

I have 1.6.5 on KSP 1.0.2. It seems my Stayputnik Mk 1 is not using the internal antenna. If I add an omni to it it has a connection, but even on the launch pad, no extra antenna means no connection. [Edit]: Additional information. I was looking in the ships file at the Stayputnik, compared to another different saved game with a hex probe (which works), and noticed this difference: In Stayputnik: MODULE { name = ModuleSPU isEnabled = True IsRTPowered = True IsRTSignalProcessor = True IsRTCommandStation = False RTCommandMinCrew = 6 In probeCoreHex: MODULE { name = ModuleSPU isEnabled = True IsRTPowered = True IsRTSignalProcessor = True IsRTCommandStation = True <-- !! RTCommandMinCrew = 2 Also, I notice that the probeCoreHex has a ModuleRTAntenna (in addition to ModuleRTAntennaPassive) while the Stayputnik only has the ModuleRTAntennaPassive.

The new version (0.4.1.1) in CKAN still seems install to the GameData/Timmers/Keepfit directory, which doesn't seem to work.

For me it looks like it was tied to the RealChute mod, and a new update was pushed out this morning. Since you don't have that mod on your list it's probably not much help to you.

I have the same issue. Still trying to nail it down.

I've done further reading and saw mention that sometimes parts clipping inside each other can produce phantom forces, causing wild spins. I'm betting that is the problem (because of a design thing I did with batteries inside a modular girder segment and a goo canister mounted outside the girder segment) and it is nothing to do with the DangIt! mod. It's just the leak and the spinning happened at the same time and led me to the wrong conclusion. Thanks for the timely response. Edit: Nope, not that either. Problem ended up being that the save file had SAS turned on, so reloading seemed to cause all sorts of torque. Turning it off in the save file fixed the problem. DangIt! is performing flawlessly.

Ah, my mistake then. I saw a post where you mentioned adding that, and thought you had in the latest download. Might not be this mod then. Additional info: 1. 32-bit Windows, with other mods on ship (RealChute, TAC LS, Deadly Reentry, but no major parts mods like KW or B9 installed in game). 2. Looking at the messages tab before switching to the ship, it does look like a fuel leak was reported, so it must have happened just before switching sway from the ship. So the randomness part of this is answered. 3. Here is the log file from just after the ship spun itself apart, sending the capsule on a very fast out-of-SOI trajectory. Interestingly, the ship is stationary for a very short bit before it starts spinning (it doesn't spin from the very start). At this point I'm thinking it's not your mod, but if your eyes see something wrong...(log file sent to your outlook email address). Thanks for the quick response.

Love the mod as I played with a previous version in a previous game, but having an problem with a new game and the latest version (0.4.4.1). Not sure whether to classify it as a bug or a feature. My first orbit mission in new career mode game. Orbital Ship was basic: pod, goo canister, chute, LV909, simple FLT-400 tank. Got to orbit with no problems and saved the game. Came back later and resumed saved game. Went to tracking station and switched to orbiting ship. The following happened in the first 0.5 seconds after the switch: 1. Screen gets drawn. Ship has red tank. 2. Ship spins like crazy (4 revolutions per second or so). 3. Ship pulls itself apart, pieces flying everywhere. No chance to repair or deal with a failure, just instant destruction. Might it be possible the force due to a leak is a bit extreme? Also, out of curiosity (thinking RNG bad luck) I have reloaded the saved game several times, and even used time acceleration at the launch center a bit to "jumble up the randomness" if it's based on the clock as a seed. Doesn't matter, ship instant-destructs when I switch back to it the same way. It seems the randomness isn't as random as expected, Bringing to mind the following question. Is the mod set up so that the RNG determining when/if failure happens is determined ahead of time, and stored waiting until the clock gets to that point? Doesn't seem that would be the way it would be done, but the "reloading from saved game produces same 'random' result" seems strange.

I'm finding that if I zero out a science value in the cfg file (for example, Kerbin LandedDataValue, since I don't want to count things that could be explored from the ground as "rocket science") the mod will work but I get two glitches when I try to do science from there. The science window is graphically mangled a bit, and the science number shown is NaN. Not critical, just a note for your next update.