DMagic

Unity asset explorer to the rescue, once again. I think you'll need to open with photoshop or some equivalent. Just make sure the alpha channel is turned on and it probably needs to be flipped vertically. I pulled it out of sharredassets7.assets. I checked the file in a 0.22 installation I have and it looks like the SpaceObject icon is the only new one, located at 3 down, 4 across (starting with 0). Edit: Or maybe you don't need to flip it, so it's 1 down and 4 across, or 19 in the enum. Edit: Zap

I won't post the whole list again, but a quick check shows they are all the same. This is what I expected given that there weren't any changes to the science system. I'll check again in 0.24, as that seems like the more likely update to contain changes to the ScienceParams values. Of course, whether or not the game is still ignoring the same values as it did before is another question. The only way to test that is in-game.

The source is included in my toolbar version download. http://www./download/u5egmogu8nisctq/SCANsat_Toolbar_V0_2.zip I downloaded the SCAN-master.zip from Github, added my own class then repackaged everything for the download, so it should be identical to the Github version aside from my changes. I actually looked at that OrbitIcons enum in SCANui and I couldn't quite figure it out either. It's clear that MapView has a method for retrieving those textures (MapView.OrbitIconsMap), but I'm not clear on how the SCANsat code takes an input from the OrbitIcons enum and translates it into something the MapView can use. I can see how it gets from a VesselType to an OrbitIcon, but there is some step after that that isn't clear. I think it's not only the addition of a new VesselType that screwed up the orbit icons, but that those new types were added to the front of the enum, instead of the end. If it were the other way around (which to me makes more sense) I'm not sure that this would have caused problems in the first place. And yes, I think it's just SpaceObject that's new, since there is a reference to VesselType.Unknown in the existing SCANsat code (it just might not have ever been used). I'm guessing that you don't have to worry about re-ordering the OrbitIcon enum to add in SpaceObject, since it is already a jumbled list of VesselTypes and other icons. About the toolbar code. Adding a hard dependency on Toolbar is really simple, but since some people seem dead-set on not using Toolbar you'll probably need to allow for the default behavior to work too. I commented out the code necessary for generating the minimized probe icon, and made the UI ask whether the small map has been closed or not before drawing the window. The probe texture code probably doesn't need to be commented out regardless of what you change (I did that before changing the window drawing behavior), but you probably will need to make some changes to allow for the default minimized icon to be used instead of the toolbar icon. The only other changes I made were to some access modifiers (from private to internal) and I changed the 'minimode' int to -2 instead of 2 when launching (maybe that's a bit of a personal thing, but I think windows should never start out opened by default). Edit: Just had a minor epiphany. What if MapView.OrbitIconsMap doesn't get individual textures for every icon, but instead generates one big texture with each individual icon located on a grid within that texture? Then the texCoords from the GUI.DrawTextureWithTexCoords determines where on the grid the texture should be drawn from. That would explain why the OrbitIcon enum is used only for the tc_icon Rect.

I'll repeat this again for 0.23.5. But it seems that most of the values are simply ignored. "Splashed" looks like it has a default value, even if there is no ocean. And the different values for flying low/high and in space low/high don't seem to be considered. The altitude thresholds are probably the only really valuable thing to come out of that code.

