DMagic

Do you mean putting two emissive animations on the same transform? I tried getting this to work once, making a blinking yellow light to start blinking green, I could never get it reliably working (with my own plugin). If you make sure that each emissive animation is on a separate transform it should be fine, though it might still require a new plugin.

That's normal, same for the biome. There's not much for a legend to show for the slope map; solid puke green, no slope, yellow lines, slope, red lines, steep slope. Maybe it would be a good idea to remove the "legend" button if you're on the slope or biome map.

Yeah, it works fine. Several of my experiments (the laser, drill and telescope) actually have science reports written specifically for the default biomes pack of Custom Biomes (my ScienceDefs.cfg file is getting really long, it's closing in on twice the length of the stock file:wink:). They also should work with any mod planets and have custom reports written for the Krag's planets.

Thanks for that. I checked about 20 or so asteroids to get those mass ranges, but I figured they might be off by a little. My bigger fear is that it might be possible for the ranges to have some overlap. I ran into that same issue with using the Discovery Info size value and figured it wasn't worth the effort to work around it. As far as I know that's the only indicator of asteroid class (and you'll notice the class is never referred to again after you've approached within loading range of the asteroid), so maybe I'll have to see what you come up with. I don't have any real plans to make do anything with EVA experiments, but if I do ever come up with something (asteroid samples would be most likely if I ever implement some kind of asteroid composition system) I'll check it out. Well, it's not really a sample drill, that would basically be the same thing as an EVA surface sample. It's designed to search for trace levels of gasses associated with biological activity. You could probably come up with an experiment designed to search for biological activity (or maybe a more likely idea is an experiment designed to look for the remnants of biological life, not on-going activity) on non-atmospheric planets, but it would presumably look very different from one designed to look for some kind of microscopic lifeforms that share at least some similarity to known lifeforms. I think I need to continue my series (or maybe that should be start my series) on the actual science behind all of these parts. I wrote up a post about the RPWS because that is the most esoteric and complicated of the parts I've made, but I always intended to write more in depth explanations about the other parts as well.

It's released under GPLv3, which I think is compatible with SCANsat's 3-clause BSD license (and the license for CLZF2). For now all it requires is recompiling RPM from its source using a reference to the updated SCANsat.dll; both the SCANsatRPM.dll and JSI.dll need to be replaced. Of course, this might not always be the case. But as long as nothing else is required to get it working it would probably be ok to include an alternate version of RPM. Though I would very strongly warn people not to go complaining in the RPM thread if things don't work, that might cause problems.

I might look into a making a KSPI MM for all of my parts that could be used in both mods. For now I think that's just the magnetometer and Double-C. There are some aspects of the parts that could be cleaned up a bit if they are being used in KSPI, I can turn off the magnetometer readout for example. Well, that would be awesome, but that's way beyond the scope of what I intend to make. For the rover parts (and telescope too actually) what I plan to do is put the laser/drill segments on extendable arms with a rotating base on the end (and maybe a hinge with a limited range of motion). Then I can rotate that base so that it's pointing in the direction of the ground before activating. And I would eventually like to put in some kind of ground contact detection so that it actually has to touch the ground to return results. That should work ok. I'll have to figure out how to work out animations from two different mesh files in the same part, but otherwise I don't think there will be any problems.

I've never really been clear on how to properly setup this interface code. But I thought I had setup GetScienceCount and GetData the same way (for the anomaly scanner code and the generic module). ScienceData[] IScienceDataContainer.GetData() { return anomalyData.ToArray(); } int IScienceDataContainer.GetScienceCount() { return anomalyData.Count; } Then further down I'm hiding the ModuleScienceExperiment methods: new public ScienceData[] GetData() { return anomalyData.ToArray(); } new public int GetScienceCount() { return anomalyData.Count; } I setup things the way they are so that transmitting from the antenna button would work, but I didn't exhaustively test it, so I'm not sure exactly what is necessary and what isn't. And I know there are still some problems with it, EVA data collection, for instance, is using some overly complicated workaround to transfer the data. Obviously I need to spend more time figuring how to get this interface stuff setup right.

Yeah, that's true, I put some very basic instructions on how to do this 5 or 10 pages back. The process is extremely simple if you already know what you're doing, but baffling if you don't. So unless you already know how to fix the problem it's probably best to stick with version 5 until a more complete update is released and RPM can officially be updated.

Your code sees everything that uses ModuleScienceExperiment, including everything that inherits from it. Since most of my parts inherit from ModuleScienceExperiment they show up in the list of science parts on the vessel. The problem though, is that the base ModuleScienceExperiment.GetScienceCount() method won't actually return anything, so the method from the more derived module needs to be used. Because I'm generating science data differently from the standard way of doing I need to use my own methods to make sure that everything gets moved around and stored properly, so I use new public int GetScienceCount() { return scienceReportList.Count; } while base.ReturnScienceCount() always returns 0, because my module never creates anything for the base method to see. The same goes for DumpData(ScienceData x) and ResetExperiment(). The base methods won't do much of anything so the more derived method needs to be called. There is a way to instead call the methods from the most derived module, xEvilReeperx came up with something for calling the derived DeployExperiment() that seemed to work fine when I tested it. The code is here (search for "deployable" to skip to the right section). It's a little over my head (using GetType().InvokeMember()), but it doesn't look too complicated and I think it should work the same way for the methods your code is using. Thanks for looking into this.

No, it makes one aspect of SCANsat much more interesting. We just need a way to limit what is available to be displayed on the ground to what has already been scanned. Everything that you would need to determine what has and hasn't been scanned is stored in the persistence file, and cached if SCANsat is running.

This caching idea is looking promising. All three map types use elevation data, so it's only necessary to cache the terrain height data once for each projection type. You can build the map once, with grey or color mode, it doesn't matter, in any of the three map types (elevation, slope, biome) and it caches the terrain height data. This drops the time by around 50% for building or rebuilding any of the other map types and more importantly doesn't have so much of a framerate hit. The best way to run it, I think, is to find a big map size that you like and stick with it. If you are constantly re-sizing the map this won't make much of a difference, but if you stay with one size it should help a lot. The memory implications don't seem too bad. For a totally insane 4000*2000 pixel map (that's bigger than full screen on a 4K monitor) this would require 4000 * 2000 * 3 32bit values, which comes out to 96MB, which is a lot, but that's a ridiculous map size. A more reasonable, but still huge map of 2000 * 1000 pixels comes out to 24MB. And something more realistic, like 1000 * 500 comes out to 6MB. Maybe there's some overhead that I'm not accounting for, but this seems like a reasonable trade off for the increase in performance. Maybe some kind of warning could be triggered when the map is stretched above some limit. The biome map has some issues that need to be worked out, but it looks good so far.

