Tiron

...Uhhh...funny, because my testing shows it only uses about 600MB for the Maps, and that it doesn't vary with their scanned or unscanned status even the tiniest little bit. Which strongly suggests the memory usage is caused by the game keeping the decompressed versions of the maps loaded into main system memory, which there's absolutely no reason to do. There's also this: This is what happens when you suspend your system with KSP running. When you come back, the working set (but not the commit) drops to a SMALL fraction of its normal value...and stays there until you do a scene transition. What I believe is happening based on this behavior is that when the game goes through a scene transition, it's failing to unload all the transitional bits from the system memory. This means, for example, the decompressed versions of the planetary maps, even after they've been recompressed as DDSes and loaded into VRAM. The memory usage for the maps, based on my testing, is consistent with two compressed copies and two uncompressed copies of each map being stored in RAM. So if, for example, the game loads the PNG, decompresses it, hands it off to OpenGL, which Recompresses it as a DDS...well there you go. My testing seems to suggest that at most times, the game's actually only actively using something on the order of 500-800MB of RAM, and the rest is just bloat from the scene transitions. Edit: Forgot to mention. Simply not unloading things isn't in and of itself a bad thing. But it's clearly not treating them as cache that can be overwritten when needed, if this is in fact what it's doing. There's also some indications that the scene loading may actually have a memory leak, where it re-loads things that are still loaded from before. Not all the time, but at least some of the time. It's either that or just loading more parts as you do more things, but if that were the case in theory going into the VAB should pretty much do it all in one go... Someone that knows what the hell they're doing really needs to look at the memory usage during and after scene transitions though, that much I'm certain of.

There's a difference between 'Open Source' and 'Source Available'. The difference being what you have the rights to do: 'Open Source' generally includes the rights to distribute, modify, and crucially also to distribute your modifications. It's entirely possible to make the source available without giving up ANY of those rights. The key thing people might have misgivings about in that regard is that it makes it easier to rip off, although it doesn't make it any more legal. It also makes it easier to see when something HAS been ripped off, because you'd look at the source for Mod Y and see that it's using the exact same code as Mod X. The main thing there however is security: being able to look at the code and verify that it's not doing anything malicious before running it. Some people, particularly in the Linux World, feel so strongly about this that they quite literally won't use anything they haven't compiled from source themselves.

You're welcome. I'd just seen it a minute ago when I was looking at GAoA so I remembered. To be fair it appears to have only been started a month ago, roughly.

http://forum.kerbalspaceprogram.com/showthread.php/44738-License-Selection-Guide

Not really quite accurate. Usage is only 'impractical' to people that insist on using a large number of memory hogging parts packs. The misconception that it 'causes problems' arises because it uses almost no memory at all when it's not being actively used(Which is actually good practice). People consequently fill up their memory with parts packs and don't leave it any room, and then grumble about it crashing the game when they try to use it. It's really their own fault for not leaving it enough space. The high memory usage in general might actually be a bug, based on what I've seen. It kinda looks like the game's keeping stuff it only needs temporarily during scene transitions in Memory at all times. I'm really the wrong person to investigate though, as I'm a tech, not a developer, and consequently I'm not at all sure of this. Second, he hasn't abandoned it, he's just been working on other, non-KSP projects. He hasn't updated it because people have told him it still works in the current version, which it does. If it breaks, I'm pretty sure he'll fix it.

It highly depends on the mods you use and how you use them. Doing it all stock is frequently harder, but mostly it's in the realm of what TV Tropes calls 'Fake Difficulty'. Protractor, or some external tool or resource providing the same functionality, is almost NECCESSARY to do interplanetary at all, because the current UI doesn't help at all in determining when and where you need to burn to reach your target. It's a case of the UI being deficient, presumably because it's unfinished, rather than actually adding extra difficulty. Most other informationals aren't strictly necessary: It's always possible to just eyeball it, and that's how I landed on Duna the first time: I took my Mun lander that had way, way more Delta-V than it needed and brute-forced it to Duna (with some help from the Protractor). And the simple fact is, if you really wanna cheat your way through the game? I could make a copy of a LV-T45 with the stats of the real-life J-2X. Thrust halfway between a Skipper and a Mainsail, Isp a bit better than a LV-909, weight a bit less than a poodle. I could make a LV-N with a tenth the weight, 20 times the thrust, and 50 times the efficiency. I might even be able to make one PRODUCE fuel rather than burn it. (Haven't tried, they may have a check that Kethane's plugin sidesteps.) You'd never be able to tell any of that from screenshots. The parts would look completely stock, even though they didn't perform that way. I'm not trying to get the challenge shut down, I'm just saying it has stupid, elitist restrictions. Which it does. Which I don't personally think justify having a second challenge for, which is why I've never bothered entering it. I swear I entered the other one though...don't see it now. Weird.

