DMagic

Thanks. I want all of my parts to have custom science reports and not only provide an alternate means of taking default science results, and BeastofChicken already has a pretty good robotic surface sampler. I am a little worried that providing a bunch of extra science experiments will start to effect the career mode progression a bit too much. And this will only get worse when more planets get biome support. Those ideas are really similar to what I've been thinking about. I actually suggested something similar for a part that Yorik has made, I'll see what he does with that part, but that is one of two probe instruments I have in mind. The other will hopefully be a relatively simple thing to make. I've been thinking about space station and/or base instruments too, but I'm not sure how to implement them within the current science system. I'm not sure what I'll do about those types of parts, I might just wait a while to see what Squad does in the next few updates.

The engines were probably breaking off. That's usually what happens when a heavy craft gets put directly on the launch pad.

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 I've been thinking that I should probably explain a little bit more about what exactly radio and plasma wave science is. The other parts are fairly simple to grasp, at least on a basic level. The magnetometer measures a planet's magnetic field. The specific model I based my instruments on are from the Cassini spacecraft. The sensor in the center of the boom is fairly simple type, a fluxgate magnetometer, which has three separate instruments to measure the magnetic field in all dimensions. The one on the end is called a vector/scalar helium magnetometer, it is quite a bit more complicated, but it basically does the same thing with only a single instrument. The reason these instruments are placed on a long, non-magnetic boom, is that the fields they are studying are very weak, and interference from the spacecraft itself can affect their measurements. The laser is based on Curiosity's ChemCam, it vaporizes a small amount of the surface. This causes the compounds in it to release light in a very specific way, which is picked up by an imager. The telescope is simply an optical telescope, made to pick up visible light. The radio and plasma wave science instrument is not so simple. The model I used is also based on the Cassini instrument, but these instruments are very common; some type of plasma wave antenna has been included on most of the major interplanetary probes. Let's go through it word by word, starting of course, in the middle. Radio and Plasma Wave Science The plasma in question is the solar plasma, generally referred to as the solar wind. The common examples of plasma on Earth are lightning strikes (the molecules in the air are ionized and carry a huge electrical current back and forth between the ground and clouds) or gas discharge tubes, like a fluorescent or neon light. The solar plasma is the same thing, just far less dense, we're talking about a handful of particles per cubic meter. It is mostly electrons and protons (hydrogen ions) ejected from the sun, though there are some heavier ions. Coronal mass ejections (associated with solar flares) carry a much higher density of plasma. Radio and Plasma Wave Science Plasma waves are simply repeating patterns of movement made by electrons or positive ions within the solar plasma. While the solar wind flows mostly straight outward through empty space, its path is altered by planets and magnetic fields. Once the plasma encounters a magnetic field it can behave in several different ways. One type of plasma wave, called a Langmuir wave, consists of electrons oscillating longitudinally within the overall movement of the plasma. That is, not moving up and down like a water wave moving toward the shore, but moving back and forth like a sound wave travelling through the air. If the overall direction of the plasma is to the right, then Langmuir waves consist of back and forth left and right movements. The plasma is moving to right below, and the dot represents an oscillating electron: ----------> <--.--> -----------> This creates an electrostatic wave, one without a magnetic field component. A radio and plasma wave instrument detects these waves using its antennae. To distinguish between an electrostatic wave and an electromagnetic wave it uses something called magnetic search coils. These are basically simple versions of a magnetometer instrument that don't need to be mounted on the boom. By measuring the signal from the antennae and the search coils at the same time you can determine whether the antennae are picking up waves with a magnetic field component, or without one (my model doesn't really have magnetic search coils, so I'm just pretending they're hidden away in the base somewhere). Plasma waves are a very short-lived, short-distance phenomenon. You can't study Jupiter's plasma waves from the Earth, not directly at least, you have to send a probe there. Only when you are within this plasma can you really get a good reading of it. That is one of the reasons why these instruments are so common. Radio and Plasma Wave Science There are many other ways for the particles within the plasma to move, and most of these generate electromagnetic (EM) waves, waves with both electric and magnetic field components. These are generally in the radio wave section of the EM spectrum (that goes from radio waves, to microwaves, infrared, visible light, and so on). Again, these are picked up by the antennae, and readings from the magnetic search coils are used to determine what component of the signal is generated by EM waves. These waves can be simple up and down movements of electrons within the plasma. They can also be more interesting patterns; electrons can spiral around magnetic fields causing something called electron cyclotron emissions. Radio waves generated from such movements are associated with auroras (called auroral kilometric radiation) and are found coming from Earth, Jupiter, Saturn and other planets. Lightning can also generate plasma waves (called whistler mode waves), which in turn produce radio waves. Radio and Plasma Wave Science And now back to plasma for the third and final component of the instrument, the Langmuir probe, a small metallic sphere put on the end of a short boom (which pops out from the side of my model). This is used to study the density and temperature (a measure of the average energy, or speed, of particles) of the plasma. These measurements give us some idea about the characteristics of the plasma. The workings of the probe are a bit complicated, but basically it is a device that takes advantage of the fact that plasmas can conduct an electric current. It measures the current moving from the spacecraft, to the probe, carried by the plasma in between, or the reverse. Measuring the characteristics of the plasma and how they change during the probe's orbit, can tell us a lot about how the planet's magnetic field and the solar plasma interact. Radio and Plasma Wave Science So RPWS instruments don't give us any pictures that are easy to appreciate, they don't fire laser beams or drill into rocks, and they don't study phenomena that are easily relatable to everyday occurrences on Earth. They do tell us a lot about the solar system, even where it ends. Voyager 1 still has a functional plasma wave system, and it is one of the instruments that tells us it has left the solar system. Much about planetary magnetic fields, radiation belts, ionospheres, and even planetary rotational periods can be learned by studying radio and plasma waves. The most well-known results of radio and plasma wave instruments are audio recordings that have been produced based on their measurements. Some of these are more or less direct conversions of plasma waves to audio, others just convert radio wave frequencies to audio signals (this is not how AM/FM broadcast radio works), sometimes compressing the results so that they are within the audible range of frequencies. There are a lot of these out there, but JPL has a pretty good selection. And now I see that I'm over three pages in Word. So I think I'll stop. I hope this explains a little bit about how this instrument works. Most online sources are either too vague or too complicated to be of any real help. There's more to it of course, and I alluded to some other things in my science reports. I have no special knowledge about this area. I only know what I've learned from making this part and coming up with the science results, so there are probably some inaccuracies here, but I think the general overview is correct.

The solution to the problem in Rhidian's answer is that you have to report lat and long in radians not degrees. So you need something like: public void BiomeCheck() { print(FlightGlobals.currentMainBody.BiomeMap.GetAtt(vessel.latitude * Mathf.Deg2Rad, vessel.longitude * Mathf.Deg2Rad).name); } That will return the correct biome, though you won't get anything for the KSC, just shores (maybe there is some specific area that will return KSC, but I didn't find it).

Update to V0.5 Download on Spaceport See note below or in the .zip file about backward compatibility. New science part added: Surface scanning laser instrument: This part has custom science reports for the surfaces of all planets and moons, with full biome support. New, custom plugin modules are included for each part: This addresses issues with the stock animation and science collection modules. Primarily it prevents parts from playing the retract animation after resetting or transmitting data. It also supports reversible animations and prevents the part from deploying when science cannot be collected (it can still be deployed with the animation-only button/action group). The laser only plays a forward animation, and science is collected during its animation. The other notable change is that the magnetometer and both versions of the telescope have had their part names changed to avoid conflicts with other mods, the RPWS is not effected. This will break compatibility with existing crafts. To get around this I've included an alternate folder with updated versions of the parts with their old names. You can also change the name manually if you want. The instructions included in the .zip have more details. Full changelog: v0.5: - New surface scanning laser instrument. Designed for rovers and landers. - Changes in magnetometer and telescope part names to address compatibility issues with other mods (will not be backward compatible without manually changing the names or installing the alternate part folder). Re-purchasing parts in the R&D center is required. - New model for magnetometer, includes added details to the instruments themselves, cleaner animation, and lower RAM usage due to more efficient use of textures. - All parts are EVA accessible, Kerbals can collect and transfer science reports. - Custom part modules for all parts to address animation and science collection issues: - Magnetometer and RPWS animations are fully reversible while playing, animation speed for these parts is increased as well. - Deployed previews are available in the VAB/SPH for all parts - Attempts to collect science where not possible will trigger a message with suggestions about where to use the instrument; will not play the deploy animation if the part is in the retracted position. - Transmitting or resetting the instrument will not trigger the retract animation. - Repeatedly pushing the collect data button/action group will not spam multiple results. - The laser has only a single, forward animation. Data is collected midway through the animation. - Edited existing science reports, and added several more. Added full set of surface reports for the laser.

Wow, thanks for taking the time to look at this texture. I still find texturing to be the most challenging part of the process. It's almost an entirely empirical approach for me, change one thing, save it, apply it in Blender (or Unity to really get a good idea). It's not like modelling or coding where I have a better idea of what I'm going for and what I need to do, despite very limited experience in both activities. Though I think the new laser texture is better. I actually remade the magnetometer for the new update. The old Blender file was a huge mess, no consistent hierarchy, transforms not applied, bad animations with way too many key frames; I wouldn't be surprised if I had some of the smoothing inconsistently applied too. The new model is pretty much the same as the old, but better organized. I also put the truss textures onto a separate 128x128 file because those are the only thing that need alphas. I can see what you mean about the additional layers for dirt, ambient occlusion, and the specular layers and normal map. They look much better that way. I plan on taking another pass at the textures as well as the models for the RPWS and telescope. Which brings me to my next point. Update to V0.5: SpacePort:http://kerbalspaceprogram.com/dmagicorbital/ MediaFire:http://www./download/84h818y5sq6cc3v/BTDTv1_1.zip Check the first post or the release thread for a full preview of the new version. The primary changes are: - A new surface scanning laser shown in the previews in the last few posts. - Plugins for all parts to address animation and science collection issues. - Breaking backward compatibility for the magnetometer and both telescope versions. The part names needed to be changed for those two parts to avoid issues with other mods. I included an alternate folder with updated versions of all the parts with their original names. You can also manually change the names if you want, instructions are included in the .zip file. That's really irritating, but it's better to change the names than to continue having the same issues. Parts with the new names will need to be repurchased in the R&D center if their tech node is already unlocked. ---------------- There are a few issues with the plugin that I'm aware of. If you don't transmit or reset an experiment the "collect data" action group function won't work. The right-click option will still work fine and will pop-up that "re-log data" window. I know why this happens, but I'm not entirely sure how to get around it. I don't think it's much of an issue, there is no reason to keep reports instead of transmitting them, but it's still a problem. There is also the issue that flying through an atmosphere while on an escape trajectory (aerobraking, generally) still counts as being in space, not flying. This happens in stock KSP too, and I think I know how to fix it, it's just not much of an issue. Let me know if you find any other issues, of which there are probably several that I haven't considered or discovered. ---------------- Full changelog from v0.4.1: - New surface scanning laser instrument. Designed for rovers and landers. - Changes in magnetometer and telescope part names to address compatibility issues with other mods (will not be backward compatible without manually changing the names or installing the alternate part folder). Re-purchasing parts in the R&D center is required. - New model for magnetometer, includes added details to the instruments themselves, cleaner animation, and lower RAM usage due to more efficient use of textures. - All parts are EVA accessible, Kerbals can collect and transfer science reports. - Custom part modules for all parts to address animation and science collection issues: - Added plugin module for telescope, functions similar to the other parts - Fixed the animation states so that the parts stay deployed after saving and loading - Science reports will automatically be collected after the deploy animation finishes (when using the log data button, not the regular deploy button) - Repeatedly pushing the collect data button/action group will not spam multiple results. - The laser has only a single, forward animation. Data is collected midway through the animation. - Deployed previews are available in the VAB/SPH for all parts - Edited existing science reports, and added several more. Added full set of surface reports for the laser.

My plan is to change the part names for the next release. I will also include a separate folder that includes all of the updates and keeps the old names with instructions on what to do. I'll only include that for this release and maybe the next one though, I don't want to keep including two versions of the old parts in every update. I will also put instructions in the readme file that explain as clearly as possible how to alter the cfg files to change the name, and how to deal with the R&D center issues. I spent some time looking at the that plugin. The parameters are all the same as those used by the legacy Unity particle system, so I can figure that out, but I couldn't figure out how to incorporate them into an animation. The animation is also the problem with the KSP Particle Effects, so I'll have to spend some time to figure out how to get it working. It's probably fairly simple to do with a plugin, I just need to sit down and figure it out. My plan is to put some kind of stationary sparking/glowing effect where the three arms of the laser meet, then maybe add some smaller particles that flow around the laser beam mesh. I hope that I can get something that looks ok, but for now I'm just going to release it without the particle effects, either later today or tomorrow.

Unity imports .fbx files at 0.01 scale by default (!!!) When you first load the .fbx into Unity check the Inspector window and look for the model tab. The scale should be at the top, change it to 1 then hit apply down at the bottom.

What do you mean by both places? The only line that must be changed is at the top where it says: PART { name = magBoom module = Part author = DMagic That name =magBoom entry is what causes all of the issues. Later on where you see: title = Magnetometer Boom manufacturer = DMagic Orbital Science ... The title entry doesn't really matter, that's just what the part is called in the VAB. The only other location where the name magBoom appears is in the animation module: MODULE { name = DMMagBoomModule animationName = magBoom experimentID = magScan ... The animationName = magBoom entry should not be changed and shouldn't be affected by duplicate parts (my .cfg examples might look a bit different from the release versions). Right now my plugin does not check for animation name changes, I've fixed that in the new version, but I suspect that changing that entry could cause... issues. Edit: Oh, and by imploding crafts in that other post I don't mean the craft will actually blow up while flying it, I mean the game just won't load them. You'll get that "craft missing part file..." warning when you first load up the save file.

Maybe you could use that as some kind of solar plasma, or dust collection apparatus. Say that it generates magnetic fields to guide particles down to the center for collection (sort of like the magnetic scoop for the Bussard ramjet mod). It might also be used as a sort of advanced atmospheric scoop.

If you're going to be replacing the motherboard I would go with an Intel i3. Either something like the i3 4130 or an i3 3240, whichever one you can get cheaper or maybe in some kind of combo deal with a motherboard. That i5 4440 should be fine for KSP, although the CPU itself is probably quite a bit more expensive than the i3s. For KSP those would perform much better than just about any AMD CPU (and use a whole lot less power). If you have some other needs, especially for highly threaded work loads then maybe the AMD would be a better option, but for KSP AMD CPUs just don't perform well.

Currently all of the experiments are surface or splashed down only. Overriding the stock behavior to get surface experiments while not actually landed would be a little tricky, but it would be nifty. Figuring out if the laser mesh actually intersects the ground probably wouldn't be very hard, but I'm not sure if I would want to have that check. I can imagine it would be extremely annoying to get to a planet's surface only to find out that the part is at the wrong angle and doesn't actually hit the ground, or something like that.

I found a model based work-around for the laser animation. It's a bit of a hackjob, but I think the final result is pretty good. I just made a tiny cube that sits inside of the laser emitter, then scales way up (about 1000X) over one frame of the animation in one dimension to make the laser beam. The animation is effectively instantaneous, so I think it works ok. It could use some tweaking, and I'm hoping to get a particle effect at the origin point for the laser (the KSP Particle Effects from the part tools don't seem to want to animate), but I think it's ready to go. The plugin still needs some work though, as I wasn't expecting this to be finished so quickly.

New Part Update: This thing is finally far along enough to warrant a preview. It's meant to be a rover or lander mounted surface scanning laser, similar to the ChemCam module on Curiosity. Sethnizzle has pretty much got the realistic rover science parts area locked up, so I figured I'd go for something more befitting of Kerbal construction for this one. I've pretty much finished all of the modelling, animating, texturing, and writing for the science reports. The module coding is almost ready to go, it just needs some cleaning up, but everything is working as intended. The only thing remaining is particle effects, which I know next to nothing about. So I'm estimating somewhere between 2 days and 6 weeks before this thing is ready to go. There is also the nagging problem that this thing for some reason refuses to let me put an attachment node on it. Surface attachment works fine, but stack nodes don't appear for some reason. I think it has something to do with the armatures used in Blender for animating the power cables (why that would effect attachment nodes I don't know, but there seem to be many odd effects caused by those armatures, and animating the cables without them would be a nightmare). It's not really a big deal, I think I might leave it with only surface attachment anyway, but it's still annoying. The next update will also contain some tweaks to the other parts and improvements to the plugin. I will also add plugin support to the telescope to get around the weird animation and science collection issues. Stay tuned.

Did you apply all of the transforms in Blender? If something is scaled or moved without the transform being applied it can have very weird effects once you load the model into KSP, even if it looks ok in Unity.

Do you mean just adding one part on top of the other? I think some weirdness about moving attachment nodes makes that really hard to do. But I'm actually remaking the magnetometer to deal with some issues with the model, animation and texture usage, and to add more detail. I'll see about making an alternate version with an antenna at the end of the boom, similar to the one use by the Galileo probe, I'll try to put both experiments on it, but you could also add the RT2 module.

I uploaded the part and added a link over in my parts thread: http://forum.kerbalspaceprogram.com/threads/64755-WIP-DMagic-Orbital-Science-New-Science-Parts-V0-4-1-%281-19-2014%29 I included a plugin that controls all of the animations. The scanner function works without the plugin, but none of the animations will. The code is a bit messy, but right now the main deploy animation will open the part and start the dish spinning. The lights can also be triggered manually, but don't do anything otherwise. There are some issues with triggering the light animations before or during the main deploy animation, so wait until the part is fully open and the dish is spinning before you try to play with those. I included the .cs file in the zip. It's all pretty well annotated, so it should be easy enough to follow. The part has a different name in the .cfg file, so it won't interfere with the old BTDT part, but it also won't be backward compatible with existing crafts. Let me know if this is working right for everybody else, or if there are any issues.

I added a link for my partially functional SCANsat BTDT scanner to the first post. It works fine with SCANsat, but the animations are not tied to the SCANsat module; they must be triggered manually. The light animations can also be triggered manually, but don't do anything otherwise. The plugin is required for any animation function to work. It will work as a scanner without it, but won't open. The part is not backward compatible with existing crafts, and I make no promises about future backward compatibility either. MediaFire link: http://www./download/84h818y5sq6cc3v/BTDTv1_1.zip SCANsat thread posts: http://forum.kerbalspaceprogram.com/threads/55832-PLUGIN-PARTS-0-23-SCANsat-terrain-mapping?p=928786&viewfull=1#post928786 http://forum.kerbalspaceprogram.com/threads/55832-PLUGIN-PARTS-0-23-SCANsat-terrain-mapping?p=930623&viewfull=1#post930623

It's not about making the science system harder, or less user-friendly, it's about making the system deeper, or at the very least making the tools more flexible. The current science system and the tools available for modders don't allow for much customization or added depth. There are ways around this, but it requires a lot of work. I think this is why we're only now starting to see some different takes on the science system, rather than just alternate ways to collect default science reports (like adding crew reports to probe cores). While it can be helpful to discuss what should be done about it, I think the best option is to try out different ideas using mods to figure out what works and what doesn't. Maybe some good ideas will be discovered and picked up for a future update, or maybe not, but I think it's worth trying out some different methods for the science system.

I'm thinking about that. I can release it as is, with the single, deploy animation using the SCANsat module. The other animations won't work, but it's still an improvement on the default model. I could also release my own plugin, with all of the animations manually triggered, I don't really want to do that though, as that's not a good solution. Either way I need to make a proper .cfg file and check everything again to make sure all is as it should be.

Thanks for running all of those tests Blaster. That's a surprisingly big boost in performance from turning all of the graphics settings down. The HD 7770 is fairly powerful, but I guess it's not always enough for KSP. I don't have many recommendations about settings, there isn't much to change. There are a few things in particular that are know to affect performance though: The terrain lag issue is a pretty common one that affects all planets with an ocean, there are some ways to work around that, which reduces most of the impact. Lowering the texture and rendering settings can also help sometimes. Some people have issues with anti-aliasing on AMD cards, that's something to keep in mind. Mods and memory usage is another matter, one not really related to performance. Too many mods and you'll run out of memory and the game will crash. There are some methods in the links below about addressing that. There are also a few mods that affect performance more directly. Mechjeb's delta-v window in particular can really drag down your performance if it's open. There are probably others, too. Ubizor's part welder mod is another option if you're specifically looking for part-count related performance fixes. There are a few threads more specifically related to performance and settings: http://forum.kerbalspaceprogram.com/threads/60230-I-would-like-to-ask-you-to-configure-your-computer-for-advanced-players http://forum.kerbalspaceprogram.com/threads/61798-Optimization The best way to increase KSP's performance though, is a better CPU. A recent generation i3 or i5 from Intel is probably your best bet depending on how much you want to spend. Of course you have to be able to upgrade your computer for that to be a possibility though. The best advice I can give is less hardware related and more gameplay oriented; use fewer parts and practice more efficient design (which is, admittedly, not always helpful advice, but fewer parts will pretty much always lead to better performance).

I'm not sure if anyone is working on this, but I realized the other day that the BTDT scanner still uses that original, generic mesh. So I whipped up something to fill in. I had a few things in mind when I made this. It needs to be small, much smaller than the other scanners, because it is meant to be used on rovers and planes and such. So I made it a 0.4m square, it fits comfortably on top of a probe core, or on the side of the rover body. I borrowed heavily from the look of the multispectral scanner (in an abstract way, not in a copying-elements-of-Milkshakefiend's-texture way) for the texture. The model is somewhat similar too, but that's not intentional. The radar dish is similar to some missile detection systems and naval firing control systems, although much smaller, so it seems at least somewhat plausible as a close range anomaly detector. There are a few problems with my current design though. The complex animations (there are four of them) require a separate plugin to work correctly, and don't work well with damny's plugin. The scanner function works, but it ignores the animations or whether or not the dish is deployed or not. My thinking is to make the orange light and text flash while no anomalies are nearby, then switch to the green light when an anomaly is detected. I don't know how to do this, or if it's easily possible. It will require input from damny's plugin; obviously there is some event triggered when an anomaly comes into range, I just don't think I can integrate my plugin with that though. In the .gif above I'm just manually triggering all of the animations. One for the dish and light deployment, one for the dish spinning, one for the orange light, and one for the green light. Obviously that's not a good solution. I can integrate the deploy animation easily enough with the regular SCANsat module, but if I want anything else to happen I need my own plugin. And if there is already some plan or part in the works for this model I can retract my submission and adapt it for use in my own part set, so that's no big deal.

That's odd, your second run is a little slower than the first. It begins about the same, but then starts to lag behind about half way through. A 20% OC like that should give you a pretty good boost. Something weird must have happened there.

I have been mulling over some of the exact issues you discussed. I even started making up science reports for low orbit, Kerbin biomes for my magnetometer, but I realized that I don't want so many reports to be possible, I just want two or three while the others give some default result and only return science value once (limiting the actual result to a default report is simple, but they still give science value for every different biome). I've been trying to come up with ways to limit science experiments by biome with a plugin, but that's not very simple. I think Rhidian's Science Redefined mod is a good start for all of this, and I hope some of his ideas get picked up or adapted at some point.

Argh. That was stupid, I've downloaded and used that part for comparison several times. I guess I never loaded it at the same time as my magnetometer. If you actually have both parts in your GameData folder they won't work together, even in sandbox mode. The second magnetometer will still show up in the VAB, but it will be replaced by whichever part was loaded first when you actually try to launch. And in career mode the entry in the tech node field remains even if you delete the part from your GameData folder, causing the issue that people have been having above. So that's obviously a problem. I guess I'll have to change the name for that, and probably the telescope while I'm at it. The RPWS should be fine, that's not something I expect to see a lot of, and name = rpwsAnt doesn't seem like it would be used again anyway. At best people will have to research the part again in the R&D center, at worst their crafts will implode because they're missing the part. I think I'll provide a folder with alternate .cfg files using the old names for the next release, but after that it's probably best to only use the new names. Thanks for pointing that out, and thanks for trying out these parts everyone.