Tiron

Most likely it's caused by the fact that it does SOMETHING to massively inflate the size of textures: ISA Mapsat's maps, for example, end up taking up about 600MB of RAM when loaded. That's 20MB *per Map*. Compressed, they're around 2MB each(Except the Blank, which is 38 kb.) Uncompressed, about 8MB each. Uncompressed with the Mipmaps in VTF format came out to 10.6MB. I have yet to see the memory usage vary substantially based on the number of completed maps, which is a good indicator that it's probably loading even the blanks as uncompressed textures. This is a pretty good indicator that something really goofy is going on, like it's upscaling them AND uncompressing them, or something similarly stupid. No wonder it takes awhile to process.

The problem's not Part Count, it's the textures. Unity massively inflates the size of the textures when it loads them into system memory for some reason: ISA Mapsat's maps, for example, are taking up about 600mb worth of memory with an average file size of 2.11mb for the completed maps, and 32kb for the blank placeholder. Somehow it's using ~20MB per map, when even an uncompressed 32bit bmp is only 8mb at that size... I suspect this is probably part of why the loads take so long: It's doing whatever horrible thing it does to inflate the textures and loading them into the system memory.

Interesting. I've seen this bug before but this is the first time I've seen someone able to duplicate and document the process that spawns it. So it's placing a singular, bugged article on the first click and then all of them on the second. That's interesting...

Uhhh...huh. Not really supposed to install it that way...You didn't have an old install lurking in said folders while you were trying to install to gamedata did you? Also, 'They're in Aerodynamics'? There's no 'Aerodynamics' folder...

After having Mapped Kerbin, Mun, Minmus, Duna, Ike, Dres, and then Kerbin AGAIN... 567 Days, 20 hours, 50 minutes, 5 seconds. Unfortunately the other flight log stats seem to only be for this session, or something, because the Distance stats are barely 3 times the altitude difference between Kerbin and Dres, and the Maximum Altitude is definitely 'this session only'. Which is irritating.