You should never move files out of their original location. This is the quickest way to screw up mods, it might still work, or seem to work, but it's always a bad idea. Even parts-only mods can depend on their files being in a specific location.

TG: You should probably put a disclaimer about RPM in all of your release posts. RPM is not going to work with anything but the v5 release until a more official update is made available.

That multispectral scanner that I've been showing off (but not actually working on) would be perfect for identifying asteroid composition. That's how they are classified in real life, so it would be a great addition. Thanks. My plan for the next release is to fill out the US parts with the other three stock science parts (goo, mat bay, and atmospheric sensor) and hopefully to replace the wedge model. I should also be able to get the telescope finished, I just need to fix its animation. The rover parts could also be put into the US wedges. But I really need to figure out a good way of getting them to actually point at the ground when you use them. I have some ideas in mind, but I just need to sit down and figure it out (and this would be good for the regular laser and drill parts too).

Keeping compatibility with my parts probably shouldn't be too much of a priority, but I agree that there are some problems with trying to make a single core + fairing piece with the wedges placed inside (or maybe the fairings would go on after the wedges). You could make multiple door animations on the fairing, but I don't know of any way to determine which right-click button would apply to which door, clicking anywhere on the part would always bring up every door button. It's probably possible to make a gap in the collider of the fairings and then have the wedge control the animation for the nearest door, but that wouldn't be simple to setup and would still be awkward to actually select the right part. I think the easiest option is making a tapered core (and maybe a special, double-tapered core for single layer stacks) that I think has been brought up before. That could be put at the bottom and top of a stack to make it look a little nicer. I actually kind of like the way it looks now, there are some cases where it might look a little odd, like when the part above or below it is hollow, but that's not a big deal.

OK, I'll have to look into all of this more. For now I've been able to build fine, there were just a few things I had to change. I had to remove SCANdebug altogether and redirect the references. The toolbar reference actually shouldn't be included at all. SCANtoolbarwrapper takes care of everything that Toolbar needs so the reference to the .dll and the using directives should be removed. After I set it to release it compiled fine. So it works fine for the quick testing I've been doing, but obviously I'll need to check into getting things working properly. I forked your Git repository so at least you can see exactly what I've been doing (a 4D array to cache values for the big map seems to working ok so far). The standard crafts and scenarios are great ideas, it shouldn't be difficult at all to setup, really all that should be required is a save file and to point the loading plugin at that file when debugging. Imgur albums are the easiest way to setup initial posts, that way you can just update the album without needing to edit the post as well. I see, I switched off local copy and now I think building it directly in the GameData/SCANsat folder works fine. Normally I start KSP with a .bat file that just copies over the .dll, but your first method seems to be working. I may know a bit more about KSP specifically, but my programming skills are pretty limited. The git fork I setup should give you an idea, but I need to setup VS's autoformating so that it doesn't keep shifting things onto different lines when I don't want it to, that kind of stuff can make it hard to see exactly what has been changed. VS doesn't seem to have a good way of always using Unix line endings, but it can be set manually (and seems to require resetting it every time I save) so that at least the final update for whatever I'm doing can be saved correctly. I'll try looking into all of this stuff more thoroughly to try and figure out what we need.

