DMagic

So apparently this isn't really difficult at all. Ok, SCANsat already has a method for background scanning built in, but still, it took me literally five minutes to come up with a workable solution. The trick is that SCANsat doesn't actually scan anything in the background, it just records what sensors have flown over what area of the planet. The elevation and biome scanning is all done when the map is drawn. The same thing is possible with Kethane, you just check which areas of the planet have been scanned and which cell those areas correspond to. The active vessel, with the blue orbit, does not have a Kethane scanner and is orbiting at ~750km. The inactive vessel, in grey, has a small Kethane scanner with a SCANsat module attached to it and is orbiting at ~250km. It took about 15 sec at max time warp to go from the map shown in my last post to this map. The Kethane grid doesn't seem to accept my additions to its database until I reload, but the SCANsat map (note the "Rebuild Kethane" button) works fine. I added a Kethane sensorType to SCANsat (using sensorType = 4, the old slope scanner number), set the fov = 1 and the best alt = 250000. The rebuild button checks which cells have been scanned and adds them to the Kethane database. I'm guessing you need an active Kethane sensor or part on the vessel for the grid to update without reloading. So if the reason for not having background scanning really is technical and not philosophical then I don't see any reason why this can't be added to SCANsat. Working out how best to handle the part modules is another question, but that's not really a big deal. Edit: The code for all of this is available on a branch of my Github page, the base is technogeeky's latest build.

Does anyone particularly care if the SCANsat map's Kethane overlay actually looks like a grid of hexagons? The performance impact of really accurately matching every pixel to the Kethane grid is significant. Displaying the grid at a lower resolution is very easy to do and reduces the performance impact to almost negligible levels. Note the "Kethane" button below, next to the "Grid" button, that can be used to turn the overlay on and off, and the Kethane quantity indicator showing the amount in the cell under the mouse pointer. The color of the overlay is a little bit more saturated now and it's easier to see on colored maps; cells that actually have resources under them are emphasized. The overlay works on all map types now, but the polar projection breaks my low resolution grid method, so I'm using a higher resolution (though still not as high as possible) for that.

Ideally the magnetometer would be more like a mapping instrument than anything else. Of course, the problem is that the game doesn't have anything to actually scan, not to mention that displaying such a scan would be a bit of a challenge. I decided not to allow biomes in space mainly to prevent having too much science available for it.

It looks great, but what happens when you put two of these next to each other? The doors look like they will overlap.

Say it with me everyone, proof-of-concept... It's pretty simple actually, I'm just reading from Kethane's database, I'm not doing any scanning with SCANsat. The colors show up a bit better in the grayscale mode, but that can obviously be improved upon. The distortion of the grid isn't too bad until you get to very high latitudes, the rectangular projection is only slightly worse. And this becomes less noticeable the more you have scanned. But, once again, this isn't a workable solution. I'm just slapping one or the other shade of green on top of the altimetry map if the given cell has been scanned. Ideally the Kethane overlay should be toggleable on any map type and should be more easily visible. Showing the Kethane deposit amount under the mouse would also be a good idea and shouldn't be difficult at all.

