Tiron

True, but to get any kind of resolution you'd need a LOT of them, and that's going to be a major pain in the butt to code. And there's a reason that the map comes in two modes: Rectangular and Polar. The Polar uses a pair of polar azimuthal projections laid out side-by-side. You can swap back and forth between the two on the fly: This is the reason there's 30 maps instead of 15. I can't see why not, except that KSP seems to be botching something up here: When I check the memory usage without doing my little trick, the Private Working set is still only a tiny bit smaller than the full Working set: Somehow, all the 'cache' bits aren't getting flagged as such (or at least that's what it looks like). Which is probably the sole reason textures, including Mapsat's maps, are using so much memory in the first place. Which isn't a problem in and of itself, but I get the impression one of the side effects is that it's not dumping parts of the cache to make room for new stuff when it needs to, which is probably a lot of what's resulting in the out-of-memory errors people with a lot of mods get.

Okay, that's kind of a point, but I'm not sure how exactly you'd apply that to an actual topographic map. I mean, sure, it works for Kethane because you're only having to store a few, smallish textures and use them over and over. Mapsat IS perfectly capable of storing an elevation dataset as CSVs, but I can't personally figure out how you'd get that into a usable ingame form without generating a texture out of it that's the same size as the maps we're already using, which is going to hit the memory just as hard. There aren't really repeating elements you can reuse like there are for your Kethane Hex-Map. Also, did you miss the part where I said the high memory usage appears to be entirely because it's leaving things loaded in cache that it's not actually using at the moment? I had a mapsat equipped plane sitting on the runway earlier using less than 400,000K of memory for the entire game, even with all the maps loaded. It looks like the game's caching all the intermediate steps in getting it off the hard drive and into the vram. Worse, the sheer number of complaints about out-of-memory crashes suggests it's not reallocating that memory when it runs low. Even worse, that could also lead to the 'memory leak' some people say they're encountering, and technically it would actually qualify. Which would mean almost the entire memory usage of the game is one massive, non-iterative memory leak. Edit: Working set: Total memory currently being used by the program. Peak Working Set: Maximum value of Working Set achieved during the current session. Private Working Set: Memory being used by the program that cannot be reallocated. Commit Size: Total Memory Allocation reserved for use of the program. PF Delta: The change in the number of Page Faults since the last update: basically the current rate page faults are occuring at. A page fault is the term for when a requested item is not found in memory, and thus has to be retrieved.

...Um...what? The 0.20 version is the dev version and completely official, and works fine (albeit with a bit of minor prodding to get the height scales correct.) I sure see a darned lot of tiny craters on the map I got out of it too... I haven't been on the surface in quite some time and haven't examined it that closely but uh...I don't think I recall all those being there before.

...What exactly do you mean by that? Are you referring to Anhedral? Or rotating the wings to change the Angle of Attack? (and if so, which way?)

I did forget to mention, that for really dangerous flights, I have a trio of cannon fod-...er... Specialized Test Pilots. The difference being the 'Regular' Pilots are restricted to proven, relatively 'safe' craft and missions. This absolutely isn't because the Specialized Test Pilots are Dumb as a Box of Rocks and about as Brave, and thus expendable. Not at all.

Not enough options! I take precautionary measures, but I wouldn't say 'as many as possible'. There's a lot more I could do, including things that would be more effective. I tend to shoot for relatively easy things that are effective the majority of the time: almost all my 'escape provisions' would be considered insufficient in real life. I care, but I don't care enough to make it 99.999999999% certain they live. 'The Vast Majority of the Time' is good enough for me.

That would explain it, but it raises another question... if it's supposed to dump it if needed, and KSP evidently needs very little to run on, even with some very memory-hogging mods turned on... Why is it still generating out-of-memory crashes for people if most of what's there is Superfetch stuff it's not actually using? I mean, part of my brain is niggling that you'd probably still get out-of-memory if the commit went over the possible allocation, but it still seems...kinda dumb. It also seems like, if that's the case, there ought to be SOME way to exploit it to stop all the out-of-memory crashes people with a lot of mods are getting... (to a point anyway, but at least get it so that if you can get everything loaded you don't end up crashing later because of a fluctuation in memory usage). Edit: Okay, so I looked at some more stuff. Apparently Superfetch is actually designed primarily to help load Windows and Programs faster, and what we're looking at here is some kind of more traditional caching system, which it also has. I did notice one other thing, however. In looking up this stuff I found a guide to what all the different 'Memory' readouts in the task manager are. They listed 'Private Working Set' as being the memory the process is using that it will NOT 'share with another program'. Now if I interpret this correctly, this seems to refer to the fact that Superfetch/Cached memory is supposed to cede what it's using if something else needs it, leaving the Private Working Set to be the the things the program's actually actively using at the moment. When I flipped that column on, I found that KSP's "Private Working Set" was only infinitesimally smaller than the Full Working Set. I then immediately went into suspend mode on it, and came back up, and again found only a few hundred MB used. It's almost as if everything the game loads at any point gets cached, and that the cache is for some reason being flagged as actively in use when it's actually not. Somehow Suspend is killing it anyway, but not the commit allocation. This could account for the 'memory leak' that some people have observed: It's not so much a leak as a case where things are only being loaded as they're used, but never really get unloaded. This would cause the memory usage to climb throughout a long play session as more and more bits were loaded at some point or another. Most of the memory that's flagged as 'in use' isn't actually being used, but because of the way it's flagged, it doesn't get reallocated. My observation after going on suspend mode is that it has no trouble whatsoever loading things on the fly. So if it were somehow set up to either unload things entirely or at least flag the presently-unused stuff as being able to be reallocated, it could help some people out rather dramatically.