Well that's the sticky part, because motive does enter into it somewhat, and that's almost impossible to judge. Some people do like to try to be a little more subtle about it, but usually only to a point. A couple examples I've seen that are at least pushing it this way: "I Fly Pure Stock" underneath a Ribbon Salad bar. 'Kerbin Circumnavigation Challenge - Reloaded': I circumnavigated multiple times with a plane that only had an ISA Mapsat GPS and a Mechjeb AR-202 on it for non-stock parts. Even if I took them off and did it manually (which would've been a major pain in the butt before the new SAS), I still technically wouldn't be eligible simply because they're INSTALLED(Although he wouldn't know that from screenshots.) The current version of the plane has multiwheels landing gear as well. All things that don't affect the ability of the plane to fly at all. The all stock version of it I uploaded on spaceport could do it no sweat, but the sheer asininity of a blanket mod ban rankles too much to bother doing it. There's a reason there's two circumnavigation challenges. Edit: I forgot to mention, the title might not say as much, but the image at the top of the thread says 'ELITE CIRCUMNAVIGATOR' with a device in the middle. Some people put it next to their salad bar.

In and of itself using only stock parts or even saying you only use stock parts, is NOT elitism. Saying that you're BETTER because you only use stock parts is what's elitism. Unfortunately that's the usual reason why people say it: "I'm better than you because I play all stock." Even if not outright stated it's frequently implied. And that, ultimately, is what the thread is about. Not people that go all-stock because they prefer it that way, but people who condescendingly sneer at mod-users. It's 'Why the Hate Towards Mods' not 'Why do some people not use mods'.

And docking ports. If you pair up docking ports facing each other but unconnected in the VAB, they'll auto-multidock when the physics loads. Although that's still just a physical connection, like the struts, only with more joints inbetween...

The problem there is he's assuming the same mass, Delta-V, and TWR. It's basically impossible for that to happen on an actual rocket, because the engines vary in mass, thrust, and TWR. Generally, a craft with a lower Isp engine is going to have to carry extra fuel to end up at the same delta-V, which is PROBABLY going to increase the weight and negate the bonus. The thing you DO run into on practical designs is that less efficient engines sometimes weigh less than more efficient ones: The LV-N is particularly bad this way, because it weighs 2.25 tons. What can happen in this case is that the delta-V gain from the decreased weight can more than make up for the loss in efficiency. My mapping probe's upper stage for example, consisted of a FL-T800 with the scanners, probe core, batteries, solar panels all just stuck onto it. It turns out it actually has MORE Delta-V with a 48-7S or a LV-909 than the LV-N, simply because they weigh so much less and it was such a big portion of the thing's weight.

You should really read better: I never said or even IMPLIED that everyone that insists on going 'all stock' is an elitist. I myself, for example, have tended to go rather light on mods because I found many of the parts packs to be unbalanced, lacking in things necessary to do things the way I want to do them (a problem I'm STILL dealing with now that I'm really giving B9 a serious shot, I'm on the verge of deleting it again at the moment,) or simply not seeing the point. The key is to some extent why you're doing it, but it's mostly behavior. If you're going around on the forums bashing on people for using or not using one or more mods, claiming that your preferred stance makes you superior, you're an elitist. Denigrating other people based on what they do or don't do in the game makes you an elitist, regardless of how you play the game and why.

It's just another incarnation of elitism, and it actually goes both ways. As evidenced by a few people in here denigrating the 'no-mods' people. The key thing that differentiates this type of person is that they're seeking to make themselves appear 'Superior' to some group of people because they do something 'Better' than the people in that group. They may say it's actually about the challenge, but if they're waving it around and using it to insist that they're 'Better' than someone else...well, they're at least partially lying. It comes down to insecurity. They try to make themselves feel better by trying to make other people look worse. It's just a different, less impactful form of bullying, really. If 'the challenge' is what they were concerned about, they wouldn't feel the need to denigrate the accomplishments of others. I can also say from personal experience that if 'the challenge' is what you're worried about, you equally don't feel the need to cheat, and actually find it undesirable because it removes much or all of the challenge. Which is why it was funny when I read an article once basically claiming that I was the only person on the internet that has never cheated in multiplayer. The article said pretty much flat out that EVERYONE had at some point. Knowing with a certainty that I never had because I never saw the point AND don't find succeeding by cheating enjoyable... made it slightly comedic.

Yeah, Squad has a habit of forgetting to check the positions on them when they redo the terrain. When they added the non-Munolith eggs in 0.18, most of the Munoliths ended up floating or buried. So now all the non-Munolith ones get the same treatment. I did report a buried Mun Arch I found back in like 0.16 or 0.17 or so, and surprisingly they moved it above ground in 0.18.

Actually that one's been below ground since the previous time they messed with the terrain, in 0.18. You know, when they added the big crater and stuff.

Honestly, there isn't a huge amount of point if you aren't encrypting your hard drive, not from a security standpoint anyway. Last I heard, and I've got no indication it's changed, windows login's password storage and setup aren't really all that well protected. My understanding is that with physical access to the system, a bootable USB drive or CD, and the right software, you can break it wide open in a matter of minutes. At most. The Bootable CD/USB isn't strictly speaking always a requirement: particularly on older versions of windows I'm led to believe you can do it within windows. I suspect the advent of UAC has limited this somewhat, but it's still nothing like robust. The only thing it's really useful for is keeping people from using it casually. Anyone that seriously wants into it and has half a clue what they're doing can get in. Drive encryption, on the other hand, is an entirely different critter. But frankly an EXTREMELY paranoid one for most purposes.

Something like that. With the Squad logo on it. It used to float pretty high off the ground, and I'd wager it still is. Last time I found it was by using a plane with a bunch of lights mounted on covering a fairly wide angle (though I used the long-range narrow angle lights, just a bunch of them), and flew out there at night. Seemed to work pretty well.

No, the terrain error spot you found isn't the anomaly, those are all over. You'll know it when you see it. They can be hard to find though, because as the guy before your most recent post mentioned, the terrain got changed and it's screwed up some of the anomaly locations. Granted, some of them were already floating far above ground, or buried underneath. I might suggest checking closer to home for a more accessible example of the most common type of anomaly.

I saw a thing in a thread here a few weeks back where someone had done an analysis of the loading and determined that one thing took longer than anything else: Textures. Textures are also the number one Memory Hog, so far as I'm aware, and I'm guessing the two are related. It seems to me that it's not that KSP is slowing down your SSD, it's simply that it's taking awhile to process the textures (and using a ton of memory doing it.) Your SSD Helps get the textures into the system faster, but frankly...even Mapsat's huge maps are only 2mb compressed. It's not getting them off the hard drive that's the problem. Now if we could use DDS textures and not HAVE to send them through processing to load them...it'd probably make for huge load-time AND memory usage gains all around. If it was done right, anyway.

My understanding is that the drag is calculated by a method involving the mass of the part and the 'drag' stat of the part being multiplied. ANY Extra mass increases the overall amount of drag. What you're describing is partially true, but only as regards the Center of Drag. One of the more bizarre effects of this is that an atmospheric craft's drag drops as it burns off fuel. My modified Ravenspear Mk3 for example gains several hundred M/S and several kilometers maximum altitude as the fuel burns off. In stock, anyway. The key thing is that all parts have their full drag all the time: there's no 'shielding' effect. In reality, nosecones and fairings DO actually reduce the total vacuum Delta-V of the craft because of the extra weight. They're used because they more than make up for it in reduced drag losses and preventing damage to the payload on the way up. One particularly notable example of this was NASA's Orbiting Carbon Observatory Satellite. It was launched on a Taurus-XL 3110 from Vandenberg on Feb. 9, 2009. The payload fairing failed to separate when it was supposed to, and the extra weight caused the craft to have insufficient Delta-V to make orbit. It crashed into the ocean near Antarctica. If you add nosecones, adapters, or any other such 'aerodynamic' part, you're just reducing the Delta-V of your craft by adding weight AND drag. Unless you use FAR, in which case you BETTER use those aerodynamic parts if you know what's good for you!

Hrm, I've removed parts from craft in flight before without any problems. The key thing is to make sure you get ALL the references to it. I don't know what it does if you fail to do so in the save file itself, but if you miss a reference in a .craft file it screws the game up something fierce when you try to load it. The key thing here is that the link system works by putting a reference to the link on BOTH SIDES of the link. So the winch contains a reference to the connector, the connect contains a reference to the winch, the winch contains a reference to whatever it's attached to, and whatever it's attached to has a reference to the winch. The VAB really, really hates dangling references (it actually locks the edit up and you have to force close the game), and I can't imagine the actual game handles them any better. You'd have to get anything that was radially attached to the winch too, and all the references to that as well. The connector, at minimum. Barring that, heck, I don't know...it always worked for me.

Okay. Here we are. Starting in the VAB with the first part of the setup put together. My mockup here has a Okto2 on top of a Rockomax x200-16, with a PB-NUK on top of the Okto2. On bottom of the -16 are 3 LV-Ns. I first place a small stack separator on bottom of the LV-Ns, using symmetry to put it on all three. I then attach another tri-adapter in such a way that it appears to be connected to all three of them. I then spend some time mousing over all the engines and the decouplers. There's a reason for this: When you mouse over a part, not only is it highlighted, but all of its 'child' parts are as well. Every part connected to it, and every part connected to those...and so on, as far down the tree as it needs to go. At least it's supposed to do that, it wasn't when I was hovering over the stack separators for whatever reason. First thing you'll note, if you watch carefully, is that the only things that cause the bottom tri-adapter to be highlighted is hovering over it, or hovering over a specific one of the LV-Ns. Hovering over the other two does not highlight it. This an indication right in the VAB that it's not connected to those two, but I took it a bit further just to make it explicitly clear. Having used that method to determine which of the stack separators the tri-adapter is attached to, I mark it by placing a linear RCS port on it. I could've also just split it out into its own stage, but decided it'd be clearer what I was doing if I didn't, thus the marking. I then 'launch' the craft. While sitting on the launchpad, I right click the marked stack separator and select 'decouple', which causes only the selected stack separator to decouple. Predictably, the Tri-Adapter falls off as well, leaving the other two Stack Separators attached to the bottom of the other two LV-Ns and demonstrating that they were never attached to the Tri-Adapter in the first place. This test can be duplicated by anyone that thinks they've found a way to make this 'work'. When you decouple the singular decoupler that's actually attached, the entire bottom part will be disconnected. Any struts stabilizing the connection should break automatically when it disconnects. I don't use quantum struts, so I'm unsure if they will disconnect or not. I've heard tales of them grabbing onto debris before, so it's possible they might re-grab the bottom half and hold it in place physically, even though the two parts are now separate craft. I would hope that's not the case however, as it seems like it could make the quantum struts hard to use.

If it's connected, why do you have that big ring fairing with a bunch of quantum struts in there to hold the joint together? Because the joint was floppy, due to only one of the stack separators being attached to the bottom tri-adapter. Again, it's the struts holding it together, and two of those stack separators are just extra debris. I swear, I'm gonna see if I can't make a video just to demonstrate once and for all, single multi single is NOT possible.

Errrr....no. You want to burn Prograde shortly after Munrise (assuming you're on a 90 degree inclination, Eastward orbit.)

That rocket should definitely be able to make it to the Mun, as I'm fairly certain the stock Kerbal-X is perfectly capable of managing it.

There are only two saves: the 'Autosave' (Persistent.sfs) and the Quicksave (Quicksave.sfs). Both are automatically overwritten when a new one is made. Quicksaves are only made when you press F5, and only loaded by holding F9 (which WILL overwrite your autosave, so be careful.) If you're on a new enough version of windows and supremely lucky, you might be able to recover an older version of one or both of them using the 'previous versions' feature. To do this, you need to navigate to <KSP Root>\saves\<Save Name>, right click on the file, hit properties, and then go to the 'previous versions' tab. It will take a few seconds to bring up any results, as it searches through system restore points and any windows backups you've made for older versions of the file. In your situation this probably isn't going to help much, because even if you're very lucky the most recent you're likely to find is one from yesterday.