asmi

Yes I know about this bug and I've been trying to fix it for the whole this weekend, unsuccessfully so far But I won't release anything until I fix it.

If it's going to be true N-body, than the more stuff is in space, the slower performance would be. In practice it's quite common to cut off bodies that will have negligible impact on trajectory. But that would allow you some very cool stuff like putting a satellite around your huge space station

That is why I'm not going to introduce power requirements until I get around to simulating internal atmosphere. With that said, I'm not gonna stop anyone from modifying configs in whatever way they see fit.

I used code for algorithm from that post as baseline: http://forum.kerbalspaceprogram.com/threads/49121-On-Newtonian-trajectories-vs-patched-conics and that post for more detailed description: http://www.roesle.org/cms25/index.php/projects/81-general/95-on-newtonian-trajectories-in-kerbal-space-program The code uses Dormand and Prince's Runge Kutta RK5(4)7M. It uses adaptive time step and also provides coefficients for fifth order interpolation. The idea was to precalculate trajectory to set amount of steps ahead, and use these points and interpolation to actually move spacecraft. This way we would only need to recalculate the whole trajectory is there is some sort of dynamic event (like applying the thrust, or entering atmosphere). It provided pretty good accuracy, and would be relatively cheap since you could calculate additional data points in the background. Unfortunately due to spare time constraints I never got to the point of getting it into KSP, but was focusing on profiling algorithm's performance and used simple WinForms app for ease of testing. If you're interested I could try to dig out that code and send it to you. Oh, and I used whole KSP celestials (orbital and physical data is taken from wiki). Time step have to be adaptive, as sometimes even 10s is too much, while in other cases 10 days is OK. And why ion engines are so special? There are plenty of other low-thrust engines, besides it's not the thrust is what's matters, but acceleration they can provide.

You should really read Mike Foale's memoirs, and you'll know how he and his crewmates were ventilating the station without electricity for 2 days And thermal control is usually not an issue since when there is no electricity, no devices are working and generating that heat either (since they use that very electricity), besides space stations are usually quite large so it will take a long time for them to cool down enough to cause any concern for the crew. But all of that is beside the point anyways. I do want to eventually implement proper atmosphere modeling, but not in this version for sure.

That might not work for performance reasons. The best I've managed to get 100k steps of RK5(4) executed is in about 1 second if my memory serves me - that it's on powerful i7 3930K CPU with significant portions of code written manually on SSE2/3 intrinsics (=assembly). And in your case it will have to be done in addition to regular updates calculations. You could probably run it for t and (t+dt) in parallel on separate cores if you write the code carefully not to use any shared state, but experience with my mod (which is heavily parallel and extensively uses all available cores) indicates that there are enough users here with relatively weak 2-core or even 1-core CPUs.

That is not true. I use vs2012 for my mod projects without any issues.

And that's exactly what I meant when I said

Very good development, I've attempted something like that myself but run out of spare time so it was never finished. I just want to comment on one thing. My experiments have shown that using long double is non-starter in terms of performance. I used doubles and written a host of vector madd (multiply+add) functions using SSE2/3 in C++ and C++/CLI as "glue" interface. You can theoretically make them even faster if you utilize AVX commands, but that would severely limit users who would actualy be able to run it as these commands are relatively new, while SSE2/3-capable CPUs are widespread. Since I used RK5(4) integration which is not much except a ton of madd's and got very good performance out of it. However there are few things to consider: 1. mixed-mode C++/CLI does not conform to CLR specification and as such it is not given that it would work under Unity - I haven't actually tried that and was focusing on optimizing algorithm performance. 2. Unity is cross-platform and runs on MacOS and Linux. Again I'm not sure that mixed-mode would actually work on these platforms. 3. To make matters even worse, there is 64-bit version of KSP for Linux so you would have to ensure you provide 64bit binaries for that platform.

I've made a conscious decision not to consume electricity for basic functions since that would either lead to nonsensical results like kerbals dying 'cause they run out of power (Hello, Mir! guys there would be dead if that was true.), or require more realistic simulation of internal atmosphere.

