Claw

That's probably exactly what is going on. The MiniISRU was intentionally set to run at 10% the rate of the bigger one, which pretty much matches your results. What is probably happening is that the MiniISRU is getting first chance at the ore harvested that frame, so it's consuming all (or most) of it before the BigISRU has a chance. As for the thermo, ISRU drills and converters use a CoreHeat system, which is completely decoupled from the thermo overlay. And is fairly isolated (though not completely) from the rest of thermo. Finally, there is a bug at the highest time warp for mining vessels in focus. Sometimes the temp hangs up at strange values. If you are going to high warp for extended times, then it's probably best to be at another vessel, or at the tracking station. (I imagine you did it for testing, but just FYI.) Though keep an eye on the ISRU, because sometimes it shuts off when you are away. I'm not sure yet if that's another bug... Cheers, -Claw

Windows MOD key is ALT. Otherwise, what selfish_meme said. Also, StockBugFix v1.0.4c.2 doesn't include the GUI. The GUI is part of the StockBugFixPlus 1.0.5a.1 overhaul/update. Noted. As mentioned above, please make sure you are running the newest version of StockBugFix (v1.0.5a.1). Version 1.0.4c.2 does not include a GUI. If you are using version 1.0.5a.1, then please start up KSP and grab the log file. Also, you can delete the StockBugFixPlus.cfg file, and the GUI should pop up again the next time you run KSP. Unfortunately it was a lot of work to update for 1.0.5, and to rewrite things and integrate it all into one package. So I don't plan on releasing a 1.0.4 compatible version with a GUI. Cheers, ~Claw

Fengist, So, oddly enough. I had totally forgotten I did Dres and never posted it. So this trip is about a month old, but here is the mission report. If you want to skip to the punchline, here's the album. Sorry it's a bit thin, but there's only so many pictures of black and dark grey terrain one can post. Cheers, ~Claw

Dres The sweet vacation The “almost forgotten†Dres turned out to be a bit of a treat. The mission certainly started off in an exciting way, since the Mission Director decided last minute. The extra recovery vehicle was basically shot directly at Dres, but will still take some time to arrive. In the meantime, the crew enjoyed some rest in the comfort of the Mothership while waiting for the recovery vehicle to arrive. There was no need to sit on the surface waiting when they could wait up here and head down to Dres after the recovery vehicle’s arrival. The descent was pretty uneventful, considering the lander had excess thrust and fuel for the job. However, after landing, the real fun began. It took several days of driving about near the landing zone. Turns out there's some sort of terrain kraken hiding around on Dres. Any time I got around 1200m, the rover would sometimes spontaneously blow up as if hitting a wall. The F3 log reports "crashing into terrain," except that nearly the whole rover would vaporize. Sometimes there were only wheels left, sometimes only the rover's engine core. It wasn't even tied to terrain tile seams. I'm not really sure what it was, but it cause a drastic change in routing near the beginning of the mission. I was planning on an equatorial route, but couldn't get more than about 2km east of the landing zone before blowing apart. As it was, it took me nearly two days to find my way out of the mine field. However, after that, the trip was relatively uneventful. It was actually really fun to drive on Dres, after I got over the initial (and extreme) frustration. Also, turns out the poles aren't anywhere near as messy as Duna. The south pole is also home to a nice canal in the polar area. I would definitely not recommend driving on Dres at night. The terrain is quite dark, and when the sun goes down it's pretty much a black hole. Anyway, took me long enough to get around to posting this, so it's not a particularly clever post. Thanks for tuning in! Cheers, ~Claw

