asmi

There is no room in VAB - it already hits the roof Looks like we need to get EditorTools to expand VAB more.

Make sure you put this somewhere for download - looks like there's quite an interest Oh, I've found a bug in VAB - sometimes it doesn't display all icons in staging when I'm adding multiple engines (ullage motors and SRBs in my case). Saving and reloading craft makes them appear, so no big deal for now, but it's somewhat annoying. Not sure if it's related to your MFSC, or something else - although I don't quite see how resize could affect that.

Ok then - I'll get to it. To be honest I don't have too much spare time during the work week, but I do have "good Saturdays and Sundays" My wife is in the business trip abroad, so I've got plenty of free time during weekends Yea, that's what I was thinking of (stuff like Radius, GeeASL). This would be easier for users. And config should include orbital parameters as well so we won't have to have them in a separate place.

Wow - this is a first time in a loooong time I wasn't able to reach orbit on the first try: Getting ready for reentry: Entry interface @21.5M lol Peak G-load (almost 10G): Sorry man, but I just can't stop playing this It's so awesome!!!

Ok, awesome! Now we need to come up with config system so instead of hardcoding values we could provide them in a config, which would automatically be processed by the mod and it will configure solar system. If you want, I can take care of that bit since I'm intimately familiar with stock ConfigNodes system. The only thing I need to know is what degrees of freedom (minimal list of independent parameters that would define the complete state of the celestial body) do we have so I could code them into configs. Just in case you haven't seen it already, watch this: This is Squad's speech at the most recent Unite conference, it contains a ton of very useful technical information on how exactly KSP works under the hood.

So, we went from "It's impossible!" to essentially "Done!" in less than 24 hours. Great job! Looks like my "motivation" technique hit exact spot I was aiming it to

Check PQCity. This component is responsible for setting things up on terrain. I'm on my way home, will pitch in in about 1 hour. Make sure your stuff is checked in so I won't have to do things you've already done

Remember that Earth rotational axis is tilted, and so Moon's inclination in regards to equatorial plane is not constant. I wonder if it's possible to tilt Kerbin's axis... But I'd suggest to solve problems one by one, and not jumping on everything at once as it's the most sure way to not get them all solved. My few short tests have shown that orbital mechanics works just fine with whatever parameters we set in CelestialBody. It's graphics which could prove to be a problem. If we'll succeed in rescaling terrain (and something tells me that we will ), it will look rather blurry and coarse as textures are covering specific spherical patches which are defined using lat/lng angular coordinates, and so their physical size is defined by the radius of the body. Theoretically quadtree could be extended beyond current max subdivision level of 10 (BTW Orbiter uses the same approach, and it uses levels up to 14, while my D3D11Client engine for Orbiter allowed for up to lvl 18, which gives <10meters precision for the bodies of Earth-like size - although there were FP precision issues to be solved to achieve that), but that would possibly require generating additional higher-res textures if we want it to look nice, AND implementing rather aggressive paging mechanism for textures as they simply would not fit within the confines of 32bit process address space. Well - I've solved this problem once already (for D3D11Client graphics engine for Orbiter), so I'm sure we'll find a way to solve it within Unity But let's not get ahead of ourselves. The task of the day is to get terrain to render at all according to the new size. Once that is done, we'll see what to do next.