Chapter 1: Radio and Plasma Wave Science Chapter 2: Magnetometer Chapter 3: Telescopes and Imaging Systems Chapter 4: Laser Ablation Chapter 5: Core Drill and Biological Experiments Chapter 6: Neutron Reflections and Subsurface Water Chapter 7: X-Ray Diffraction and Surface Composition Continuing on with my bi-monthly (read, -annual) series on what all this stuff does, I'll be going over the magnetometer today. On a basic level magnetometers are rather simple, they measure the magnitude, and sometimes direction, of a magnetic field. Near the Earth's surface these kinds of measurements are extremely valuable for navigation purposes. In space they are used to study many aspects of the solar system and its planets. Considering that every planet, moon, and large asteroid is associated with a magnetic field of some kind, it's not surprising that most interplanetary, and several Earth-orbiting probes come equipped with magnetometers. The Boom About the boom, except for the large high-gain antenna and maybe the solar panels, the boom is typically the most noticeable feature of a probe craft. The reason these long boom are used is that the probe itself can emit a significant amount of magnetic interference. The body of the probe usually contains several ferrous (iron-containing, magnetic alloys) metals and there is a lot of electric current passing through the probe, these factors can generate a lot of background magnetic noise. Putting the magnetometers on a long boom, typically 10m, moves the instruments away from most of this interference (which tapers off quickly with distance) and allows for much clearer reading of the surrounding magnetic fields. In most cases there is one instrument placed at the end of the boom and another placed near the middle. The boom itself is made of non-magnetic materials, sometimes carbon fiber in newer designs, and aluminum in older spacecraft. Occasionally the magnetometer is mounted at the end of a solar panel, the Juno probe uses this design. This saves the weight and complexity of the boom, but can add complexity elsewhere (not to mention that Juno is the only outer-solar system spacecraft that actually uses solar panels). The Instruments There are a wide variety of different magnetometer instruments, most of which aren't really appropriate for spacecraft use. But there are still a fair number different types used by various spacecraft. I'll only go over the two used in my model which is based on Cassini's magnetometer. Fluxgate Magnetometer Back to the instruments themselves now. A common type is the tri-axial fluxgate magnetometer. One of these is mounted in the middle of the boom on the Cassini spacecraft and is what I've modeled my design on. The tri-axial part means that it measures the magnetic field in three dimensions by combining three individual instruments into one, with each instrument aligned 90o away from the others. An individual fluxgate magnetometer is very simple in principle (anyone who's tried the wrap-a-wire-around-a-nail trick will be familiar with the basics of this). It consists of a central magnetic core wrapped with two sets of wires. The first, usually inner, set of wires is the drive coil. An alternating current is passed through this wire to induce a constantly reversing magnetic field in the coil. This magnetic field then induces a current to flow through the second, sense coil, wire. When you put the whole thing in an area with a background magnetic field (that would be anywhere in the solar system, or galaxy for that matter) this background field subtly alters the induced field in the fluxgate core. This alters the signal that is produced in the sense coil, and, with some very sensitive electronics, can give you a reading of the magnetic field strength. When you combine all three sensors you can figure out the magnetic field strength in all three dimensions. Helium Vector/Scalar Magnetometer The other type of magnetometer included in my design, and also found at the end of Cassini's boom, is the helium vapor magnetometer. This one uses an entirely different method to produce a measurement similar to that of the fluxgate magnetometer. The specifics of how this instrument works are, let's say, complicated. There are basically four components: an infrared lamp, an infrared detector, a chamber filled with helium gas, and a number of surrounding loops of wires called Helmholtz Coils. The lamp generates IR light at a very specific frequency that is passed through the helium chamber. The helium molecules absorb this light, then some physical chemistry, quantum physics and hand-waving happens, and the IR detector measures the results. When the helium chamber is placed in a magnetic field the interaction between the helium and the IR light changes, and these changes can be monitored through the IR detector. With some modifications to the sensor's electronics in can be used in vector and in scalar mode. In vector mode the Helmholtz Coils can be used in a feedback loop to determine the magnetic field components in each dimension, allowing a single instrument to do what three fluxgate magnetometers can do. In scalar mode the total magnetic field intensity is measured with a very high degree of accuracy. The Science So what's the point of all these finely tuned instruments being strapped onto nearly every interplanetary probe? There is much to be learned from studying the magnetic fields of other planets, the sun and the Earth. Measurements On Earth the most immediate application is for navigation. Compasses point at the magnetic north pole, but there is a surprisingly high variation in the intensity and direction of the Earth's magnetic field near the surface. The two measurements frequently used for purposes relatively close to the Earth's surface are magnetic inclination and declination. Magnetic inclination is a measure of which direction the magnetic field is pointing relative to the Earth's surface. Near the equator the field is mostly parallel to the surface, so it is around 0o inclination, closer to the magnetic poles the field begins to point downward, into the Earth's center. Near the magnetic north pole the inclination approaches +90o, near the magnetic south pole it's -90o. Magnetic declination is the difference between magnetic north and true north, basically the difference in what a compass says is north, and what is actually north. This changes greatly with latitude and is obviously useful for navigation. Both of these components show a great deal of variability across the Earth's surface, much more than you would expect from a simple magnetic field model. Earth orbiting satellites are used to make very precise measurements of the magnetic field at all locations above the surface; data from these and surface-based observations are used to calibrate models used to predict these components (the standard version of which is used by my magnetometer). These two images show the variation in total field intensity (left) and magnetic declination (right). You can see the south magnetic pole between Australia and Antarctica, it coincides with a peak in intensity and the declination can be as high as 180o near this area. There are two more peaks on either side of the north magnetic pole, which is at about 80o north and not visible on this map, and a low point over South America. This is called the South Atlantic Anomaly and is the point where the Van Allen radiation belts come closest to the Earth's surface (still about 200km up though). Further away from the surface the magnetic field is usually reported in terms of its three-dimensional components, the X-, Y-, and Z-fields (or sometimes they are given in spherical coordinates of B-radial, B-theta, and B-phi) and the total intensity. My magnetometer switches between reporting the inclination and declination while close to the surface, to the vector components when far away (the X- and Y-dimensions are combined into a horizontal measurement, given along with the vertical measurement) while always displaying the total intensity. Magnetospheres in the Solar System Some large planets, like the Earth, generate an enormous magnetic field that wraps around the planet. This field gets warped and stretched by interactions with both the sun's magnetic field and by the constant stream of charged particles flowing out from the sun, the solar wind. These charged particles and their interactions with the Earth's magnetosphere are responsible for a number of events, from trapped high-energy bands of radiation, to geomagnetic storms like auroras, to a band of charged particles constantly spinning around the equator called the ring current. Many of these events can be studied by very accurately measuring the magnetic field in the space around the Earth. The presence or absence of an intrinsic magnetic field can also tell us much about a planet's interior composition. The Earth's magnetic field is believed to arise from the liquid iron outer core spinning around the solid iron inner core. The fact that Venus has no intrinsic field suggests that it lacks this kind of geologic activity (though it does have an induced magnetosphere generated by the interaction of the solar wind with its atmosphere). For smaller bodies the presence of large amounts of iron, or other magnetically active elements can be inferred from magnetometer measurements. For truly complex systems like Jupiter and Saturn magnetometers can be used to learn a great deal. They can give an estimate of how large the planets' cores are and how fast they are rotating. The composition and presence of subsurface activity on the larger moons can be studied with the magnetometer. They can also give us an idea of how a moon's thin (or thick in the case of Titan) atmosphere interacts with the parent planet. Here is a look at Saturn's magnetosphere. The solar wind, coming from the right, pushes down on Saturn's magnetic field. A lot of interesting things get trapped in the region where the two meet, some of which was discussed in the RPWS post. You can also see where Titan passes through this soup of the magnetic field and all of the particles that get trapped within it. Sometime soon, or not soon, I'll continue on with the other instruments. Update (3/15/2015): Magnetospheric Multiscale Observatories (MMS) A really interesting launch happened a few days ago. The payload contains four identical satellites meant to orbit in formation and take very precise, high speed measurements of the Earth's magnetosphere. In particular, they are designed to study the points where the Earth's magnetic field reconnects; points where magnetic fields intersect and recombine after having been pushed around by the solar wind. During two stages of its mission the satellite quartet will move into two elliptical orbits to intersect the points where magnetic reconnection occurs. The actual instruments onboard are fairly similar to those described above and are present on many spacecraft. The primary difference is that there are so many of them. The instruments designed to monitor energetic particles usually rely on the spacecraft turning to get a complete view of the area; each MMS has multiple copies of each instrument (eight per craft in the case of the Fast Plasma Investigation instruments), which helps to give very rapid measurements covering the entire area.

