Tiron

You can't, in stock. There's http://forum.kerbalspaceprogram.com/showthread.php/38577-0-21-UbioZur-Welding-Ltd-Lower-your-part-count Which has some 'Pre-Welded' parts (actually new parts made out of multiple stock parts), and purports to be working on a plugin that I'm assuming might actually allow you to weld parts together. Until then, there's nothing. Not that I'm aware of, anyway.

Spaceplanes that are really pushing it weight-wise can be really, really difficult to fly with the keyboard and mouse, particularly if you're using FAR and the drag variations it introduces. Rockets, on the other hand, you don't really need one for, I don't reckon.

Basic, relatively cheap, and works really well. I've got both an Extreme 3D and a Freedom 2.4 (which is basically a wireless extreme 3D with a different base and 2 fewer buttons,) and they're both quite good (Although the Freedom does have a metal trigger and throttle, and thin metal plating on the upper backplate behind the thumb buttons, while on the Extreme 3D they're plastic). Been using the Extreme 3D lately because my battery recharger died on me (it was throwing sparks out the ventilation grill last time I tried to use it!) Seems more stable than the Freedom, which would sometimes tip if you threw it over hard enough in the right place (But then the Extreme 3D has a big (@% metal plate in the bottom of the base, which seems to be where the extra stability (and weight) derives from.) But I cheated and put the metal trigger and backplate from my first 2.4 (which died on me after several years of use) on the Extreme 3D (the throttle wouldn't fit, different bases.)

Part of the definition of an 'Exosphere' is that it's so thin that it ceases to behave like a fluid. The molecules that are present are so spread out they basically don't interact with each other. The drag in such an environment is effectively negligible: Even Low Earth Orbits that are still within the Thermosphere frequently have decay lifetimes measured in years. Vanguard 1, the US's second Satellite is still up there, in a 3969x654 KM orbit. The edge of the Exosphere varies between around 500 and 1000km depending on solar activity. Current estimates it'll probably be up there for around another 240 years or so. At the altitudes LADEE is going to be at, Tidal Forces and Gravitational Variances are going to so outweigh the effects of the Exosphere it's measuring it might as well not be there for maneuvering purposes.

Parts packs are generally the biggest memory hogs, because the thing that really seems to cause memory hoggage is textures. Parts packs tend to have quite a few of them. Mapsat's kinda bad this way too, at least in part because it has a large number of exceptionally large textures (the maps themselves). I mentioned it to Innsewerants and he's going to look into it when he gets a minute from the game idea of his own he had and has been working on. He also indicated something which suggested he hadn't been active in part because he's been told Mapsat's still working in the current versions, with the unstated implication that it's his intention to update it should it stop working, at the very least. When I talked to him a few months ago he had some...interesting ideas for future changes, but it sounds like he's more engrossed in his game idea at the moment.

There's a reason it includes the capability to disable functions or entire modules via the .cfg. It does provide some *excellent* informational stuff, though, including one no other mod can do: Atmospheric entry simulation. Unless you have FAR.

Ion Hybrid Pack has a Tiny-sized L-shaped piece, referred to as an 'adapter'.

It's not crap, it's just...motion sickness inducing. It saves you the bother of dealing with it when you try to thrust left and it turns out you're rotated 90 degrees relative to your camera, so you just thrust down.

I've been using MSI Afterburner. Thing you're going to run into is that if you're compressing to any substantial degree on the fly, that's going to hit your CPU really hard, and probably make it lag. You can do somewhat better without causing too much of a problem but they're still going to be large, particularly if recorded at full resolution.

Actually I'm pretty sure there's a setting in the options to change it back to the old skin. And there's two mods in play there, the two windows on the right aren't part of mechjeb, only the 'Landing Guidance' is (and the little tab in the upper right that says 'mechjeb', obviously.)

Well that almost kinda halfway makes sense. Except for the part where it doesn't help us any. And the part where Unity's getting a really bad name among KSP Players, and KSP's getting bigger and more popular all the time. I was thinking about something...more than a little ambitious the other day. Initially in terms of trying to make KSP do it, but came to the conclusion I'd probably actually have to start from scratch pretty much. Because KSP's probably not really quite suited to pulling it off. My thought was more or less 'well that'd leave me having to start from scratch, which I'm not even sure I could do. And the only thing I know of where I could even TRY is Unity, and I'm not going to use Unity, because it's crap!'