So I still don't know if anyone cares about Elcano challenges, but this post here reminded me that I never posted my Elcano Dres trip. I actually did this trip a bit over a month ago, but 1.0.5 sort of stalled out my posting (then I completely forgot). As it turns out, I even wrote up the post (about a month ago). I just never got around to editing and uploading pictures. To kickstart myself, I'm going to post the transition pictures, and my month-old writeup: Dres Transition The mission director wasn’t even thinking about Dres until the crew was nearly done with Duna (probably for good reason). He had actually started thinking ahead to Jool and how difficult Tylo is likely to be. But when studying the solar map, the mission director realized that the crew on Duna was smack in the middle of a transfer window from Duna to Dres. The Duna Mothership is already carrying two spare rovers for Duna. One rover is parachute capable only, but the second has roughly 1200 dV (more than enough to land on Dres). Also, the Mothership is carrying excess dV. The only real problem here is that there are only two recovery vehicles, both of which have been spent on Duna and Ike. After looking at transfer windows from Duna to Kerbin, then out to Dres, the Mission Director decided to try a new approach. The transfer window from Duna to Dres is open now, so the crew will do a more optimal style transfer directly from Duna. The window for Kerbin to Dres doesn’t open for some time. However, since only a small recovery vehicle is needed, the Mission Director gave the go-ahead to send a small crew recovery vehicle on an “out of window†high-dV transfer to Dres. While this will be more expensive, it’s better than the alternative of waiting a couple years to transfer the Mothership to Kerbin, then wait a couple more years to transfer it back out to Dres. With that decision, the Elcano crew began immediate preparations to transfer to Dres. They sent the spare parachuted rover and remnants of the recovery vehicle on a burn-up reentry back into Duna. Julella plotted a course while Obemy warmed up the nuclear engines. Meanwhile, back on Kerbin, the KSC crew cobbled together a recovery vehicle using existing designs. When the news media asked how the engineers were going to get the recovery vehicle there so quickly, a KSC engineer was quoted as saying, “more boosters.†“Whoosh†is about the only thing that seems appropriate here. When asked if this was overkill, a KSC engineer was quoted as saying, “Yep, it sure is.†Here's the rest of the transition, but not the Dres Elcano. Stand-by for another post...soon. Cheers, ~Claw

Actually I've done this already in 1.0.4. Turns out with all the work on 1.0.5, I completely forgot to post it. Think I'll go do that now... Thanks for the reminder! Cheers, ~Claw Edit: And here's the mission report.

The SPH assumes a about 5 degree angle of attack, whereas the VAB assumes 0 degrees. They are both correct. You can rotate the plane about 5 degrees nose down in the SPH, and you should see the CoL match the VAB (or vice versa).

You'll have to update to 1.0.5.1028 (the most recent). That will fix the issue.

It's a precision issue inherent to the way floating numbers in computers work. Although generally orbits below 100km are less stable. (Yes, I see you are at 120km.) If you are waiting for the mapping, time warp also makes the orbit more stable.

Yes, I would definitely check in the new version. Body lift was inadvertantly turned off in 1.0.5.1024. That's been fixed in 1.0.5.1028. That can have a huge impact on large designs. Other than that, drag was increased a bit at higher altitudes, and (I think) degreased slightly at lower altitudes. At least for fast flying stuff. Although I can't imagine that would cause such a drastic effect as what you are indicating. Cheers, -Claw

Yes, the achieved info will be in the message center. Once you have discarded those messages, the only place to find the info is in the save. There isn't an in-game interface. Cheers, -Claw

It will always be able to heat to at least it's target temp. The current temp and target temp is annotated in the right click menu. (For example: 500K / 500K) It's supposed to be about two small radiators for a drill, and maybe four for the miniISRU. Though I've noticed that if you have lots of hot parts, you can get away with fewer radiators than if you added each individually. i.e. 6 drills don't seem to require 12 small radiators. About the enter key, must be something with your browser. Did you change or update recently? Cheers, -Claw

Yeah, a screenshot of the situation and contract, or the save itself might help. If it is a bug, then it also helps to have the save so I can feed that info back into the tracker. Cheers, -Claw

Well, that's just an easy ModuleManager file to create (which, ironically, I just did away with). However, I think I've seen a mod like that already, though I don't recall the name. Indeed. Plus I was able to shed ModuleManager, which slims things down a little. I think the .zip is about 46kb now? Cheers, ~Claw

