NathanKell

Ok, thanks to a conversation with asmi where he mentioned getting resources by Component, I finally figured out what's going on. PartResources are now added as components to the Part, and even if you remove them from the PartResourceList they get added back because the component is still part of the Part. So, fix: destroy the component when remove from list. Tested; works. Now we can finally go back to NOT nuking existing resources, etc., and all those NANs and phantom resources will go away.

Thanks! Oh, absolutely. It's just waiting on my finishing getting MFS working. There are prerelease builds of MFS and Realism Overhaul (and Stretchy) in the MFS thread, but no promises your save won't break again with the final.

It's because I haven't fixed DRE yet to notice RealChutes.

Dragon01: MFS is *almost* done. Also, careo just updated ExsurgentEngineering (see B9 thread) so that one is up to date. Or try dtobi's new one from Space Shuttle Engines? jrandom:

Fixed for .23

https://github.com/careo/ExsurgentEngineering/raw/master/ExsurgentEngineering/obj/Release/ExsurgentEngineering.dll Fixed link.

heatProduction in a ModuleEngines[FX] is only applied, lerp'd, when the engine is on. It shouldn't have anything to do with drag force. That the parts are overGing, then, implies that it's not the culprit. Kraken attack? KSP's G meter is weird... I'll check as soon as possible (and also fix it to recognize ModuleEnginesFX, and RealChutes). SirJodelstein: That's a KSP "feature": if the root part dies, so does that vessel. Frankly, I'm impressed the other parts didn't just explode; that often happens too. Use SelectRoot to make something survivable your root part.

With KJR, that's usually because breakingForce and/or breakingTorque is set too low. Can be true without KJR too though. I assume you mean "and shows as structural failure in the F3 log." If not, explain further?

Yeah, I think it's just they changed how to access AtmosphereFromGround. Dirt_Merchant: cool, thanks. The curve is in the format of a Unity AnimationCurve, that is, a cubic bezier that uses tangents rather than positions for the two middle control points of each segment. http://answers.unity3d.com/questions/464782/t-is-the-math-behind-animationcurveevaluate.html My first experiment using tangents ended badly (solar panels) and I haven't had a chance to play more with them. You'll probably want to use either Unity's curve editor, or MuMechCurveEd ingame, to get a visual of how the curve looks.

Elan: Regarding 2. Here's how you use an interstage adapter. 1. Grab proc interstage adapter 2. Place the floating node on the bottom node of the thing you want to decouple from / adapt to (i.e. the bottom of your engine, or, if multiple engines, the bottom of the tank on which the engines are mounted) 3. Hold down H and mouse over the adapter to move it down as far as you want 4. Hold down N and mouseover to make it as wide as you want (you may have to place the thing you want below the adapter first, in order to see what width is desired). 5. Place ONE side fairing on the ring, so you can see the shape 6. Use J and Y to adjust shape 7. Remove that side fairing and re-add in symmetry. 8. Readjust using H,Y,J,N until everything is as you like it. 9. Adjust staging so that when you want it to decouple, you have both the fairings and the adapter's own decoupler in that stage. NOTE: The decoupler in the adapter itself does NOTHING, it is only there for compatibility with KER and MJ. What _actually_ decouples the floating node is when you decouple those side fairings (the stuff above the adapter is hanging in space supported only by the fairings...)

Huh, weird. Ok. Sorry 'bout that then.

It doesn't. But I'd think that anything Taverius did for TVPP, he also did for B9.

Weird, because there _is_ no model.mu in that folder. At some point you changed the mu file's name but didn't update the cfg. (the mu file *used* to be named model.mu.) Does it just grab any mu file then?

How is it incompatible? Especially since Taverius is coauthor of B9.

Yes. It's a bug in the new tooltip system.

Well, Pollux is actually a different solid stage. So that might be confusing. Why not call it, oh....the Castor 30?

Will do. I'm sure it's just I'm not grabbing the right objects, since looking at the public vars in VS shows the class looks basically identical to that in .22. If you're quick, you can probably do it during the load screen so the view in spacecenter is correct?

Speaking of bugs. LFE4X800Mini has no TechRequired line by advUnammned. Mercury LES has a mesh line that doesn't point to its model. (should be mesh = Mercury_LES.mu right?)

No longer the appropriate folders. The appropriate folder is "GameData": stick your MechJeb2 folder there. Installing mods changed in KSP .20, and it's been "dump me in GameData" ever since.

Most pretty! Also, we were going to catch up at some point about RealFuels-ing Ions?

Nova: Re: saves. Explored; it's HighLogic.CurrentGame.Title Re: AFG. Ah, I and Starwaster can walk you through it then if you want, at least as of .22; haven't dug into any .23 changes yet. There's a default somewhere-around-1.025x scalar used, but you can override it. Check the AtmosphereFromGround code in RSS; Starwaster even wrote a GUI so you can play with it in realtime. Err, well, on a .22 copy of KSP.

Oh, that one. Yeah, I walked Hodo through changing the transforms so that you can use ModuleEnginesFX and the native switcher. It's true that MFS right now doesn't notice a second engine. I need to fix that. Sky, I'll see what I can do.

jrandom: weird re: gauges. And how are you getting 3 of them? Re: B9. I will check; I didn't do anything to the old SABRE file, so I don't know why that would be. But basically, while I hoped to have full support for air-breathers in v4, so much time on .23 compatibility that it's not coming yet. (Hey, I do support velocityCurve techlevels now, at least!)

It's only got a couple changes over 1.5.5, which has been rock-solid for a while.

rbray: bac9 is talking about shader-based procedural noise, not making a single prerendered texture and using that. Totally different thing (and it's both better looking and saves on memory--especially since KSP is CPU, not GPU, bottlenecked, so shader-side stuff is comparatively cheap).