Keeping track of which mode you're IN. I have ADHD, part of that is that my short term memory is shot. My working memory in particular is very, very bad. For example, I'm good at math, almost always getting the correct answer (at least in the types of maths I've had instruction in) but NOT in my head. If the math problem in question involves keeping track of a partial result while working on the rest of it... it's going to take me an inordinately long time to get there. My processing speed is also already lower than it should be because of the ADHD, but hanging on to part of the result while I work on the rest is HARD. So what I'll normally do is get a piece of paper and just jot down all the numbers as I work on it. Writing it down doesn't really help me work it out, I'm just using it in lieu of my craptacular working memory, so I can focus on the actual math part. Unless I'm actually trying to make it clear what I was doing, it usually ends up being just a bunch of numbers with no indication of how they're related. Given that, my chances of correctly recalling which control configuration I'm in are basically zero. I'd constantly end up re-discovering which setup I was in when I tried to do something and it turned out to be in the wrong one. It's just easier for me to have it on a separate set of keys. Left hand on WASD, Right hand on IJKL. Only hard part is having to switch right hand to the mouse to move the camera, but I dunno how much of that I'll need to do with the Docking Port Alignment Indicator mod (I haven't actually docked anything since 0.19, I Kinda gave up on my refueling station design.)

...It might be difficult, but PhysX already has the capability. The problem us, Unity's using PhysX 2.

Once you've managed a close rendezvous there's nothing to do EXCEPT eyeball it, though. Once you're close, orbital dynamics stop really mattering, and it becomes all about the relative motion. The HARD part is thrusting correctly given the camera may not line up very well, if at all, with the way that the craft is oriented. That's what the 'chase cam' mode is for, though it has its own problems. What I've always found funny is that I end up doing final alignment so slowly, that when the magnets finally kick in, they actually pull the craft together far faster than I'd been moving.

Well it'd help if the various available metrics were a bit more straightforward about what's going on, exactly. The one thing I've gathered in all this is that they're really not, and that there's no good, consistent way to observe the actual memory usage because it's simply not presented in a clear way. Regardless, it's my understanding that if nothing else, the working set constitutes the bits it's actually referencing, even when it's not indicative of how much the program is using. The fact that it's dropping by such a large factor and crucially not climbing back up again suggests that there's something interesting going on that I'm not adequately able to probe myself. It's not a small drop, it's generally somewhere between a factor of 3 and 6. Going through a scene load is the only thing that jacks it up again in a big way, and even then, even after multiple scene loads, it's staying ~20% lower than normal. It rather strongly hints at things being loaded into memory that aren't really being used very much, and just get left there. People are crashing because they run out of memory, so if it's being wasted on caching things that aren't being used, that's kinda important to figure out huh? The unfortunate fact is that a 64 bit build is dependent on Unity fixing things so that it's possible to do one that isn't titanically unstable. And frankly, it's not the magic bullet it's been made out to be either. I personally only have 8gb of physical memory on my system, and that's more than a lot of people have. Going to 64 bit would enable me to use, at most, about another 2 GB before it starts paging out to the hard drive in a big way. You think the loading is slow NOW...heh. Wait till it's having to load gigabytes worth of stuff into the swap file.