No, I was mapping Dres, and consequently had it sitting focused on the one probe (the only thing I had up with mapsat even ON it.) I do kinda tend to focus on one thing at a time, so I usually don't do a lot of craft switching. And so far as I can tell, it actually loads ALL the maps into Memory, including the blank ones, when you load a craft which has an ISA dish/GPS on it. The PNGs on disk have an average size of 2.11mb for the ones I've completed. There's a total of 30 map textures, two for each planet, which would lead to an extrapolated total size of about 63.3 MB for all the maps. Somehow, when the game loads them, they're taking up TEN TIMES that much memory. Even 32 Bit BMPs at that size are only 8MB each, so it's clearly something more than that. I first started hearing reports of PNG textures having incredible memory use a version or two ago, and also heard complaints that it still doesn't get scaled down if you drop the texture quality. When you get right down to it, the question is not so much 'why does it load all the maps at once when you load a vehicle with Mapsat', it's 'Why is Unity using 20mb per 2mb map'. I also have yet to observe any increase in the size of the memory usage as I map stuff, either. It's pretty constant around 2,400,000 for me. With occasional excursions into the 2,500,000s and rarely edging on 2,600,000, most likely because I fairly recently added Modular Multiwheels to my repertoire(Dem landing Gear.) I've turned on the peak working set column to help me monitor changes in the amount of memory it uses, and so far I've seen nothing of note. I'll set up a test for some ISA and Non-ISA ship swapping later, to check for those memory leaks. If there's anything particular involved I'd love to hear it as it'd help set things up (IE: Is two craft enough or do I need more than one? Does it matter if they're within physics range of each other or does it need to go through a scene load to get it?)

I dunno, some of my old designs did that, and it handled it fine...if and only if the symmetry coming out was exactly the same as the symmetry going in. 2->1->2? No problem. 2->1->4? Problem. 2->1->3->1->2? Problem. I think they did mess with the logic since then though so I'd have to check.

Actually you don't, but if they're liquidfuel powered engines the engines have to be attached to the fuel tanks, either directly or with a fuel line/crossflow capable parts. Monoprop and electricity propagate automatically throughout a craft, liquidfuel does not.

If there's no grid, something isn't installed right somehow. Remnants of an older version or something. Or I once put it in gamedata/gamedata/kethane by accident. It...almost worked. Assuming you've hit the 'show grid' checkbox on the little green config window, that is.

This is kind of an old bug, I noticed it in MJ2 awhile ago, but never remembered to report it (just like I still haven't remembered to hack the hacked kerbals from the stupidity test out of my save, grrr.) I've seen this twice, with the same basic setup: An 'inert' (no engines) probe on top of a 'lifter', with the MJ unit on the lifter. I Frequently end up with fuel left over in the last 'lifter' stage once I get to where I want to dump the probe at. Trick being, when I dump the probe? The 'Lifter' loses the ability to calculate Delta-V. Turns into just NaN from then on. I suspect it has something to do with the probe having the root part, but I'm not sure.

I think with the new system it actually only drains power when it fires a scanner pulse...which it only does when it passes over a segment it hasn't mapped yet. I think.

I'm pretty sure fuel ducts don't actually have mass or drag, much like struts. Also, you may not NEED the second fuel line if your target is connected to the part that intercepts the fuel line: Fuel lines attached to a part make it able to pass fuel, even if it normally isn't. Attach some launch clamps and do a static test, it might actually work anyway.

Nuclear Engine. Bill

It works like the struts: the duct is drawn in a straight line between the two attach points. If something gets in the way of that line, it attaches to that spot instead of where you clicked. It can't 'route around' anything.

I named it after a Relevant NASA probe.

Actually what we need is a way to get Unity not to convert the textures to uncompressed bitmaps, thus massively bloating the memory usage. And a 64 bit build that's stable. Both Unity problems (although there's speculation there may be a way to use a plugin to use DDS textures.) And seriously, I'm NOT seeing increasing memory usage as the game runs, it's very near constant. If you're seeing increasing memory usage over time it's likely that one of your installed mods has a memory leak. And a bad one, if it's burning up 700+ MB in a few hours. After running the game constantly for a bit over 26 hours, I saw less than a 150mb increase in memory usage, despite the fact I was actively scanning every time I checked it. Edit: With 1 ISA Mapsat equipped ship in the air that I haven't focused yet in this instance, I'm running just shy of 1,900,000 KB. Most likely because it hasn't loaded Mapsat's assets yet. The problem is not Mapsat, it's Unity bloating the textures, probably mostly the map textures themselves. Edit2: I should further note that any Mapping mod is going to encounter the same texture memory bloat problem, because you HAVE to have a texture for the planetary maps, and it has to be fairly large if you want any kind of detail. Edit3: Yep, when I loaded the craft in question, the memory usage blew up to around 2,600,000, with the game exhibiting symptoms of 'waaah you alt-tabbed', like it was late in my Dres mapping. I'll try a quick further experiment, no idea if it'll work or not. Edit4: Surprisingly, it did. I stripped every single texture ISA had, the GUI, the parts, everything, except for the map textures. And the 'Sun Textures', which he's apparently loading Dynamically off the NASA website, which is actually kinda cool. Note the white dish and the lack of any GUI at all other than the box itself and the text, which are both built in features. Memory Usage? Peaked at 2,466,508. Maybe I'll try blipping the models too, but I doubt that's going to have much effect. In any case, it looks like almost all of the memory usage is...the maps themselves, bloated by Unity converting them to Bitmaps from PNGs. Either that or the 'pull the sun images from the interwebs' thing is using a LOT of memory. Edit5: I don't like telling people things that are actually wrong, so I went and figured out a way to test it: With all the textures gone, I created a 8x8 square of red pixels in png format, and then laboriously copied and renamed it as if it were the map textures, replacing both ISA and Polars for every planet, as well as noterrain.png, blankmap.png, and mapbg.png (I think the last was unneccessary). I did all this because I thought that part of why memory usage was so high is that it was creating/loading blank textures of the appropriate size (2048x1024) for all the blank maps and holding them in memory, if not saving them to the hard drive like it used to. Basically, I tricked it into loading very small textures so it wouldn't try to create new, big ones (which is what it's designed to do, that's how it works after all.) The result? Upon loading the ship with the ISA dish (I wasn't able to delete the models, it pitched a fit), the memory usage spikes back up to about 2,400,000. And then immediately drops off...to 1,800,000 or less, about what it is without ISA installed at all(Almost like it's allocating the memory for the expected size of the textures and then realizing it doesn't need that big allocation after all.) In short: the plugin itself uses very little memory: That hogging actually IS almost entirely the textures, specifically the extra-large map textures. If you really wanna cut the memory usage you could crush the resolution on the map textures down, at the expense of losing detail on the maps.(Make sure you use sizes that are a power of 2 if you do this. I don't know for sure that it's a requirement, but it's fairly likely that it is.) It'll probably still spike pretty high on initial load, but then drop off, which should still help if a memory leak from a mod is your problem. Just as one final test, I gave it back everything, all the textures, except for blankmap.png and the topos. Memory usage: peak 2,444,160kb, fell down to: ~1,835,500

You mean like multidocking does with the 2nd and subsequent port pairs that lock together?

Not that I've ever found, unfortunately. best you can do is like, use strut cubes to rotate the node connection. :|

My general thought would be that the problem is the parts packs, not Mapsat itself. Texture files are the number one user of memory, and parts packs have a lot of them. But seriously, even with the other mods I *do* have, There's still nearly a gigabyte and a half of memory left for other things. That's a LOT of memory to play around with. If the parts packs you're using are hogging up that much, then the parts packs have just as much of a memory usage problem as Mapsat does. The ultimate cause probably has to do with the many bug reports there's been recently about png based textures causing insane amounts of memory usage ingame, and it not being affected by turning the texture quality down. ISA uses PNGs for the maps... And memory leaks? I've never noticed any substantial memory leaks. My memory usage has historically hovered around 2,400,000 for KSP, regardless of just about everything. The memory usage actually DROPPED after I made my previous post and ended up in the high 2,500,000 range, and this after having the game run continuously for almost 24 hours straight! (Mapping Dres takes FOREVER.) Could it be that one of your other mods has a memory leak and that's what's causing your problems? Now then, I'm going to measure Mapsats' memory usage. I've removed the ISA folder from Gamedata, and manually edited persistent.sfs to pull the mapsat dish off the one probe that's using the part, to minimize the difference between the save files. Without ISA, at initial load, I'm getting memory usage by KSP of 1,786,500 kb, or so. Climbs to a little over 1,800,000 after a bit. With ISA re-added (and my original save with the dish restored) I'm getting 2,478,500...and then dropped to 2,462,400 after a bit. And back up again to over 2,488,000. So Mapsat's using about 700 MB of Memory. That's quite a lot more than I would expect, yes, given the folder's only 26MB it's really a bit hard to fathom. The key thing here though is your parts packs have to be taking up around a Gigabyte to even get near territory where you could get an out of memory error at all. Secondary, you've got the fact that my system with relatively few mods only had the memory usage about 100mb higher after a full 24 hours of mapping, so you're either right on the razor's edge to start with...or one of your mods that I don't have has a major memory leak in it. Edit: Actually, it was more like 26 hours of continuous game running, since I posted that I'd just dropped into Dres mapping orbit at 8AM yesterday and posted this at 10AM today...

I've only had it happen with Mod-added parts that were, for whatever reason, completely invulnerable to impact damage. The old Bigtrak rover and its Cuttlefish lander for example. I screwed up the setup on the Cuttlefish, or staging it, or something, and lost the engine. So I bailed the rover out and went down with just the rover, just for fun. I bounced, skidded, tumbled, and rolled my way to a stop on the Munar surface, having lost most of the parts attached to the outside of the rover. I went on to deliberately crashing the still-closed lander into the surface in a power dive. Did the same thing on Kerbin right off the launch pad. Tried crashing it into the water. Literally nothing would destroy those bigtrak parts. Ran into this more recently with the super-large 'caterpillar tracks' module on a design one of my friends was having trouble with. I got it off the ground, but it didn't have enough lift OR thrust to fly, so it ended up in the water. Everything died EXCEPT the track module. Try crashing that same plane into the ground, I'll bet the same bit of it survives.

I'd wager the struts: The docking port bit really works better when you're trying to build circular structures or something. If that turns out to the be the case you can probably use just ONE decoupler, use the struts to keep it from flopping, and save a bit of weight. It'll unbalance the weight and drag very slightly, but the SAS should be able to cope with it. It'd also give you only one set of fairings instead of three, so you'd have six fewer pieces flying around at decouple. If the mass/drag is a problem you could get the same effect with balanced mass/drag by placing the decouplers individually, on the tri-adapter instead of on the bottom of the engines(Except the first one, which the tri-adapter is itself attached to). That way they don't detach when you stage it.

Yeah. The game's not capable of doing node-to-node connections with multiple parent parts. Two of the stack separators aren't actually attached to the tri-adapter at all. They look like they are because of physical proximity, but there's no actual connection. That's why it flopped without the struts. The struts form a physical connection that prevents it from moving. Docking ports like in my screenshots would do the same thing, although probably a tiny bit floppier than the struts.

If all you did was swap the decouplers for stack separators, no, it's not attached, at least on the bottom. You could in fact remove all but one of the stack separators and it would work exactly the same way it is now: The only thing keeping it together is the struts from the top section to the orange tank. This accomplishes essentially the same thing as using docking ports would.

Hmm. I should investigate this for my mapping probe(The one I mapped Kerbin, the Mun, Minmus, Duna, Ike, and Dres with, and am probably going to remap Kerbin again with.) I can see why this would be the case though: The LV-N weighs 2.5 tons, the inline 24-77 is 0.1 tons. My upper stage only weighs 5.21 tons, so literally half the weight of the thing is the bloody engine. And that's such a massive weight reduction, I can see where it COULD have more Delta-V after. Though the prospect of using a tiny engine on a size 1 probe...heh. Edit: Oh dur, it's only 2/3rds [Half (specifically 53%)] full...because I used it to get from Duna to Dres...But still. That's a huge fraction of the weight for the engine.

Remember, there's no friction. If you're moving in a direction, no matter how slowly, you will not stop or slow down unless you either: Hit something; Use your thrusters again. As a result you need to do two things to fly around on EVA effectively: 1.) Be patient. Going faster makes it harder to be precise and uses more fuel. 2.) Think ahead. It takes just as much thrust, and therefore just as much time, to stop as it did to gain the speed in the first place. This means you need to be counter-thrusting to kill your velocity BEFORE you get to your target. How much before depends on how fast you're going, but it's exactly equal to the time spent accelerating up to that speed in the first place.