Adding another SCANsat scanner type wouldn't be very difficult, and using that to check Kethane data should work fine. It is possible to read data from Kethane's cache of scanned cells and I think it is possible to write to that as well, so a SCANsat scanner should be able to update both the SCANsat database and the Kethane database (or rather, SCANsat shouldn't need to keep its own record of Kethane data). The simpler solution is not doing any scanning with SCANsat and only reading the existing database directly from Kethane. And while it's possible to also access anything that Kethane stores in the persistent file, I don't think doing so is a good idea; anything that SCANsat uses should probably go through the Kethane code, not go around it and directly access the persistent file. My problem with this is that I don't really like the idea of working around the very carefully setup method that Kethane uses for scanning. If you really want to change how that works I think it's better to petition Majiir to do that (which probably isn't going to happen) rather than to work around it with another mod. The only way to truly screw up a save file with part.cfg changes is to alter the "name = " field, usually found at the top of the file (not to be confused with the "title = " field which controls what the part is called in the VAB). This is what the persistent file and craft files use to identify parts, changing it will result in that part not being found and the craft not loading. It's really easy to check if part.cfg changes break anything because you can reload the database without restarting KSP, you just have to be in the spacecenter to do it; I do this all the time and it's rare that changing a part.cfg does any real harm. Using Model {} nodes adds some other ways to break a savefile, but SCANsat parts don't use those, so it's not an issue. There is also some amount of changes that can necessitate re-purchasing a part in the R&D center, I've never been clear on exactly what (besides tech-node position) triggers this, but it won't affect any flights in progress. You won't be able to load a craft file in the VAB until you repurchase the part, but it won't delete anything. About Module Manager, and this goes for adding SCANsat to Kethane scanners or for adding the MapTraq to command modules, I don't think there's any particular reason why MM is actually required for this. It's not that difficult to dynamically add and remove modules from parts when necessary. You have to be careful about removing the modules and about not saving anything with that module, but that's not really any trouble. xEvilReeperx's Science Alert does this with his transmitter module and I don't think it causes any problems (and that mod seems to have a good method for making sure the module gets properly added and removed). I think it's generally a good idea not to make dependencies unless it's absolutely necessary, even if it is just MM or Toolbar. That would also open up the possibility of managing these things from the settings menu. Turning off MapTraq for all command pods, or integrating Kethane (or maybe even adding Kethane background scanning) could be controlled through the settings menu so that everyone could configure it how they want.

