thorfinn

I don't think I understand... because of Unity you have noise on the momentum values, the tiny residues of the Kraken, but if engines and RCS aren't on isn't any acceleration an error? Again, wouldn't a low-pass get rid of the noise? Do you think it would be useful at 100000x or the like? I know that story From Kernighan and Pike's The practice of programming. But the funniest thing for me is discovering that Ada code looks very much like Pascal. I learned programming in pascal and I still miss Borland TP7, I haven't yet seen anyone replicate that ease of use in a IDE....

I suppose the hardest thing to manage would be "medium thrust" burns - i.e. if you wanted to accelerate the typical 30-minute LV-N burn beyond 4x. Too fast to treat the ship as a point mass but still annoying. Fair enough But do you need it off-rails? I suppose that what you're worrying about is a tiny wiggle in the here and now making predictions after one or two close passes totally unreliable. But then again, wouldn't that imply excessive precision in the burn and in the setting of maneuver nodes anyway? Couldn't you just low-pass the initial conditions data fed to the predictor? During high warp travel your integrator would take over and of course wou'd need that to be exceedingly precise - but that can be done. You actually have experience with that? I thought that was an old USDoD in-house tool.... You mean "where should the long-duration burn regime start"? I dunno, you might want to make a runtime test: before allowing transition to high warp with engines on, check that the ship has no angular acceleration and a good margin of control authority left - to avoid tricks like having a single ion engine way off center and no reaction wheels and still flying straight because at high warp the ship is a point-mass LOLOLOLOL.

No offense, but I don't think you can do that without getting old in the process..... The thing about orbits being calculated for the root part and not for the CoM is definitely true (altitude is referred to the root part, too.) And from a gaming point of view, I wouldn't want to COMPLETELY kill inaccuracies maybe... after all, real probes do midcourse corrections, if we could hit a 1000 m wide entry corridor from the other side of the system without a single midcourse that would be unrealistic too

Well, almost nobody has the requirements of KSP, and it's a budget game engine at that.

For very low thrust engines ("ion" is what we have in stock now in that class) you'd want to be able to apply thrust during high timewarp, so craft physics will be off and you'd have to have some replacement simplified model to apply thrust to, decrease mass et cetera. I guess you would have to handwave thrust offsets and things like that. I suppose there would be an acceleration cutoff somewhere low (0.01G?) below which your ship is considered "ion class" and can thrust during high warp.

I guess we'll know how hard it becomes when we get there (I'm still a bit scared, but after all satellites moving around would be a really big problem only for Remotetech, true.) But if you ever got to this: I would be very curious to see what orbits would look like around a realistic Haumea

Wonderful. I'll watch this space carefully. Just wanted to add that having the new integrator even without N-body would be great: things like realistic nuclear-electric propulsion and more intelligent trajectory planning would be invaluable even in the 2-body approximation. All in all, this will make flight quite a bit more difficult (we will really need a "charting table" more powerful than the current maneuver nodes to get around) but making realistic bi(tri/quater)nary star systems possible would be enough of a payoff? I'm leaning towards a "yes"

For anyone who is wondering, Billy-Bobs have been here for a long time.

You know what the problem really is, for me? I just don't believe they can make multiplayer work. Not in a reasonable amount of time, not with the mess they have made while working on simpler features. This project has gone too far to allow a refit of this magnitude.... it's what they have been saying all the time for almost two years, right? Then they see the kludge that is KMP, and suddenly multiplayer is feasible? They will lose loads of time that would be better spent on.... well, pretty much anything else, really. And if the problem is that they must concentrate on new players, I just want to say that I'm ready to waive my right to free updates as an early adopter. If you really need more money to develop ISRU, good aerodynamics, automation et cetera, just say it and make it into an expansion pack. I'll buy it. I think many more would.

I don't understand whether the "new main" chutes are two-stage drogue+main parachutes... if not, I recommend those Since lots of things seem to be in flux I think I'll wait for 0.23 to rebuild my modpack and add this one also, but great job!

This stuff is great, it's the new KSPX. Thank you very much. Also, have you considered making your own tech tree? With multiple grades of nuclear and electric engines, and many more possibilities for probes than in stock, you could make something which actually offers progression and challenge!

.....that's real scale?

I think the idea here is more about following historical progress better than just adding extra difficulty. Airplanes are hard, if you manage to do something worthwhile with them at the start (without top of the line parts, also) then good for you Especially if you have FAR - which this tree should be used with if it's a direct spinoff of Nathan's "series".