And the last treat for today (it's 11:40pm over here, note orbital velocity): Believe or not, only one - it was GeeASL (set it to 13.8 in SpaceCenterAddon::Start() (that is my class marked with [KSPAddon(KSPAddon.Startup.SpaceCentre, false)]) for the first screenshot, and Radius (set to 6371000 in the same place) for the rest of them. Visuals are still "old", but solving THAT is IMHO well worth investing time into. Looks like you guys might need to turn your balancing gears to the opposite direction - with that kind of environment, even mainsails won't do much good . I gotta commend Squad devs as they (possibly unintentionally) made it so easy to play with. And I've gotta thank you for setting me up for the challenge - I've been wanting to try it out ever since I've started playing KSP, but never went as far as to actually sit down and try it So, once I finish the work on my current ECLSS mod, I'm all set to take up the challenge of making it all work. Join up and maybe we'll turn KSP into what we want it to be for us! That's enough for today. asmi out. P.S. Remember that theorists in US in 60s had concluded that staged-combustion KeroLOx engines can not be built, but the Russian engineers didn't care about theory, and instead actually tried and developed the most advanced KeroLOx engines on the planet to date.

THIS is THE stuff (note parameters): KSP feels kinda funny (craft is ejected with quite a velocity from the launchpad), but maybe these issues could be solved afterall?

LOL, it turned out to be much easier than I expected (please note orbit and orbital velocity): P.S. Looks like my dream of turning KSP into Orbiter while retaining all KSP features might not be as far after all...

Orbits are using doubles right now. There is no difference between 64bit and 32bit as far as doubles go - they are just as "free" in 32 bit app as they are in 64 bit because they are supported by underlying hardware which doesn't care if current mode is 32bit or 64bit. And please note that I didn't ask you why do you think we can't do that - I've asked if somebody had actually tried to do that. As an engineer, I don't buy theory unless it's proven (or disproven) by experiment. As example, for long time it was belived that it's impossible to read and moreso change resources for inactive vessels. But it took me one good Saturday to prove this belief wrong by finding a way to do just that. Here is a screenshot: http://imgur.com/q8wyAiN Please note that it's made from Tracking Station, when vessels aren't even loaded yet (vessel.loaded says false), and yet it still is possible to read and write resources for these vessels. The same is for Space Center screen - believe or not, but game time doesn't actually stop when you go into one of these two screens, and my life support mod still works in these scenes (by consuming/generating resources). Oh, and all of that without any nasty hacks like reflection, private members and so forth - everything is done using public interface only. With that, can you please tell me if you, or someone you know of, have actually tried to do that? Or everyone gave up without even trying? P.S. I'm sorry if that sounds a bit harsh, but I deeply believe that engineers are supposed to solve problems, including those problems which were never solved by anybody else before them, and even those which are thought/believed to be unsolvable...

The Russians fire-tested MethaLOx engine with Isp of 380 sec. As for the main topic - maybe it would actually be easier to find a way to redefine celestials' properties to match RL, than doing all of this?

No it isn't. It's space port's issue. Try re-downloading.

KAS is NOT for auto soft-landing engines, it's used for something else (not sure what) - I guess it's EVA-movable batteries on Kvant.

The same as before - of course it's FAR.

Yea, I know about that. What I meant is more of GUI for that mod - so that we'd have another setting that would affect engines performance. For example, first-stage engines with no restart ability and ground-start system would be lighter than these with these functions. It would also be great to limit throttle range - if my memory serves me, stock ModuleEngine actually supports this (via minThrust/maxThrust or something like that - don't remember details off top of my head). I was using MJ until I recently realized that the only things I use in it are dV info and orbit/target info, so I've switched to KER since it have all I need without excessive overloading with features that I don't or can't use.

It was me. Yes, as it turned out, making Buran FAR-compatible requires model changes (on top of config changes of course), and I didn't get any response from BobCat on whether he's willing to make these changes.

Good stuff here - MFT update was long overdue. It would be great to add support for non-restartable/finite-times-restartable and ground start/airstart/no-zero-G-start for engines to bring it even closer to RL. Oh, and if you could come up with patch to KER similar to what you've done for MJ, it would be awesome!

To be honest, I don't quite understand the point of this thread. Being "realistic" means "like in real life", so there is nothing to balance as you can't tweak laws of physics for your purposes. It's either "like in real life", or it isn't "realistic". There simply could not be two "realistic" aerodynamics since laws of physics are universal. "Balancing" it to craft is even more ridiculous since with FAR craft itself is just one variable in the total equation, piloting is just as important (if not more important), and you can't possibly come up with any baseline since underlined mechanics are totally different. And as was pointed out before, testing aerodynamics with single SRB is just not very scientific.

I think you don't understand what exactly stall means. It means two things. First - your aerofoil doesn't produce any lift (which is kinda expected since it doesn't move laretally and therefore there is no airflow around them that creates lift). Second - your aerodynamic control surfaces don't work (which also makes sense if you recall that they work by manipulating the airflow around them, when there is no lateral movement, there is no airflow). BUT - it doesn't mean you lose control - if you have other means to control (like ideally balanced VTOL engines, or RCS), you'll be just fine. Since ideal balancing is next to impossible, RCS is often use to compensate for small imbalances. In real life it's compensated by differential thrust of engines and/or by thrust vectoring, both of which are kinda hard to do in KSP (although I seem to recall that there is a plugin to do just that), so using RCS sounds like a good way around...

I see that you've got FAR installed. With payload as un-aerodynamic as yours you either use fairings, or "you ain't going to space today".

These engines are for different things - SSME is for sustainer (core stage), while NK-33s are for LRBs (liquid rocket boosters, essentially SRB replacement). It's all is still up in the air - there are rumors that NK-33 production will be restarted for both Antares and Soyuz-2.1v. This engine is the best choice for SLS LRBs due to its efficiency.

The irony is that 6 out of those 9 launches (two thirds) are powered by Russian engines.

I think if there is winner at all - it's science. There has never been a period in history when science had expanded so rapidly. Regarding the Moon race - Soviets didn't make it to the Moon, but engines they've built for it are unsurpassed even today in terms of advances in technology. Just think about it for a moment - Antares flew twice propelled by engines built over 40 years ago - before most of us were even born!