DMagic

You need something to initialize it the first time. This will set which game scenes it will run in and store that in the persistent file. After that it should run onload and on save whenever you go to the relevant scene. Most of the Scenario Modules I've seen use basically the same method, so I would just check around.

Release Candidate 2.5 has been posted on GitHub. This is primarily an update for the new version of RasterPropMonitor. The folder structure has changed, you must delete the existing SCANsat folder and copy over the new version. You must also copy over the version of SCANsatRPM from the RasterPropMonitor package. - Updated for RPM v0.17 - Fixed a bug with map caching - Fixed a bug with the small map opening on exiting timewarp with the non-toolbar version - Active scanners will start already deployed instead of playing the animation on startup - Internal version number, and version logging changes

There's quite a bit of good information on texturing, UV maps, and AO in the last Open Part Mod thread: http://forum.kerbalspaceprogram.com/threads/81024-The-Open-Part-Mod-Week-23-5-Project-started-Texturing?p=1180360&viewfull=1#post1180360 Good AO layers can really improve the look of your parts. More so if you're going for a relatively untextured, or basic metal look.

You might want to enforce strict character limits on the info blurb that goes below the mod's title. It seems fairly easy for these descriptions to be too long to fit in the box, which kind-of defeats the purpose of them.

This isn't really a solution though. Those extra versions might be needed by other mods. So if having multiple versions of the .dll is causing problems there might be more needed to really fix it.

Since the x64 version of KSP has no desire to work for me I'll just shamelessly repost these results from Franklin in the 64bit thread here. Assuming this is from the same computer as before, this is being run on an AMD Phenom X6 1100T at 3.3GHz It's unlikely that you'll see much of a performance difference unless you're using enough mods to push upwards of 3GB of RAM. Above that amount performance can begin to degrade severely when using the 32bit version of KSP.

I'm not sure if there's anything in particular necessary for landing legs, but this should be relatively simple. If you create the colliders in the modelling software you can just make the collider a child of the moving part of the model (I think, I always add colliders in Unity). If you are adding colliders in Unity they should automatically follow along with the movement of the mesh.

Those look really great. These parts are probably a good way to start out with modelling, they have a very well defined framework. If you have problems with UV maps you might want to get rid of those indentations along the ends, those kind of little details are always the biggest problem for me with UVs. You can probably make a pretty good approximation of them using just textures and normal maps.