Okay, so I was in the middle of an atmospheric flight when I had to leave for my Grandmother's for Memorial Day stuff. So I suspend my system (Windows 7, used 'sleep', I still haven't turned Hibernate back on since I got a new hard drive), and today I get home, bring it back up, recommence my flight, chatting with people on IRC. Get to talking about Mapsat using tons of memory to load the maps. I go to check my Memory Usage. ~800,000 KB. Wait what? KSP has used ~2,400,000 as long as I can remember. Lately it's been a bit higher, probably because I started using Modular Multiwheels fairly recently. During specific checks I've found levels in the neighborhood of 1,800,000-1,900,000 without a mapsat module or 2,500,000-2,600,000 with a mapsat module. Suddenly it's using a QUARTER of that. After I land, I go back to the SPH and load a new craft, it climbs. To ~1,800,000. I go back into the SPH, put a mapsat dish on it, and reload. About ~1,900,000. So I test it by leaving a plane sitting on the runway and suspend->unsuspend again. It comes back up using ~380,000(less at first, it climbed pretty quickly once I started doing stuff.) Something in the process of suspending and unsuspending windows is unloading massive amounts of KSP's data from RAM. And it is to all appearances COMPLETELY FUNCTIONAL that way! One thing that DOESN'T change is the 'Commit size', which according to Microsoft is just the memory that's allocated to the program. Which makes sense, it's obviously not something that's intentional, so it makes sense that it'd still be requesting the same amount of memory as normal, even though it's suddenly and mysteriously not using anywhere near that much. I don't know how useful it actually is (the commit is still just as high as normal, and you're still going to spike during the loads), but it does seem like it has some potentially interesting implications.