I've never looked at the Open Resources System, but I have spent some time with the Kethane code. I think it stores the data in a somewhat similar manner to SCANsat, basically a publicly accessible list of which cells have been scanned and whether or not they contain Kethane. SCANsat works entirely with positions described by longitude and latitude, whereas Kethane uses the grid system. It seems relatively straightforward to figure out which cell is below any given point above the surface and that could be translated to something that SCANsat understands. The issue that needs to be worked out though, is how everything should be displayed. For one, I think the Kethane map should be shown as an optional overlay that can be activated on any map type rather than a separate map, that seems like the most useful method. The other issue is how Kethane's grid should be shown on the map. As far as I can tell there is no granularity below the level of an individual cell, so any map overlay would end up looking like a stretched out version of the Kethane grid (I think even the polar projection would be distorted). I think this would look somewhat awkward, especially on the rectangular map where cells at high latitudes would be very warped, but I don't see any simple way of doing otherwise.

That would be the GetInfo() string from the PartModule. public class YourClass : PartModule { public override string GetInfo() { return base.GetInfo(); } } Then just set some other string equal to that and display it in flight somehow, a screen message, a field in the right-click menu, etc...

Do you mean adding the module directly to the EVA Kerbal, or just dragging around the BTDT part on your back? The KAS method would work fine for just picking up the part, but I'm not sure if you can use MM to add modules to a Kerbal. There is no user-accessible EVA Kerbal part.cfg file, I assume there is something like it somewhere, but I'm not sure if MM can actually do anything with it. The people in the MM thread might know more about that though.

Hmm, you're probably right. I actually do something similar already with the anomaly scanner and with my existing asteroid science system. I also have a pretty good method for assigning experimental situations, though it doesn't handle multiple nearby asteroids very well. My original hangup with using the R&D center was that I wanted to append the asteroid seed # to every subjectID, the same way that stock asteroid samples do. I was thinking this would cause problems when trying to identify what has already been recovered because every asteroid would give a new ID. But as I've been working on it I realized that I don't really need to append the seed #, so every report would be the same except for the host planet. And really it probably wouldn't be very hard just to check for the relevant parts of the ID anyway. But the more I've been thinking about using my own scenario module the more I like it. I alluded to this a little, but using my own module allows me to store extra information, aside from the standard science values. The most obvious example is an experiment number (first sample, second sample, etc...). For the asteroid thing I could use this as an easy way to determine the diminishing returns. But I could also use it for doing things like ordering experimental results (the first magnetometer scan of Duna gives result one, the second scan gives result two, etc...). Maybe there's an easier way of doing that too, but this is turning out to be fairly simple, well, assuming it actually works right, which it probably won't.

It's not really a bug per se, it's more of a technical limitation due to how anomalies are stored by the game and scanned. The KSC is one object with its center located about 30m below the path between the launchpad and the VAB. All of the surrounding buildings, including that monolith, are considered part of that one object. It's possible to set it up to scan individual objects, but I don't want to have different results for every building at the KSC (and the airfield). Coming up with something specifically for that monolith might be a little easier, but I'm not sure if it's worth it. The general rule is, if the anomaly doesn't show up on SCANsat or ISA, then my scanner won't pick it up either. And if you want to know the exact distance and location to an anomaly (not the intentionally vague directions shown on-screen) open up the debug window with alt+F2, it will show the exact values.

