Starwaster

Minecraft didn't die. They still update it, at least fixing bugs for it. A cursory look tells me that at least some of the mods I used to play with are still updated. Do you mean that you just stopped playing because your personal favorite mod stopped being updated?

That's fully six TIMES longer than the shuttle's runway. What do you think you're going to land (or launch) that requires that much runway???? :confused::confused::confused::confused:

If you're going to make a statement like that, you need to back it up with something, at least some specifics as to how they're failing you. As I've said before, I've used these wings and they function fine. However, the fuselage parts have the lift modules on them so to rule out the possibility that I might have been fooled by the other OPT parts providing lift, I decided to stick some of the OPT wings and control surfaces onto non-OPT parts. In fact, I stuck them onto plain old rocket parts. No Mk2/Mk3 spaceplane, just big orange tank, a small gray tank with some lead ballast (it's Real Fuels). Four landing gear parts and a mess of intakes. Aside from having given it a long tail to increase stability, only superficial thought was given to aerodynamics. Center of Mass is horribly placed in relation to lift and it's a ..... to get airborne, but I blame the overall design of the 'plane' - I designed it to be deliberately flawed and if there was really anything wrong with these wing parts then it shouldn't fly at all. But it does fly and it maneuvers adequately in spite of having been set up for failure. So... EXACTLY what is the problem you have with these wings???

The wings/winglets/control surfaces are using the appropriate stock modules for aerodynamics. Not having Firespitter would have zero impact on the control surfaces.

The cause was MechJebRCSFXExt.dll which is an extension to MechJeb2 for when you have RCSFX installed. (it helps MJ be more accurate when using RCSFX) The solution is to update to the latest MechJebRCSFXExt

If you're having trouble with OPT control surfaces, you should specify which ones because I've used several myself and all of the ones I've tried so far are working just fine. The plane below only uses OPT control surfaces/wings except for its rudder

I haven't tested Real Heat without Deadly Reentry, but with Deadly Reentry, Kerbin still definitely requires care and planning if you don't want to burn up.

The PROPELLANT node inside the MODULE node for the engine needs to have a line that says resourceFlowMode = STAGE_PRIORITY_FLOW. Don't edit the part config file directly, make a Module Manager patch that does it. If you're not sure how, let me know Edit: Oops Sebi posted while I was typing. His suggestion should do it. @K.Yeon The config file for the Mk2 turboramjet is malformed with a mismatching bracket count. Not sure where the missing one is. I think it's an extra } after the ModuleLiftingSurface block because that engine lacks a functioning gimbal even though one is defined in the config. (extra } is also just in front of gimbal section so that's where the parser thought the part config ended)

It happens in the editor (VAB/SPH) - probably because SetConvectiveStats is trying to do something that only makes sense out in the world after FlightGlobals reports ready. There's an issue for this on the bug tracker: http://bugs.kerbalspaceprogram.com/issues/5169 It mentions a work around but I don't know what the work around is. (I just ignore the error when I don't have Realchute installed and it stops being an issue at all if RC is installed)

That would neuter heating and make it pointless. But if you want it to do that then it's just a few key presses and mouse clicks away. Alt-F12 to bring up the menu. Click Physics then Thermals. Increase conduction factor. (that will increase ALL conduction. Skin-Skin (part skin-part skin), Skin-Internal and part-part (internal).

The stock animators for both small and large Mk2 cargo bays were replaced with HangarAnimator. It does not have either open or close GUI event names and I do not know what HangarAnimator's behavior in that case would be. (that may not be relevant though: see below) (that info came from the MM cache file, which is why I now ask for it. Lots of information in there about what happens to your parts on modded installations) The main problem however seems to be that the Hangar.dll is not loading (from output_log.txt: line 2327-2339) AssemblyLoader: Exception loading 'Hangar': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded. at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0 Additional information about this exception: System.TypeLoadException: Could not load type 'AtHangar.HangarFilterManager+<add_filter>c__AnonStorey0' from assembly 'Hangar, Version=2.3.1.0, Culture=neutral, PublicKeyToken=null'. (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) Maybe a dependency is out of date or missing, but I think the error would actually tell you that if that were the case, and I don't see that...) I'd report this in the Hangar mod thread.