He logs into the IRC chat just about every day. Spoke with him yesterday morning. He's somewhat mystified about the memory usage himself and says he'll look at it. Apparently he's been spending most of his time working on his own game idea he's had, and hasn't touched Mapsat or the forums because everyone indicated to him that the dev version still worked. Which it does. On the other hand I just discovered something absolutely incredible memory usage wise that I'm going to be making my own thread about, which is...very mysterious. Edit: Okay, they say this is 'a known bug', but it might still be useful. If you suspend windows with KSP open and a flight in progress, it uses A FEW HUNDRED KB MB [Why did I type KB?] until you load something else. Even after several loads it was still depressed 500-600 KB MB below my normal levels. And that's on a ship WITH Mapsat with all the Maps loaded. Edit2: Okay, if I interpret what I'm seeing now correctly, the memory problems in general appear to be the following: Almost everything KSP loads into memory at any point is cached, remaining in memory even after it's not actually being used out of main memory anymore. Textures and Part Models that are already loaded into Vram. This could explain Mapsat's apparently high memory usage rather handily: The textures are loaded, decompressed, and passed to OpenGL, which passes it to the vidcard(At some point re-compressing them as DDS textures). The subsequently unused results of each of those steps remains cached in main memory afterwards. This also accounts for the 'memory leak': Every time something that wasn't being used previously is loaded into Memory, it stays there afterwards. If you're switching between craft that have parts on them that weren't used on a ship you'd focused previously, those assets go through the entire process and then THAT sits there in main memory as well. This would result in climbing memory usage if you were playing in such a way that more and more previously-unloaded parts were getting loaded as time went on. That would account for why I've never seen it: I tend to use a pretty limited subset of parts, in part because I don't really use parts packs and in part because there are significant numbers of parts I tend to avoid using. If this is the case, however, in theory loading into the VAB should load...well, most things if not everything. It uses the part models and textures to draw the icons on the GUI, so in theory even things you don't actually use would get loaded. They might not get FULLY loaded unless you actually went to whatever page they're on. I suppose it's possible the VAB has better garbage collection on it for this reason too though, but that's just speculation. The key reason that it's a problem looks like, based on what I can see anyway, that the things that are merely being 'cached' are being flagged like they're in active use. In theory, memory that's not in active use but merely storing cached things is supposed to be able to be reallocated if needed. It seems fairly likely to me that KSP isn't doing that, for whatever reason, because if it were it seems like there ought to be a lot fewer instances of 'out of memory' errors, if any at all (it really appears to not use very much at all the majority of the time!) Edit2: Also, I did read your post, I just didn't tear it apart completely enough for your taste evidently. You only get stuttering if you've set your 'Resolution' setting too high for your CPU to handle(It's not really the Resolution, though, it's the number of scanlines it uses,) and even then only while you're actively scanning. See, there's this little button on the UI that turns the scanning feature off and cuts the CPU use to basically zero. There's also a 'GPS' part that's incapable of scanning at all. Also, I can cut map segments out and blow them up by a factor of 2 as well: Strangely it looks better than your 'ISA' image despite the fact that it's also 127x101 image blown up to 254x202 (a process that would naturally exaggerate any quality problems, scanline artifacts, or compression artifacts present.) Which also raises the question of what the heck resolution are you using for your maps, and did you actually load that into the game? Because to get resolution THAT much better it'd have to be a MUCH larger map, and therefore using even more memory... especially since recent evidence suggests that unloading it might not actually even unload it. Your...thing isn't even an approximation. It's a crude demonstration of an exceptionally basic method to accomplish a superficially similar task. It's missing almost everything that makes Mapsat useful, and it additionally contains very little to suggest it's actually better. Your 'Scanned' image isn't complete enough to gauge the resolution you've actually used ingame, you didn't do a complete enough job to verify the memory usage actually IS any better, and there's quite obviously serious problems with the way you're tracking the current location and applying it to the map (You're going off the top and bottom of the map, and your 'scanlines' are perfectly straight and symmetrical at all latitudes. Neither of those are possible on a rectangular map.) Edit3: Oh, I see. 16384x8192 resolution maps. No wonder you didn't mention the memory requirements, because by my calculations a 32bit uncompressed bitmap at that resolution is 536,870,912 bytes, or pretty much dead on 512 megabytes. Given that Mapsat's memory usage was over double the size of the uncompressed version of the texture and there's evidence that suggests that may be intrinsic...well, that'd put you somewhere in the neighborhood of 1.2gb of RAM to load your one map. Gee. Also, comparing an image that's been upsized by a factor of 2 to one that's been downsized by a factor of 4 (which is at least equivalent to 4x supersampling anti-aliasing) is kinda dirty pool, don't you think?

His 'lower memory use' is below what I understand to be the minimum possible for loading all 30 maps, so it's plain that something's not right there. Dynamically loading and unloading them is fine, the question is what kind of a hang does it have. Part of ISA is being able to look at any map at any time, and if it's going to hang it would every time you switched maps. If you can do that without causing a hang, that'd be very useful in reducing the memory footprint, but I've yet to see someone test that. I'm not a developer so I've no clue how to do that myself, or I would. I'd also set up something just to load all 30 maps and see how much memory that used. I'm also being told that Unity itself can load compressed DDS textures, but KSP doesn't allow it for some reason. That would help tremendously as well. And I'm defensive because, well, I don't like it when people tear something down based on incorrect ideas stemming from Ignorance. I very much follow the scientific ideal that you should be able to hold your ideas up to experiment. People tearing down something fantastic based purely on ignorance pisses me off something fierce. Do I say it's perfect and couldn't be improved? No. But I've yet to see one verifiable way to improve it come out of this so far(Other than drastically improving the CPU use at the cost of defeating the entire point.)

