DMagic

I'm not really familiar with how people generally setup their toolbar buttons. Do people prefer having different buttons for each window of a plugin? And do plugins that require a specific part make the buttons only appear when that part is present, or do they just leave a non-functional button? I can setup the toolbar support for any of these options, none really requires any more or less effort than the other. I think buttons for each SCANsat window would be a little superfluous, but two might be ok, one for the big map and one that opens a menu to open all of the others. Or maybe just one button to open a menu for all of the windows. I also have a method for making the SCANsat buttons disappear if none of the parts are present.

If you don't want the interstellar science reports for the magnetometer then all you would need to add is MODULE { name = DTMagnetometer animName = magBoom } If you want the science experiment you would also need to add the ModuleScienceExperiment section too. The right-click menu will start to get a little crowded with all of the buttons and fields being updated, but it should still work.

Is there some specific problem you're having? Did you not see the section marked "solution" in his emissive textures thread that linked to the emissive tutorial with a detailed walk-through of how to set up the animations?

KSP upgraded to Unity 4.3 for 0.23.5, but they didn't release new parttools. We might need to wait for them before Unity 4.3 is working properly.

I think this is a problem with either Unity or the way the KSP Parttools handle transparent textures. From certain angles transparent textures just disappear. Alpha-cutoff textures don't seem to have this problem, but they can't be used for partial transparency like you see above.

Maybe this is a better idea. I didn't realize how simple the Toolbar API is, so this is a really simple thing to change. It requires no further modification of the SCANsat code, I just added a few lines to the toolbar class that I added. All of the regular open and close buttons work the same as always for all of the windows, there is just the added option of opening and closing them from the toolbar menu. I'll clean this up and make sure it's working right tomorrow.

I updated this again with the latest version: http://www./download/5uetoyutzgiadt2/DMModuleScienceAnimateGeneric_V0_4.zip The newest plugin adds the ability to collect science from asteroids. To setup your experiment for asteroids you need to change the "asteroidReports" field in the .cfg file to true. In your ScienceDefs.cfg file you setup the "situationMask" as normal (the "biomeMask" doesn't matter); the InSpaceLow experimental situation will give results when you are within 2km of an asteroid, SrfLanded will give results when you have grappled an asteroid. Outside of those two cases your experiments should work as normal and give regular science reports for all relevant experimental situations. If you have multiple asteroids within 2km it should only choose the first of them (I don't know how it will order them, or if it will always be the same). For custom asteroid science reports follow the format: "AsteroidSrfLandedClassA" and "AsteroidInSpaceLowClassA". Separate reports for each class (A-E) can be created, but the host planet does not matter (results collected near an asteroid in orbit around Kerbin will be the same as those in orbit around Eve, the Sun, etc...). I am classifying asteroids by their mass; I think I have the ranges fairly accurate, but it's possible that the plugin could report an asteroid as the wrong class. The science value multipliers for reports near an asteroid are: 1.5X, 3X, 5X, 8X and 10X for classes A-E, respectively. The values for a grappled asteroid are 1.5X higher for each class. These can obviously be adjusted in future updates if anyone feels they are too high/low. I fixed a handful of other, minor bugs with this update as well. Let me know if anyone has thoughts on this idea.

Well, since I was tooling around in the SCANsat code anyway, I decided to figure out how its UI works and whether or not I could add toolbar support easily. It turns out to be pretty simple to add in some basic toolbar support. Edit: No need to have multiple versions of this floating around. If anyone wants the single toolbar button version PM me. Otherwise go here for the multiple button version. Download the package linked to above and copy the new SCANsat.dll over the old version (or delete the old version first) in the GameData/SCANsat folder. You must also copy the included texture into this folder as well, the toolbar icon will not show up without it. And, obviously, you need Blizzy78's toolbar installed, it is not included here and the plugin won't work without it when using my new .dll. The source code is also included and all changes made by me are noted inside the .cs files along with the relevant license information. This is provided as is, with no guarantee of working or compatibility. I'm not taking requests or suggestions and I have no further plans to modify the SCANsat code. If anyone finds any bugs I can take a look and try to figure it out, but I make no promises. It works at a pretty basic level. The toolbar button (I pulled the icon out of the Unity assets and colored it to match the default SCANsat icon) opens and closes the small map. It doesn't have any effect on the big map, the settings window, or the instrument window. The instrument window can be a little wonky if you try to drag it off screen while the small map is closed; it will snap back to below wherever the small map was, even if it's no longer on screen. But otherwise the windows don't seem to be affected. The "X" on the top-right of the map closes it the same as the toolbar button, you can close it this way and it will still open fine from the toolbar. The toolbar button will always be visible (though it can be changed like every other toolbar button) in flight or in the map view, regardless of whether or not you have SCANsat parts on board, but it won't do anything unless you have a SCANsat part on your current vessel. The only thing to be aware of is that the Start/Stop Scanning (or Open/Close Map for the MapTraq) buttons on the SCANsat parts won't actually open the map. They will start scanning, but you have to click the toolbar icon to actually open and close the map. *Warning: Does not work with RasterPropMonitor Check out that sweet action.

