Starwaster

Been there, done tha, got the T-shirt that says "HOLY crap why is the ground rushing up to meet me at break neck speeds???"

0,0,1 points to the top of the fuselage. thats not weird; if necessary I'll draw you a diagram illustrating why that is. never misunderstood that part uh.... balance? overpowered? I'm really having trouble understanding where this one is coming from.... balance doesnt even come into this.... it just reflects a proper shuttle / spaceplane orientation. no, I dont think it's 'overpowered' maybe I need to draw A picture on this one too because I dont think you're grasping the nature of how it actually works. I have to go to sleep now; I'll post something later. In the meantime I suggest you read the KSO thread and try to figure out why so many people have trouble with KSO landing gear burning up on reentry. And why they resorted to giving the KSO ablative shielding.

You mean you wish Sarbian the very best of luck.

o Are you referring to the jettison contextual menu? that's for the engine fairing only.

You know the drill. ouput_log.txt file unless you're on a mac or linux. then it's player.log Never ksp.log Especially not ever.

Direction controls which way your craft has to face to get full benefit from its shield. most shuttle space plane designs require an entry angle of 35-55 degrees or you run the risk of losing control. let's take 45 degrees orientation as an example (heading is irrelevant in this regard as a consequence of 0,0,1) your shield is only 50% effective for a reflection of 12.5! face directly into or away from your velocity vector or any pitch value of 0 relative to your velocity vector and you have 0 shielding. only a pitch of 90 degrees gives you your full rating of 25%. that's not only unrealistic, it makes things unrealistically difficult. That's why you see people frequently complain about their landing gear burning up. they're trying to fly their shuttle like it was a shuttle. to put it another way, 0,0,1 means you must face the belly of your shuttle directly into your velocity vector for full shields. as though it were an apollo capsule instead of a space shuttle. if you know any math and/or programming and look at the DREC code the reasons become obvious. Reflection = reflection * Mathf.Dot(direction, velocityVector) (pseudocode to boil it down. actual code has more to it but that's basically it)

As I said elsewhere, I suspect that there is and that it's maybe just been overlooked by us all. There were some variables in the CelestialBody class that made me think that awhile back but I never looked into it. If I can get my PC into functioning order then maybe I can check it out. Functioning for more than 10 minutes anyway.

RSS has this functionality. It's disabled by default because as Blizzy pointed out, renaming planets can interfere with other mods. It shouldn't be that way IMO because there should be some means of searching out planets other than their player visible names. In fact I think maybe there is and we've just overlooked it.... would like to explore that fuether but my PC is really acting up lately

What's the level of completion on the models? there's areas where meshes intersect instead of terminating or being merged and it's pretty noticeable. (docking nodes on one of the base elements and ends of some rails sort of butting up against each other instead of merging cleanly) There's also areas where there seems to be bad tangents, like on some of the rails. Maybe something that could be solved by hardening edges on the ends of the rails. (longitudal? latitudal? forget which is which)

Yes but scale it up to 8-10m (Orion? SLS?) and it looks frightfully thick.

I'm not entirely sure if the heatshield direction is correct. I did test it by creating a test attachment node (e.g. for direction = 0, 0, 1: node_stack_test = 0.0, 0.0, 1.0, 0.0, 0.0, 1.0). Anyways, you've been warned. Feel free to correct my mistakes Z is wrong for parts that you specified 0,0,1 for. It should be 0,0,-1 Thats the typical direction vector for space plane parts. HOWEVER. That vector means the plane has to have its bottom pointed directly prograde for maximum effect. That is why spaceplanes typically have a hard time in DREC. For stable flight they shouldnt exceed 45 degrees. but 45 degrees means that they get no more than 12.5 reflectivity. On my personal PJSP DREC config I use 0,1,-1 I also have adopted that direction value for KSO parts (which on my end are NON ablative like they should be)

I was thinking a thorazine drip myself...

ablative shields generally have a reflective value of 5%, specify a resource that will ablate away to reduce unreflected heat and resource ablation and heat dissipation curve data. non-ablative uses a higher reflective rating of 25%. I am of the opinion that space plane / orbiters should have their direction value set to something that rewards a 45 degree entry vector instead of the 90 degree that pretty much all space plane parts use (I think that would be direction = 0, 1, 1 ?) that's a little too broad. Are you just asking for how to configure it? do you at least have a model and know how to import that into KSP?

If your rocket flips when turning with FAR then you're not initiating your turn early enough or it's too aggressive. Start your turn early when your velocity is ~100m/s You can do it later in the flight but it's not a good idea because you're having to make up for the lateral acceleration that you should already have accumulated. And of course, if Q is still high then you're risking losing control. Best to start early. If you're using MJ2's ascent AP then know in advance what altitude you're reaching ~100m/s and set turn start for that altitude. If using RSS, also set turn end for 122 km for Kerbin and ending turn degree 5-15 degrees. YMMV Turn shape% .... varies. you want it high so that it turns gradually. such that you're within 5 degrees of prograde marker. (which is not the same as where MJ thinks prograde is that early in the flight but that's not important right now)