I've yet to see anyone demonstrate that it's POSSIBLE to use less RAM while still loading all the maps. I've been chatting with people that actually DO make mods about it, including Innsewerants himself, and it was a pretty interesting discussion. He said he's going to look at the memory usage when he gets a minute, because he's as mystified as I am. Someone else speculated that it might be loading it into memory twice, once in Unity, which then throws it to OpenGL, but doesn't bother to wipe the original when it does. If someone can set up something that loads 30 2048x1024 textures at once with less memory usage, then we'd have found something useful. Equally if someone actually does set up something that dynamically loads and unloads them and can demonstrate it not causing unacceptable slowdown when it does, that would be useful. Right now mostly what I'm seeing is a lot of uninformed whining. There's a general assumption that it could be done better without any actual data to base that on, because nobody has so far done anything even close. For a start, try this one on: Unity definitely loads the textures as uncompressed. 30 maps at 2048x1024, uncompressed, without mipmaps would take up 240mb. That's the bare minimum without lowering the detail level. So how does he come up with 150mb if they are being loaded correctly? And For the record, I said that you could do about 18 times the resolution on Kerbin with Mapsat. That maximum is not because that's as high as it can go, it's because that's as high as you can go while still remaining outside the atmosphere. You can go to an arbitrarily high level, but only by using aircraft. The resolution is determined by your altitude. The maps are a fixed size, however, and thus have a higher resolution for smaller bodies than for larger ones. With the mun, for example, you can again get a little over 18 times the ingame map's maximum resolution with a 23km orbit. In that case you can go down to as low as 7.5km without hitting the surface, so you can go MUCH higher resolution than that, at a greatly increased time and difficulty. But the Mun's ingame map is already 3 times the resolution of Kerbin's to start with: so at 23km you're getting a map with 54 times the resolution of Kerbin's ingame ISA map. But it boils down to this: Uniformed whining isn't going to help anything. People are whining about Mapsat causing problems because, frankly, they're overloaded on other mods. They see Mapsat as being the cause of the problem because they 'only have problems when I use a ship with mapsat on it'. I've already established that Mapsat only loads the maps into memory if you have a Mapsat module on your ship. If there's not enough room left for it to do that because you're using 27,000 different add-on parts and didn't bother to account for that, well frankly that's your problem. He's going to look at the Memory usage issue. I'm personally pretty sure that it's a problem with the way the game loads textures and not something that can be reasonably solved without degrading the functionality. And seriously, if you think you can do better? Quit whining about it and DO it. Or at least supply hard data demonstrating that you're correct. Complaints and speculation don't help anyone, we need hard FACT, and so far I'm pretty much the only one trying to get any.

Mapsat's kind of a memory hog, so it's possible that it put you over the top and was crashing you with out-of-memory errors. Anything with a lot of textures can potentially do that.

That's the problem. They're ALWAYS under acceleration. Any change in direction OR speed is an acceleration. Including the fact that you orbit things instead of flying in a straight line: Gravity tries to accelerate you down towards the body, but your speed is so high that it can't do so fast enough. Not to mention if you're turning the craft at all. Using SAS to hold an orientation? That's a (very minor) acceleration. Turning round to face the other way? Acceleration. In fact the only time you're NOT undergoing any accelerations at all is when you're On-Rails. The focused craft only goes on-rails during time acceleration. Other craft are on-rails constantly unless within about 2.4km of your ship (assuming you haven't modified the simulation distance.) And they call it going 'on rails' because all physics simulation is suspended and the path of the craft is strictly dictated, as if it were a train running on rails. Nothing affects an on-rails craft at all, they just keep going in their predefined orbit, exactly as it's defined. So they kinda already do that...