Wow, thanks for this. I am actually making use of Kerbin's year and solar day times, so this will cause some drift in my calculations. I'll have to adjust for these changes. Edit: Kerbin was moved in a little from 13,599,840,256m to 13,338,240,256m.

There are two types of asteroids, the unknown, untracked versions and the tracked versions. The tracked versions have lots of information associated with them and show up in you persistent file, so they won't go away. But the untracked ones are just temporary objects, if you wait long enough they will disappear.

Yep, the new "SpaceObject" and "Unknown" (I think that one is new) VesselTypes screw it up. A simple recompile fixes it. Replace the SCANsat.dll file in the GameData\SCANsat folder with this one and it should work: http://www./download/a4v6v8r0d96ao89/SCANsat.dll Though I make no promises about the reliability of this replacement, I didn't change anything and it should work fine.

I was just a bit too slow to edit my own response. I saw that all vessels have the new "Discovery" section in the persistent file with the "size" value that seems to match the asteroid class (though it seems to default to 2 for non-asteroid vessels). This seems to work for finding the value of asteroid you're docked to, and I have another simple method of getting to the vessel data of a nearby asteroid. KnowledgeItem<UntrackedObjectClass> sizeItem = FlightGlobals.ActiveVessel.DiscoveryInfo.size; string size = sizeItem.Value; That spits out A, B, C, etc..., then I can convert that back to "Class A" and so on. The DiscoveryInfo.GetSizeClassDescription() method gives you the long description shown in the tracking center, GetSizeClassSizes() gives you "C (medium)" and so on. There may be a more direct way of getting at the value, but that seems to work well enough. The only thing I'm not sure of is whether that "size" value is affected by your actual vessel. The asteroid I'm docked to now is size=2, which should be Class C. I need to find a different class asteroid and dock to it to see which vessel's size number carries over. Edit: Well drat. The spacecraft's "size" value seems to override the asteroid vessel's value, and it seems to be persistent, so once you've docked once it will always be seen as a Class C asteroid. Looks like it's back to using mass to figure it out.

I was working on the EVA anomaly scanner, then I got frustrated (and have again several times since then), so then I made this part. I still have no plans for actually using, but I'll think of something. It's ready to be textured and the animation needs some cleaning up, but otherwise it's mostly ready.

Anyone have any ideas on how to access what class any given asteroid is? ModuleAsteroid doesn't seem to have anything that directly indicates the class (maybe the seed number indicates it in some way?). The only way I can get at it is indirectly through the part's mass, but I don't have accurate values for the mass range for each class (if that is even how they are classified). I would prefer to get the class value directly, but if I have to I can just figure out the mass ranges and get it that way. Edit: I may have found something, DiscoveryInfo and UntrackedObjectClass look promising, now to find out how to get to this from the asteroid part itself.

That's not what they're saying. You can take an asteroid to different locations around Kerbin (or any other planet) and collect different science reports and gain more science points. So you can collect a sample high in orbit around Kerbin, then another in low orbit, one while in flight, and another on the surface of Kerbin (I think the surface also has biome support) and so on. Each location will give you more science.

I updated the spaceport and mediafire links with the new version of the rocket. It turns out that the new joint system causes struts to hold on to radially decoupled parts a little bit tighter. This was causing some of the SRBs to crash back into the rocket. So I just struted the SRBs to themselves (the struts are nearly invisible now, but they are still there), this way the part-count and part types remain unchanged. Performance is the same and the rocket has been stable in the five or so times I've launched it. A better comparison between 0.23 and 0.23.5 performance: And I ran a quick camera-view test to see how much difference 0.23.5 made to the ocean terrain lag. I didn't get much of a decrease in performance in 0.23, so this difference will be more dramatic with weaker GPUs, but it is still quite visible. The blue and green tests are the standard, looking-up tests, while the orange and grey are the worst-case tests, with the horizon kept centered in the frame. The decrease in performance is still there in 0.23.5 (in orange), but it is almost unnoticeable for me. And in real-world cases, where I would have V-sync on and the framerate capped at 60, I would probably never see it. It is still a good idea to keep the camera pointed up while running the test though, this helps to remove a lot of GPU dependency, especially on weaker systems or laptops.

I have considered maybe making stock science parts that could fit in the Universal Storage parts, but I'm kind of waiting to see what happens with that project. But it's not likely that anything will get done soon regardless of what happens with that project, as I have a few parts that I've started working on already and I'm mostly focused on the plugin right now. I think that I've seen a stackable goo container somewhere, maybe I'm just imagining it, but I thought someone made one. There is at least the smaller goo and materials bay parts made by Sethnizzle.