I dunno if it'd actually help, because I'm pretty sure if the commit hits 4GB you're in crashville, and that's staying high. Size of gamedata isn't a good way to accurately judge memory usage though, because textures for example seem to get vastly inflated. If it's caching all the intermediates involved in getting the texture to the vidcard, that would make sense. Caching things in and of itself isn't bad: If it's reusing them when it needs them again later, it'd actually speed up loading quite a bit. What would be bad is if it's not reusing the cache and if it's not allowing the cached bits to be dumped to make room for other things when needed. It doesn't really seem like it is allowing the cache to be dumped given how many people complain about out of memory crashes and how far it drops when you suspend. Yes, you could hit a point where you were just loading so much stuff that your peak load got too high, but I don't get the impression that's happening at all from what I've seen. I have some ideas about checking that by deliberately inflating my memory usage, but I've got about three different things I want to test at the moment and trying to trace the memory is evidently quite ugly for a pre-compiled application (which doesn't surprise me a bit.) I've only ever dabbled in programming really, so it's something that's completely new to me and I'm trying to figure out how to do it as I go. Yay.

It kinda can already do that. There's an option that allows you to save the raw data, which is lumped into a CSV file, which you could use an included program on to generate a map of any size you wanted, with configurable options for the colorscheme et-al that was used. The dev version still includes the option and still generates a file out of it, but didn't include the program to use the data. I forget why, need to re-read Innsewerants' post on the subject, heh. It was never a feature I paid much mind to. Well what Majiir was talking about more or less was storing the data as a grid instead of an image. You don't even really create a full map texture at all: You create a whole series of 1 pixel tiny ones that are shown for each point in the grid. This is actually exactly how an image actually works: Each pixel is a point with a defined color. In this case you'd be reconstructing the image with just the control data for it. The memory savings would be because you'd only have to generate a single 1x1 texture of each color you were using, and then re-use that for each grid point/pixel where that color occurs. It's the same basic method he uses for the current incarnation of the Kethane map, just a lot higher resolution and with a different layout. I suspect it'd be a pain to get it working properly, in terms of time and effort, but there's no reason it couldn't be done (as he's amply demonstrated).

Yeah, those are the 'medium' landing gear. It's really not obvious from the icon but the big chunky ones are the 'large' ones and are much longer than those, though they look shorter in the VAB. Because they're the only landing gear type that telescopes. Need to use those. Those are MORE than long enough to get past an LV-909...did you hit really hard and bend them or something?

That's the thing though, it's NOT dumping it into the page file while it's suspended (I haven't tried Hibernate, because it's disabled on my system. Suspend saves the System state into RAM and keeps the RAM powered so that it's not lost. Hibernate Saves the system state to the Hard Drive and as such can power down more fully. Because Suspend just goes to RAM, it's a lot faster, but it's also susceptible to power outages. Cutting power to a suspended system has the same effect as cutting power to the system in normal operation. But because Hibernate is saved to the hard drive, if the power is cut, the system can still resume from where it left off at. Downsides to Hibernate are the much longer time it takes to write the state out to the hard drive, and the fact that you have to reserve a few GB of hard drive space so that there's definitely room to do it. I used to only have a 150gb HDD, so I turned Hibernate off to free up some space. Now that I've got a 2TB I've just never gotten around to turning it back on. As for dumping things to the swap file, that'd be...counterproductive. The whole point of suspend is that it's fast, because it only uses the RAM. Dumping things onto the hard drive (Swapfile or otherwise) would drastically increase the amount of time it takes, and it'd be obvious it was doing it: there'd be a ton of hard drive writes while you were waiting for the system to suspend. Well, the thing I noticed personally is that ISA Mapsat's maps are using up about 20MB of RAM per map, which really doesn't make much sense, but this whole situation almost provides a plausible explanation: It loads the ~2mb png file into memory, decompresses it into a ~8gb file, also in memory. Passes it to OpenGL (there's another 8GB), which converts it to a DDS (~2mb again) which then gets passed to the vidcard. At that point, most of that usage is redundant. Going to be looking into some more specialized software though, to try to see if I can't track what's going on here a little better. Assuming I'm right about this and it's not just a display problem with the way task manager indicates things (which it could admittedly be), the problem could be more-or-less resolved without bothering to do an optimization pass. If most of the memory usage really is cached items that aren't actually being used at the moment, all you'd have to do is set it up in such a way that it could dump part of the cache and reallocate the memory it was using when something new needed it. The memory usage would still LOOK high, but it wouldn't crash unless you actually managed to get it to where it was actively trying to load more than ~3.5 GB of stuff. If it's caching things and not re-using the cache when it reloads that thing, that's pretty much your typical textbook memory leak. From what I've seen of the current structure, though, it really doesn't allow re-use of the same texture/model for different parts unless you're completely re-using both of them. This means, practically, that each part ends up with its own copy of the texture, even if another part uses it. That doesn't really give the game a way to be able tell it's the same texture, though, so it's treated as if it wasn't.

Ahhh, I WONDERED why 'fully scanned' showed up as a long list of As. Makes sense. Very shiny. And what I really was referring to was the fact that getting such a large array to show up nicely as a rectangular grid would probably be a pain, just because you're basically substituting entries in the array for pixels. While you could easily use the array indexes to figure out which goes where, getting the entire thing to display and line up properly, particularly in a movable UI item, would probably bit a bit of a bother, just because of the sheer complexity. I have no doubt whatsoever it'd use a LOT less memory, simply because you'd only have to load a series of single-pixel textures that are used over and over, as opposed to 30 very large textures that are each used once. As for getting the memory usage down not being a huge concern, I tend to agree...but it seems to be the number 1 complaint against the current version of mapsat, and the primary reason the topic that became this thread came up in the first place: People with a lot of mods have problems with crashes due to out of memory errors, and identify Mapsat as being a huge memory hog(which it is, although I think it's only because the game's caching all the intermediate steps in the 'get it to the vram' pipeline unnecessarily) and the cause of their problems. That misidentification as being the cause of crashes seems to stem from one thing: They have more problems when they use a ship with a Mapsat part on it than they do if they don't use the mapsat parts. Which ultimately seems to stem from the fact that it doesn't even load the maps unless the mapsat module is loaded, which it obviously isn't if none of the parts that use it are loaded. This causes the total working set to be about 600MB higher when using a craft with mapsat than without it, and that pushes their already marginal memory usage right up to or over the edge.

Well the depth was always there, it just wasn't quite so accessible as it is now. You can still just slap some stuff together and see what happens. You could've always done the 'careful planning and much math' route, but it's a lot easier now with all the aids in the UI (maneuver planner, SOI change prediction) and all the mods to help you do the math (Protractor, Kerbal Engineer Redux) or even pretty much fly it for you (Mechjeb).

I think so, at least in theory. If you timed your launch so you ended up at the right point at the right time to make the transfer, it should work. I think. But then I'm kinda tired too. Edit: It occurs to me there's the possibility that you might not be able to get to the right point right off launch without circularizing and at least doing a partial orbit, if it's around the other side of the planet, say. At the very least it'd be harder.

Oh, I see. You didn't mention the part where you scaled it down after making the 16k version. And replying to your own posts in series is, as a general rule, against the rules of most forums and apt to get you banned. I've seen mods on here chastise people for it and tell them to edit their previous post instead. In short, to add more information when nobody's replied, editing is the REQUIRED behavior. I sometimes think of things faster than other people reply (bloody ADHD), so I end up doing that rather than waiting for someone to reply. I stop editing it and carry on below when someone else DOES finally reply. Which means, in short, the only way it could change on you is if: A.) You opened the thread a substantial time before replying and didn't refresh, in which case missing edits is the least of your worries. B.) I happen to do an edit in the middle of you posting something, which isn't particularly any different than if I made a new post while you were typing. As a general rule I mark my edits with headings for just this reason, to make it obvious which is which. Except for a short period right after I post, which is mostly just grammatical corrections I didn't catch initially.