You could just leave out KSPAssemblyDependency ("SCANsat") from SCANsatRPM. Anyone installing it over the existing SCANsatRPM should be fine if they're using SCANsat v6. We'll update SCANsat v6 with the new SCANsatRPM (compiled against RPM 0.17) and add in the KSPAssembly and KSPAssemblyDependency at that time. This will have to be done for SCANsat v7 anyway (the version of SCANsatRPM that works with SCANsat v6 doesn't work with SCANsat v7), so it won't really be a problem.

Is this what you need: https://github.com/S-C-A-N/SCANsat/commit/812d9741a0019341d7c04c89d3cc92e05995beef? Both versions can be updated whenever you release RPM 0.17.

It doesn't save when you get to the spacecenter. But it does save if you go back to the mainmenu. Closing KSP immediately (alt+F4, the close button in windowed mode, or alt+Tab out and close) after getting the deleted parts message is one way to avoid losing your flights. Or you can download the backup generator from my signature. The latest version of Module Manager also creates backup saves when missing parts are detected.

That's a technical limitation of how anomalies are classified. Anything that shows up on the SCANsat map can be scanned by the anomaly scanner. Individual structures that are part of a larger group of buildings can't be scanned separately. More US conversions, three are complete, the goo pod, the materials bay and the telescope. A fourth, the atmospheric sensor, is almost done, I just need to finish texturing. I think only the goo pod will have asteroid reports, so those also need to be written. Depending on when 0.24 is released, that being the time when I want to update, I also have three new parts in some stage of development that may be included. The multispectral imager that I showed a long time ago is finally complete, it just needs a bit of tweaking and a lot of science reports written for it. We'll see how much I can get done for the other two soon. I also plan on implementing some version of an upgraded asteroid science system. This update will probably only a have a simplified version of allowing repeated science experiments for each asteroid class; I've been working on a much better system and maybe some method for assigning asteroid spectral classes, but that's a lot more complicated.

You don't need to bump a post that's still at the top of the list... In my experience debugging doesn't work on VS. Using a setup that works on Monodevelop doesn't work on VS and gives me an error similar to the one you're seeing. It's not exactly the same message though, and I've never really tried to get it working, so I have no advice other than to try something similar on Monodevelop.

This isn't going to work with simple Module Manager configs, the code will need a specific method for EVA collection; until that exists there's nothing you can do.

Because the stock science system is very dumb about "flying" experiments. It seems to use the Vessel Situation "Flying" as an indicator of whether or not you're in the atmosphere. As far as I know this only triggers when you're within the atmosphere and on a sub-orbital trajectory. If you are still in a hyperbolic trajectory, that is, one end of your orbit is escaping the planet's SOI, then you can never be flying, it's only when you get to the point where both ends of your orbit intersect the planet that you can be considered flying. A far better solution, and the one that I use (though not correctly at the moment), is to only check whether or not the vessel is within the atmosphere. If it is, then you should be able to conduct "flying" experiments. This makes far more sense than requiring some arbitrary definition of flight.

More Module Manager support is planned for the next version. This includes adding SCANsat modules to the appropriate parts, making Universal Storage parts available, and more stock science reports. I'll see about adding support for the Interstellar magnetometer too. I will probably do it using my own science module instead of the default ModuleScienceExperiment used by KSPI, this should prevent some of the problems of having two experiments on the same part.

So the lesson here is to not launch an infinite fuel Mainsail with 16 telescopes, a command pod, and nothing else , I'll keep that in mind.

That seems to be the result of something in the SCANsat partmodule not working like I thought it did. That's actually really useful to know.

The difference is just that, KSPActions are for action groups, KSPEvents are for right-click events. KSPActions only really have one parameter, the name (I've never really seen anyone use the second, KSPActionGroup, parameter). KSPEvents, on the other hand, have a lot, the various Active parameters, the name, unfocused range, etc... Also note that you can control these paramaters with: Events["event method name"] and Actions["action method name"] and that you can set Actions[""].active to true or false this way (which will either show or not show the action group in the VAB)

You just want some of your events ([KSPEvents]) to also be available through action groups? Create a [KSPAction("name")] and have it call your KSPEvent method, or make separate code for it.

Generally this is the Module Manager config people use to add SCANsat to command pods. It doesn't scan anything, but allows you to use the maps, and allows background scanning to continue working. @PART:HAS[@MODULE[ModuleCommand]] { MODULE { name = SCANsat sensorType = 0 fov = 0 min_alt = 0 max_alt = 0 best_alt = 0 power = 0.05 } }

Yeah, but only if you count the G train. I noticed two more issues today. One is that the science bay doors collide when using an octocore. I'm thinking one relatively easy way to fix that is to make the left and right doors open slightly different amounts and at different speeds, so that one door slides behind the other. The other thing is that using a lot of science bay wedges (and regular wedges to a lesser extent) causes a lot of slowdown when flying through the atmosphere at ludicrous speeds. This might only really be an issue when you strap a mainsail onto a command pod and cheat your way into orbit, but it's a pretty significant drop in framerate once the aerodynamic effects start to show. The same thing doesn't happen with empty octocores, so I'm thinking it must have something to do with the wedge colliders, though I don't really know how any of that works.

I managed to cram a telescope in the science bay. It's a bit smaller than the default telescope, but I think it worked out well. And if I ever decide to get really fancy it's on a rotating and pivoting base, that could be something to play with.

Are you trying to call the animation from ModuleAnimateGeneric with your plugin, or are you creating your own animation code and trying to call that? ModuleAnimateGeneric can only handle playing one animation at a time for a single part. Even if you have multiple modules, with multiple buttons, only one animation will play. I think some of the other animation plugins that are available (Firespitter, Advanced Animator) will allow you to simultaneously play multiple animations on the same part; they still have the multiple button problem though. You can probably use your plugin to call multiple "deploy" events using those modules.

Kethane conversion can be tricky when using docking or radial connections. You need a path from the fuel tank to the converter for it to work. The simplest solution is to attach a small fuel tank directly to the converter, this will always work, even if it does require manual fuel transfer in some cases.