Assuming that science works for the Urania planets my parts should also work. They will all give default results, but the science values should be correct. I have already added custom reports for all of the default Sentar planets, but I don't think I'm going to be adding more for other planet packs, that could balloon into a lot of results very quickly. Thanks. The magnetometer was my first part, and I think still my favorite. It's doubtful that I'll get this updated again before 0.24 (unless that takes a lot longer than I'm expecting to be released). Everything else should be working, but the asteroids will have to wait. For now though, I still need to find out if I can directly access the asteroids' class values, or if I have to determine it myself based on the mass (and I'll need accurate mass ranges in that case).

Yeah, this is something I have already been thinking about a little. A lot of the existing results for the laser scanner refer to different types of asteroid composition. I could try to add something like this for the actual asteroids. For now though, I think have the basic system working. It was more complicated than I thought to figure out if an asteroid is nearby, but I got it working. You can get results while latched onto the asteroid or in space nearby (within 2km for now) based on how the experiment is setup in the ScienceDefs file. Aside from a single true/false field in the part.cfg file, nothing needs to be changed for this to work, though custom reports would be nice. I have broken the asteroids down into their classes by mass, I don't know how accurate the values I'm using are, but that can be fixed later. Larger asteroids give more science, and each class represents a different result. The surface experiments give twice as much science. The results can be transmitted and seem to be accepted by the R&D center, they also show up in the persistent file. The results windows shown below are for reports taken again after transmitting it once (as you can see in the debug window). Edit: I also fixed the bug that was causing a mismatch between the title displayed in the result window and the title being sent to the R&D center, it was actually an underlying bug that affects all of my experiments, though I'm not sure if it actually matters.

Ok, ignore all that business about not being able to get it to recognize the asteroid as a celestial body. I don't need to make a new CelestialBody, I can just temporarily reassign an existing one, change its name and some of the values associated with it (hopefully based on class/mass), and I should be good to go. A quick test shows this to be at least mostly working.

I should probably clarify what I mean by biome method. For the sciencesubject you need to input a biome string value. If the experiment doesn't use biomes then the string is empty, but it's still there. I can put in whatever I want for that string. My anomaly scanner takes the name of the anomaly, turns it into a string and uses that. In my sciencedefs file I have results named "KerbinSrfLandedKSC" and so on for each anomaly. So when I say biome method it doesn't actually have anything to do with the regular biomes, you wouldn't be able to get repeat results based on which biome of Kerbin you're flying over. I was thinking the same thing. I don't know where the asteroid class is stored, or if I can access it, but I should at least be able to get the mass and make up different results based on that. I agree, but for practical reasons I think it's easier to try and separate them into two different experimental situations. That way experiments that are meant to be used only in space can behave properly, while surface experiments can work while docked to the asteroid. This would allow for the experiment definition in the sciencedefs file to be easier to setup and more consistent. I can probably get this to work by determining what your target vessel is (ie the asteroid) and its distance from you. That way you would need to be targeting the asteroid and in close proximity for the experiment to work. This is my thinking for why I prefer the celestial body method. I don't want people to just drag an asteroid around to different planets to get repeat science from it. The problem is, that this might be mutually exclusive with the biome method. The options might be: Get repeat results for each class (or mass range) of asteroid around each planet, or get one set of results for each class. I might be able to get it working my preferred way with either method though, I just need to spend more time with it.

Anyone have any ideas on how asteroid science should be conducted? Should they act like another biome, allowing science to be collected around each planet? Or should they be like their own planet, with multipliers that can maybe be changed based on asteroid size? The biome method is pretty easy to setup, that's what I'm basically doing above. This would end up with results like "KerbinSrfLandedAsteroid" for each experiment, with results for each planet being possible. The other method is more trouble, I'm trying to coax the game into thinking that the asteroid is a celestial body with different multipliers for different situations (detecting a landed craft is easy, I'm not sure about getting it recognize something merely nearby yet). The celestial body method would allow for science reports like "AsteroidSrfLanded" or "AsteroidInSpaceNear" for each experiment, and they would ignore what body you are actually orbiting. I've got this method partially working, but it doesn't seem to fully accept the existence of my newly constructed CelestialBody parameters.

Thanks. And what do we have here. This is about the hackiest way of doing it that I can think of. My more clever method wasn't working, but it's a start.

Wow, that's a good idea, I'll look into that more soon (I'll also get your other results added sometime). Yeah, that seems to be the case. I'll need to switch back to 0.23 and run this again with different viewpoints, I might also need to cripple my new GPU since it seemed to be able to handle the ocean lag without many issues. In the meantime I've been fixing my CPU rocket with some rather predictable results. I think I've found a way to fix it though, replacing the parachutes and nose cones with sepratrons on the second and third SRB rings seems to make it stable, I just need to test it several more times. Hopefully the difference in part type won't affect performance.

This happened to me on a stock install yesterday (obviously without the autowarp, just using the regular keyboard command). I'll see about trying to repeat it and report it.