I'm actually worse - Nathan himself said so The math is actually surprisingly simple. It's basically a vis-viva equation plus some trigonometry to figure out inclination change and launch azimuth to 51.6 orbit from Baikonur's Site 1. I don't quite know how could I make a video out of tons of my paper which I used to figure out formulas so that I could stuff them into Excel The actual mission was totally automatic from parking orbit insertion - I programmed everything into RT on the pass over ground station following insertion, and then the rest or it was just watching events unfold and timewarping as necessary. It was exciting for me precisely I knew what it took for me to figure it all out, but I doubt anybody else would find it so interesting.

Please don't get too excited about it just yet. Unfortunately I can't do anything during work week these days as I leave home at 6:30 am and come back at 8:30pm every day, so the only time I've got is weekend. Public beta is still at least a week or two away.

I mean this pack: http://kerbalspaceprogram.com/0-22soviet-engines-pack-v1-0/ It contains very realistic 1:1 models of several real life Soviet/Russian engines. Just make sure you DON'T install "0.64-ization" folder. Indeed that could be RF issue. Will talk to Nathan once he gets back home. It's probably RO, but I was just writing whatever issues I remember to run into over weekend's testing. It's the latter one. That actually makes sense. I would probably think about doing the same for structural parts (like girders) - since once you get access to smaller ones you can always build larger ones and the only issues is you gonna run up parts count. I'm at work too, so I'm writing that stuff as I recall it You're very welcome! Honestly I was very proud of myself after I've managed to calculate entire high-orbit mission using pen, paper, calculator and Excel, and then programmed it into RT's flight computer to watch it unfold! So kudos to you for putting this all together! Another thing I just recalled - maybe you can consider splitting second "manned" node and making 3man pod available earlier (and cheaper) than the rest of the stuff. The reason is I balance my ECLSS so that 1man capsule would have consumables only for 2-3 days flight (so nominal use would be early Vostok-like missions, plus shuttling crew to and from LEO stations). Besides it make sense to force player to send multi-man crew to the Moon for mission safety standpoint (yes don't tell me about N-1 - I know all about it ) And you can also consider adding separate nodes for space stations (using BobCat's Soviet pack - you can create entire Salyut-Mir series using DOS part from his pack) - and maybe some station experiments - like staying on a station for X amount of days? That would be cool!

I've been playtesting 2.0 whole weekend and found a bunch of issues. Once I fix them I'll do another round of playtesting, and then put out public beta.