Structural.

Yes there is but I dont remember what it is... A prop that you set True on ModuleGimbal.... PC out again so on iPad. I'll find out. edit: here it is useGimbalResponseSpeed = true theres also gimbalResponseSpeed i think default is 10 or 100. faster is better...? Edit 2 @ECat: difference btw is that, just setting high gimbal range means you're relying on the system to react when it starts to go off course. Even with fast response time or zero delay, things can destabilize. If the problems with auto trim can be nailed down, it's calculating optimal trim BEFORE things destabilize. Proactive instead of reactive. Edit 3: tried what you did btw with the KSO, replacing their custom gimbal with stock ModuleGimbal at the KSO value of 14 for range and it did better than just cranking it up to something like 14. too bad gimbal rangen isnt tweakable

Wouldn't be a problem for 70s NASA.

"For the world is hollow! And I have touched the sky."

'just trim a little' you know what? I've been bit by that bug and there comes a time in a man's life when he's careening down that runway at breakneck speeds and the rudder is jammed hard over to the right and the plane is still veering left and the spotlight at the end of the runway is rushing up to meet him and he realizes that all the rudder trim in the world wont save him this time and that he should have worn his brown pants that day.... times like that make me wish I'd listened to my mother.

I might have some knocking around.... but I'll have to search for them. I once made a rover using a habitat module (or was it a science module? I forget) and the Fustek cupola for the cockpit. Plus it had red B9 lights on the end that were tied into the brakes and some nifty headlights up front. Plus I had a station core that I designed using Fustek parts + zzz's dome and was intended to dock with an automated nuclear drive section and be sent to Duna. It never actually went but it was cool Click the Voyage to Duna link in my signature for pics. I'll see if I can find the craft files for it if you want. They're buried in archived 0.21 folders though

# is for properties, it says that on the front page. What you want would be: // Do you see what I did here? We checked that the PART :HAS[FNModuleResourceExtraction] and immediately appended a :HAS[#resourceName[Lithium]] to the first :HAS[] // Also pay strict attention to bracket placement and always make sure you have matching numbers of [] @PART[*]:HAS[@MODULE[FNModuleResourceExtraction]:HAS[#resourceName[Lithium]]] { @MODULE[FNModuleResourceExtraction] { // None of these values make any sense in this example because none of them are actually altered; just using them to stay within context of your example @resourceName = Lithium // @name = FNModuleResourceExtraction <- Huh?!?? Don't touch this unless you intend to change this PartModule into a different PartModule @extractionRateLandPerTon = 0.0008826 @extractionRateOceanPerTon = 0.0008826 } }

I have a couple of requests/suggestions for when this plugin's problem (with gimballing all the way over) is fixed. config option to lock max gimbal angle to gimbalRange. provide autotrim enable toggle as an actiongroup item.

They should be smaller than their real life counterparts and have lessened thrust. Otherwise they are overpowered for stock. Case in point: American Pack's Orion is half size at 5m diameter and reduced thrust. not sure how much reduction. I forget.

oooh you mean craft files using the Fustek station parts?

it should be right next to the first one. did you get the recent update?