DMagic

That shouldn't be much trouble. I would think checking for Vessel.Situations.Orbit would be enough, though I assume it ignores the atmosphere, so I would have to check to make sure you're above the atmosphere. If you're not in a stable orbit then it would display some kind of message, "Experiment requires a stable orbit" or something like that. What I would really like to see is an Experiment Situation for sub-orbital, limited to atmospheric planets, one where both ends of your orbit must intersect the planet (to distinguish from re-entry). Then you could write separate results, and make separate experiments for sub-orbital hops. I don't think there's any way to add values to the ExperimentSituations enum though (not on my end at least), so it would require some kind of work-around.

Yeah, the earlier builds that I was releasing were compiled with Debug on. But I switched it to release for the version on GitHub.

Did you turn the scanner on by right-clicking the command pod and pushing the 'open map' button?

I made a proper release with the latest version on GitHub: SCANsat V7.0rc 2.1 It includes SCANsatRPM, which worked when I tested it. And it seems I was wrong, it does show the resource overlay. There is no way to control it from the IVA, but you can turn it on or off from the settings menu and the regular big map. The Module Manager configs with the SCANsat module definitions are included and can be placed anywhere in the GameData folder. The updated toolbar icons with the clear background are also included. Otherwise everything should be the same as my previous release. The gallery in the first post has a basic demonstration of how resource overlays work (I know the UI is terrible, it's mostly a place-holder).

I haven't really thought about space station types of experiments yet. I've got too many probe experiments to get through for now. I've been toying around with some ideas for atmospheric sensors. I've been working on a model for a microwave limb sounder. It measures atmospheric composition and temperature at very high altitudes. It is also part of a series of satellites that orbit just a few minutes apart, allowing their different sensors to scan the same areas at slightly different times. This would be an interesting idea for KSP. I'm not sure how it would be accomplished, but I can imagine having some sort of baseline science level for each different scanner type, then an additional amount if the scanner is part of a constellation and they are in an ideal orbit. This is a schematic of the microwave limb sounder. The primary part is the large elliptical microwave mirror, there is another, smaller, sensor on the bottom left. I've started working on this, but there's not much worth showing yet. These are the various satellites making up the A-train constellation, though not all of them actually made it into orbit. Another idea that I've been thinking about for a long time (and one that would prioritize sample return) is for a solar particle collector like Genesis. It has several collectors for solar particles, mostly passive, but one active (the ring in the center). It might also be interesting to give the part a command module, a little bit of power and a parachute (though maybe it would be a good idea to make the parachute somehow automatically deploy and not have to worry about power), to simplify sample return. I think the whole thing could basically be shaped like a nose cone that unfolds to reveal its collectors, then closes up for re-entry. I've also been working on Universal Storage goo pods and materials bays. I have a decent model of the material bay, but it's still rough. The goo pod is more or less complete, it just needs texturing and I need to get the animations right. Using Model {} nodes to insert the part into an empty US Science Bay seems to work fine, and I can activate the door animations along with my own. So I should be able to transition all of my existing parts over to the new model.

Thanks for the results Slugy. It's good to see that there is at least some improvement going from two cores to four. I've updated the front page. I'm wondering if someone can test out this frame rate logging plugin I created. It's fairly simple, and only works when used with my CPU rocket (the name must remain unchanged). It begins running at liftoff and generates a text file in the GameData/CPUDatabase folder with a log of your frame rates during the run. It seems to work ok in Windows and gives results comparable to FRAPS, but I'd really be interested to know if it works in Linux, where there aren't any really good options for frame rate logging. The download link is here: http://www./download/roni660v2r0e6vo/CPUDatabaseLog.zip And the source can be found on GitHub

It would probably be best to simply delete all of the duplicate EXPERIMENT_DEFINITION nodes in the LionHead ScienceDefs.cfg file. As far as I can see they are the same, though from an earlier version.

You might also want to consider my Science Multiplier Editor, it can give you a lot more control over how much science you get from each planet and each situation. It would be especially useful if you want to decrease the science given from the Mun/Minmus to force people to go further to get more science. Not currently, though that could be an interesting addition. I'll see if I can come up with a way to include any number of resources.

It may not be caused by that mod, or at least not by LH alone. Do you have my mod installed too, DMagic Orbital Science? Those duplicate ScienceDefs.cfg experiment definitions might actually be causing a problem. I've had KSP choke before when it runs into multiple experiment definitions for the same experiment. Edit: This seems to be the culprit, or at least a culprit. Adding the ScienceDefs.cfg file to my GameData folder along with my mod and nothing else breaks the crew report, though it doesn't seem to affect my parts (the magnetometer collected data fine). Since I've seen this other times, I think that something else must be going on here too. It may be that any ScienceDefs.cfg can somehow screw up certain experiments this way, it's very strange.

I'm pretty sure that RPM was working fine when I update SCANsatRPM along with my latest version of SCANsat, though I'm not entirely sure why resources don't show up in the IVA maps (it works similar to how the zoom map, which does display resources). But I'm really not sure about how this dependency stuff works, and what breaks what, and so on, so I didn't include it with the other files.

This is with the limited-release version that I uploaded a few pages back. RPM works fine with it, I just didn't include the updated SCANsatRPM.dll in the files that I released since I wan only really interested in whether or not it broke scanning data from older versions.

This is weird. I don't see this happening. I tried this with all SCANsat modules around Kerbin turned off (you can see on the small map if any vessels around the current body are active) and all resource overlays were working. Switching resource types can turn off the overlay in some cases (switching to different Kethane resources), but the overlay button should still be there on the big map and work if you push it. When you see the overlays disappear are the buttons still present? And is the main resource overlay toggle activated in the settings menu? Oh yeah, I've seen that pack before, I think I looked at some of them when I was designing some of my science parts. Though I have no idea why those parts would cause problems with science reports. Edit: Ha, some of those ScienceDefs.cfg reports sure do look familiar:kiss:. Strangely enough I see no indication of attribution...

But does the MapTraq just have a single 'analyze' button? How much data were you able to collect, and which type of report did it give you? It should say something like "Analyzed low resolution altimetry data" in the experiment result page based on which scanner type is being used to generate science. As far as I know it is only setup to collect data from one scanner type at a time, so if you only collect data once you only get a third of the possible science from each planet. It really shouldn't work at all from an unmodified MapTraq, or config file with a sensorType = 0 field. I don't understand what this means.

I've released an update for this module; see the first post for the download link. The primary change is that non-animated parts should function properly now. To be safe you should set all of the animation related fields to false (showEndEvent, showStartEvent, showToggleEvent, showEditorEvents) and you must set 'experimentAnimation' to false. You can still set your experiment to use resources when activated, you must define a 'waitForAnimationTime' value and you must change 'resourceExpCost' to something higher than zero. Try not to set 'waitForAnimationTime' shorter than around 0.2-0.3 seconds, this can cause odd behavior in resource usage. ---------------- The other major change is the addition of the 'planetaryMask' field. This is a bitmask used to define on which planets your experiment can be conducted. It is similar to the 'situationMask' and 'biomeMask' used when creating a custom ScienceDefs.cfg file definition. The difference is that there are 19 possible values here instead of 6. By default it is set to allow experiments on every planet, default and mod, and on asteroids (it should still respect the 'requireAtmosphere' flag in your ScienceDefs.cfg file). All | Asteroid | Eeloo | Dres | Pol | Gilly | Tylo | Bop | Vall | Laythe | Jool | Ike | Duna | Eve | Moho | Minmus | Mun | Kerbin | Sun The first two are special cases. The 'All' position allows your experiment to be carried out on any mode planets, this, unfortunately, is an all-or-nothing option, there is no way to further specify which mod planet you want your experiment to work on. The 'Asteroid' position allows reports to be collected from asteroid, this requires that the part be configured to collect asteroid science. The rest are for the default planets. To simplify converting the values from binary to decimal, here is a string of 19 ones that you can plugin to this converter. Switch the values to zero for any planet that you don't want your experiment to work on. Just copy the values below and paste them into the binary-to-decimal box, it should tell you how many digits are in the value. 1111111111111111111 Some examples: If you want an experiment that only works on the Mun you would use 100 (you only need to start at the first '1', any preceding '0's can be removed) in the converter, which comes out to 4, so you would set planetaryMask = 4. If you want something that works on every non-atmospheric planet you would put the value in 0111111110010011100 the converter; which comes out to 261276 (note that the first value for mod planets is set to zero, there is currently no way to specify which mod planets to add or ignore). It's a lot of numbers, so it's worth checking a few times to make sure you've got the values in the right positions if you want to use this. If you don't care you can just leave out the 'planetaryMask' field and it will default to work on every planet. ---------------- I have also made several bug fixes and updates. It should properly detect the boundary between the upper atmosphere and space now, and it respects the FlyingHigh and InSpaceHigh science multiplier values (they previously defaulted to using the FlyingLow and InSpaceLow values for both of the respective situations, which is also the behavior of stock science parts). You can really take advantage of this with my Celestial Body Science Multiplier Editor. A few other minor bugfixes are included as well.

Which version gave you an 'analyze' button on the MapTraq, and was this the standard MapTraq or was it altered (is the sensorType = 0)? From v6 on there shouldn't be any science button for it unless you change the sensorType. What is the LH mod? This science experiment bug is really weird and I want to figure out what is causing it, or if some combination of mods is involved, even though I don't think SCANsat itself is doing it. The SCANsatRPM will have to wait until we get a real update. I'm only interested in testing for data continuity in upgrading from old versions with this release.

Does this happen with other parts, or just SCANsat parts? I've seen this happen before, though never with SCANsat parts specifically. I don't think it's caused by SCANsat, I'm pretty sure that I've seen it happen without it installed. I've always suspected it has something to do with Module Manager (that's the only thing I can think of that might be altering loaded config files like this), but I've never really been able to find out. And the MapTraq isn't supposed to have an 'analyze' button, there's nothing for it to analyze. Only hi- and lo-resolution altimetry and the biome scanner (but not a stand-alone, regular, anomaly sensor) generate science.

You should probably update the version of module manager you're using, and the EVA-X part has the more-than-two-resources bug in the VAB. The science bay looks good though.

So what's the end goal here? Is this to be a series of parts, presumably unlocked in order while working up the tech tree, and are they meant to Kerbal-sized, 1.25, 2.5m, etc... or something bigger? If you have models to work off of I might be able to help. Modeling is fairly easy for me if I have something to work from, even if it's just a few pictures or sketches. You'll probably want someone else handling any texturing though.

Wow, the values are off by quite a bit in some cases. The top values are from: CelestialBody.maxAtmosphereAltitude and the bottom values are from: CelestialBody.atmosphereScaleHeight * 1000 * Math.Log(1e6) which Anatid's documentation tells me is the accurate value for maximum altitude, and those numbers look right to me. [LOG 11:57:37.790] [Kerbin Max Altitude] 70000 [LOG 11:57:37.790] [Kerbin Altitude Scale] 69077.5527898214 [LOG 11:57:37.791] [Eve Max Altitude] 90000 [LOG 11:57:37.791] [Eve Altitude Scale] 96708.5739057499 [LOG 11:57:37.792] [Duna Max Altitude] 50000 [LOG 11:57:37.793] [Duna Altitude Scale] 41446.5316738928 [LOG 11:57:37.793] [Jool Max Altitude] 200000 [LOG 11:57:37.794] [Jool Altitude Scale] 138155.105579643 [LOG 11:57:37.794] [Laythe Max Altitude] 50000 [LOG 11:57:37.795] [Laythe Altitude Scale] 55262.0422318571 I'll make sure to correct that in the next release, though I'm pretty sure I've seen other mods use a similar scheme to what I have, so you might want to watch out for this bug occurring elsewhere.

Can you define where a KAS pipe will attach? You could put some kind of port/attachment point on the front of the tank to give some kind of plausible way to transfer fuel. It would be nice if a KAS pipe, or something similar could be forced to attach directly to said port.

How do you mean? Is something giving you "flying high" reports when you are still in space? The values I'm using for that should be coming straight out of the game, CelestialBody.maxAtmosphereAltitude, but it seems that might not be right. There is apparently another way of calculating the max altitude for some reason. I'll look into it more.

This all seems to be working fine. Here's the link for anyone interested: Edit: See the first post for the download link Just overwrite the existing files in your SCANsat folder. We'll see about a proper release sometime soon. Some quick instructions are in the gallery on the first post of this thread. And it's probably a good idea to make a backup of your save file (which you should be doing anyway). Also keep in mind that any resource scanning data from previous releases of v7 won't carry over, and you'll need to replace any Module Manager configs with those included in this package.

One of the worst offenders is the OX-STAT solar panel. The tiny one that is always active. Every one of them is constantly calculating its position relative to the sun and whether or not it is being blocked by another part. Since people have a tendency to put a lot of these on their crafts it can really slow things down.

Selection of resources and resource types is handled through the settings menu. The overlay can then be toggled on and off using the button on the big map.

I think MM's backup generator is acting too aggressively in certain situations. Whenever both needsSave and needsBackup are set to true it will go through every .sfs file in the save folder and overwrite the original while generating a new backup. Even if the originals are placed in a new backup folder it can be more than a little disconcerting to find that all of your quicksaves and backups have been replaced with an identical .sfs file.