Thanks! And few more things if I may. I've been playtesting ECLSS 2.0 whole weekend and since I couldn't make myself play KSP without RSS for any significant amount of time, I've been going through your career tree. 1. Please stuff BobCat's Soviet Engines into appropriate nodes. Right now they all are in a single node (500 science one - forgot its name) which doesn't make a lot of sense - for example RD-171M shows up before RD-170 And once I got that, I could delete pretty much all the rest of the engines as these are enough to get just about everywhere. 2. Make AEIS and NP packs required instead of optional since it's impossible to get to GEO with only KW engines (I've tried that and was not successful even when I clustered a ton of them, but I was launching from Baikonur (45.9 north latitude). Also revisit engines heat production as that early RL-10 overheats way too quickly if the stage is large enough - which is counterintuitive BTW. 3. There are issues with certain engines' attachments points (but I guess this is more of RO issue than yours, but it still affects the end result). For example, Ariane-5 US engine's bottom attachment point is in the middle of the engine, as result it's impossible to attach lower stage to it. 4. Aforementioned "500-science" engine node contains engines that are wider than 3m which is the widest fuel tank available. 5. I'd suggest you to revisit fairings' positions in the tree as getting that 500 science node requires launching stuff above GSO, which requires "building" solar wings from girders (example here)and that requires using wide fairings (I used 4m KW Fairings modded by Nathan for me to launch that example, which oddly enough ended up being in planes node). I play with RT and a player would probably have to launch at least one GSO sat so that he'll have comm coverage near apogee to actually run experiments. I've managed to come up with the way to do it using RT's flight computer (which allows you to pre-program just about any sequence of events, invoking action groups, stagings and so forth so that they could be executed without comm coverage, but I had to spend almost an hour in Excel calculating exact mission profile and timeline to get timings just right).

No, it's a part of the "main" NP package.

Can you please also include NP's escape towers to the tree?

Forgot to mention that in real life with right timing it's possible to launch from KSC directly into lunar orbit plane. Here is what direct intercept looks like: This one is 3184 m/s deltaV. The Russians have been always flying to the Moon like that since plane change from 51.6° is prohibitively expensive.

Not sure about that (didn't install these mods as I'm running on the edge of memory limit already ). I'd suggest you installing this mod: http://forum.kerbalspaceprogram.com/threads/58135-TechTree-0-22-Milestone18-Realistic-Progression-LITE-%28Get-on-TreeLoader%21%29 and all related mods which are mentioned there. Biomes are not adjusted (yet) for RSS Earth though. FAR works just fine, as for DR - RealismOverhaul takes care of that.

I play with MedievalNerd's carrer mode, so no ion engines...yet. Using limit acceleration is unrealistic and since the whole setting is meant to be realism, it's kinda buzzkill Here is my moonar science sat right after entering Moon SOI and separating booster on collision course:

There is no need to plane change. just proper timing. I've launched a mission from Baikonur (220x220x45.9° orbit) and then went for direct intercept from the line of nodes (that guarantees that you intercept orbit, and with right timing the Moon itself). Once you near apogee, you can do whatever plane change you need to aim for landing (in case of free-return-like trajectory) for just few tens of a deltaV since your orbital velocity is really low. For GSO sats (I use RemoteTech) I use three burn profile similar to what is used in real life (check here on page 2: http://www.ilslaunch.com/sites/default/files/pdf/TURKSAT-4A%20Mission%20Overview%20final.pdf ). My GSO sats require to have about 2400 m/s of deltaV as they complete GSO insertion and plane change at the same time. 1. LV delivers orbital unit (space tug + satellite) to suborbital trajectory (-10x220x45.9°) 2. First burn completes orbital insertion (220x220x45.9°) 3. Then at equatorial node (either AN or DN depending on target GSO position, I use MJ to find these nodes - "Time to equatorial A[D]N") I do second burn (220x35875x45.9°). This way apogee will be exactly above equator. 4. Unlike a real life, I separate my comsat at that point and later dispose of the tug via small burn at apogee. 5. At apogee I do a circularization burn combined with inclination change (total dv is about 2250 m/s) - I use excel spreadsheet (essentially vis-viva equation plus cosine theorem) to calculate direction of that burn at exact dV as function of transfer orbit and then stuff numbers into RemoteTech flight computer. I use RT's flight computer to pre-program that whole sequence so that I could turn off antennas to save electricity right after completing orbital insertion, and re-enable them once the sequence is executed to fine-tune final orbit - that mostly involves fine-tuning orbital period so that it would be exactly 23h56m4.09s - my comsats have small amount of RCS for that since it's hard to get it right using main engine only.

If I may suggest modifying support for BobCat's real engines - now all of them are in a single node that is far before they were actually developed.

MJ's maneuver node editor allows you to do that if my memory serves me.

All of that (except for centrifuge) has already been done and/or is still happening to certain extent. First seed-to-seed full growth cycle in space was first completed onboard Mir station in 90s, current RSOS has greenhouse. Speaking of growing stuff - research onboard Mir have shown that growing crops not only gets food, but also have very positive psychological effect on the crew.

USOS has been designed the way it did because there were shuttles, not the other way around. And honestly I gotta say I prefer Russian way of doing things, where they can assemble the station all automatically even before first crew arrives. Imagine that we're building a station in lunar orbit. If done in "Russian" way (unmanned) in can be assembled and checked out before crew comes in, and in case of some contingency they do have a safe shelter that is a station, while in case of manual assembly they could be doomed as it is not known if station would actually be available prior to crew lift off. And using SRBs for manned craft without abort is just accident waiting to happen - it's not a matter of "if", but only "when".