phoenix_ca

The values in the cfg files suggest that, yes, every part can have heat conductivity. But I have no freaking clue what those values do. I've been experimenting with heat radiators and generators using PowerTech, but they tend to explode in atmo, and the lack of any feedback about heat levels is the most difficult part. I might need to do the testing in space (annoying but necessary).

Realism? Kethane on the Mun? Little green men with hilariously over-sized helmets made of scrap metal found by the side of the road? What? Your logic no make sense. It occurred to me the DEMV Mk II would be a great companion to this mod. *ponders on that*

A longer but less powerful burn with an engine of much higher vacIsp will be more efficient though. The only note about that is it's more important to start your burns at appropriate times; that is, start them early. A 30s burn starting 15s before periapsis will have a similar effect to an instantaneous delta-v change at periapsis, or at least, it spreads-out the unwanted effects. NERVA engines can be annoying like this, and I'd suggest against using MechJeb for large orbital corrections for that reason (MechJeb always starts a correction burn on the assumption that the total delta-v required can be delivered instantaneously; to do otherwise requires more calculations based on TWR, the burn's vector, Isp of the engine, etc...it's...quite a bit more math).

Create a torrent. Only logical way to go about uploading so much data, really. O.o

Indeed he is! Sagan was a huge inspiration for him, and it's quite suitable that he do such a project. I'm pretty sure it's a PBS project.

There's an explanation of the command-line arguments for ISA_Map_Gen.exe in the first post.

There's also EEP, EPS, and PowerTech, carts, Erkle's Warp Clamp, MMI Kethane, ORDA, and Orbital Construction, off the top of my head.

