Claw

If we want to split hairs then sure, Laythe is a moon and not a planet. But he also asked for interesting places to visit. "Most" is a subjective qualifier to which I specified as "A lot of people enjoy..." - - - Updated - - - Nice shot. Two thumbs up! (Although it looks like your lander is hovering ever so slightly. )

The problem with KSP is that you can't store fuel in the wings like most real planes do. Since the fuel is mostly in the fuselage and the engines can be quite heavy, you run into problems when the fuel drains.

I suppose that's why I offer it as a suggestion of something for Squad to add. The way the part is handled probably needs to be modified just like a fuel tank to allow tweaking of load and not just capacity. Tweakable isn't my favorite option. I think I prefer the popup idea. I'm also still not a fan of saving a specific roster in the save file. What do you do then if one of those kerbals isn't available? Now you're back to a list of rules that may or may not fit what the user wants. Leave it empty? Put somone random in? Flag it for popup?

A lot of people enjoy Laythe due to its island/water terrain and ability to support jet aircraft.

This is probably an issue with KSP. There are several craft destroying bugs going on right now that haven't really been sorted out yet.

I was thinking the same thing. But then again my little green guys, who sometimes spend years in a space suit, seem less concerned about this.

I've become a big fan of this one. Although it is split so much that sometimes it's tedious to do all those calcs. (I know, it's a rough life... )

It's okay, that's why we are all here, to help eachother out. Like when someone is looking for their glasses while they are wearing them.

Marky, your methodology is on the right track but you have to account for the fact that the gravitational value (9.81) is not constant. --- This question comes up from time to time. Deorbiting from a lower orbit is always cheaper dV wise than deorbiting from a higher orbit. That's all assuming you execute everything perfectly. DeMatt said it right. Killing orbital velocity will take less dV at the higher altitude. However, the dV to stop the descent will be more. When you look at the differences, the extra dV needed to stop the higher descent is more than the extra dV to kill the higher orbital velocity. That being said, killing your orbital velocity and dropping straight down is not the most efficient deorbit method. But from your two options, the lower orbit takes less dV. None of this discussion takes TWR into account...

You are very welcome. Parasitic drag is drag due to air flowing over the surface of an object. For example, a flat plate going through the air edge first has less drag than when it goes through face first. And a ball has less drag than a cube. Induced drag is a byproduct of creating lift. Some component of the lift is always acting opposite of the direction of airflow. As AoA increases, more of the lift vector points backward which effectively acts as drag. I don't have the equations with me at the moment, but I can post them later if someone doesn't beat me to it. I actually didn't figure out the equations, but several other forum members did. I am very confident squad will update the aerodynamics. The game is only v0.23.5, so there is certainly a lot of work to do. I'm happy enough with the way stock aero behaves now that I accept it's faults. FAR fixes your two big complaints. Use it if you want, ditch it if you don't. Some people get so angry with stock aero that they wouldn't even play without FAR. I suppose I'm a little more forgiving. I avoid mods too because I grew tired of crashes. Also, I didn't want all of my craft to be at the mercy of waiting for mod updates, especially when the game updates. All I use right now is MechJeb and Kerbal Alarm. Ironically, MJ is causing me grief at the moment in v0.23.5. Don't get me wrong, there are a lot of awesome looking mods out there and I don't want to belittle anyone. I just seem to crash a lot more often with the ones that I did try.

Seems to take me about the same dV it always did. Although I haven't been building much yet with the new large parts yet, so maybe there is something wacky there. BTW: MJ and KER are supposedly updated to take massless parts into account.

Heh, strange. I guess the auto-fill code is more picky than I thought. More reason to have some sort of pop-up or tweakable.

- Parasitic drag doesn't depend on AoA, but induced drag does. - There is a lift bug with control surfaces. Their lift increases all the way to 90 AoA. - Lift production is dependent on arspeed, AoA, and air density. The equation is consistent throught the flight envelope. So no, the center of lift does not move (unless you envoke the control surface bug). I have equations if you really want them. - Drag (as the wiki shows) is a weighted function. Basically part mass times the drag value. So things like nose cone drag are vastly overshadowed by fuel tank drag. - Part drag is independent of placement. So big flat pancake rockets have the same drag as tall sleek rockets. In my opinion, KSP does a reasonable job of approximating aerodynamics enough to have reasonable aircraft behavior. It does have some quirks and a limited flight envelope (super and hypersonic aren't really modeled), but it does okay. I run all stock aero, but most people who want "hardcore" aero use FAR.