Actually, there's two more things Mapsat offers which this combo couldn't. It isn't just a change in the statics it can cope with, it can handle a change in the Terrain Itself without needing an update. Which it actually already HAS, because the current version was released right after 0.20 came out. It's still giving me accurate maps of everything, even though the terrain's been redone on more than a few of the planets. It's also my understanding that it's also able to cope with having entirely new *planets* added without an update, though for obvious reasons I've yet to see this in action. Regardless, adding *all* the features mapsat offers wouldn't be the trivial exercise it's been made out to be, or someone else would've done it by now. No alternative offers both the flexibility and completeness that Mapsat does, and a product like Gammoner suggests simply couldn't. Every time the terrain changed, or if a new body gets added, or new objects get added to planetary surfaces, a 'revealer' type 'scanner' is going to have to wait for updated maps and issue a new release containing them. Not saying it's perfect by any means, but coding and memory issues aside, it's really QUITE an impressive piece of work. Especially for being an experimental dev version he pushed out due to the old version being broken by 0.20. And I've still yet to hear a confirmed solution OR cause for the memory issues, more specific than 'using way too much memory for the Maps'. If dude above can get all 30 maps loaded and not use 600MB doing it, that would be interesting. So far what I've seen is nothing special or useful. Edit: Also, if you really wanna +rep him, you can do it by right clicking on the star and hitting 'open link in new tab' or whatever. The link itself and the rep system itself both still work, it's just not doing it when you just click on it for whatever reason. Edit2: Oh crap, I think I just figured it out. The Map textures are 2048x1024. Uncompressed, with mipmaps, that's only 10.6 MB. But I just now had an epiphany. And checked it. 2048x2048 uncompressed texture with mipmaps. 21.3 MB. I'm going to try scaling the map textures up to 2048x2048 and see if that increases the memory usage any. Edit3: Okay, well, that increased the memory usage like, another 700mb or some stupid thing. Sheesh. There goes that theory.

Protip: Even in translation-only docking mode, WASD will still control the pod torque's rotation unless you turn RCS on as well. Even if the rover in question doesn't have RCS. Edit: Errr, it didn't show up on that last rover I was messing with, by I swear I was using one with a reaction wheel and it'd still go nuts with the torque unless you turned RCS on...

lots of monopropellant

This is exactly what I was told: It's already multithreaded, but each thread represents one entire 'Thing' the engine is doing (Sound, Physics, etc), and these subsystems can't be divided among cores. The problem being that the Physics thread uses more CPU Time than everything else put together, so even with it monopolizing a core while everything else is running on another one, it's STILL the bottleneck. As for why ships are multiple parts and not consolidated...can't have the joints break and bend if you're treating the joint as being unbreakable. That said I saw a thing in the mod forums the other day, somebody's welding (I forgot the name) or something like that, which is basically just that: Commonly used assemblies of stock parts consolidated into a single part.

LV-T45s are rocket engines that require both Oxidizer and Liquidfuel. Jet fuselages only contain liquidfuel, as jets use Intakeair instead of Oxidizer.