I meant a lot of CELLS. The current ISA maps are 2048x1024 (although the polars map obviously has substantial areas that aren't part of the actual map because it has two round bits in a rectangular texture.) Easy enough to set up logically, but I can just imagine that setting it up graphically could be a real pain. You'd also have to either recode recode the way the plugin records the raw scan data, or set it up to translate it into the matrix format on the fly. Right now it's set up to save it as CSVs that pretty much just defines the coordinates of the scan location and the altitude of the result(I think, anyway.) It's kinda crippled in the dev version, I'm not sure it's working quite right, and he didn't include the map generator program with it either (something about redoing the way it works, or something), though the 'RAW' option is present and does generate a file. It was designed to save whatever data you managed to collect very precisely so that you could make maps of an arbitrary size with it, even ones far larger and higher resolution than what you're using ingame. It's the method he uses for his Kethane Hex Map. It stores the scan data basically as a mask in the savefile, with a single character indicating if each segment's been scanned or not. There's some other data in there which I'm not sure exactly what it's for, but it's a really simple solution that only requires 1 byte per cell. He's also got it set up to have the cell colors be based on the amount of Kethane in the cell, and there's no actual on-disk textures for any of it. So far as I can tell, he generates them on the fly too. It's very slick. Unfortunately if I'm right about this memory thing, his method might be just about the only way to keep it from using tons of memory. Unless the overall 'cache' thing gets resolved, in which case it won't really matter that much.

Well, I think the only extra thing you need to know versus doing it normally would be the Launch Phase Angle of your craft: How far ahead of the ejection burn point you have to launch to end up at the ejection point when you hit that altitude. It varies per craft and is basically just another way of measuring how quickly your craft will reach the desired altitude. Mechjeb's LPA and rendezvous features aren't quite as useful here as they might be: Mechjeb's LPA assumes you're shooting for a circular orbit, which if you're launching directly to an ejection burn there's not really any reason to bother with.