Sorry, but this isn't going to be able to go much further without logs. Please read this thread: How-To-Get-Support-READ-FIRST Find the appropriate log files (output_log.txt if Windows; player.log for Linux/Mac) and upload them somewhere you can link to, like DropBox. (hint: you really should use DropBox) Also include your ModuleManager.ConfigCache file from your GameData folder.

Correction on something I said earlier: Real Heat isn't altering the actual density of the atmosphere, only calculating its effect on heating differently.

Press Alt-F12 Click Show Input Lock Stack (under Cheats) Click Clear Input Lock Stack Then see if you can open the doors.

It's not just an issue with its altitude. That's not even the main issue. Raising the altitude of its atmosphere won't be as much use as reducing its density as I said before. Installing Real Heat will make Jool survivable and relevant for aerobraking because it reduces the density of the atmosphere and therefore rate of heat transfer is reduced as well. (and no planet's atmosphere has an obvious boundary. It simply becomes lower and lower in pressure until there's no longer any point in measuring it.) Edit: An example of a Joolian entry. As you can see from the altitude I've just hit the top of the atmosphere. Dynamic pressure is almost 14 pascals. 1 pascal is 1 newton of force spread over 1 square meter. (or 1 kg per meter per second). That's the benchmark for dynamic pressure for a reentry from a standard orbit around the given planet. There's not much point in in having the atmosphere any higher. Look also at the amount of drag currently being generated. There's reasons why it's as low as it is. Clarification: I mean reasons why the top of the atmosphere is where it is and it is because of expected dynamic pressure and drag at that altitude. Any higher and it ceases to be relevant in terms of drag.

Just set the epoch accordingly. At least that's how it worked pre-Kopernicus where epoch zero corresponded to a particular date... Time warping wouldn't break it

First, you're going to need some kind of heat shield on your craft for aerobraking / aerocapture at Jool. You're coming in way too fast to get away with an unshielded craft. Second, even with shielding you're going to have trouble because the atmospheric composition of Jool is the same as Kerbin, so the density for any given pressure value is the same which means heat transfer is going to be high. Jool should have a composition that is largely hydrogen and lighter gasses which means it should be less dense. KSP 1.1 should hopefully see some fixes in that area, but for right now there is Real Heat which has a more realistic atmosphere for Jool that you should find more survivable. (with shielding)

What exactly are you thinking the relationship is between heat shielding and aerodynamics is? Because I see none. None whatsoever. Either the the aforementioned craft does not have its aerodynamics properly set up or its tumbling should be considered a natural consequence of deviation, or both. (every aircraft is capable of being put in situations where it becomes uncontrollable or requires special recovery procedures performed to regain control) Edit: I see that DG is your mod. Are you making use of CoLOffset / CoPOffset in any of your lift / control surfaces? If not, then have a look at how that's done in stock parts and give some thought to doing that for your parts.

They can be, and technically they don't require Real Fuels. Only the Community Resource Pack for the hydrogen and oxygen. (could be gaseous or liquid; assume if liquid that it's converting to gases first)

Yes. (10 char)

The parts still work just fine, but there will always be those who if there is not continuous new development and/or developer presence feel the need to proclaim a mod dead.

When building the craft and placing the Real Chute part, did you use the editor (enable Action Group editor to see the chute editor) to apply settings? (after first making any desired chute changes) Even without specific configurations, Applying will ensure that you get a properly sized chute for the mass of what you want to land.

Most likely cause is MechJebRCSFXExt.dll. Remove it and it should go away. Then ask Sarbian to accept the pull request for MechJebRCSFXExt. (MJ accuracy should only be slightly degraded when using RCSFX without it. It will still do the job.) And StoryMusgrave, either be part of the solution or stop being part of the precipitate. That was zero help whatsoever.

Pretend you're an end user and install both plugins and then test them and then tell me there is not a problem. (spoiler alert: neither one works) And since you've given your plugin a landing on the forums, guess where the support requests are going to end up if people actually DO install your plugin? Except that you go days or even weeks without so much as a peep, so basically they're being hung out to dry. Your 'friends from forum' aren't giving you good advice.

I thought I'd share my OPT spaceplane with you: The Starseeker OPT (2nd one is a 4 engine variant with winglets) Through Real Fuels & my own personal MM magic, it uses Kerosene, Methane or Hydrogen Also, what looks like intakes on the front are actually forward facing thrusters for added braking power. Even the heaver versions can land at the desert temple and stop in a very short distance. (didn't that temple used to be on flat open desert...? So confused right now)