asmi

Speaking of which, Ferram, some time ago I've got sick of Editor GUI resetting its' position every time I go to VAB, so I've made small change in source code to save this position in config file. Would you be interested in integrating this change into your source code? I'm sure I'm not the only one who is bothered with this That's just around 10 lines on code in one file, and four more in another

Yea, sometimes, while other times it doesn't. I wasn't able to identify any pattern. I'll continue using it and will let you know if I'll get more stable results.

I remember some time ago I've asked Bobcat about that and his position was that it only ensures it works in stock. I'll ask again, but if his position is still the same, I guess I'll have to fix FAR - since I'm developer myself it would be easier

Just tried it - and it still sometimes ejects in weird direction, trashing my solar arrays (I've lost 60k in my Mission Controller's mission due to payload was incapacitated by fairings ).

Thank you for the quick response! I don't have source model files, but from what I see in config file (attach node coordinates) it most certainly isn't Again, looking at config files, I can tell that it's stack node. Is there any way to make this work at all? Again, as I've said I have no control over the way it is built, I'm merely a user... This model is the only Shuttle that actually works and doesn't require a lot of skill to fly (I can fly it manually with no problems whatsoever), but with FAR installed it's completely unplayable - I can get it to orbit, but on reentry it turns tail-first and there is absolutely nothing I can do about that as far as controls go...

Hi ferram! I'm trying to "FARize" BobCat's Buran shuttle, but there seems to be the problem - lift vector is in odd position, and debug values in game (btw you should leave them on - very useful!) show that it is not just a visual glitch. Please take a look at screenshots: http://imgur.com/a/Nj48f Configs for left and right wings are here: http://www.asmitech.com/Stuff/KSP/Buran_Configs.zip Thank you!

Looks like the mod doesn't work with parts that have space in it's name. I've tried this: and this: Neither works.

This point it - proper n-body is easier and better than what's being proposed here.

So, from "it's hard" statement you went to "it's not casual'?

You couldn't be more wrong. Ever heard of Orbiter? It implements n-body physics and work just fine with time acceleration, and even on ancient computers. The fact that in can not be solved analytically doesn't mean that in can't be solved at all. Numeric integration methods work perfectly fine in this case.

Looking at all of this, I have to say that implementing real n-body would be much easier. You only need second Newton's law plus some numeric magic to make it work with timewarp...

Being his subscriber for quite some time, I've noticed a signs that Scott has got bored by KSP as most of his videos in the last month or so are just stupid explosions and some other "LULZ! EXPLOSIONZZZ!!!". And that's not the kind of videos I expect to see from real-life scientist. Hell, if I wanna see some explosions, I just go in and make them myself...

I'll hold on updating until at least FAR is updated. Sorry, Squad, but that stock set of bugs that for some weird reason is called "aerodynamics", doesn't cut it after FAR...

Was successful on first try. Having done many dockings in Orbiter, in KSP it's much easier.

You're welcome! In addition to increasing VAB/SPH (which alone makes it worth trying IMHO ), there are few other features which I'm sure you'll like I'm not going to spoil them - check it out yourself - make sure you read readme! I usually budget 3.5 km/s for ascent, but this includes healthy margin in case I screw something up, which I do sometimes As far as optimization goes, my personal record is around 2900 m/s, but achieving this was hard and required several retries. Since we aren't exactly short on fuel (I play with Mission Controller mod which makes me pay for everything I use, and still fuel is pretty cheap), I pack more just in case. The trick is to control throttle in way that ensures you get to apoapsis with orbital velocity. In this case gravity does turning for you, so you just have to let it do so (ASAS/MJ off). Yea ASAS it generally useless (if not worse) during ascent as usually the way it works (assuming rocket is aerodynamic) is you either on a correct trajectory and so aerodynamic forces will keep it there without any input from you, or you're in a wrong attitude and so aerodynamic forces WILL overpower whatever RCS/SAS/ASAS you've got anyways and the mission is a failure regardless of what you do.

I use MJ's Smart ASS Surface mode to steer rockets during ascent and even before lift off I put 88 pitch angle, so I'm starting gravity turn right at the liftoff. Then SLOWLY decrease pitch as your velocity vector goes lower to avoid it getting farther than 5-7 degrees away from your orientation. Yes, FAR clearly prefers tall rockets with vertical staging and so having EditorTools installed is practically a must (it expands VAB/SPH so you won't have to worry about hitting ceiling). The real problem is thrust - you have to do few test launches to depermine optimal thrust profile. In ideal case once initial pitch over is completel, you shall just direct MJ to follow prograde vector and use only thrust to control your profile (more thrust = rocket turns slower, less thrust - faster). This way you won't need any RCS at all for the ascent. And after playing with FAR I simply can't play stock without banging my head and shouting "This is impossible!!! This can not be!!!" But I agree, it will require modest time to re-learn how to build and fly vessels.

You will have to. Turning more than 5-10 degrees away from velocity vector is a recipe for guaranteed fireworks with FAR.

And how is what you said contradicts what I'm saying? They paid for their screw ups (and apparently failed to learn on their own mistakes by repeating them).

You don't need to tell me that - I'm in this industry for well over decade. The thing is - they picked Unity themselves, nobody forced it upon them. When I make some decisions in software I develop that later turn out to prevent implementing some features that my customer wants, I acknowledge the fact that it's my screw up and do whatever it takes to fix the problem for free (my customers don't have to pay for my screw ups, unless I'm on per-hour contract). That is what professionals shall do and are doing. Complaining to the customer that due to my bad decisions they are not getting some feature they want is UNprofessional and unresponsible, and by NOT fixing the problem Squad acts as such. I wouldn't be too far off from reality if I go on to say that these two issues top the list of issues that vast majority of community want resolved. It's their fault no matter how you look at it, and therefore their obligation to do whatever it takes to resolve it. That is professional and responsible thing to do if Squad wants to retain a fairly good reputation they have (had?).

There is just one thing I wish would happen - once they release 0.21 (and 0.21.x of course), Squad would announce todo list for 0.22 containing just two items - performance and 64bit support. They really need to focus on it and solve the problem. Pushing it out and blaming it on Unity/PhysX/whatever is just unprofessional.

Really? By now only really ancient computers don't support 64bit, and these computers would better be donated to museums...

Buran was launched and successfully completed the mission setting up the record that was not beaten for many years (fully automatic reentry, descent, approach and landing)

Hey Majiir! I've already asked this question here, but it looks like you didn't notice it. Are you planning to add an option to allow explicit set up of resource deposits?

I've found a bug - insurance cost doesn't get saved across reboots. Nobody uses it?

Hi TWR on low throttle means excess weight (higher-thrust engines are more heavy).