Another Tuesday, another weekly installment of mod dev notes. I took a short leave of absence after releasing the last update (by which I mean playing X-Com Enemy Within, which is awesome, rather than working on KSP) so I haven't done very much. But in the last few days I have been working on the second iteration of asteroid science. Now I'm glad that Squad didn't do anything with asteroids because it gives me a blank slate to implement whatever I want. My thinking is to assign spectral types to asteroids; I'm not sure what the best way of doing this is, preferably something that can be compatible with other mods, like Custom Asteroids, but not have any dependencies. Right now I'm just assigning type based on each asteroid's seed #, but this has some issues, and I'm not sure if the number is truly random or has some connection to an asteroid's size class. The idea is to make asteroids behave like a planet and have the spectral type behave as a biome as far as recording science reports is concerned. That way I could make experiments that are dependent upon spectral type and give different results, and make others that aren't dependent on type and give one set of results for all asteroids. I'll use the asteroid size class only to determine a science value multiplier (and I've found a better way to determine the size class). The other goal of this version is to allow for reports from multiple asteroids with diminishing returns. I don't know of any way to do this using the stock R&D scenario module, so I'm creating my own (Scenario Modules are used to save data in different sections of the persistent file: the R&D module saves tech node and science results info, the Progress Tracker stores info on where you've been, etc...). This way I can create a new science cap for my asteroid experiments and assign science values for the current experiment based on how much has already been earned from other asteroids. Then I can pass off the science value to the regular R&D module so that your results and science still get recorded. Basically I'm just bypassing the stock subject value (the planet/situation base multiplier), scientific value (the diminishing returns multiplier for repeated experiments), and the science cap (normally based on the science cap defined in the SciendDefs.cfg file * the subject value). This all seems fairly simple to do, but I'm sure there will be problems that crop up at some point. The end result of all this is that you'll be able to conduct the same experiments on multiple asteroids while gaining a diminishing amount of science. So the first experiment (using the magnetometer while near an asteroid) would give you the full science value: the base value of 5 * the multiplier for the asteroid (say 10, for a class E). The next asteroid you visit, another class E would give you only 40, then 30 for the next, and so on until you reach a cap, maybe 250 science total. Because you get more science for larger asteroids this would mean that you would have to visit a larger number of smaller asteroids to reach the cap. So another way of doing this might be to set a soft cap and limit the number of asteroids you can research. Instead of conducting experiments until you reach the 250 science cap you could conduct experiments on 10 different asteroids. If they are all large you would get more science, if they are all small you would get fewer points. For a spectral-type-dependent experiment like the laser there would be a separate science cap on each type, one for carbonaceous, one for stony, etc... I've started coding some of this, and it doesn't seem to complex. I'm mostly replicating how the R&D persistent node stores science results which is all fairly straightforward. I still need to figure out the exact math of how to set diminishing returns and I need to figure out the spectral type thing. I've also made some designs for the Universal Storage Goo experiment, but I'll wait to see how their empty wedge design comes out before going any further with that. And I still need to come up with ideas for the other two stock experiments and finish cramming my telescope into a wedge.

Yeah, I was thinking maybe someone would crash land and break off their antenna, it seems unlikely, but I guess it's bound to happen eventually. It's easy enough to add in EVA collection. External collection (or other manipulation) through other mods is dependent on how those mods are setup, but most of them search for parts implementing ModuleScienceExperiment, so they won't see this at all. The only mod that I know of that properly handles this is Tarsier Space Technology's hard drive part. It searches for parts using the IScienceDataContainer interface, checks if they have Science Data (using the standard interface methods), and pulls out any that it finds. Then it clears out the part's data using IScienceDataContainer.DumpData, this is the same method that is called when you transmit data by right-clicking on the antenna.

I've tested the changes to the SCANsat partmodule that I uploaded a little more. Everything seems to be working ok. The primary change is to the storage of science data. It now persists through saving and loading and can be reviewed as you normally would. Do people want to be able to collect the data on EVA? I don't see much need for that, but it's an easy fix. The other changes are just to move stuff off of OnUpdate where possible. I think people need to pick a dev build and stick with it, either SCANsat or MechJeb; using both is probably not a good idea. And more to the point, the SCANsat releases are test builds, any errors encountered while using a test build of SCANsat, an unofficial build of RPM, with a dev build of MJ and another unofficial build of RPM won't provide much insight into what might be wrong with SCANsat. When an official update for SCANsat v6 is released then RPM can be updated and this problem will go away. But for now I think it would be helpful if anyone testing SCANsat and SCANsatRPM stuck with the standard release of MJ.

