Starwaster

Suggestion: Make a Module Manager patch that people can put in their GameData folder (or subfolder of GameData) so that they don't have to edit files.

Here is a backup link to Module Manager 2.5.6 github.com/Starwaster/ModuleManager/releases/download/v2.5.6/ModuleManager-2.5.6.zip Source https://github.com/Starwaster/ModuleManager License reminder: CC share-alike license I will likely create a new thread as the future seems a bit unclear at this point for the fate of this thread.

Please provide your log file. Read the thread at the following link for instructions on finding your log and how to make it available to us. http://forum.kerbalspaceprogram.com/threads/92229-How-To-Get-Support-READ-FIRST Also, where is your KSP installed? If it's in Program Files or Program Files (x86) then you should move it out of there. I keep my KSP installs in c:\Games which is a folder I created expressly for that purpose. You might want to try that before going for the logs. If it still happens, logs.

Those ports are not compatible by design. You can't dock with them. Two different designs

Do the Venusians look like this?

Your trollish disruptive messages got deleted because they have no place in a thread that exists to support users of Module Manager and and its further development. You're not going to get your way so get used to the cat or go recompile it for your personal use without the cat.

Maybe that part needs heat shielding, or a nose cone with heat shielding. What part is it?

Ok, I think I figured out what happened to the recycler. It's linked to a fix for another generator bug I fixed. So undoing the fix.... have to see how bad the damage is. Yeah, I know that some descriptions need updating. Also, please note that in the case of stack mounted tanks versus radially mounted tanks that the stack mounted tanks are going to have more mass. They are load bearing structures. The radially mounted tanks don't bear load.

Not to worry though! As long as the capsule survived, there's nothing that a damp sponge and a bucket can't fix inside...

At what orbital point are you trying to adjust your inclination? It matters. You want it to be either the ascending node or descending node. Which one doesn't mostly matter. Mostly.

eddiew, make absolutely sure that you properly downloaded and copied the the dll from the github site. It's this one right here: https://github.com/ferram4/Kerbal-Joint-Reinforcement/blob/master/GameData/KerbalJointReinforcement/Plugin/KerbalJointReinforcement.dll Delete the old one first to eliminate any chance of accidentally not copying over it. (even I made that mistake just the other day testing to see if 3.0.2 fixed a problem with the SDHI service module getting stuck on decoupling) (Spoiler alert: It does.)

Don't forget though that entry angle is still a factor. If you come in steep, you have less time for aerobraking and may well still be supersonic when you reach deployment altitude.

Also, see the first post for some heat shield pack links. The ADEPT is a deployable high drag shield like the inflatable. Only it looks nicer and doesn't have animation issues that confuse the animation module. No really, it looks really nice.

Right, air density is a factor, otherwise we couldn't deploy stuff like this on Mars. (which is where I presume they're planning on using that given the high altitude testing)

Wow, I thought you were talking about its terminal velocity on Mars. I would suggest you post those in the FAR thread, but I see that Ferram has already seen and commented.

Guys, don't bug Chris about DRE issues please Regarding chute opening velocities, IRL you're not going to open a chute at supersonic speeds, at least not over Earth and certainly not with something as massive as a space capsule. Not a drogue chute or the mains. They'd be ripped apart. And if you opened them at the altitudes and speeds that you're used to (that you're allowed to) in a non-DRE environment they could burn up, exposed to temperatures measuring in thousands of degrees. as for the utility of drogue chutes, the importance of them in KSP (regardless of any mods currently existing ) simply doesn't match real life. They've never been particularly important. Maybe some day that will change, but right now neither RealChute nor Deadly Reentry treats drogues and mains differently nor are their RealChute materials treated differently with regards to durability. So, TL;DR, Deadly Reentry restricts chutes to subsonic deployment, just as they would be IRL. (low pressure / density atmospheres generally allow deployment at faster speeds, so you could so a hypersonic chute like with Curiosity)

All pre-existing craft with Real Chute parts (the SDHI Paradock uses RC) will have the same chute parameters they launched with. All saved craft have the same chute parameters they were saved with. Meaning: If you launched it and you found out the chute has problems OR You saved the craft when the chute had problems THEN No files you download will help that craft. (any files that change how the chutes work will only affect newly launched craft) No files you edit will help that craft. (any edit changes will only affect newly placed chute parts) If it is a craft in flight then you are going to have to manually change that chute's parameters by right clicking on it in-flight and clicking Get Info. Then change the sliders until its predeployment / deployment numbers are where they need to be for you to land that craft. If it was a saved craft then you either need to fix the chute part's chute parameters OR you need to delete the chute and replace it with a newly placed chute part.

Which fuels specifically are you saying should be affected and what exactly are you proposing be done to them?

Now that's just sad that a person can't provide feedback without this kind of response. I do think his feedback was a little rougher than it needed to be, but surely you can provide a better response than just 'don't install it if you don't like it'. But you shouldn't suppress feedback like that.

I told you the only thing I know of that would do that. Question: Is this the same craft as before? Changes to RealChute configs don't affect existing ships. And I think they don't affect craft files either. So any existing craft are going to have be landed somehow and any craft files you will have to remove the chute parts (the SDHI port in this case) and delete it. Then replace it with a new one. (from 'inventory' as it were)

Ok, I get it. I've been playing with that part for a few hours now and it's producing O2 even with all Kerbals evacuated from the ship. Can't see what's changed in the generator class that would account for it and I don't think I changed the config either.... Edit: I basically have a docking port attached to that part so I can dock and undock from it. I hacked the save file to remove ALL O2 from the pod and from the recycler and I undocked. And it's producing O2 with no CO2 and no electricity either. Wow. (I can attest to the fact that it has no CO2 because the recyclers are going to lose their CO2 storage capacity in the next update. They'll be like their O2 storage counterparts but with less O2. Basically the total storage they had before is all O2 now)

They had some issues, but I tested with them and didn't have any ill effects happen, other than what you'd expect from lack of struts in key areas. Nothing that was an issue in MechJeb interaction. I'm not using too many struts these days myself though. In fact excessive numbers of struts can sometimes cause worse problems than they solve. I had one craft that I downloaded from the net that when launched just led to cascading structural failures and the more struts I added to fix the perceived problems, the worse it got. I think I fixed it by reducing the struts to key areas. And I'm getting off topic a bit, but lately I've been experimenting with dephysicalizing all decouplers. Except for separators they don't really contribute anything by being separate physical attachments. Most of my rockets are as rock steady as with KJR and launches as smooth as a baby's bottom.

Well if that's truly the case then it doesn't matter if the poll is biased or not. If I take the last few posts at face value then BTSM players essentially exist in their own world and no changes I make to the configs will affect them since FlowerChild is overriding them with his own to fit the BTSM world. In fact I suppose it's better if they don't respond to the poll since I'm only looking to see what kind of impact any config changes I make will have players.

It's in your log file. It lists your mods. And if those mods want to log any debugging info that's in there too. That's why modders want the output_log.txt (or player.log if Linux/Mac)

MechJebFARExt is throwing exceptions I don't think that's the issue because it's pretty much all internal to MechJeb and it's trapping the errors and reporting them after. Your launch clamps report being activated; no logging of them being destroyed or anything else happening to them. (activated just means they were loaded in and turned on... so to speak. Doesn't mean they disengaged or did anything in particular. Every part that loads in does that) You might want to try removing StickyLaunchPadFix and trying again. I have nothing solid to base that on, there's no errors or anything logged about interaction between the two so it's just a hunch really. That's all I got right now.