There's two maps per planet, in the format <Planet>_<MapType>_Topo.png The two map types are 'ISA' and 'Polars'. So for example: 'Mun_ISA_Topo.png' and 'Mun_Polars_Topo.png'. The full name of the planet is used. Files are placed in \Innsewerants Space Agency\Plugins\PluginData All the other textures (GUI textures, blankmap.png, etc) are in \Guitextures in Plugindata. Removing them didn't seem to do much to the memory usage, though I didn't try using placeholders. The SOHO Images when you select 'Sun' are actually dynamically loading the very latest images from NASA's SOHO website, at the address given in the window, which is actually kinda neat. First, Unity does decompress the textures, it's been a complaint for a few versions now that PNG Textures get massively inflated. There was one that reducing the texture quality setting doesn't help as well. My analysis indicates that if you replace the map textures, and ONLY the map textures, with 8x8 pixel solid color textures, it knocks about 600MB off the memory usage, though the full 700MB gets allocated at load and falls off after. So it's clearly something with how the map textures are being loaded that's such a memory hog. As for pasting them into Gamedata, are you sure they're actually being loaded into the Memory? If you load a craft without Mapsat on it, it also knocks about 600MB off the memory usage (only with no initial allocation spike), so it's pretty clear that they're not loaded from plugindata until mapsat is started. If you're just dumping them into gamedata with nothing calling them it's entirely possible they're not being fully loaded into Memory. IS isn't exactly a professional developer. He started the original ISA Mapsat project basically just because he wanted to see if he could. He's an amateur programmer with very little training or experience who frankly, did an incredible job considering. You've also missed one of the key features of Mapsat, probably because it's crippled in the developer version: Mapsat doesn't just make a '2mb png', that's just the ingame map. It's also capable of saving the raw scanned data into CSV files, which can be used to generate a map of an arbitrary size and resolution, limited only by the scanning resolution you managed. On Kerbin, this can be as high as 18 times the resolution of the default map. Edit: That map you linked uses the same basic method to generate the map that ISA does, to wit: "The map data is a collection of point samples..." :End Edit He's also been doing this in his spare time, and when I spoke to him on IRC a few months back, he told me that he hadn't actually played KSP in a very long time because he spent all his KSP time working on Mapsat. That method has a serious, serious problem: If you're using a pregenerated map in the first place, why bother with 'scanning' at all? Especially as it'd be virtually impossible to prevent someone from editing the save data to indicate it was fully mapped when it wasn't, or just to strip the alpha so it didn't do that in the first place. You might as well just make it a 'map for each planet' mod and dispense with the pretense. I also don't see any kind of indicator of what your present location is, which hinders navigation. It's also lacking the Polar views, which would make navigation near the poles difficult due to the impossibility of creating a rectangular map that accurately conforms to the entire surface of a sphere. And there's no anomaly detection either. So, it's not only crude, it's vulnerable to cheating AND lacking almost all of Mapsat's core features. Actually matching Mapsat's level of functionality is going to take a LOT More work than you let on. I'd also like to see what happens to your memory usage when you try loading 30 maps into memory. I'm betting it ends up quite a bit higher than you'd expect. Edit: And I forgot to It would be possible, but it would present a problem: any time you wanted to change what map you were looking at, you'd have to load the new map in. That's not going to happen instantly: There's another thread on these very forums that indicates that the number one thing slowing down the load times is texture loading. So you're looking at either limiting it to viewing the map of the body you're currently orbiting and getting a hang every time you change SOIs, or getting a hang every time you change what map you're viewing if you don't limit it.

I did it the other way around, I replaced the map textures with very tiny image files, 8x8, instead of the maps to see what happened when Mapsat loaded them. The memory usage spikes up to the 'Normal' level for Mapsat for just a few seconds during loading, and then drops back down to the level it's at when you've yet to load a craft with a Mapsat unit. I think it's allocating memory for the full-size textures, and then de-allocating it when it doesn't get used by the tiny ones that actually get loaded. It does the exact same thing to in essence the same values regardless of if it has the gui/other textures or not. The difference between the 8x8 images and the 2048x1048 maps being loaded was right around 600mb. The numbers are in the last part of my mega-post on the previous page (edit5).

I hope you're referring to the fact that SATA is backwards and forwards compatible. So that if either the motherboard or the hard drive have an older version than the other one, it'll still work, but only at the best speed the older part can handle.

Last I heard it doesn't use that feature either. I've read things indicating that both the multitheading and the hardware acceleration are options that can be enabled or disabled, but that might only be applicable to PhysX 3. It really, really is, because you're entirely limited to what a single core on your system can handle. I'm told that KSP actually *is* multi-threaded, the catch being that the threads are basically entire specific subsystems. The problem is that the threads themselves can't be split among different cores, and the Physics thread uses far more resources than any of the other threads. So everything else *is* running on different cores, but are so small compared to the Physics it's not even noticeable.

Being 'damaged' by the sepatrons isn't a big deal, other than annoying log entries. Right now at least, 'damage' consists of 'got heated up a bit', and the part will only be destroyed if it fully overheats. Back when you could still see the fuel tanks listed in the staging interface it was easy to see. The trick being, that as soon as the part isn't getting hit by the exhaust anymore(Actually even before that, just that more's being added still), it'll start losing the accumulated heat. There's no lasting 'damage' caused.

Because Unity uses an old 2.x release of PhysX, heavily integrated into the engine itself, and I've yet to hear so much as a peep that they plan to upgrade it.

Yes, sort of, except it's more complicated because of the units involved(specifically, the thrust being in KiloNewtons). There's some math on the subject on the wiki but I'm not sure they did it right. They're reporting a TWR for the Kerbal-X with the math that's quite a bit higher than what Mechjeb reports.