DMagic

580 parts is definitely a lot. Yes, you can build crafts with a lot more, but 580 is still a very high number and it will drastically slow down all but the most powerful CPUs (and how many of those parts are struts makes little difference, with a few exceptions all parts have more or less the same impact on performance). That said, high part counts alone should not cause crashing, you probably have something else causing this. I don't think I've had anyone complain about problems with crashing while using my 600 part CPU performance test rocket. And some of the systems used for testing that rocket were far slower than yours; they ran very slow, but there were no issues with crashing.

Very nice mod. I've never really liked the radial lights, they seem to be a bit big, so these parts are a great idea. I'm using them in the next part of my Eeloo mission. There are four lights here: two under the rover, one on the little lander on the left, and the big one. I agree that the UI can be a little finicky, but otherwise these parts are great. I like that a battery can be incorporated into the lights as well.

What is the wikipedia you speak of and why have I never heard of it before.... ? Anyway, I don't think the computational aspects of the N-body problem are what rule out their use in KSP. I think it's the gameplay implications of trying to account for the gravitational effects of multiple bodies that keep Squad from implementing some kind of numerical or otherwise simplified N-body solution.

Now I'm not so sure about that, trying to conceptualize this stuff in my head can make me a little dizzy. I need to try this out in-game and see what happens.

Struts and fuel lines have zero mass in-flight. Just put a thousand of them on and check if you want to be sure, have fun waiting for it to load though. The nubs that get left behind also don't have any mass, this goes for struts and decouplers. If you want to get rid of the nubs just save and reload, they should all disappear. The only exception is when you keep the start point for a strut. This is why you should also start your struts on the part that gets removed (put them on the lower or radial stages and connect the second point to the upper or inner section). These strut start-point nubs won't add to your mass, but they will add to your part count, so make sure the start point gets left behind, not the end point.