Any idea of how you'll assign types? I'd like to do it based on something in-game, not just randomly assigning a type based on something that I implement. It seems like the seed # might be the best option, but I'm not sure if it's connected to the size class somehow. They don't seem to be, but I haven't actually checked that many asteroids. Also this would require visiting the asteroid since the ModuleAsteroid doesn't get created until it comes within loading range. That would seem to eliminate any kind of long range spectral-type assignment. But maybe you could instead just force the module to load when the asteroid is first generated.

Using my module would probably require too much work to fit all of SCANsat's requirements to really make it worthwhile. There are a number of issues with the SCANsat part module though (thanks for reorganizing that), some of which I think can be cleaned up right away, like saving and transmitting science data. There are also a lot of things running in OnUpdate that probably don't need to be: the KSPEvent initializations (there is after all, an OnInitialization method), and a few other things, some of which might need to be more carefully looked at. I'll try to go through some of it tomorrow. I haven't really done anything since I released the update last week. But today I started coming up with better methods to do asteroid science. At first I was disappointed when I saw that Squad didn't really do anything for asteroid experiments. Now I'm glad though, as it gives me a completely blank slate to come up with my own designs. Yeah, you can also probably add a check to see if any of the values are greater than zero before adding them to the string. But otherwise I think it's ok.

I never noticed that. They should all be [0,1,0,0,0]; that is, you should only be able to attach them to the surface of other parts (provided those parts allow surface attachment). The "node_stack_bottom" and "node_stack_top" lines should be removed, they should all only have "node_attach". There are a few other issues in the .cfg file too, the masses should probably be tweaked a bit, the bigger scanners are should probably be heavier. I suppose "cost" and "entrycost" don't really matter now, but at some point those will presumably become important. And the low-res altimetry scanner needs a "scanName".

If you are worried about losing map data, or anything else, just make a backup of your save folder, which everyone should probably be doing anyway. All of the mapping information is stored in your persistent file as a string of compressed gibberish, so as long as you keep a backup of that file your mapping data should always be there. If you're careful you can even copy the data from one persistent file to another. I believe this is referring to putting the min, max and ideal (if you don't change how that works) into the parts' VAB descriptions. Though I think it might be a better idea to put this into the extra info tab (the right-click window in the VAB), that way it will always match the values from the .cfg files. The only aspects of ISA that I believe are worth discussing are the variable scanning resolution and maybe some kind of info tab for each planet (ideal orbits maybe?). While I think there are benefits to SCANsat's method of simply increasing the scan width up to a point, I also really like the way that ISA start giving more sporadic data at higher altitudes. Maybe some combination of the two would be good. For instance, the scan width could increase, with 100% coverage, up to the ideal altitude. Above that the scan width could continue to increase (but within reason, not greater than 180o like I think ISA could sometimes do) up to the max altitude. I'm not sure if implementing something like that would be possible without changing the way SCANsat registers a scanning pass. But it might be, I haven't really thought about it.

That's quite a setup:confused: It's a little surprising that it's running slower than similarly clocked 4770s and 4670s, the difference is pretty minor though. It's not surprising though, that those extra two cores don't really make a difference (they do sort-of break my benchmark comparisons ), KSP doesn't really do anything with more than two cores and most of the performance is limited by the single-threaded PhysX calculations.

I can get results from the profiler in emveepee (I think), but it is a little hard to get any actual information out of it. I can see that getPartialMap, getElevation, gui_bigmap_build, etc... are all very high up on the list when I quickly go in and rebuild the map. So that's reassuring. Putting an upper limit on map size might not be a bad idea, especially if there is some other way to export larger sizes. Thankfully moving the map, or opening and closing it, doesn't force a reset of the texture and the cache. And as long as you're resizing it between reasonable sizes, not changing from 2500 to 2700 pixels wide for instance, it shouldn't really be a problem. Do you mean making a big texture file of the map that KSP can open when loading? That's a bad idea and will cause the same memory issues that ISA had. Any texture that gets loaded into memory from a file will stay there permanently, taking up space. If you mean generating a texture from a full coverage map and using that as a base to rebuild the big map might, that might work out better. There might be problems with the sheer number of maps required to make a complete set for your current planet though. Yeah, these are all made with the stop watch on my phone and by pushing Task Manager into a corner so I can see the various memory usage values while KSP is running (I always run it windowed). I'm watching FPS using a.g.'s plugin. Though I do have a plugin of my own that writes out FPS to a log file, it's intended to be used for my CPU database, but if I could setup a kind of standard test run it might be useful for comparing performance.