I finally got around to more thoroughly testing the change in performance from 0.23.5. I ran several tests on my Surface Pro 2, which has a weak enough GPU to be significantly effected by the terrain detail. I ran six tests, three on 0.23 and three on 0.23.5, all at the same graphics settings and all with the terrain quality set to default in the settings menu. Two tests were run in the standard, looking up mode (orange and yellow). Performance here is pretty similar. The next set are more interesting; after applying the ocean terrain quality tweak I launched the rocket again, this time keeping the horizon centered throughout the entire run. You can see that the 0.23.5 run clusters together with the first, looking-up, tests (green). The 0.23 run shows a significant drop in performance though (grey), only improving when the vessel gets above 160km where the terrain switches to a lower detail mode (indicated by the blue arrows). The last set are the most telling. With terrain quality set at default, and no changes made to ocean terrain settings, you can see that there is a huge drop in performance in 0.23 (brown). I was also watching CPU usage during the test (I run KSP in windowed mode) and I could see that after I was above 50 or 60km the CPU started throttling back. Normally it runs at about 50% utilization at 2.3GHz, during this test it dropped down to around 25% and the speed dropped down to around 1.5GHz. Clearly the game was GPU limited at this point. When I tested it in 0.23.5 a completely different picture emerged (blue). Performance while keeping the horizon centered (which I've generally found to be a worst case scenario in terms of terrain related performance) was almost the same as it was while looking up, and looks almost identical the run with the ocean terrain settings tweak. Compare the blue and green lines, most of the difference appears to be from stage timing rather than performance. If you look carefully you can see that the framerate does begin to suffer as the part count drops. In both of the horizon runs under 0.23.5 performance is capped at around 30 FPS until the vessel gets above 160km, so I still recommend looking up while running the test. Nevertheless, the performance change is pretty impressive. Above a certain level of GPU power you aren't likely to notice it, but with mobile computers and older graphics cards it can be a major, and very welcome, change. TL;DR: Compare the brown line to the blue line; huge jump in terrain detail-limited performance. I'll see what I can come up with for this. It's definitely a good idea, but I don't want to make this the standard way of collecting results. There are several practical issues that come to mind when including a plugin that writes out results to a log file. But if I can come up with a way that gives results comparable to those given by standard benchmark software I will offer it as an optional method for collecting data.

But there is a technical difference between not having a biome map, which the game reads as being an empty biome, and not having any terrain data. Conducting a scan (and having the science collection mechanism recognize that scan) would require some kind of special case for the sun and Jool. It's not that it can't be done, it's just that this probably isn't a high priority.

I believe you are in debug mode. Click that little icon to the right of the lock symbol (the down arrow and the three lines) in the upper right corner and select the normal view and the write button should appear.

This is a problem with that part model specifically. The collider mesh is not setup very well, so it's very difficult to actually select the part. The easiest way to do it is to select the backside of the scanner. If the backside is completely covered try selecting it from the side. Or you could try zooming in very close to the part, if you can zoom in through the front section you might be able to click on the base of the part. Is this only a problem with Jool? I've haven't had any issues with science collection in 0.23.5. It might be that the scanners don't collect anything for Jool because there's not really anything to scan.

Here's the link to the post for the original one: http://forum.kerbalspaceprogram.com/threads/55832-PLUGIN-PARTS-0-23-SCANsat-terrain-mapping?p=928786&viewfull=1#post928786 You can download it from the link on my parts thread (it's just below the gallery): http://forum.kerbalspaceprogram.com/threads/64755-WIP-DMagic-Orbital-Science-New-Science-Parts-V0-7-5-%284-1-2014%29 I have actually considered cleaning up this part and making all of the animations and blinking lights work properly. It's easy to do, and wouldn't require doing anything with the SCANsat code, I just have to get around to it. In its current state it doesn't really sync up with the SCANsat code and you have trigger the animations manually. You can also use the anomaly scanner that comes with my other parts (which can be downloaded at the same page) like MeCripp said, though that one requires that you keep the plugin from my mod and that you keep the science module for it.

Whoops, I thought I had noted that in the part's in-game description (it's on the description in the first post of this thread). I'll add that in next time. Part of the reasoning for this is that I intentionally want to create more limited-use parts. This and the anomaly scanner are the first two, but I am thinking of making more. I have in mind something designed specifically for asteroids, but there are many examples of more specialized parts. I was also thinking of something made specifically for liquid science, so it could only be used on Kerbin, Eve, Laythe, and maybe Vall.

Why are they dead weight? You can use the science lab to reset used experiments. And instead of complaining about the lack of documentation for the part maybe you should test it before beginning a long mission.

Thanks humpty, I added your results and a few backlogged results to the first page. For now I just used Excel to convert the results in the log file to something usable, but I'll try out your script too. Yeah, I spent forever figuring this out then promptly forgot all about how to install it, so thanks for those instructions. And a 32-bit / 64-bit comparison would be great. Someone did that a while ago, but that was before version 0.23 and I'd be interested to see if something has changed. Measuring the time scale difference might be a good idea. But it is inherently related to FPS, once you drop below 33 FPS the time scale is forced to expand, regardless of what is pushing you below that limit. I also changed the charts a little and included some with more relevant comparisons. I like the online chart idea that xaiier suggested, but it's a little bit slow, I'll look into it more though.