Delta-V is just a sort-of weird way of measuring the total energy output of your rocket (though that's not quite right). But part of the confusion is that delta-v is a function of ISP, and ISP is a function of the atmospheric density. So you'll have a different delta-v depending how dense the atmosphere is and mods like engineer or mechjeb can't quite deal with this. You can calculate delta-v for a specific ascent profile, but it will be a little bit different if you don't fly that same profile. Another problem, and this one prevents you from calculating it based on initial and final velocity like you describe above, is the effects of gravity and atmospheric drag. The amounts lost to drag and gravity are highly dependent on how you fly and your rocket design. Flying straight up means you are fighting gravity the whole way, so you have huge gravity losses (and yes, gravity loses are worse on planets with higher gravity). Flying almost straight sideways means you will have huge drag loses. That's why there is so much discussion about ideal ascent profiles. The ideal profile will minimize your gravity and drag loses, but it's a little hard to calculate exactly how much you lose, and it can be difficult to actually follow that ascent profile, too. TWR is another matter, and there are about a thousand threads about ideal launch TWR.

I still can't tell exactly what you want. But I think there might be some confusion what about SAS really does (even if it could be left on and active when the ship is out of range). SAS doesn't consider your orientation relative to the planet, it only tracks your orientation relative to the entire Kerbal universe. It will lock you one direction while everything else moves around you. The easiest way to see this in game is to create a maneuver node and watch what happens as you follow it on the navball. Maneuver node directions are also oriented relative to the Kerbal universe. When SAS locks onto the blue maneuver node vector, your orientation will follow it in the short term. In the long term it will start to drift though, because the planet you are orbiting is also moving around the sun (the same thing happens with timewarp turned on; it doesn't happen when in orbit around the sun though). Edit: Derp, now I'm getting myself confused. Maneuver nodes don't quite work this way. You will very slowly drift away from the blue maneuver node marker because your craft is oriented relative to the Kerbal universe, while the maneuver node is oriented with respect to the SOI it is in. That is why you slowly drift away as the planet/moon orbits around the sun. So SAS will never be able to lock your position relative to the planet you're orbiting. The only exception, as has been noted many times, is when you are pointing directly north or south relative to the sun (thankfully all of the planets and moons are oriented the same way, regardless of inclination). The axis of your craft oriented along the north/south axis should stay that way while the rest of the ship rotates around it. This should remain true regardless of whether the ship is in range or not. The orbital parameters and orientation of the ship are stored in the persistence file, so this should be true. I haven't confirmed this for every possibility, but this should remain true even if you are in a non-equatorial orbit, or in the SOI of a planet in an inclined orbit (Moho, Minmus, etc... ). Obviously you need to set the docking port that you want to use as the "control from here" point when orienting the craft in question. Anything else might result an incorrect orientation. As for the complaint about not remembering SAS when you go out of physics range, I think you are right, and obviously RCS fuel will never be used. It gets turned off and you have to turn it back on. However, SAS behaves functionally equivalent to being in on-rails physics, both maintain your orientation with respect to the Kerbal universe. So the end result would be the same regardless of whether SAS was actually on when you went out of range. Switching between the two crafts that you want to dock together could be a minor nuisance, but I don't really see what the problem is. When the station is loaded (which happens once you are closer than 2.4km away) switching should take no more than a few seconds. The parts are loaded once you reach this 2.4km range, not when you actually switch to a different craft. There is a delay of a few seconds while the physics activates, but this is not the same thing as actually loading the whole craft. Once you set SAS on the station while both crafts are within physics range, and you remain in physics range, it should stay on and remain locked to its orientation (within the limits described above). If you bump into the station it should use any available RCS and torque to return to its original orientation. If you bump it so hard that you overload its ability to maintain its orientation then you need to be more careful. As for what you describe above about the station no longer being oriented correctly once you return to it, I'm not sure. This shouldn't happen, the status of SAS makes no difference here; the orientation of the craft is stored in the persistence file and that orientation should remain constant as long as it is in on-rails mode. The only thing I can think of is that you aren't orienting the craft correctly (maybe you don't have the "control from here" set to the docking port you want to use), or that this is a bug. The phantom rotation bug could easily cause this kind of thing. The craft may start out oriented correctly when you first approach it and it is loaded into the regular physics mode, but it could have started rotating by the time you get close enough to see it. I'm not completely sure what you're are describing, but it sounds like it could be this. When you say that the craft is rotating once you get close enough to try and dock do you mean that its orientation has changed, or that it is actively moving? By this I mean, if you switched to the craft would the navball be drifting without any input from you (beyond the normal amount of drift that occurs due to orbiting the planet), does activating time-warp stop this rotation? If the craft is rotating without any input then you probably have some kind of phantom rotation. This can be caused by parts clipping together, but it can be really hard to track down the issue with bigger, more complex crafts.

Impressive base modules; I like your launch-all-at-once method, it's much simpler than building it on the ground.

That's not too surprising and probably a good thing. Putting out little hotfixes for non-critical bugs can be a bad idea. When they put out a hasty update for 0.21.1 it screwed up the scene transition. So I'd rather have them wait and properly test these kinds of changes for a big update rather than having small, potentially problematic fixes.

You can refresh the big map by clicking on the map-type button again. So if you are looking at an altitude map on a rectangular projection just push the altitude button again and it will refresh, at least that's how it should work. Also, I think you can see that smiley face on ISA maps, too, it's just not quite as clear.

Don't let the low ISP for RCS thrusters discourage you from trying this. That value is a little misleading because the mass of RCS fuel is lower than liquid fuel. For low gravity planets/moons you can actually build a decent lander using only RCS.

Everything looks good so far. Performance is much better, with both the grid and orbit overlays on my FPS drops just a little bit, from 60 to about 55, but it stays at 60 with either on alone, and CPU usage doesn't change much with them on. All the other changes work fine, except that I couldn't figure out how to resize the big map. I was using a touchscreen though, so I didn't try too hard to figure it out. What's the little symbol and number in the bottom right of the big map? I like the little "X" markers too, they do look a little funny, but I think that's ok. I also think a zoom window on the little map would be nice.

I'm not sure that you'll be able to find many people with this CPU on a screen at that resolution. This is a really uncommon and pretty expensive part. But if I had to guess I would say that it won't do very well at max settings, even Intel's best integrated GPUs are pretty bad compared to a low-end discrete GPU. You will probably have to turn down a few things. The game will still be CPU limited most of the time, but running at max settings could slow things down in some situations.

I haven't seen any offline apps for KSP, but I know that it's common in flight sims to have some kind of mapping app that takes data output from the sim to plot your location, like a GPS map. One of the things that came up over and over again in the thread I created about using portrait mode is that some kind of multi-window support would be really great for KSP (think putting the map in one window, regular screen in another, IVA or instruments in another, etc...). It won't happen, this is a Unity limitation that's not likely to change anytime soon, but it would be really neat. So the possibility of having some kind of offline map, maybe one showing your present location above, or on, the surface, and some info like Kethane, slope, altimetry, etc..., is really interesting. It's not something I would expect from this mod, but providing the data output to allow this (if it's possible) is something to think about. I like this aspect too and I hope that we see some further differentiation between the parts. I'm thinking something like a wide range of size and mass for different scanner types. That way you would have to be more selective about which parts you want to add, unless you just want to make a really huge mapping craft. Having different scanners work at different altitudes could be interesting, too. For instance, the high resolution scanner could be limited to under ~100km, while the low resolution scanner might work anywhere below ~750km. RAM usage for these parts actually seems to be really low. It doesn't have the same issues that ISA did where the map files got blown up by KSP/Unity's inefficient way of dealing with texture files, and the parts are really simple. I also got around to testing this again on my desktop and the map overlays definitely seem problematic. Using all three overlays only dropped my FPS from 60 to around 50 (on an quad-core i5 3470), but CPU usage shot way up. With the big map open and no overlays turned on the CPU was at about 15%, but turning on the orbit and grid overlays pushed it up to 55% (that's the highest I've ever seen for KSP). That's ok for the tiny little mapping satellite I was using, but if you put some of these parts on a big space station, or larger craft it would be a problem. I'm not sure if having multiple mapping crafts further increases CPU usage, I'll try to check that later.

