Starwaster

WOW. Well at least I'll know where to go next time I need crucifying, so, thanks for that

If a part (control surface with the FARControllableSurface added) has animated flaps, how might I make those flaps useful? I want to increase both its lift and drag, right? There doesn't seem to be a way to just configure a control surface to arbitrarily add lift/drag.... unless maybe I just altered its parameters when it's animated. (I can do that with DREC's ModuleAnimation2Value) But what would I change? Increase MAC to reflect the increased length and decrease e to increase drag? Am I correctly interpreting the results of those actions?

Is this a deliberate suborbital or an accidental one that you're trying to survive? If the former, add extra heat shielding or better shields if they exist. If it's an accidental one.... you might try burning +radial, I've had some luck that way with capsules that had a bad reentry and I needed to modify their reentry angle. Also don't forget using lift to keep your capsule in the upper atmosphere longer. Angle your nose up.

I suggest that in the real world, the kind of accuracy that MJ has for stock drag is impossible or very difficult. For exactly the reason you just cited. Even returning space capsules have to accept a certain amount of inaccurate predictions. The only ones that don't have to accept inaccuracy are those that can control their descent, like space planes/shuttles, or reentry vehicles like the one Curiosity had that could control its descent by pitching/yawing of its aeroshell with RCS thrusters. (that only allowed it to narrow its landing area down instead of giving pinpoint accuracy) So, suggestion #1: With FAR installed, abandon all notion of accuracy. suggestion #1-B: Accept that it's ok for MJ to become inaccurate when FAR is installed. Discarding those notions will let you move forward. suggestion #2: This is the hard part because I don't know if FAR actually has provisions for you to query it as to drag for different orientations but you would query it twice for two orientations. One oriented along its -y axis and one for +z. (if possible to differentiate between space planes and capsules, you'd want +y but I dont know how you'd determine that) Either you average your drag result to return your predicted landing site or report your landing site as a range using the difference between the two drag results from above.

The problem with the direction is that you only get that 25% when the bottom surface of your plane is completely perpendicular to the velocity vector. You literally have to come in with a pitch of 90 degrees. At a standard space plane reentry posture you'll only get half of your rated reflectivity. Which is still fine for stock Kerbin and default DREC settings, but if you increase the difficulty for Earth scaled reentry heating, you will notice the difference. (the tip off is burning insulation and Kerbal flesh) direction 0, 1, 1 is better and more realistic Edit: Oh and your 0, -1, 0 actually has another problem, which is that it points towards the back of most fuselage parts instead of their belly. You'd actually want 0, 0, 1 for your version Kit: What do you mean it's not working? Have you actually tried the shields in flight? It's not likely you'd notice a difference otherwise

That's ok, it has enough separated in the other parts (rudders / nose) that it can throttle back the parts it needs. The game might not be that clever but MechJeb is. It also occurs to me that we need a plugin to shift CoM (bound to action group) You know, to simulate pumping resources or moving / ejecting ballast. Surprised nobody's made one yet. I might have to....

Crap, I forgot about that. Do you use MechJeb? If so, turn on RCS Balancer. I didn't even notice there was a problem because I nearly always have it on. It automatically throttles back RCS based on distance from CoM. The further it is away, the less powerful it needs to be. (although, I've had problems with RCS for everything after build #256, even with properly balanced RCS so #256 is what I use)

There's been some stuff written on it for the wiki. Check front page for link. First post.

BTW, you want to talk BRUTAL? KSO25 + RSS + FAR + DREC MY. GOD. I'm having a devil of a time coming up with a reflective only set of configurations that can survive. I'm having to crank it up to 90% reflectivity and I'm still losing bits. Nothing important; just stabilizers, wings and landing gear. Part of the problem is the FAR configuration itself I guess, took some tweaking on someone's part but it's a pain keeping the orbiter at a decent configuration. I have a mess of Kerbals on sub orbital right now who are waiting for me to come back with a decent config that will get them home. I'm reminded of that scene from Serenity actually... "Just get us on the ground!" "That part will happen pretty definitely!"

I've gotten better because of this pack. It made me want to build spaceplanes, real SSTO space planes and I so I dared where I had never dared before. Remember, failures are just data. You HAVE to learn from your failures; you don't have a choice. Your brain was wired to be made stronger by anything that didn't kill you.

They work fine for me. Even the MechJeb RPM functionality works for me and it did not in previous versions.

add CoMOffset = 0,-3,0 (on KSO25_Cabin) caveat, will affect pitch trim. though interestingly, it looks like 14 degrees now than it was before. in the SPH anyway. not flight tested YET. almost was able to take off from runway so FAR glide ratio should improve. still testing using your FAR config that puts it just forward of CoL where it belongs on most aircraft and sorry softweir I missed your reply as I was composing when you posted, I guess. Does what I said above hold true for the shuttle's reentry CoM? Jus before CoL? And is it ok if it's displaced a little above, do you think?

well I also have DREC to worry about so angle gets more important I just thought of something I'm going to try right now: going to shift CoM back 2 m when FAR is installed FAR gets really upset if CoM is too far from CoL I also just realized this about your config: For the pass you should use :BEFORE[FerramsAerospaceResearch] or maybe :AFTER[FerramsAerospaceResearch] (sp?) and a :NEEDS[FerramsAerospaceResearch] so they dont execute if FAR is uninstalled?

Fine, I'll put another habitat in the cargo bay, but their blood is on your hands! May the god of unplanned disassemblies have mercy on your soul.

Pretty sure the answer you want is on the front page, first post, third paragraph, plain as day. I'm not not sure how we can get that information to people any plainer unless we use a flashing red neon sign Not to be mean but my mean bone is acting up and I'm down to my last nerve coming up with FAR and DREC configs that will let the KSO25 survive an RSS reentry. And I just witnessed 8 kerbals die. AGAIN.

Here's another question... how the heck do you maintain a 40 deg pitch angle through max Q???? Maybe it's a problem with the FAR config or maybe it's FAR in general. How did the space shuttle do it? Or should I give up on making a KSO reentry perform like the space shuttle would?

I think that's what they've done but it still gets shielded. Can I suggest an addition to FARCargoBayModule in the future? A list of nodes that FAR will ignore parts that are attached to them?

Is there a way to stop wings attached to a cargo hold from being shielded? Ideally, some sort of override? Or a way to mark designated stack nodes as never shielded? (this is for KSO25. Someone is trying to write up a FAR config for it. They've tried moving the nodes but sometimes it still seems to want to shield the wings)

You know what would be cool is if there were an override property you could set on a FAR module (wing/controllable/etc) that says 'never shield' Maybe there is one and we don't know it. Gonna check that out. EDIT: Just occurred to me that this could be why my KSO25 had so little drag. My BC was something like 40,000 at 54km altitude. I kept waiting for it to decelerate more and stuff started burning off. It was kind of frustrating because this was hours and hours of testing of my heat shield config that I'm working on and I even ended up tripling the values (because it was also RSS) and stuff still started burning off. I was left with just the fuselage coming up on 14 km altitude, still had rising heat problems and only decelerated to 3000 m/s. Now I see it, it was the dang wings being shielded. So concerned about the lift, I forgot about the drag.

Get this: http://forum.kerbalspaceprogram.com/threads/59005-0-23-5-Release-3-1-Active-Texture-Management-Save-RAM-without-reduction-packs%21 If that doesn't help then provide more information. such as an output_log.txt file

Unlikely to be the cause, unless you were using an older version, and only then if you had actually deployed the chute before flying up to space and trying to dock.

I'm not even sure you can change whether or not a part's resources can be tweaked. I checked the DREC heat shields and the config for the Mk1pod where AblativeShielding is added, and they're both done the same way. Not sure why you can't change it and I don't think there was a conscious decision to render it untweakable buncha stuff deleted Edit: Dunno if this will actually work but try making a config file with this in it: @PART[Mk1pod]:AFTER[DeadlyReentry] { @RESOURCE[AblativeShielding] { %isTweakable = true } }

Thank you for not calling it a strut. (it might have struts IN it but it's not a strut )

I used XSI Mod Tool. Except I'm not sure if it's really called that because it was purchased by Autodesk and I think they called it Softimage. Except that it's also been discontinued. But I liked it because it was free and it didn't have Blender's convoluted steep learning cliff. (it's not a learning curve it's a CLIFF and you fall off and die) So, I'd build the mesh in XSI, unwrap it and adjust the UV map there. Then export it using Crosswalk as a .dae which Unity's editor can read. Tangents are a pain; it seems like hit or miss if I build them and export them with the mesh as to whether Unity picks them up or not. Also after unwrapping and adjusting the UV map, I 'stamp' it, which means that it saves the UV map as a texture which I use later when creating the part's texture So I then load it up in Unity, open the stamped texture Photoshop and then I can edit the texture in Photoshop and alt-tab over to Unity to see how it looks. Then I export it from Unity after adding collision mesh, KSP shader and any special colliders (like ladders or hatches). The texture I save while working on it as a psd so I can retain photoshop's layers. Unity can read the psd natively and later export it as a tga (or other texture) with the mesh. I already have the part folder set up and export directly into the part folder (of my development copy of KSP) And I guess that's about it... Most of my textures look kind of bland; I lack experience. The one in the adapter above was a frankenstein creation mostly using Porkjet's SP+ textures. (otherwise I might have released that part)

Tweaking isn't set on a per-part basis. AblativeShielding is set to be tweakable. How are you trying to adjust it? Did you try right clicking the part?