asmi

Actually, a series of experiments with this rocket and dummy weights showed that it's max performance is almost 50 tonnes (my test launch with 50 tonnes payload ended on -40 x 200 km orbit, which likely means that with more careful piloting it could've reached orbit). But 40-45 tonnes will be good even with my sloppy piloting.

I've added config as you said, and it seems to be working as intended: It shows 7261.6 kN of thrust while specs says it should have 7259.4 kN. I'd say it's close enough! Thanks for your help!

That NK-43 is actually one hell of an engine - it's got TWR of over 128 while still having 1.75 MN of thrust! If there is a candidate for SSTO engine - it's gotta be it! Atmo Isp kinda sucks (246 s), but that's totally expected given the "vacuum" nozzle - it's actually so huge that makes the whole NK-43 engine (5 meter height) full 1 meter higher than RD-171(4 meters height)! But vac Isp of 346 is very good, and given the unusually high thrust I was able to easily build a two-stage rocket that lifts around 30 tonnes to ~300 km orbit (as you can see on the screenshot, second stage accounts for 2/3 of rocket's dV). I mean, I knew that NK-33/43 are amazing engines, but I didn't think they are that amazing!

These are custom-made engines - they are not in any pack.

Why can't you save propotions into your part module's config using double-precision once user enters them, and then after rescaling recalculate amount/maxAmount based off these numbers? Oh, and speaking of which - PartModule's built-in persistence mechanism doesn't support doubles - only floats. This revelation cost me a good couple hours of debugging and head-scratching this weekend So if you want to save doubles, you'll need to override OnLoad/OnSave and manually read/write doubles, or resort to floats which work fine. Thanks, I'll try it out. But you surely can attach your part module on flight start

How many "v3's" have you released already? I know about at least three of them The point is to use notation like v3.X, where X is just a sequential release number, so that I would be able to figure out if there is a never version just by looking at your download's filename and comparing it with what I've got locally (I keep all packages of all mods I ever downloaded, including old versions). How about instead of calculating the delta you recalculate the whole tank? This way there will be no rounding errors. I think I know what the problem is. I use custom-made RL engines: I thought MFSC would automatically add thrust correction, but apparently I was wrong. What do I need to do to make that happen? I don't need any other features of MFSC (like fuel types, levels, etc.) since it's a RL engine - I only want thrust corrector to work. How do I specify sea-level thrust (I've set thrust in vacuum as maxThrust)?

Please meet "the one that could've been" Zenit-4 (name is mine, since the design is an improvement over base Zenit-2/3), carrying Mir Station's Base Block to orbit:

Honestly I was a heavy user of QS before 0.21, but starting from that version it seems to bring more issues than benefits. So I've dropped it off - and guess what - I never missed it as bad as I thought I would.

NathanKell: Can you please include build number in the file name of your download? It's very hard to figure out if the version I'm using the latest one or not... I use bitbucket.org for my projects, in addition to git/mercurial source control and bug tracker it provides an area for downloads, where you can put your packages. With that said, Stretchy Tanks & MFSC still don't play nice together - when I load craft, it puts incorrect amount of propellants into tanks, once I go to action group menu -> select tank -> remove all -> load it back, dV and TWR magically changes. Second - when I resize the tank, it usually overfills them (the numbers are yellow in MFSC GUI), again remove all props -> re-add all props fixes the problem. These issues are not a deal breaking, but very annoying. Oh, and you MJ build still can't seem to recognize the fact that thrust in atmopshere is lower than in vacuum.

Well technically it's totally possible to do that right now - via adding part modules. We need some sort of GUI for that...

Zvezda's "main engines" produce only 23 kN each, and these are used to maintain an orbit of 450 mT vessel, not to mention that Progress' main engine providing whopping 2.95 kN is routinely used for most of ISS maneuvers. Welcome to the world of real spaceflight Nobody here puts 200 kN engine instead of 1kN one just 'cause he isn't patient enough to wait for several minutes-long burn

It's hardcoded in KSP itself, not it the mod. I guess it still could be corrected, but I'd say there are higher-priority tasks at the moment

Taked about it just a couple pages ago Auto-switch is hardcoded to be at the altitude of 6% of celestial's radius, which for rescaled Kerbin is 384 km.

That's why 144 m/s dV burn takes over 4 minutes in reality Also on real Soyuz RCS and KDU (main engine) uses same fuel from the same tanks - that allowed designers to get rid of backup main engine - if main engines fails, they can use RCS to deorbit craft.

Make sure you guys update mass for the Soyuz spacecraft itself. BobCat's version is quite a bit heavier than the real thing. In reality it launches to ~200 km @ 51.65°, but not from equator, but Baikonur which is at 46° N.

NathanKell: Just watched this video and thought about this mod. Check it out (watch it all the way to the end):

Hydrogen peroxide is used as RCS fuel to control LV attitude during ascent. Guess what - there are no "magic torque wheels" in real life, so engineers had to resort to old good RCS attitude control system Ask ferram4 in his FAR thread - he is usually very helpful.

Well then we'll need to mod PQSMod (lol) so that it would work with texture patches instead of whole thing. But then there is a problem of memory - these textures aren't gonna be small. To get our KEarth to Kerbin resolution, well need to increase resolution by factor of 11, which will increase total texture size by factor of 11^2 (area is proportional to radius squared)... Which basically means that we will have to implement paging mechanism for heightmaps and textures since they simply won't fit into process memory. By editing KSP's config file I've made engine to render planet beyond max level 10 (I've made it to lvl 11, but theoretically we can go even further). Another problem of PQS system is that it generates geometry in RAM using CPU, which could become a bottleneck (although as far as I understand Unity allows initializing its' objects in other threads, so moving init code out into separate thread could possibly alleviate the issue). In my engine for Orbiter (and another space sim engine I'm working on now in a background) I was generating all that stuff on GPU right within rendering pass - via vertex shader for initial vertices setup, then tessellation(for DX11) or Geometry shaders(for DX10) for subdivision. PQSMod components even do bilinear filtering on CPU (while in GPU there is hardware dedicated for that, so there you get it essentially for free). Bottom line - this is not easy nor simple, but it could be done. And whoever manages to do that will probably end up hired by Squad since this mechanics would be useful for stock game as well We have complete access to Unity runtime, which basically means we can do just about anything that Unity itself can do (and as such, Squad devs can do). ------------- Another thing - you've probably noticed that speed indication doesn't automatically switch to orbit mode as you do ascent. My experiments have shown that it does so once your altitude is more than 6% of celestial body's radius, which probably won't fly in our case as 6% of Kearth is 384 km

Regarding improving terrain detail - currently Kerbin uses 4096x2048 heightmap, theoretically we could increase it's resolution to 8k by 4k or even 16k by 8k (DirectX 11-compatible cards support texture sizes up to 16k), but I think there still won't enough details...

AFAIK N2 is used for tanks pressurization.

That part is easy: InputLockManager::SetControlLock/InputLockManager::RemoveControlLock. Check ControlTypes enum members for possible locks (for your case it's probably ControlTypes.ALL_SHIP_CONTROLS).

Really? How about proving the mere fact that orbital flight is possible? This is the most important scientific result in the whole space science. Vast majority of space science is done using probes. Human flight hadn't done a mere 0.01% of what has been accomplished with unmanned vehicles.

Ferram4 Have you considered disabling gravity one you go to pad, and then gradually reintroducing it to help the simulation settle? You can do it by manipulating CelestialBody::GeeASL value. Set it to 0.01 initially, and then bring it back to what it was over few seconds. The point being that at first it settles from the kick to the side (caused by planet rotation), and only then settling against gravity.

I've tried disabling clamp reinforcement, but the message still appeared: "Launch Clamp Break Force / Torque set to Infinity". The rocket still gets stuck, but now clamps are not failing. Here is the rocket: http://www.asmitech.com/Stuff/KSP/REAL/Rocket.zip, this is the screenshot: http://www.asmitech.com/Stuff/KSP/REAL/Rocket.png It contains KW parts, AEIS and proc fairings. Try my rocket - you will get all kinds of random failures with it once you move to the launchpad.

I'm gonna try to convince BobCat to make RD-170 engine, because I just love it, and he is the best man for the job Shuttle's ET needed insulation because it was flying in the airstream (and as such was subjected to airloads and heating), while inline HydroLOx stages are in the aerodynamic shadow of the PLF, and as such are not heated by airflow (remember that in supersonic and hypersonic flight regime airstream behind the shockwave is almost nonexistent). Look at Centaur for example - although it uses HydroLOx, there is no insulation. DIV has insulation since its' CCB is supposed to be common with DIVH, which again has its' boosters flying in the airstream.