The non-rectangular maps definitely render faster, the polar especially. I was referring to the effect of the grid/orbit overlays; the performance drop is the same regardless of which projection the markers are shown on (which isn't exactly surprising, I just wanted to make sure).

Seems good so far. The map UI doesn't disappear anymore and the BTDT scanner seems to be working right. The improvements to the big map and the different projections are great, too. The performance impact from the overlays are pretty significant for me (on an i5 4200U at 2.3GHz; I'll test my desktop later). The grid knocks me down from 60 to 30FPS, and the orbit projection knocks me down to 40FPS. With both of them on I'm down to about 25FPS. The anomaly markers have no effect. Changing map type, color, or projection type doesn't have any effect on performance. Edit: I did find one problem. A completed map on the polar projection has a small gap running up from the center of the north pole, and down from the center of the south pole. I'm not sure how easy this is to see, but it's pretty clear in-game.

This is the terrain performance issue that gets brought up a lot. In most cases it's the ocean terrain settings that cause this problem. The slow-down can be reduced by lowering the ocean terrain details in your settings.cfg. Though I agree that something should be done about this. I suggested a while ago that they could add a dedicated terrain detail option in the settings menu, which would at least help for people who don't want to mess around in the settings.cfg file. http://forum.kerbalspaceprogram.com/threads/43253-Default-Terrain-Quality-Without-most-of-The-Lag%21

They talked about performance improvements before 0.22 was released, and based on yesterday's Daily, it looks like they are trying to get them into 0.23. How much, and it what ways it improves performance are yet to be seen, but it seems they are doing something. http://kerbaldevteam.tumblr.com/post/65574326046/the-daily-kerbal-first-edition

It really all depends on how efficiently you can build your crafts. You can probably get just about anywhere and back with less than 100 parts on the launch pad, but that's not easy, a lot of skill is required to really minimize part count like that. The same goes for space stations and multi-part vessels. If you can get really good at avoiding excess parts you can do a lot with less than 100. I haven't really tried this, but I imagine if you start out in career mode, and get the hang of the game using a more limited part set, that it will train you to get by with lower overall part counts. On the other hand, if you're not careful even a simple Mun lander can balloon to over 400 or 500 parts.

I get the same. I loaded KSP with a bunch of maps from Kerbin and Moho (that's right, I was bored and confirmed that the plugin does, in fact, work for Moho too) and got about 1010MB of RAM used, the same amount used without anything in the folder map image folder.

I have encountered the same thing on two different machines. I tried saving/loading and editing the persistence file to turn off all scanners, but only a full KSP restart worked. And the craft icon placement bug I referred to earlier seems to be due to Diazo's touchscreen controller mod. I didn't have the issue on my desktop, and removing it from my Surface fixed the issue.

They shouldn't spin unless something is wrong with your design (or maybe a bug), so a picture would help. There is nothing inherently unstable about asparagus designs so there is probably something about the way you are building them that causes this to happen. It could be a fuel flow problem, uneven placement of radial boosters, or something else.

Wow, this is working really great so far. I have a single craft with all six parts running without any real problems. I can only see a few issues: - The dark anomaly text is hard to read against the greyscale as has been mentioned above. Some way to change the color would be nice, it might also be nice to be able to toggle the anomaly text on/off. - What is the distance for the BTDT detector? I can see the anomaly names for the KSC, Island Airfield, the Pyramids and two monoliths from a satellite in a 160*180 km orbit. I didn't have any scanners running until I reached orbit. I also have two unnamed anomalies. - The only real bug that I can see is that the craft indicator on the small map is off. The "x" is displayed about 20o to the east of the actual position. It's correct on the big map and can be confirmed by looking down at the surface. The latitude is correct in both maps, but the longitude indicator on the small map doesn't match the ship's position on the big map, found by holding the cursor over the "x" on the big map (also, the order of the lat/long and alt values are switched on the two maps, I assume that's what you were referring to in the first post). - Is there any way to clear the zoom in window? Once I right-click somewhere I can't remove the zoom in window, I can move it to somewhere else, but it's always there. - The "Forget Map" button is usefull for testing, but I imagine it will be better to shrink it or hide it somewhere for later versions. It's pretty easy to accidently click it and erase your map. - As for the suggestion to add a map-only part, I assume that's what the MapTraq will be. Otherwise this is looking really good, nice work. I'll get around to testing multiple crafts later.

One other thing that I forgot about; camera focus in map mode. Is there a button for this that I missed? You already have the onscreen camera buttons, so there should be space around them to add a previous/next button for the camera focus.

Yep, and I've landed on all of them except Dres. The Mun doesn't work though, the TWR of the ion engine itself is sufficient, but the extra mass of the solar panels necessary to power them is too much, not to mention the mass of the structural components and the xenon.