OK, I understand your point. I'm still not that sure about dumb rockets, but trying a few combinations of the small SRBs you're adding could be fun for the frst few launches Another thing: what about having thrust minimums on the (cfg)modded engines? Limited restarts would be realistic but also a pain, having limits to throttling is realistic and also has a gameplay effect - you'd have to include RCS/verniers to get perfectly trimmed burns, or leave trimming to an upper stage with a more modulable engine. A basic Mun mission would not need RCS, though. (Lander engines would have deep throttle, of course ) There is a minimum thrust parameter already in the .cfgs, it's just that nobody uses it (except the jet engines I think.)

After trying both, I'd say I like Majir's tree better. It allows you to make worthwhile probes earlier than the Yargnit tree. Though I think that more deeply modded trees like what NathanKell is putting together will be where it's at for old players

Are you going to make reaction wheels (heavier) or RCS available together with these "uncontrollable" probes, though? Otherwise I think it would be more pain for no compelling reason You know, maybe it's just me, but when you already know the game well having whole classes of mundane parts like RCS or ladders locked away because you are at a low level is just a bother and stifles your inventiveness instead of enhancing it. Even Juno I had an early RCS after all, to orient the upper stages package before firing it. I'm all for gyro-less probe cores if that means you have to include an (early, heavy) gyro or an early, low-Isp RCS system (cold gas thrusters?) to fly them; dumb rockets, on the other hand, would grow old very quickly I believe (And maybe you could find use for these cold gas thrusters in the following too, when you know you'll need just some brief maneuvering. What about gas bottles made from downscaled Stayputniks? Very light, but with an Isp of just 100?)

My suggestions: 1) I would keep the Mk1 Mercury not at first node, but near to the beginning: we can justify it with "spaceflight is easier on Kerbin", and I'd like to see it in the first position on the tree where it's very hard but not impossible to orbit it. 2) Tricouplers, adapters etc. should come early. They are quite low tech pieces of kit after all. 3) I don't think that LV-1Rs can be used for much as a first stage - I'd start with 24-77s available, then LV-909s and the 48-7S as the third level, if we keep to stock parts. For higher realism I think that mod parts like the ones OP uses are necessary.

Downloaded before 0.22 And I will also get TreeEdit as soon as you make it public. Thank you.

Will you release a KASA mod pack someday? Better yet, maybe you could write a KASA tech tree (you mostly have it in your head already), so the people who want challenge in career mode could follow your footsteps!

Ferram, this is very interesting and could make me switch to FAR for good, but I would respectfully make a suggestion: why don't you increase atmospheric density instead of killing Isp? We (well, at least me) got used by now to Kerbin being a planet different from Earth, with its own balance of gravity and aerodynamics losses which is different from what we experience here. All the other planets are also inspired by the Solar System but not really copies. Why not trying to mantain that experience in FAR by embracing the fact that yes, we are flying through pea soup? Kerbin's atmosphere IS seven times taller than Earth's in proportion, after all. It would also make spaceplanes comparatively more efficient, which should be good for people like us who install FAR in the first place

Oh, but we will have to timewarp anyway. There will be those weeks where nothing of consequence happens but waiting for a launch window. Also, I was thinking more about the mid and late game phases, where we will always be doing seven different things at once. When your space center gets too busy to keep up, you should always have the two options of brute force (build moar pads!) and doing something about turnaround times. Both would be legitimate choices.

A question: eventually, in the complete game, will the rockets still be assembled instantaneously and just appear on the pad ready for launch, or will the assembly require time and space like in BARiS? Personally I think that having a timetable to manage could be fun if it's not too hard - also, it would be a powerful incentive to getting right spaceplane SSTOs that would have extremely low turnaround times.

Well, no, but Kambridge university could be so thrilled by your results on Mun rocks that they will pay for the development of the engine you need for going to pick up Duna rocks

What Harv's post doesn't explain us is the way through which money enters this process, and I think that's an important part. For example, it could be a way to explain the connection between science and parts advancements - Science translates into Funding that pays for Engineering, flight experience directly improves Engineering, parts are unlocked by engineering points. Flight experience does not equal flight time - even when you launch a multi year probe mission, the first stage engines fire for just 2 minutes like always. Also, I think that flight experience with a particular component (subassembly?) should reduce its unit cost - that would give an incentive to standardization.

There is a very little difference actually: the Orbiter weighed 70 tons, not much more than the Buran, and it went to orbit too. 100t is the payload of Energija, which was non reusable (there were plans for reusability in the future, kinda like those SpaceX is considering.)