Starwaster

More like 6.25 not 5. 160 units = 1 cubic meter. So, a resource with a density of 0.00625 (water) = 1 metric ton = 1 cubic meter. (water's special that way)

Look at all the pictures, not just the ones where he's been editing stuff. In that final on he's got it up to 5k delta-V. TWR should be ok too. Unless he's using thrust corrector, in which case it would be lower in atmo than Mechjeb says. mwlue, out of curiousity, ARE you using Thrust Corrector? Edit: Oops sorry, Watched video, you are turning a bit early. But the main problem is that your TWR is a lot higher at that altitude because you've burned a lot of fuel. Where it says 'limit acceleration to' change that to 20.

Or use the Fuselage Fairing that has no decoupler at all, but yeah.

Wow, let's also only launch rockets to Kerbin. That will DEFINITELY make things a lot easier!

Yes, there are situations in which autostaging will do that... but I forget what exactly if you provide a full list of your staging or a picture showing it we might be able to figure out where the problem is. bottom line is that there's something your staging that's confusing it ... (that doesn't necessarily mean that you have bad staging though that could also be the case)

Is anyone working on a next version?

Pretty sure the connector will give way before the winch, or maybe neither will. Only options I see are to smack it off with something heavy. Bring something alongside like maybe a big orange tank with some reaction wheels and a remote control unit then line it up and pitch forwards or backwards and just smack that sucker off. Other option is go back to editing the persistence file but instead of deleting the part, change it to something else. (and be sure to delete the modules on the part so that it stops thinking it's a winch) The reason why it failed is probably something like this: srfN = None, -1 attN = top, 1 attN = bottom, 3 I'm not 100% certain but I believe that the last digit indicates the the part number on the vessel. By outright removing a part you changed the ordinal position of every part after it. In the above example, this happens to be part #2 (first part is #0 btw) and part #1 is attached above. Part #3 is attached below. Lets say your winch was part #13. The part that it's attached to would have one of the nodes having the #13 at the end. Say you had it attached to one of those adapters that lets you surface mount (winches aren't surface mountable are they?) The adapter piece might say something like attN = top, 13. But you deleted it so now something else is #13 and it confuses the hell out of KSP because basically everything after a certain point can't be logically connected in the way that they say they are. Make sense? You'd have to go through and re-number everything with no margin for error. Edit: actually I lied, I am certain that's how it works.

What software are you using to try to make them with? Do you have photoshop? If so have you tried the plugin released by nVidia that creates normal maps? (uses any image you supply it to create a normal map. Desaturated images work best)

LANTR LO2 mode is optional. Like high and low gears. Meant to be used when thrust is more important than Isp. The LVN is NOT a LANTR. It runs that way all the time and its Isp is way too high to be a LANTR running in LO2 mode. (a value of about 647 would be a lot closer for a LANTR running on O2 which it actually injects into the propellent stream as it passes into the nozzle) The truth is that they didn't want to make a new fuel tank. They say as much in a comment found in the part.cfg file for the LVN // Yes, I know this is wrong. NTRs don't actually burn fuel and oxidizer, but we don't want to jump into making separate tanks for the two yet. Its stats also are closer to the old Pewee NTRs test fired back in the 60s.

Yes, it does. Well, it cancels MOST of it. There' s a definite damping force at work such that I find it necessary to put sepratrons or other retro rockets to blast those parts free.

Just remember to flip it back when you're finished, so that the holes on the bottom are pointing at the ground or you will not go to space today.

Or that could be triggered when a certain stage triggers

Why should force roll help with that situation? That's not what it's for. Yes, by all means change the Tf setting. Force Roll affects only roll, not yaw or pitch. The final effect of Force Roll are noticeable after it has finished all maneuvers. It's easiest to spot for the prograde/retrograde & normal orientations. When in orbit around a planet you will notice that with Force Roll set to 0 that the 'top' of the cockpit is oriented away from the planet surface and the floor is pointed at the ground. It has a different meaning when the docking autopilot's 'Force Roll' is set. When 0 is set it will try to align the top of the port with the other port's 'top'.

Each habitable part might then require some sort of sanity or stress factor assigned to it, with 'pods' having the worst of it and larger ones like the hitchhiker pod being a bit better and greenhouses and the big 6 kerbal dome being a lot better. (I forget who makes them, same person for each one). (actually greenhouse isn't habitable I don't think but its presence could be a mitigating factor because it gives Kerbals somewhere to go to unwind and look at something green that doesn't remind them that they're locked up in a cannister with a bunch of other Kerbals)

before (working, peak, private, commit) 2924 mb, 3008mb, 2895mb, 3157mb after 2889, 2967, 2864, 2963 percentage drop 1.2%, 1.35%, 1.07%, 6.145% All in all, the actual drop percentage-wise isn't very impressive except perhaps for commit. (which in some ways is more significant as it translates to lessened 'paged' or 'swap' file usage) However a little harder to quantify is that load times between scene changes 'felt' more responsive. The numbers above might actually have been a little worse for 'after' because I pushed things a little more than 'before' to see if the superior load performance was placebo or if it was real. My testing procedure in each case was 'start ksp, load saved game, enter tracking station, exit, enter VAB, load each page in each parts category, exit VAB, enter tracking station, visit ship. 'before' this last took ~30-45 seconds. After it seemed more like 15 seconds. Or less. So, actual memory usage, little improvement except for commit. in-game it just feels faster and it's harder to place a numerical value on that.

@TANK_DEFINITION[Monopropellant] { TANK { name = TestResource2 } } That's what the @TANK_DEFINITION does. It means 'at TANK_DEFINITION[Monopropellant] insert TANK{<tank stuff>}' In other words, insert our resource into the Monopropellant tank definition.

Not really, seems pretty smooth to me. Any lag I attribute to the 69,105 pieces of debris in orbit around me, some of which I have actually watched whiz past at extreme velocities within visual range.

It looks like it would make a nice greeting card!

I'm pretty sure we can quickly write up a ModuleManager + ModuleManagerExtensions config that quickly checks every part and module and everywhere it finds externalToEVAOnly = true it sets it to false. Is that an idea?

Crap! So I guess it's bad that I keep zero'ing that field out, huh?

I blame it on Force Roll. Or at least it seems to me that it's less likely to behave that way when I have it off than when I have it on. How does that mesh with your experiences? (Force Roll should definitely be the lowest priority when MJ2 is aligning to any node seeing as how it becomes a trivial matter for it to achieve after alignment is complete) Under Attitude Control, try adjusting Tf. For large ponderous ships set it to 1. It will make its maneuvers less aggressively, more gradually. @Sarbian On the subject of Attitude Control and the Tf setting, those settings really need to be saved per ship as other MJ2 modules are. It's too easy to forget that I need to go and change that setting every time I change vessels.

^^^ THIS ^^^ So important. For MJ users with large unwieldy rockets, it's about as important as the 'prevent overheating' option. You should have those set even if you're flying on manual control.

But isn't it really just passing through the node back to MM when it finishes determining how many nodes need to be applied? Shouldn't it just work if you pass :Final through with the rest of the node? (assuming that :Final was present to begin with) btw, glad to see you're still here, I thought you'd left us to go on vacation

Wow, loved your story about Dres... I swear I could almost hear the screaming myself. Dres... attempt no landings there...

I'm not currently using FAR so I can't check right now, but has anyone checked the config file(s) actually responsible for adding FAR modules?