This looks promising. I implemented a very simple caching system for the big map to store the terrain height values for any already scanned pixels on the map. It has to be recreated every time the map is resized, but when simply rebuilding the big map it cuts down the build time for a nearly complete, low-res scan from around 17 sec to around 8 or 9 sec. The big map in my case was nearly full screen, about 1200 or 1300 pixels wide, the difference should be less the smaller the map is and greater the bigger the map is. RAM usage didn't seem to be affected. It bounced up and down from around 950 to 1130 MB the entire time while testing both the standard and the cached version. This was all very quickly setup with minimal changes made, so there could be a lot of room for improvement, but it's a good sign so far. It breaks changes in map projection mode, so it would have to be recreated for each projection too (or maybe each projection could be stored in a separate array). The big map obviously has a huge combination of different styles and modes, so it's probably not possible to cache every possibility, but there's obviously room for improvement.

There doesn't seem to be much consistency in what does and doesn't get rep. And rep giving sometimes seems to be contagious, with one post or small thread generating a dozen rep comments while other threads can be updated over and over again without getting any response. I seem to get much more rep for tutorials/q&a and from my CPU thread than from my mod work. But I don't care so much about rep when it comes to mods. Having replies, feedback, and questions is much more valuable than having more little green bars. Having a reliable download count would be nice too. When signed in at Spaceport my DL count seems to make sense, a burst of downloads after updating before tapering off slowly over two or three weeks, but the fact that it changes when you sign out, and the general unreliableness of Spaceport makes me doubt either number. Though I think I'm also guilty of inconsistent rep giving. The only place that I reliably give out rep is when people send results for my CPU thread. I even went back and sent rep to everyone who had contributed after they changed the rep system; it took two or three days because of the limits on giving.

I was thinking that another height_map array for the big map could be used to at least store values for a given map size. Whenever the map size is changed the array could be recreated with dimensions set at the current width/height of the map. Storing values for different sizes doesn't seem feasible, but at least you could keep the data cached for simply rebuilding the map with the same size, and maybe with different map types. It looks to me like the code for the two maps was created at different times since they seem to be so completely isolated. I'm guessing that the small map code has remained mostly the same while the big map has had many features added along the way. Maybe it would be best to unify the two. Use the same methods to create both maps with the difference being that the small map is continually updated and uses a fixed size array.

Now that I've updated my mod I've been looking at this more carefully. I think my original post was basically correct. It stores a record of which regions of the map have been scanned and by which scanners. This is a grid 360 units wide and 180 units high with a value in each cell that shows which scanners, if any, have scanned each section of the map. Uncompressed this would use almost 65000 values for each planet, so it's a good thing this gets shrunk down. This coverage map is used to determine which parts of the map can remain as the unscanned grey color, and which need to have values calculated. Both the small and the big map seem to use the same method for doing so, the big just does more of it. Edit: Actually, it looks like the small map does cache the terrain height values, so it only has to build the map once after loading, then it can just repeat those cached values every time the scan line moves up the map. For the small map the terrain height is queried for each degree of longitude as the red line moves up the map, so you get 360 calculations per line. For the big map it calculates values at every pixel along the red line, so you can easily have 1000-1500 calculations per line. Even shrunk down the big map is still 400-500 pixels wide. Maybe there is more of a difference, but I couldn't see it; they both seem to repeat the same code to calculate this instead of using a single method, so it's hard to say for sure. The actual function used to calculate terrain height is provided by KSP's code. It takes a position and returns the terrain height from the center of the planet (so you just subtract the radius of the planet to get the height above "sea level"). The low resolution scanner seems to round off the lat/long values, while the high resolution scanner gives as much precision as possible. The function requires some kind of conversion from spherical coordinates (latitude, longitude) to a vector. There seems to be a standard way of doing this that SCANsat doesn't exactly follow. It uses this method Math.Cos(rlat) * Math.Cos(rlon), Math.Sin(rlat), Math.Cos(rlat) * Math.Sin(rlon) Which is some kind of inverse conversion from spherical to Cartesian coordinates (actually, the x,y,z values * by the radius) using the equations in the wikipedia link above. This vector is then passed off to pqsController.GetSurfaceHeight. The standard method that every other mod uses is QuaternionD.AngleAxis(theta, Vector3d.down) * QuaternionD.AngleAxis(phi, Vector3d.forward) * Vector3d.right That's about as opaque as it gets for me, but there might be some potential performance difference. At first glance I can see that the SCANsat method requires the extra step of converting every lat/long values from degrees to radians, maybe the second method does that later on, but it might make a difference. The Unity-to-KSP buttons definitely seems to be caused by other mods. I was testing Connected Living Space and Ship Manager when I saw this happen (and they seemed to be bugged out, not properly displaying their toolbar icons), after removing them it went away.

