DMagic

Yeah, some mods can really kill performance. I've had 500 part crafts that just crawl along at 5 FPS. But I've never noticed mods having a significant effect when they aren't being used. I'm sure there are some partless plugin mods that noticeably affect performance, and ideally everyone would run this test on a clean install. But I know that's not going to happen, so I'm not going to worry too much about variations in performance due to mods. The more results I get, the more things like that will be smoothed out. The RAM bandwidth issue has come up before (single, dual, or triple channel), but I've yet to see anyone actually test it out, so I'd be interested to see if you find anything. Thanks Demodus, I updated the front page. Those high end mobile CPUs are really powerful.

The newest macbook airs are actually very powerful. They can handle KSP pretty well (I assume you're using an older one), so if you want to stick with Apple, or just like that size, you can see about a newer Air.

Did you change all of the part names? The "name = scope" line is the important one at the top of the .cfg file. When I added both telescopes without changing that line I got the same issue. If you change the "name =" line, then re-purchase the part in the R&D center it should work. If you want to check more carefully what's going on, you can open up the persistence file and search for the line "id = advExploration", it should have a list of all the parts that have been purchased under that node. If you see "part = scope" twice then that's your problem (this can also happen when you add and remove parts from your GameData folder multiple times). But if you changed it to something like scope2, you can just add the line "part = scope2" and you should be able to use the part right away. Just be careful in the persistence file, and make a backup if you change anything. You could check your persistence file too, if you just want to check what's going on. Sometimes strange things happen when I add parts multiple times (blank part icons in the R&D center, or repeated entries in the persistence file), so there could be something weird there. But if it works now I guess it doesn't really matter. I'm planning on making a custom part module for the telescope too, it should address those issues with the animation and science reports (mostly by not closing it after transmitting or resetting the experiment). Though I need to figure out how to get the science report to trigger when the open animation finishes before that really works well. The telescope's poly count is a little high for such a small part, but it's nothing extreme, I think 1200 or so triangles. The reason I put so many leafs in the shutter is that the walls of the telescope are very thin (I decided on that kind of shutter long after making the rest of the model). If I made the leafs wider they would stick out through the walls. I might just remake the model though. I've already done that with the magnetometer to add detail to the instruments themselves, make the animation smoother, and cut down on the inefficient texture usage. It's not hard to do when I already know exactly what the part should look like.

Did you just try unlocking the tech node again, or did you purchase the individual part? If you add a part after unlocking a tech node you have to go back to the R&D center, click on the node, then click on the picture of the part itself (that should appear in the column on the right), then a window should pop up asking if you want to research the part. If you've already done that, or it still doesn't work after trying it, let me know. That should always work (I have to do it every time I change something in the part .cfg, or reload the model, so I've done it dozens of times). There is another, slightly more complex way to force a part to be available, but that requires editing the persistence file, so try out the simple method first.

I think the min, max, and ideal altitude for each scanner is in the part's description. If not it's in the part's .cfg file. It's different for each type, but basically, the higher you go, the wider the scan beam is up until the point where you're too high, then it doesn't work at all. Also, the scanner icons will change color on the map to indicate whether they're at the right altitude or not. Solid orange means too high, or too low and it won't work, solid green means it's at the ideal altitude, and flashing orange to green means it works, but it's not ideal. I think it just puts the images in /GameData/SCANsat/PluginData, or at least it used to. Just look around in the SCANsat folder, they should be there somewhere since you're not supposed to alter files outside of the GameData folder. And the problem with making maps that you can access in game is that, once you load any image into memory it has to stay there. So considering that SCANsat creates 15 or so maps for every planet (all of the different scanner types, color options, and projections) this mod would go from being very light memory-wise, to taking up 100s of MB of RAM.

If all you're doing is rotating the port 180o you shouldn't have to change the position. Just change the rotation values, though I'm not sure which one needs to be changed, just edit the quicksave file so that you can change one and quickload to check. But this will only make the part look correct, the "top" of the port, the part that's meant to dock will still technically be connected to the part below it. You need to change the attach node lines, and alter the docking port state. The attach node lines are "attN = bottom, 0" and "attN = top, 2", or something like that. For your first docking port example the lines will probably say "attN = top, 0" which means the "top" of your docking port is attached to the parent part ("parent = 0"), while the bottom is either free (it should say "attN = None, -1" if it's free) or attached to something else. You'll need to switch these, make the bottom attached to the parent part # and the top attach node free. Then you have to go down a bit to the docking port state line and set that to ready (I think the line will say "state = preattached" for you, change it to "state = ready"). And if you screw anything up your ship will probably be totally ruined, parts sticking out at odd angles, big gaps in the construction, and maybe parts spawning inside of other parts. So make backups and be careful.

High dV requirements are normal for Moho, but 6000 m/s just for the capture burn is a bit on the high end. You should be able to get from Kerbin orbit to Moho orbit for around 5000 m/s without too much trouble. The best advice I have is to completely ignore Moho's position relative to Kerbin's. Just start the transfer burn from Kerbin so that you touch Moho's orbit near its closest approach to the sun. Then treat the encounter like a docking rendezvous. It might take a few orbits to get everything lined up, but this way you can ensure that you get an ideal encounter with Moho, one where your solar periapsis matches Moho's and you meet at that point.

Ok, ignore all that junk in my last post. The problem seems to be the new version of Unity. I went back to Unity 4.2.2 and everything seems to work ok. I pointed the areas that might be of importance below (I spent very little time playing with this in Unity 4.2, I was too tired of fiddling around in Unity 4.3, so there could be other issues). I put the mesh directly under the GameObject, though I don't think that's necessary. I put the animation component in the root mesh part. There is no animator component, I didn't add or remove one, and creating the animation in the animation window didn't add one. The only key frames I made were for the emissive color under the material for the mesh. Everything is basically as described in this and the other emissive tutorials that I've found on the forums (the ones linked to in the modding compilation thread). Here it is in game... sweet part right? So if you're having issues with Unity animations try going back to 4.2 (I didn't try earlier versions of 4.3, but they made some changes to the way animations work in that update, which I assume is causing this issue). All old versions of Unity are available here: http://unity3d.com/unity/download/archive. There may be some way around this issue, or it may require fixing, either on Squad's side or on Unity's, but for now the old version seems to work ok. To be clear, I didn't have any issues with regular Unity animations (transforms), or imported animations, it was only when I tried adding these mesh renderer components that I had problems (the KSP log was spitting out some Unity animation error about SetCurve something or other).

Does anyone know how to return the name of the your current biome (either on the surface or flying above)? I was thinking it must be something like the vessel.mainBody.name type of thing, but nothing I've tried works. I tried print(vessel.orbit.referenceBody.BiomeMap.Map.name); but it just returns "kerbin_biomes_quantized" or mun, or whatever body you're orbiting. The same happens with vessel.mainBody. vessel.landedAt will return KSC, but it doesn't seem to work for anything else. There must be some way to check which biome you're in. Anyone have any ideas?

Edit: Don't use Unity 4.3 if you're trying to do emissive animations for KSP. Either stick with an older version, or download 4.2.2 from their archive. If they fix this issue I'll put those big pictures illustrating how the new animation window works, but for now I'll save space and leave them off. So apparently newer versions of Unity have changed the way the animation window works. Which is great if you're trying to follow the approximately 8 million tutorials that describe the old method. The procedure is pretty simple though. Set up your part and textures the same as described before. Once you have your emissive textures in place open the animation window. This is where problems might arise. The animation window comes up blank. To fix this, first add an animation name by clicking somewhere in the animation window's toolbar. Then make sure the red record button is on. Physical objects can be added just by dragging them around the screen (click on one of the direction arrows), then the transform options will appear in the window. Imported animations should already display all of the objections with transforms applied to them. For the other options you need to go to the "Add Curve" button though. Click on that and it will give you a hierarchy arranged in the same order as in the main window. Open the tree down to the object you want to apply the emissive texture to, in this case the cone. Then open "Mesh Renderer" and click the arrow to the right of the "Material._Emissive Color" option, shown by the big red arrow below. That will give you the four emissive color options in the animation window and you can make key frames as described in the first post. Play back the animation with the play button to check if it's working. (And if you want to zoom in on the time axis or the amplitude axis of the animation window without affecting the other, hold Ctrl or Shift while scrolling with the mouse wheel) I hope this helps in case anyone else was running into this same issue.

I had issues with this too. The problem, I think, was calling OnStart (I was replacing the default animation functions too). I seem to have fixed it by adding the base.OnStart(state) line and forcing the part to activate: public override void OnStart(PartModule.StartState state) { base.OnStart(state); if (state == StartState.Editor) { return; } this.part.force_activate(); anim = part.FindModelAnimators(animationName)[0]; } I wish I knew why that worked (well, I sort-of understand it), but it seems to. Though it sounds like you might not need to inherit the ModuleScienceExperiment anymore.

A minor update is ready for testing; download available on the first post. I made custom part modules for the magnetometer and RPWS to replace the default animation and science experiment modules. The default modules have some issues that effect my parts much more than stock science parts. I made the animation reversible during playback, and the right-click deploy/retract buttons are always present, regardless of what is going on with the science module. The magnetometer animation playback is sped up a bit, too. The default science experiment module has a few issues that I tried to work around. Trying to start an experiment where none is possible (on the surface or in the atmosphere for the RPWS, in the atmosphere for the magnetometer) no longer triggers the deploy animation, instead it displays a message about where you should use the instrument. This also fixes spoonyboobah's issue where starting an experiment where none is possible locks the instrument in the open position (only an action group can be used to close it at that point). Starting an experiment when the instrument is closed (and the experiment is possible) triggers the deploy animation. However, the experiment doesn't trigger at the end of the animation, you have to manually start it again. This is an issue that I still need to fix. The experiment also won't start if the animation is still playing. A message will be displayed and you'll need to trigger the experiment again when the instrument is fully deployed. Transmitting or resetting the experiment no longer triggers the retract animation. This was particularly annoying with my parts because the animations are relatively long. That's about all the plugin does for now. I just wanted to get this out quickly to address those issues with the default modules. It's pretty simple and I think I worked out all of the issues so far, but if anyone wants to test it please tell me about any issues or problems that you find. The part.cfg files for those two parts were changed, but otherwise everything else is the same. I have a rover part in progress too, and this simple plugin will be more important for that part. I have the model and animation finished for that part, but I need to figure out a few other things before I can add the texture and make custom science reports for that. Hopefully I can have that part finished in a week or two. Previews for it should come soon.

.mbm files are Squad's texture file format, they don't have anything to do with animations. As long as the animation options are toggled in Unity ('Import Animation' in the import inspector, and 'Animation' under the main object's inspector window) and the animation name matches the .cfg file there shouldn't be a problem.

I never actually changed any of the .fbx export options, so I assume that I'm using the defaults. Just make sure that include animation is checked in both the export options and the Unity import options. Are you creating your animations using the dope sheet action editor? If so you're actions might not be tied to any objects and are just getting ignored by unity. Make sure you click the 'F' next to the action name to prevent the data from being ignored if you use the dope sheet.

Thanks for all of the results, I've added them all to the first page. AcidEric, were you recording video during all of your tests? Your results seem really slow and recording video with FRAPS can really kill the frame rate. The FX-8350 is pretty similar to the FX-4350, it just has 8 cores to the 4350's 4 cores (and more cache), so I would expect performance to be similar between the two. On the other hand the GT 240 is a pretty low end video card, so you could just be very GPU limited, especially with all of the settings maxed out. Those T2600 numbers actually look pretty good. They are somewhere around 50-75% higher than what similar types of CPUs were getting in 0.22, even if you are still running at 7 or 8 FPS that's a pretty big improvement. I can see how the HD4000 would limit the i7 3770 in your case. That's a pretty big disparity in CPU and GPU power. But the low quality results seem reasonable, they are similar to the i5 3470, which is about what I would expect since HT isn't really doing anything for KSP. I think the frametime result labels for 0.22 and 0.23 are switched jfx. But those look interesting. It looks like each frame is alternating between two speeds primarily; one frame is 40ms then the next is 60ms, then back to 40ms. Then there are those occasional really slow frames, around 150ms per frame that really make things stuttery. I guess any reduction in those is good.

I'm still a bit hazy on all of this. But my method is to import the blender file into unity, then in the inspector window go to the second tab, "rig", and change the animation type to legacy. This always carries over my animation to unity (the animation preview in the lower right confirms this). Sometimes I still get problems with rotation/location data not being applied correctly in blender, or coming out wrong for some other reason. These problems have always been fixable by exporting the model from blender to an .fbx file, then importing that into unity. All of my animations have just been locrotscale data with keyframes on the timeline, but this has always worked for.

Well, there was an HD 7850, I guess AMD might have rebranded it, but anything in that general range ($150-200, around 150W power usage) is probably good enough.

I've spent some time considering this, and I've run a lot of tests, but I don't think it matters all that much. The biggest single graphics hog is the terrain settings on planets with an ocean. Because of the way water works it's basically like rendering two planets at the same time. You can play around with terrain settings, or tweak the ocean terrain details in the settings.cfg file, but I've found that just tilting the camera up to keep the ground out of view works just as well, which is why that is the only graphics related part of my instructions in the first post. I also want to keep the instructions short and require as few steps as possible; never underestimate people's ability to ignore directions. Most of the other graphics settings don't have a huge effect on performance, rendering and texture settings make a bit of a difference (I don't think there is any terrain scatter around the KSC, so that probably doesn't really matter), but it doesn't take much of a GPU to handle those at their max values. Resolution obviously can make a big difference, but I assume most people running at very high resolutions (above 1080) also have decent graphics cards. I'm also assuming that most people who have very powerful CPUs (and are therefore more likely to run into GPU limited situations) also have powerful graphics cards. I do see some results from laptops that look a little GPU limited though. Their framerates increase in more of a steady curve, instead of the stair step pattern I usually see. But the majority of the results I've seen don't appear to be GPU limited. Here are my two frametime .csv files. https://www.dropbox.com/s/c7s1omly1ken31d/KSP%20Frametime%20v22.csv https://www.dropbox.com/s/4xkng8krlckg6gv/KSP%20Frametime%20v23.csv

For a really basic, and really helpful overview of Blender just look down the page a bit on this forum for the blender tutorial thread. It's got a few quick videos that should at least get you started with part modeling. I also found this thread really useful for the basics of importing models into Unity: http://forum.kerbalspaceprogram.com/threads/40178 And this thread has lots of info on everything: http://forum.kerbalspaceprogram.com/threads/25013-Compilation-of-modding-information-links-for-0-19-20-21-22-23-Last-update-10th-Jan But really those quick Blender and Unity tutorials should be enough to at least get you started. I was in the same boat you're in about 6 weeks ago, and now I've put this part pack together: http://forum.kerbalspaceprogram.com/threads/25013-Compilation-of-modding-information-links-for-0-19-20-21-22-23-Last-update-10th-Jan

Apparently not with this mod, but there is another one that provides exactly that function. http://forum.kerbalspaceprogram.com/threads/64711-0-23-TweakableEverything-For-all-your-part-tweaking-needs

Thanks for the results Bean, I updated the first page. Looking at those frametime results again I notice that there are many fewer of those very slow frames, the ones running at about 5 FPS, or 200ms per frame. In the 0.22 results those frames show up pretty consistently about every 5 seconds. In 0.23 it's more like once every 15 seconds, although, curiously, they do seem to increase when the overall framerate goes up. That could explain a lot of the smoothness that I've noticed in the newest version.

Thanks. The stock science module has a few issues, and this is one of them. If you set it to call the default animation name then it disables the deploy toggle in-flight, making it impossible to retract the part until you can actually open the science report window. It also makes the part retract after every transmission or reset, which is annoying. And it doesn't actually finish the animation, it seems to stop 1 frame short of the end. This happens for stock parts too, I notice it most with the antennas. When the comm dish retracts after a transmission you have to hit the deploy action key twice to get it to open again, once is to finish the closing animation, and the second time is to start the open animation. It's really bugs me, especially for my parts because the animations are a bit long. For now you can set the animation toggle to an action key in the VAB so that you can open and close it whenever you want. But I plan on making custom modules for each part that keep the animation toggle available in-flight, and keep the part deployed after transmission.

Or fearless driving? Does this work with rovers too?

Not in KSP. The physics calculations are limited to a single core, so good single core performance at a high clockrate is much more important than core count as far as KSP performance is concerned.

Well the only settings that you can really change affect the graphics. So to run everything at high (with AA on and not fiddling with the ocean terrain settings) you probably need something around an HD 7850 / GTX 660. I thing those go for around $150. Obviously super high resolutions might need more, but that should be good enough for most resolutions. The CPU is another matter. The more powerful the CPU the better KSP will perform. You run into limits with very expensive CPUs that are optimized for multithreaded applications, but that isn't an issue if you are talking about affordable options. My recommendation, if you want a good, cheap, CPU for KSP would be a recent generation Intel i3. The desktop versions of these CPUs run around $100-150 and they are dual core with hyperthreading. Going up to an i5 would be better, but those go for around $200, so that's a different level. Of course, this all depends on your specific situation, whether you have the right kind of motherboard, how much you to spend etc..., but an i3 ivybridge or haswell is a pretty safe option.