It works fine with the basic experiments from my mod. It won't do anything with the anomaly scanner (only with my latest update, the anomaly scanner can be improperly triggered by this mod in previous versions) and it shouldn't see the drill at all.

That's exactly what I was thinking. They look fine at the relatively normal levels of zoom in your other pictures, it's only the closeup where the crinkles look a little bit deep. If you're like me this problem of adding too much details is exacerbated by the way I work in Blender. Because I find it hard to work with small parts I do everything at 10X scale in Blender and spend a lot of time zoomed in very close. So by the time I get the parts into KSP I realize that a lot of the detail isn't even visible or noticeable at regular zoom levels.

This is what I use to check the biome. public string getBiome(ExperimentSituations s) { if (scienceExp.BiomeIsRelevantWhile(s)) { switch (vessel.landedAt) { case "LaunchPad": return vessel.landedAt; case "Runway": return vessel.landedAt; case "KSC": return vessel.landedAt; default: return FlightGlobals.currentMainBody.BiomeMap.GetAtt(vessel.latitude * Mathf.Deg2Rad, vessel.longitude * Mathf.Deg2Rad).name; } } else return ""; } Though looking at it, it could probably be simpler. vessel.landedAt returns an empty string (I think) anywhere outside of the KSC, so you could just check to see if that is empty, if not return that value for the biome, and if it is do the regular biome check. I've heard that you can also get results for the "KSC" biome while flying above it (or maybe in space if you're really quick?), but I don't know how that works or how to replicate it. Do you get accurate biome results using vessel.latitude/longitude? Using the method I showed always requires position in radians not degrees. As for the experimental situation, check around. I consider it a bug that you can only conduct atmospheric science while on a sub-orbital trajectory, so all of my experiments use a method that returns flying high/low anytime you are in the atmosphere. All of the methods I've seen are basically the same as mine, there are just a few adjustments that need to be made to return stock science behavior. Ignore the bit about asteroids at the top... public ExperimentSituations getSituation() { //Check for asteroids, return values that should sync with existing parts if (asteroidReports && AsteroidScience.asteroidGrappled()) return ExperimentSituations.SrfLanded; if (asteroidReports && AsteroidScience.asteroidNear()) return ExperimentSituations.InSpaceLow; switch (vessel.situation) { case Vessel.Situations.LANDED: case Vessel.Situations.PRELAUNCH: return ExperimentSituations.SrfLanded; case Vessel.Situations.SPLASHED: return ExperimentSituations.SrfSplashed; default: if (vessel.altitude < vessel.mainBody.maxAtmosphereAltitude && vessel.mainBody.atmosphere) { if (vessel.altitude < vessel.mainBody.scienceValues.flyingAltitudeThreshold) return ExperimentSituations.FlyingLow; else return ExperimentSituations.FlyingHigh; } if (vessel.altitude < vessel.mainBody.scienceValues.spaceAltitudeThreshold) return ExperimentSituations.InSpaceLow; else return ExperimentSituations.InSpaceHigh; } } Edit: If you want a good look at how to check experiment status for stock science look at the code for xEvilReeperx's ScienceAlert, last I checked it had the methods you need for these kinds of things.

So here's an idea, since we have Dev Note Tuesdays, why don't we have Mod Note days as well. Instead of randomly updating this thread or waiting until people ask questions I can just put a small update once a week with some of what I've been working on. I dub today the first Mod Dev Note Tuesday. I've been working on several things for the next update. The asteroid science system that I've mentioned several times before seems to working. I think I've gotten rid of all the bugs and it doesn't seem to affect any of the non-asteroid science. I'm still using the asteroid mass to determine the class, but I think I've got the mass ranges figured out. The different classes determine which results you'll collect and the value of the report. I've added a full set of science reports for the magnetometer (both nearby and while grappled to an asteroid) and for the laser scanner (while grappled only). The magnetometer's readout has been tweaked and extended to work everywhere now. There are full magnetosphere simulations for Kerbin, Duna, Jool, Eve and the Sun; the size and intensity of the magnetospheres vary greatly between planets. When you are in orbit around a moon or a non-magnetic planet the readout returns values for the parent planet or the sun. I've also reduced the update speed to five times per in-game second while out of timewarp. While in timewarp the update speed increases up to fifty times per second. This should alleviate any concerns about the magnetometer impacting performance. And finally, parts. I've shown this before elsewhere, but it's been updated and changed a bit. This is based on some of the Cassini instruments and has a UV imager (in the middle), an IR imager (left) and a multi-wavelength, visible and IR imager (right). I think the model and animation are ready, it only needs to be textured. I've also been working on several other parts, but I'll update more on those when I get closer to finishing them.

Thanks for those instructions on BuGLe, it's not quite as straightforward as FRAPS, so it's nice to have some help. I think it outputs values as a framerate for each frame, which is kind of an odd way to do it. To figure out the x-axis you need to take 1/framerate for each frame, which should give frametimes in seconds per frame. Then, starting with the first frame add the frametime value to zero. Then add the next frametime value to the first product and repeat all the way down. That should give you the time in seconds where each frame takes place. Something like this in Excel, column A would be on the y-axis and column C would be the x-axis: Also, can you send me the output log for your results humptydump? I can do all of the processing, but I want to add your results to the rest.

The wiki values are intentionally different from the in-game values. In-game the apoapsis/periapsis distances are reported from the surface of the sun, in the wiki they are reported from the center of the sun. Add in the radius of the sun to the in-game values and they come out the same as the wiki values.

The actual button names are determined by the type of scanner, that can easily be changed, but it requires editing the plugin. In my opinion, the best way to deal with the MapTraq part is to get rid of it and replace it with a ModuleManager config that adds the SCANsat module to every command pod and probe core. I don't think there's any real reason why you should need and extra part. An activate/deactivate button could be left there if it requires energy, or you don't want background scanning to take place for some reason. The placeholder part doesn't really encourage its use anyway.

I'm guessing this has to do with the LateUpdate() method. The animations are being initiated in flight and in the editor, but they are only being stopped in flight, the LateUpdate code doesn't get run in the editor. My question is, why is it necessary to initiate the animations? Why can't they just be played directly, or is this something to do with allowing for multiple animations?

Stock parts are really inconsistent about this. And it's not just nodes, radial attachment is all over the place, making it impossible to configure the nodes on your parts so that they attach to everything correctly. It would be easy, though tedious, to fix all of the stock node positions, but I don't think there's anything you could do about the colliders that determine where radial parts attach.

No, you need to download the RPM source from Github, open the .sln project file in Visual Studio, reset the standard references to your install of KSP (you'll need the Mechjeb.dll too), and reset the SCANsat reference to the toolbar version of the .dll. Then you can recompile and replace all three RPM dll's with the newly generated files. It's simple if you already know how to do it, not so much if you've never done it before.

Is there any reason not to leave all of the meshes combined as one object? I know that this isn't the case for animating, or for using multiple materials, but I assume that won't apply for most of these parts. Also, if those colors really are solid, no shadows or gradients, you might be able to get away with blowing up only the labeled surfaces and shrinking everything else down to fit on a smaller texture.

I downloaded the RPM source and recompiled against my version (the second toolbar release) of SCANsat. Everything seems to be working ok, the map loads up on the cockpit screen and the toolbar buttons work fine as well. agises, when you checked this, did you recompile and replace all three RPM .dll's or only the SCANsatRPM.dll? I found that you have to replace all three files, otherwise it won't work (maybe the MechjebRPM.dll isn't necessary, but the main .dll definitely seems to be). Recompiling is simple if you know what you're doing, but if you don't it can be a little mystifying and requires software that most people probably don't have. So it's easy to fix, but it's up to Mihara if he wants to distribute another package or not (technically anyone should be able to release it, but since they're still around and active I don't want to do that).

Perhaps shifting the position of the fuel pipes a little bit and adding some kind of brace in the center would make them look a little bit sturdier. But I agree, I really like the look of these and that they allow surface attach.