Sometimes I feel a bit dumb... ModuleAsteroid.prefabBaseURL saves a string with the asteroid's class value in the persistent file: "prefabBaseURL = Procedural/PA_A" or B, C, etc... It isn't affected by the DiscoveryInfo size, so it doesn't matter if you've docked to it or not. The only problem is that you have to actually load the asteroid before ModuleAsteroid is applied. So I guess if you just want the class value you can record the DiscoveryInfo size as soon as it loads like you're doing. But if you only need the info when you're within part-loading distance, or you want an accurate reading after the asteroid has been docked to you should be able to grab the prefabBaseURL and pull out the last character in the string. Either way it's much better than the mass based thing, though there are some cases where having more of a smooth sliding scale based on mass might be useful.

I've been doing some more testing of the big map performance. For one thing I tested the alternative radial vector calculation using the Quaternion.AngleAxis thing, it made no difference in performance. For the map caching, I have some concerns about memory usage because the array can be quite large when you start stretching the map out. Unity's garbage collection is apparently fairly lax, so every time you change the map size a new array is created in memory and the old remains. Eventually the GC kicks in and all of those old arrays get deleted (by stretching the map way off screen, I'm guessing to around 4000 pixels wide, you can make the memory usage jump by 200MB or so each time you change it), but I can see this causing problems in some cases. It's also not really consistent in how much gets deleted, I've seen the memory usage drop from around 3.4 to 1.3GB, but I've also seen drop to around 3GB and stay there. That said, I don't think any of this is really a problem, at least not a new problem. This exact same thing already occurs whenever you resize the big map in v5 (and v6). I assume this is because the texture is also being recreated and taking up a lot of memory. The caching array exacerbates the problem, but I've never heard anyone complain about SCANsat causing KSP to run out of memory before. So if it wasn't causing fatal errors with just the texture taking up space, then I don't think the addition of the array will really change anything (unless you're already right on the line with memory usage, but that's a different issue and doesn't affect the majority of players). Another reason I'm not too concerned is that for this to really be a problem requires stupidly huge map sizes and constant resizing of the map. When you stay below 1500 pixels or so wide it doesn't have such a huge memory hit. If you just pick a size and only occasionally change it you won't have a problem, just like no one that I know of ever reported having memory problems pre-v6. There are some cases where I can understand using very large map sizes. I think they can be valuable for exporting high quality maps. Maybe it would be best to create a dedicated map export function, one where you can input a specific pixel width and one that doesn't cache the data. In other cases it might be a good idea to throw a warning (maybe just once) when someone stretches the map out too much or resizes it 20 or so times in less than a minute. The performance impact is pretty large and I think worth the trade off. For reasonable size maps it can cut the time to rebuild the map, or switch map modes/colors, by about 50%. For larger maps the difference is even bigger, a map of about 1700 pixels wide takes me about 30 seconds to initially build (and this is the same whether I'm caching or not) and about 9 seconds to rebuild.

This is the module from a stock ion engine: MODULE { name = FXModuleAnimateThrottle animationName = colorAnimation dependOnEngineState = True responseSpeed = 0.5 } I've never actually tried it, but I think you should be able to set it up the same way you would for ModuleAnimateHeat. Just make sure you get the animation name correct and see what happens.

These projects have been tough to vote on. I like Ven's design the best, I like tygoo7's too, but I think both are a bit big. I voted for Moon Goddess' though because I think hers does the best job of fulfilling the original purpose: a small, self contained probe core meant for recovering spent stages or collecting science drop-offs. The weak solar panel and small battery make it great for insuring that you'll be able to actually maintain control of the vessel for the short time needed without being too powerful. My only suggestion would be maybe to lower the torque a bit (the part is, afterall, very small) and those orange connector pieces might need to be extended a bit to avoid problems with the shoddy fuel tank colliders; the same issue that came up during the last mod contest too.