Jiggly map lines or no, it's still nice to have a temp fix. Most important is that you've quashed the lag-a-licious error (though it kinda underlines a good programming lesson, and that's to use exception catches where you can . And thanks. I'm running Windows right now (I don't do any development in it, as a basic rule...the command line is atrocious >.< ) while I play KSP.

Okay, this is a very neat project. (And hell, I really loved that series by Hawking, especially the creation of the universe part. Such an elegant, simple answer to why the universe can be created from naught. Math is quite incredible.) Regarding memory consumption, that isn't the limiting factor on performance. The limiting factor is the fastest single CPU core available. KSP is single-threaded, and 32-bit. The most RAM is eaten-up on loading, when it reads part files from the HD and allocates all that data to memory, but if you have enough RAM to load KSP, it's safe to say you have enough to run it. The upper limit on this is a bit over 3GB, because of the limitations of 32-bit memory addresses. Doesn't matter if you have a 64-bit processor and OS, the program is 32-bit, thus the memory limit. Since it's single threaded, only one CPU core can be used at any one time, meaning that there is no benefit from having two, four, or eight cores: KSP's performance is limited to how fast one core can execute all of the calculations, in sequence. There are good development reasons to avoid the pain of multi-threading, not the least of which is that it's incredibly complicated to write multi-threaded software, and Squad isn't a huge company that can just toss a whole team of programmers at the problem. So, in short: If you want more performance from KSP, a CPU upgrade is in order. Increases in clock speed are better than increases in number of cores. Overclocking the CPU would also help, though it's a bad idea to do that if you don't know what you're doing. (Ideally to run KSP, you'd get the highest-clocked processor you can find, with two cores so that KSP can easily monopolize one core without freezing the system, and then liquid-cooling it so that it can be OC'd to absurdity.) Now that I've straightened that out, here's what I suggest to improve performance of the ship: 1. Don't even try to get it off the launch pad. Just skip launching it. "Construct" it in orbit. When docking is completed you might be able to do this in a non-haxxy way, but for the time being, either hack the thing into the persistence file by launching a smaller ship that'll launch without issue into orbit and then replacing that ship's data in the persistence file with the data from your project ship. That, or use the Orbital Construction mod if you feel that's "cheating". (Though it's extremely unlikely that we'd ever launch something so massive from the ground in the first place, so claims that hacking the persistence file in such a way is "unrealistic" is just silly.) 2. Reduce the number of parts required by creating new parts, and/or using parts that already fill this role. Gaby's payloads mod has a huuuuuge fuel tank that is just one part, but the equivalent of a lot of NP tanks + struts. So it's the stupid number of tanks, without the lag. 3. Straight-up cfg edit things to your will (edit: even more than you've already done). Make the tanks hold lotsa fuel, or more realistically, make the engines have very, very high vac Isp. (Any such ship would need to have such engines.) Some judicious edits to those files would let you keep the look of the thing, without needing to go overboard with parts. Setting a parts-budget goal of around 200 would be a good target if you want to share it.

Uh...I assure you, that as a child, I may not have had "rocket parts" in my bins of lego blocks, but I made a lot of spacecraft for exploring new worlds. Those new worlds might have been my bedroom carpet, or the cold, grain-like surface (with odd flat, rocky, marble-like slabs at regular intervals) of the living room coffee table...but they were spacecraft none-the-less. Yeah. (That said, I lost touch with Lego when the brand moved toward much simpler designs that had less flexibility for customization and depended more on specialized parts. That got boring, fast.) I too wouldn't mind a stuffed Jeb.

Indeed. That joy is quite contagious too. Sagan inspires me, though in different ways. I'm in awe at the vastness of the universe, but since ethics and morality are my "thing", it inspires me to look for a scientific basis for ethics that is universal...which is incredibly hard, and we're nowhere even close in philosophy to figuring that one out.

Whatver. I lol'd. (Those Quebec bunnies are very, very strange, btw. Actually, Quebec culture is odd in general, from the rest of Canada's PoV. That said, best goddamn jazz scene in the country...okay tangent over.)

So...am I correct in the assessment that the lot of you have fixed-up the plugin, removing the lag and adding the map lines? Because if so...might one of you be willing to compile a dll with the fixes for the rest of us? P.S.: Nice work everyone. I'm all happy and stuff now. RCT is the one update I've been waiting for before I got back to any serious space exploration in my main persistence file.

In the real world, yes. But right now, re-entry heat hasn't been modeled yet, so it's entirely possible to send an object zipping around with a periapsis of 3km in a dense atmosphere without it turning into molten slag.

Using RCS for stability on higher stages may indeed help. Also, turning-off ASAS may help stability. The problem with ASAS as it is is that it can cause severe oscillations in rockets that have a certain amount of instability (typically, anything that's tall and pointy...like a rocket). It corrects, but doesn't reduce the speed of it's correction until it passes over the point it was aiming for. Then it corrects just as hard back the other way, overshoots, and so-on. Both stock ASAS and MechJeb suffer from this. If it finally over-corrects too much, such that it can't correct it's over-correction, the result is the whole rocket flipping. So if you notice this back-and-forth oscillation, taking manual control for a bit may help matters. You can use ASAS when the rocket is more inherently stable. Reducing throttle may also help.

Most likely case. I suggest using MechJeb to confirm what your current TWR is at that point, because it gives you an updated TWR at all times in the Vessel Information panel.

Indeed. Not going to happen in a patched-conics system, I'm afraid. As noted the best option would be to go into the Sun's SoI, and set-up an orbit that's the same as Kerbin's, ahead and behind it. The only way to put the satellites anywhere else would be to put it on the Kerbol-Kerbin L1, which won't happen because it's not modeled, and would require n-body math to do. In short, not gonna happen (as cool as that would be; there are very good development reasons to not add Lagrange points, as Harv explained...somewhere).

Wait, there was a Swedish meal time reference? I love those guys! They're totally nuts. That and they make the "manliest" (most likely to kill you in one serving from fat content alone) meals. (I admit I skipped through a lot of it just because it's not covering much I don't already know. O.o ) Edit: Mmmmm, brain meats.

Note that with each successive calculation, the result becomes more inaccurate. I'd imagine 20 would be really off-the-mark.

That looks like it will orbit around the L2, not actually be on it. Of course, that's liable to require quite a few more course corrections, but the telescope will almost undoubtedly be less massive than a space station for humans, so it would make eminent sense to put the most massive object right on the L2, so that you spend the least amount of propellant on course corrections over all the missions combined. (And...hey, if we had a space station out there, they could service those telescopes with ease if they ever needed some more fuel.) I dunno. The UK has the ESA to work with. It might make more sense purely from a budget point-of-view to keep with the ESA and just leave it at that, since you're probably getting the same benefits for less money. (I say probably because honestly I don't know any of the specifics, so tell me to shove a boot in my mouth if I'm totally wrong. )

Price tag of billions of dollars? Come on. This is SPACE people! There's nothing more exciting than reaching beyond our planet and seeing what's out there...except for maybe reaching deep into the depths of the oceans, which is in some ways even harder. O.o (Also, it always struck me as a little odd how much we money we are willing to, as a species, spend on killing each other vs. how much we spend on the advancement of science for mutual benefit...actually, it's rather depressing.) New news to me. Thanks for posting it.

Sounds like Ghost in the Machine stuff. O.O j/k

Keyword "currently". MMI.S will be switched over to use EEP eventually.

If you want a controllable arm, I would suggest creating models for parts that use the Damned Robotics mod. It'd give the end-user a lot of flexibility in terms of what they do with it and how. And, I've been hoping someone would come along and do Curiosity for a while now. Bonus points if you make it shoot lasers. (Or one could always just slap on a laser from the Lazor mod, I suppose. Not sure if they'd fit...)

That one extra variable throws a big wrench in calculating intercepts, and even if eccentricity were accounted for, then there's inclination relative to the sun. Eventhough it's simplified (thankfully) since KSP doesn't use n-body math, and a patched conics system instead, it's remarkably more difficult to go from calculating intercepts of two children of one parent body on a flat plane, where both have 0 inclination and 0 eccentricity, to calculating intercepts where those numbers change. People are working the problem, from various angles, but it's going to take time for anyone to get it done right, since it does involve complex math, and when you start doing complex math with computer code, things sometimes get wacky. (Floating point values are both a blessing, and a curse, sometimes. >.< )