A per experiment science cap is an idea that I've been toying with for a long time. I think this would be a great way of getting around the explosion in science points caused by the addition of biomes. The method I'm thinking of would be to have the standard cap and base values for each biome, but put a cap on each planet and have each successive experiment give diminishing returns. So it would basically work as it does now, just with an additional layer of diminishing returns: an experiment in biome 1 gives 100% of the standard return, biome 2 gives 80%, biome 3 gives 65%, etc... (maybe taking into account the total number of biomes per planet). Something similar should be easily possible with asteroids. The asteroid class would be treated like an individual planet and the unique asteroid ID number would be treated like the biomes for each class. That would essentially work exactly as you described. Though I think it's reasonable for the first one or two experiments to give a relatively high science value (maybe 50% of the cap after three separate asteroids), so that people wouldn't be forced to farm asteroids for little science return. I think I'm resigned to the fact that I'll never actually be able to actually play KSP again. This is something I've wanted to be able to do ever since I made my Deep Impact mission (even though I think that one turned out pretty well). I'll check out how KSPI does it, but I don't think there's anything too complicated going on and it should provide an opportunity to make an interesting part.

It does, but if you mean it should keep a texture of each map cached then you would run right back into the problem that ISA had, huge amounts of memory usage. If you really want to know about what is being stored and how it is encoded you can check out this Unity thread about the compression algorithm being used. http://forum.unity3d.com/threads/152579-LZF-compression-and-decompression-for-Unity I'm not entirely sure what it's doing, but I think this is what's being used to convert the coverage map for each scanner, for each planet, into that string of gibberish stored in the persistent file.

That's weird, maybe there is some better way to set up the alpha channel for my textures so that this won't happen. I'll look into it, but this is probably a problem with the texture loading mod. I was also considering the scale of science return when I set it up this way. The stock asteroid sample seems to ignore the regular situation multiplier so it always gives 50 or so science, which makes this a really impractical way to build up too much science, but also prevents asteroids from further throwing off the career mode balance too much. My parts don't do that though. A full set of science reports for a class E asteroid can return around 1000 science. Getting that much science for every class E asteroid you manage to rendezvous with would make the science points balloon even further out of control. I do like the idea of setting up some kind of diminishing returns for each asteroid class, so maybe you could get results from four or five asteroids before you ran out (but keeping the same overall total amount of science for each class). Even better would be assigning a spectral type for each asteroid and basing the diminishing returns and science reports off of that instead of just size. My current science reports sort-of do this, but really I just randomly assigned each asteroid class to a different type (Class E are M-type asteroids, Class A are S-type etc...) while writing the science reports. I'm not sure how to go about changing the Kerbal-specific stock science experiments. Those are all locked away either in the Kerbal code (crew reports and surface samples) or the asteroid module code (asteroid samples). It would be easy to set up a different method of collecting stock asteroid samples (with a robotic collector for example), but altering the stock EVA experiment would be more difficult. But yes, the stock method of getting multiple results from the asteroid based on your orbit is dumb and hopefully it gets changed.

Correct. The asteroids basically behave like another planet with the classes being the biomes. So each asteroid class only has one pool of data per experiment. I considered doing something like the stock asteroid samples do and just appending the asteroids id number to the end of the science report title, but I don't really like the infinite science implications of doing that. It's probably possible to implement some kind of diminishing returns for repeated scans on different asteroids of the same class. I'll look into that. Both of the major features introduced in this update, asteroid science and the Universal Storage parts, are very much first drafts. The US parts I already mentioned a little about, and I'm also planning on filling out that collection with the other three stock science experiments and at least some of my other parts. I have a version of the telescope that works great in Blender, but I got carried away with the animations before realizing Unity couldn't handle that kind of complex animating. For the asteroids I want to see what Starstrider42 comes up with for the Custom Asteroids mod, but there are many possibilities.

It should be, there weren't any significant changes made to the existing parts. There was a lot of poking around the edges of the plugin though, so let me know if anyone runs into bugs or if something is behaving differently.