I'm okay with that. Limited fuel while on EVA and returning to a capsule seems handicapping enough for gameplay.

Yeah, sorry. I meant capsules. I don't think lander cans auto fill either.

Having it tied to the save state of the ship introduces its own set of problems too. What do you do if you saved the ship with three random kerbals? Do you replace them with Jeb, Bill, and Bob on the next load? Or with the original save crew? What if they aren't available? The only way to be sure to get what the player wants is to force-ably interrupt and ask. But you have to ask in a way that isn't overly annoying. Having a pop-up window forces another click, but then you'll have the right crew. Double-click and you bypass that nonsense and take the last setting you had (before the revert if that's what just happened).

I've already done that. I've also deleted and reinstalled MJ multiple times as well as redownloaded in case it was corrupted in someway. The crashes are happening on brand new save games in career and sandbox. In any case, I messed with my GUI a bit which fixed some things. The game still crashed but at least the log gave more info this time. In case this means anything to you MJ gurus out there. [HighLogic]: =========================== Scene Change : From FLIGHT to EDITOR ===================== (Filename: C:/BuildAgent/work/d3d49558e4d408f4/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 53) [Orbit Targeter]: Target is null (Filename: C:/BuildAgent/work/d3d49558e4d408f4/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 53) ArgumentException: An element with the same key already exists in the dictionary. at System.Collections.Generic.Dictionary`2[Part,MuMech.FuelNode].Add (.Part key, MuMech.FuelNode value) [0x00000] in <filename unknown>:0 at System.Linq.Enumerable.ToDictionary[Part,Part,FuelNode] (IEnumerable`1 source, System.Func`2 keySelector, System.Func`2 elementSelector, IEqualityComparer`1 comparer) [0x00000] in <filename unknown>:0 at System.Linq.Enumerable.ToDictionary[Part,Part,FuelNode] (IEnumerable`1 source, System.Func`2 keySelector, System.Func`2 elementSelector) [0x00000] in <filename unknown>:0 at MuMech.FuelFlowSimulation..ctor (System.Collections.Generic.List`1 parts, Boolean dVLinearThrust) [0x00000] in <filename unknown>:0 at MuMech.MechJebModuleStageStats.StartSimulation () [0x00000] in <filename unknown>:0 at MuMech.MechJebModuleStageStats.TryStartSimulation () [0x00000] in <filename unknown>:0 at MuMech.MechJebModuleStageStats.RequestUpdate (System.Object controller) [0x00000] in <filename unknown>:0 at MuMech.MechJebModuleInfoItems.AllStageStats () [0x00000] in <filename unknown>:0 at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[],System.Exception&) at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 Rethrow as TargetInvocationException: Exception has been thrown by the target of an invocation. at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] in <filename unknown>:0 at MuMech.GeneralInfoItem.DrawItem () [0x00000] in <filename unknown>:0 at MuMech.MechJebModuleCustomInfoWindow.WindowGUI (Int32 windowID) [0x00000] in <filename unknown>:0 at UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID) [0x00000] in <filename unknown>:0 at UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) [0x00000] in <filename unknown>:0 (Filename: Line: -1) ArgumentException: Getting control 4's position in a group with only 4 controls when doing Repaint Aborting at UnityEngine.GUILayoutGroup.GetNext () [0x00000] in <filename unknown>:0 at UnityEngine.GUILayoutUtility.BeginLayoutGroup (UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options, System.Type LayoutType) [0x00000] in <filename unknown>:0 at UnityEngine.GUILayout.BeginVertical (UnityEngine.GUIContent content, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options) [0x00000] in <filename unknown>:0 at UnityEngine.GUILayout.BeginVertical (UnityEngine.GUILayoutOption[] options) [0x00000] in <filename unknown>:0 at MuMech.MechJebModuleInfoItems.AllStageStats () [0x00000] in <filename unknown>:0 at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[],System.Exception&) at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 Rethrow as TargetInvocationException: Exception has been thrown by the target of an invocation. at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] in <filename unknown>:0 at MuMech.GeneralInfoItem.DrawItem () [0x00000] in <filename unknown>:0 at MuMech.MechJebModuleCustomInfoWindow.WindowGUI (Int32 windowID) [0x00000] in <filename unknown>:0 at UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID) [0x00000] in <filename unknown>:0 at UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) [0x00000] in <filename unknown>:0 (Filename: Line: -1) [PlanetariumCamera]: Focus: Kerbin

You should be able to reverse your orbit at AP for double whatever your orbital velocity is at that point. So if you keep your AP really high, your orbital velocity will be low. The further your AP, the lower your velocity, the less dV you need. You double it because you basically kill your orbital velocity to zero, then set that same orbital velocity going the other direction.

I've noticed a bug with 0.23.5 running at max resolution (same as yours) and using the HUGE UI. When I get a chance, I'll see if that's the problem (as I'm guessing it is). Thanks for the help.

You know, now that you mention the display issues. I've noticed that with KSP + MJ, the clickable area on the buttons doesn't really line up correctly (I have to click low) and sometimes the text (such as the clock time) aren't in the correct place. So perhaps you are correct in that it's a graphics issue. Maybe just not a card issue. I'll try fiddling with the UI. I found another UI bug (unrelated to MJ) that might be getting triggered more often with MJ installed. Thanks! EDIT: On my 0.23.0 KSP, once MJ was acting stable I sort of stopped updating it. I was too afraid of breaking it. Oh yeah, and I sorted the event list like you said. I have zero display faults out of the 11,000 events logged.

Well thanks for the suggestion. I found the log as you described. Unfortunately, there are no video card related events in there. In fact, the only events in there are related to my network and are from several hours ago. I should have added that I can run Stock KSP fine. It does not crash in the same way as KSP + MechJeb (it has it's own brand of crashing). I was also able to run MJ + KSP 0.23.0 just fine. My crashes now are roughly 1 out of every 5 or so reverts or craft recoveries. Sadly the event log isn't really grabbing anything specific. Is there something new/unusual about recent MJ graphics? I see there are some icons now for the tool bar and I had to install MJ slightly differently than in the past. Is it possible I've messed up the install? MJ itself seems to function fine in-game aside from the crashing.

KSP seems to crash very frequently now for me when I use MechJeb. It was really stable in 0.23.0. I have KSP v0.23.5.464 with the latest dev build (221) and I'm crashing a lot. I had Kerbal Alarm installed, but have already removed it with no changes. The crashes mostly happen on scene changes such as reverting to the SPH/VAB or launching a craft. It also seems especially prone to crash if I recently visited the R&D facility. I also crash a lot when recovering Kerbals in career mode. Hopefully someone has a suggestion for this. I went back several pages and couldn't find anyone mentioning crashes, so I apologize if this has been covered recently. EDIT: I should say I use MJ mostly for information purposes and not the autopilot functionality. So I don't think this is tied to a particular mode.

They used to be physicsless in v.0.23.0. However, in v0.23.5 the "PhysicsSignificance" line is gone. I haven't tested it yet, so unless it's hard coded then they should have mass. EDIT: Hmm, interesting. I have to correct myself. I went and tested and the Small Gear Bay is indeed still massless in flight. It has been a while so I went back and looked. The part.cfg from version 0.23.0 also does not havethe PhysicsSignificance line. So it must be hard coded. So yes, the small landing gear is still "massless" in flight. Just note that the SPH will lie to you about the position of the CoM when you're building (like you said).

Here's a list of "physicsless" parts in KSP v0.23.5. http://forum.kerbalspaceprogram.com/threads/75951-PhysicsSignificance-related-problems?highlight=physicssignificance People say "massless" and "physicsless" sort of interchangeably. That's because there's a flag in the part.cfg file that says "PhysicsSignificance = 1". So in-flight, any mass is ignored. Hence "massless."

Hmm. While I can appreciate the idea of a realistic timescale, I too would find it very frustrating to timewarp simply for the sake of skipping to the point of rocket assembly. The game doesn't have the structure to allow a pipeline of rockets to be designed/fabricated. So we would be stuck with: "Design a rocket, sit and wait for it to show up. Now you can design your next rocket, and wait. Repeat..." Especially when you consider it can take years to design, build, and assemble a rocket. Although a lot of games work this way (wait for something to build), they aren't usually as flexible and open ended with design. Think of the pain if you realized at launch that you forgot to install that solar panel.... I'm guessing that Twreed87 is probably on the right track. Career mode will probably become time dependent due to budget implementation. On the other hand, I can see science taking time to fully research. A lot of games work that way. Although I'm still not sure about waiting over a year of gametime for one science node to unlock. That might make science a bit of a grind while you're waiting.