Starwaster

Ok, what exactly is 'Starfix' Maybe update the OP explaining this? And/or put it in the 'readme'? Please?

No, he said they started deployed. (and don't show up in the staging list)

It has been done and I thought it actually looked pretty good.

One option is to go with stock KSP's FlagDecal module It requires that the model have a dedicated and UVed quad. The part config file then needs this: MODULE { name = FlagDecal textureQuadName = flagTransform } That's actually been in the game for about a year now but until 0.23.5 has not even been used in stock parts. It can also be disabled in the VAB (tweak) if a player doesn't want the logo. I might put it on my own parts.

It causes drag anywhere below 180km. If you have mods that report drag, they will likely report 0 drag and pressure because of rounding. I think FAR has enough precision to show accurate drag if you have the right window open, but at those altitudes it's pretty miniscule and would likely take days or months (real time) before you you need to take corrective action. Remember, this is Real Solar System. In actuality you would have drag to almost 4 times that distance but it's too miniscule a thing to be keeping you from going off-rails over, so the cutoff was put at 180. (I actually had it a little higher than that originally but Nathan asked for a 180 cap so that you could do non-phys warps at 185. (which was the official parking orbit for the moon missions)

The Real Chute bug strikes again!

That's not enough to do what you're describing. You should post your output_log.txt file, located in the KSP_Data folder. Not the ksp.log. output_log.txt An easy way to do it for you and us is to use dropbox and share the link here. If you don't use dropbox you should. Very handy. Alternatively you could use pastebin but if it's a very large file (lots of errors) then that could be a problem.

Worthless I think they're just there as a gag item. Sadly, Stupid_Chris has rebuffed my request for parachute materials made with fishnet stockings. Apparently he's under the impression that they have insufficient drag!

If it's an ID-10-T problem, try giving it a firm whack in the control module.

There are several immediately visible obvious problems if you use the right tools to check. Offcentered thrust: According to the RCS balancing tool (it does normal engine thrust balancing too) it's actually pretty severe but I'm guessing engine gimbal control and control surfaces are enough to compensate in stock KSP Center of Lift: Lift is centered outside and above the orbiter, high up above the center of thrust. To my way of thinking this one is far worse and harder to compensate for with FAR enabled. What I've tried: Adding fins to my boosters and to the bottom stack fuel tank. Did not help at all. Tried turning the fins into spoilers. (This is a FAR thing. Right click the fins and set an action group item for spoiler activation). Did not help much. Maybe not at all. Tried putting strategically placed fins to offset the lift from the wings and rudders on the KSO. Still experimenting with this one. Have not launched yet but this one shows some promise because it moves the CoL back inside the stack where hopefully it's less of a problem. I also have to wonder if assigning proper FAR values to the wings and rudders might help instead of having them as stock KSP control surfaces, but I don't know.

Ok so it's probably FAR then. Either because that rocket design has a flaw or because the rocket engine being used lacks a bottom attach node. Far uses attach nodes size in its drag calculations. Engines without attach nodes of the appropriate size would be prone to flipping. I'm going to test that out later today. I'll specifically check if adding an attach node to the engine or leaving the bottom of the fuel tank bare with multiple radially attached engines helps with the problem.

Well what mods did you play without that you were using before? Also did you check output_log.txt for any errors happening after switching to flight mode when you launch that plane?

What exactly does it do in the first 1000 meters? Is it unstable to fly? Does something else happen? Is FAR installed?

Any ideas? You say it shows that at the end. What does at the end mean? At the very end of the log? That error is just MechJeb's attempt to cleanup because it is being destroyed. It can't possibly have anything to do why you're not getting a toolbar. In fact it looks like you might have alt-F4'ed. That's the only time I know for sure that MJ would throw that error in OnDestroy() It's better to put your entire output_log.txt file up for download (dropbox is good) and then put a link for that instead of an excerpt that might not be relevant. Edit: And as has been stated, make sure you have the latest MJ2 dev version + latest version toolbar.

Well you know us guys.... never stopping to ask for directions

He did try to warn you

Try setting the offset to -11000 But... then you'll also have to increase deformity. Unless by any chance the low point on the map isn't really pixel value 0?

I was also just thinking it might come in handy to practice PQSMod editing on a flat planet to really get a good feel for how it all works.

That should be easy to test for. Give it a flat heightfield map. All one shade. And of course disable any deforming PQSMod If you get anything other than a flat planet or anything that looks like Duna then you're probably right and the old map is being loaded. But if you get a flat planet then that's probably not the answer.

I think that's what PQSMod_AltitudeAlpha. Or is it AlphaAltitude? Something like that. Also, I've been thinking. When testing your Mars map, you should turn OFF all PQSMods for starters. Not necessarily by disabling, but by zeroing out all deformities. Get a feel for what your baseline is. EDIT I've been doing some research on the various libnoise functions are and have some observations. Start with octave and deformity. Small value changes for octaves to start with because each level of octave doubles the effect. Use frequency sparingly because it can really make the terrain choppy and spiky. lacunarity is VERY subtle and I don't see it having a huge impact for most of the PQSMods, but for a few of them lacunarity had larger impact than for others.

No, what I propose is editing the RPM files that are altering the Orb and changing those. In fact, ultimately that is what has to happen on RPM's side to fix this. Have you looked for them? Without a doubt that's where the problem will be.

I don't mind collaborating but what do you propose exactly?

I recommend aerospikes on the rescue ship seeing as how its Isp performs well in both atmo and vacuum.

I use them on shuttle type vehicles or rescue vehicles.

FAR, not so much. There's a link (in Sarbian's signature) to a FAR/MJ plugin that increases FAR compatibility but I don't think it does drag calculations yet. Just control surfaces. Drag is still off so MJ can't really predict with accuracy where you'll come down. (when FAR is installed) It's not Deadly Reentry aware at all so it's entirely possible it might orient you at an angle where you can't take the heat.