Do tell. And if you have an example, please share. Kerbals being knocked out of seats was fixed, but there might still be problems with kerbals who are knocked-out, but are still attached to the seat. Is that what you are seeing?

They are in the "High Altitude Flight" node (300 science). I think it was in the "Supersonic Flight" node before. Check there again, and if you are on steam, try to verify your game cache. Cheers, ~Claw

Version 1.0.5a.1 is released (compatible with KSP v1.0.5.1028). IMPORTANT: With the release of KSP 1.0.5, StockBugFixModules and StockPlus has undergone a major overhaul. Many of the fixes from the last StockBugFixModules release have been incorporated into Stock KSP. The primary fixes that are still needed are SymmetryActionFix (for symmetry problems in the editor), PilotRSASFix (to help with advanced Pilot abilities), and ModuleProceduralFairing (fixes some issues in the editor). So for many folks, you might not even need this anymore. !!! Please delete any old installations of KSP-Stock-Bug-Fix-Modules before installing. !!! 1) Unzip the zip file to the KSP/GameData directory. 2) During the first launch of KSP after StockBugFixPlus installation, a GUI will pop up asking you to configure the StockPlus options. 3) Save your settings and enjoy. NOTE: Do NOT delete StockBugFixPlusController.dll. None of the modules (including fixes) will function without it. Press MOD+F8 to bring up the GUI any time in-game. Some setting changes will require a scene change, but none require a KSP restart. With this change, settings will now be persistent across add-on updates. Pic of some of the StockPlus options, and the GUI. Cheers, ~Claw

Added to StockPlus, and the bug is fixed. Fixed, thanks! Yes, so I've updated ModuleGimbalPlus and PilotRSAS fix. They aren't fool-proof, but might help (and unlock some adjustable parameters) with some of the trickier designs. Done. Now goes from 0.1 to 3. Indeed. Many of the fixes are now obsolete, and the old modules consist of only StockPlus elements. (OP is updated, but an update post to come shortly.) Done. You can now tweak forward stiffness, as well as side stiffness. Thanks for the compliment. It's disabled by default because it was causing serious issues for people who aren't looking for that sort of controlability in their simple rocket designs. To the point that some folks were posting to the support forum. My aim is always non-intrusion. Perhaps (with the new GUI) I can make this a toggleable default. Ah good catch. That was old info, based on an earlier release. Though that section was just removed with the 1.0.5 compatible release. I suggest checking out the [b]brand new release![/b] (Keeping my fingers crossed.) Expect more info and further updates to come. Cheers, ~Claw

Assuming you can repeat the behavior with a specific ship, it might help if you can post the .craft or the save file for us to take a look at. Cheers, ~Claw

Ah yeah. I forgot that got added. (Though I think it's not just "IntakeAir," but works all the same.)

If it happens again, please keep a copy of the log file. We can't even begin to guess what happened without more information. And I'm sorry you lost your work. I know that can be very frustrating. Cheers, ~Claw

Yeah, it's an "off and on" problem because the decoupler is physicsless.

Ah, so I think maybe your post is better summarized as "Please add an authority slider"? Vice "there's a problem with the Big-S Elevon"? If that's the case, then yeah, I can agree with that.

It was intentionally hidden. Because IntakeAir is generated and consumed in the same frame, it can be misleading because IntakeAir may look full (am I using any?) or because it's showing empty (I have none, why is my engine still running?). Also, open/close on the intakes pretty much does nothing for drag now. It's no longer part of the new 1.0 aero model, so closing the intakes doesn't save you any drag. And IntakeAir isn't something that can be spammed up anymore and feed an engine well beyond it's service ceiling, because that was also changed in 1.0. It would be helpful to know if you're supplying the full demand to the engine, but the existing resource system isn't set up well for displaying that sort of information given the way IntakeAir works. I'm not sure if there's a better way to do it, without a rework of the resource code. Cheers, ~Claw

Top speed is pretty high now, though control turns out to become a bigger issue. I can't exactly say how high, because whatever I say...I'm sure someone will find a way to blow that speed out of the water.