BudgetHedgehog

The right hand screen. From memory, it's the C button in the normal RPM screens, but I could be wrong. Just press buttons A - E and 1 - 5 until you get that screen.

You need to select a docking port as the reference part in the Target Management page/menu.

Any update news?

In fact, I don't know why they bothered to make a different planet for KSP - why not use Earth? Like you've said in the past, people should be forced to progress the same way as humans, encounter the same planets and everything. Earth time, real world places and worlds.. it makes the most sense, after all.

He's back...

Dr Death: make sure all the necessary dlls are up to date Rulare: what altitudes have you tried? Is the 'LO' in the small map staying orange? It might be easier to see if you could post a screenshot of your orbit with the small map open.

I remember someone else had an identical problem but that apparently fixed itself. Nevertheless, could you post a screenshot of your Gamedata folder?

No, it doesn't. That's likely an installation error. Are you using a Mac?

See, I didn't think so, but inside FerramAerospaceResearch.cfg: @PART[turboFanEngine]:FOR[FerramAerospaceResearch] { @MODULE[ModuleEngines*] { @maxThrust = 200 @velocityCurve { @key,0 = 0 0.7 0 -0.00098 @key,1 = 140 0.63 0 0 @key,2 = 400 0.7 0.00049 0.00049 @key,3 = 900 1 0 0 key = 1800 0 -0.00098 0 } } } @PART[RAPIER]:FOR[FerramAerospaceResearch] { @MODULE[ModuleEngines*] { @velocityCurve { @key,0 = 0 0.7 0 -0.00098 @key,1 = 170 0.63 0 0 @key,2 = 400 0.7 0.00049 0.00049 @key,3 = 1100 1 0 0 key = 1700 0 -0.00098 0 } } } @PART[JetEngine]:FOR[FerramAerospaceResearch] { @MODULE[ModuleEngines*] { @maxThrust = 140 @velocityCurve { @key,0 = 0 1 0 -0.005 @key,1 = 250 0.2 -0.001 -0.001 @key,2 = 350 -0.005 0 0 } } } For comparison, the stock jet engine has the following, along with 150 thrust instead of FARs 140: velocityCurve { key = 1000 0 0 0 key = 850 0.2 0 0 key = 0 1 0 0 }

The parts are balanced for Kerbins soup atmosphere - it's a well known fact that drag is dependant on mass and mass alone. FAR makes the atmosphere actually behave like an atmosphere should, but obviously, you're still using parts that were designed to work in soup.

The thing about more biomes is that they will easily and quickly complete the tech tree. Even forgetting rebalancing Minmus, just adding biomes to Duna would easily grant you 1000+ points upon return (depending on if you land near a boundary/have a way of visiting more than one biome). Add in a visit to Ike on the way and you really only need one trip to Duna to complete the tree. I think what would be best is remake the tech tree. Keep the first half as it is, so people can actually get the tech needed to go places, but add in more nodes, separate out the parts, increase science needed etc.. Otherwise, people can just go to Duna once and be done with the tree. The only reason to go other places would be because you now can, not because you need to. I know the same argument can be made about Minmus now, but that's because it's so OP. Should be more in line with the Mun, possibly a little bit higher.

No. Again with the 10 chars..

And considering how quickly you'd realise it, it won't cost more than a few m/s dV to correct. Needless to say, I'm all for a 100% throttle hotkey in stock. Though, considering it's literally 20 lines of code, it hardly takes up a lot of space..

Found another thing for you to fix, Biotronic! On the RLA tanks (I haven't tested the engines yet), scaling up to 1.25m doesn't resize the attach node. The other scales update fine, just not the 1.25m one Also, how's the adapters coming along? I coulda sworn it was real, but apparently it was a dream: adapters could be scaled, but only to sizes that worked out (the green boxes in your table). You say you can limit the rescales, why not disallow rescales that end up in the red? At least for now, I mean. P.S. did I really have a dream about building something in KSP? Yeesh... EDIT: have you made sure your TweakScale is up to date?

You need to select a docking port as reference part from the target management screen. Those are the docking shutters located at the top of the capsule. When the shutters are retracted, you can click on the window at the top for another view of docking

Back one page: http://forum.kerbalspaceprogram.com/threads/67246-0-23-Final-Frontier-0-3-9?p=1188939&viewfull=1#post1188939

Huh, my mistake - guess I was looking at an older copy. Must've been just before it was updated. Seeing as the download link in the OP also contains the correct FAR cfg, I can only assume that you were right all along (yeah, you can gloat now... ) - it's a MM conflict. From memory, 2.0.7 was when the whole 'MM breaking if older versions are installed' was fixed though I could be wrong so as long as people don't have any versions between 1.5.7 and possibly 2.0.7 and definitely 2.1.5, the cfg should still work. I'm guessing though, based on the comments here that that isn't the case so yeah.. PJ, if you're reading, MM 2.1.5 should probably be included or at least instructions to remember to delete multiple copies of MM to be on the safe side. My apologies Starwaster - it's been a long day. Had a job interview up in London that took like 4 hours which meant getting up at 5am this morning for the train, bleh..

It's not written as such though: @PART[mk2Cockpit_Standard] { blah } @PART[mk2Cockpit_Inline] { blah } Note the lack of :NEEDS[FerramAerospaceResearch] there. Until MM is included or the cfg re-written to not be applied if FAR isn't installed, as you said, this thread will continue to have 'the wing's don't work' complaints.

He was joking.

Ooh, pretty probes.. Regarding texture size - won't Active Texture Management handle them? Or will that barely make a dent? I don't care either way, these are going in! EDIT: Hmm.. I notice that the cfgs contain module = CommandPod Shouldn't that be Part? AFAIK, all other parts are..

Well, that and if you end up having to take into account the curvature of Kerbin while flying to space, it might be time to re-assess your aircraft design.

From memory, that was still 0.23 and the older version of IR.

A very good idea, I think. the systems report could just not scan the scanner (because reasons) and instead of Controlsurface1 chance of failure: 76% there'd be: Con#~olsu^fa_e1 c??nc f fai*"]e: 70% That would indicate the systems report part is badly in need of repair. If it was just one character glitched out, that would still be pretty reliable, but the worse it got, the more wrong the numbers (either false positive or negative - it tells you to fix the engine gimbal but you really needed to fix the SAS, which wasn't listed). I've no idea how doable that is though, if even at all. But that's probably how I'd do it if I could.

Considering the amount of bugs this game has currently, I see quicksave/load a necessity. My rule is if I fail due to my own stupidity (like forgetting solar panels, whatever) then so be it, that's fine. But if I fail because the game didn't load Kerbin upon re-entry and I fall into the black void with the blue circle, quicksave and quickload are definitely going to be used. I've done nothing wrong, Kerbin was there when I started my re-entry, why should I be forced to fail my mission because the game failed to work properly?