DMagic

I updated to version 0.2. I think all of the basic functions are working correctly now. Transmitting data from the transmitter's button, lab processing/cleaning, and EVA data collection were causing the major issues and they all seem to work now. The only problem that I can find is that the Inoperable experiment warning will not show during EVA data collection using my module. Normally if you try to collect data from an experiment that can't be reused, like the goo pod, the warning dialogue will pop up, but that doesn't happen here for some reason, I don't think it's really a big deal though. I also added resource usage in a limited fashion. I added .cfg file fields for what resource to use (though I've only tested ElectricCharge) and how much to use (in units per second). Right now it only works when you set a waitForAnimationTime value. When you start the experiment it will begin using resources, wait for the amount of time you set, then give the result (even if you have experimentWaitForAnimation set to false). If you run out of power it will stop the experiment and give you a message about being out of power. It also displays the resource usage in the part's VAB extra info tab. Otherwise it is about the same. The code is much cleaner and hopefully easier to follow. There is a lot of support built in for collecting multiple reports with the same part, but none of it is explicit, I need to add something to tell the module that the part can collect multiple reports (either to store more than one, or to collect more than one before becoming inoperable), but most of the code is written with this in mind. Let me know if anyone is interested in using this or has more suggestions. The download link in the first post has been updated.

I updated this. It now directly copies the existing persistent.sfs file into a backup file instead of using the SaveGame method. This seems to accomplish the same thing, but now it works with plugins that bypass the main menu.

Good idea. It only took about two weeks, but I switched out one line and used File to create or overwrite a backup file with a copy of the existing persistent.sfs file. It seems to work fine with autoload plugins, everything else is the same. I updated the links on the first post.

It looks like there is a bug (or maybe just a missing condition) in the last few lines of the genericLoopAnimation module. Where it says: if(loop.normalizedTime<=0 && loop.speed == -1) { loop.speed = 0; loop.enabled = false; deploy.enabled = true; deploy.normalizedTime = 1; deploy.speed = -1; } Should it instead say: if(loop.normalizedTime>=1 && loop.speed == -1) { loop.speed = 0; loop.enabled = false; deploy.enabled = true; deploy.normalizedTime = 1; deploy.speed = -1; } The loop.normalized time will be greater than 1 after it finishes one rotation. So after pushing deactivate it will wait until the loop finishes at least one complete rotation, stop the loop, then play the reverse animation. The only problem is that I think the loop animation will just stop in place, you might need something to make sure it finishes the next loop before playing the reverse deploy animation. Edit: I think I might see why it was set to time<=0. But looped animations, unfortunately, don't reset their normalized time after each loop, it just keeps going up. Maybe you want: if(loop.normalizedTime % 1 == 1 && loop.speed == -1) That would put the normalized time back to a value between 0 and 1 regardless of how many times it has looped. Edit the second: Ok, I think eventually I will edit my way to an understanding of how this works. If the intended behavior is for the deactivate button to turn the loop around, play back to its starting state, then play the reverse deploy animation then just switching to loop.normalizedTime % 1 <= 0 should work. But in my opinion it's smoother to let the loop finish out one last rotation in the forward direction, then stop it and play the reverse deploy animation. Maybe using the deactivate button the set loop.enabled to false, instead of changing the speed, and check that in the update method would work, or something along those lines.

Thanks. I also noticed that these parts vary in size quite a bit. I was sticking all six parts onto a command pod to test something when I realized just how much bigger some of the rover parts are; it's not as obvious when they aren't right next to each other. I'll see about resizing some of them a bit so that they are a little more similar. I'm also not too crazy about the animation detection function I'm using. It works well enough in what I consider standard situations, stuck on top of a rover body or on the side of a fuel tank, but when you start attaching it to structural components it's not so easy to setup right. I want to get something that is relative to the surface, not to the part's position on the vessel. I'm not sure about making the part break when you move, but I am also planning on adding some form of ground detection to the laser and drill when they are deployed.

Yes, PhysX can be run on the GPU in certain situations, but that doesn't mean it has to. The real benefit is the improvements that have been made to CPU based physics over the old versions.

There's a big difference between PhysX 3 and the horrendously old, custom version of PhysX 2 they've been using before. Who knows if it will make a difference for KSP or if it will require a major overhaul, but it's still a promising feature.

Adding reports is no problem, they don't have biomes and only two (?) have atmospheres, so there's not too much to add. The bigger issue is whether they have their ScienceParams values set. These are the things like the multiplier, the "in space near/high" threshold, etc... I'm guessing that these are things that have to be added manually. If no one knows for sure I can fly out there and check with a function to print out those values in the debug window. It might not be too difficult to whip up a plugin that sets these values, I'll have to see. Yeah, these parts don't do much to help balance the system. I'm not too worried about it now because there's little incentive not to just bold on a dozen of each experiment and max out the tech tree in a few flights. Once we get some more depth in career mode I'll start thinking about balance more. Edit: I checked a handful of the planetfactory planets and they all seem to have their science values in order, some of them even have biomes. Coming up with new reports for all five applicable parts should be no problem.

Those are just previews, and they aren't complete either, both need at least a few changes. The only thing changed from 0.7 to 0.7.1 was the SCANsat versions of the parts. The next update won't be until the NASA pack / 23.1 / 24 / whatever they decide to give us next.

So many possibilities. I had the same thought about forcing RCS mode (now I just need to get my hands on a Kerbal model in that mode). Not only does it allow you to use the jetpacks handles, but it fixes the Kerbal, reducing the range of movement possible which should make designing something that stays in place easier. I like the idea about resource usage too, I've been thinking of that for some of my other parts too. The laser especially should have a burst of electricity required for use. That's something that I'm trying to build into my new science module. It does look a bit like the anomaly scanner, at least from the front. But of course, once you deploy it there's not much possibility of confusing the two. I suppose the exterior texture, the non-door part at least, of the previous version is ok. Like all of my second draft textures it's a bit flat, but not too bad. I really don't like the interior section though, it's clunky and I don't think it meshes well with the rest of the model, or any of the other parts for that matter. The door mechanism isn't so great either, and I think it interferes with the probe that comes out of the side (that was added long after the rest of the model was complete). There are also some issues with different components of the part not aligning correctly during the animation, though that's not so easily noticeable in-game. Overall I think the RPWS was the part that clashed the most with my other parts, so I decided to remake it from scratch.

I tried this out a little bit today. I didn't run into any bugs or obvious problems, but I do have a few suggestions/questions. Would some kind of visual indicator for the science spot bearing be a good idea? I'm thinking of something very simple, like a circle, with a line pointing up indicating your current heading and a movable line indicating the bearing to target. It could use something like 12 positions, like a clock, or maybe 8, like the North, Northeast, etc... cardinal directions. I don't know anything about making GUIs, but this might be more helpful than the "turn left/right" indicators. Do you plan on having any kind of specific experiments that you can do at science spots? Maybe different types of experiment at different spots, or have multiple experiments that give a percentage of the total science value for each spot. I like it so far, I'll be interested to try out the initial release. Edit: I see that a compass indicator is already in your plans. I think that could definitely help with navigation.

That's an interesting idea. There was a WIP thread about making new rover bodies, but I haven't seen anything about that in quite a while. I made sure that my parts could fit on a RoveMate, but they usually have to put sideways or in some other slightly awkward way, that's why most of my examples use that bigger rover. But it might be interesting to come up with something in between. I'll need to look into how exactly the asteroid science works, from the Q&A it sounds like they'll be another experimental situation that can be done around any planet. But the existing laser and drill are probably a bit big to actually be used on EVA. I'll try to fix the laser animation so that it works better on small landers, like the drill does, before the next update though. That should at least make the laser work better for asteroid science. Awesome, it does make sense that these parts could be moved around by EVA Kerbals. I've replaced the telescope texture and made some improvements to the existing model. Mostly I improved the way the shroud blends in with the main body of the telescope and reduced the number of leaves in the shutter; all of this helped drop the triangle count by about 25%. I also made it smaller and lighter as shown in the pictures below, this could still use some tweaking though. I also found an interesting Kerbal model that should be useful as a reference for my EVA scanner.

Awesome, thanks for adding my parts. I'll link to this thread for anyone looking for KAS integration.

That's a good idea, it shouldn't be difficult to do. I think I can manage with just one or two more fields in the .cfg file (resourceForScience = "", or something like that, and a cost associated with it). I'll see what I can come up with.

I did some checking. It seems the sun has some slightly wonky values for the atmosphere. As far as I can tell it doesn't have an atmosphere in the same way that other planets do (at least not at the altitudes I checked). It seems that CelestialBody.atmosphere returns false for the sun, while CelestialBody.maxAtmosphereAltitude returns 700,000 km, and CelestialBody.scienceValues.spaceAltitudeThreshold (the altitude where it switches between "in space low" and "in space high") is at 1,000,000 km. What all this means is that only the area between 700,000 km and 1,000,000 km counts as "in space near", while below that counts as being in the atmosphere, despite the fact that there is no atmosphere. There are a few things to note here. The stock science module will always return "in space low/high" unless you are on a sub-orbital trajectory, even if you are deep in the atmosphere (of Kerbin for example), if your orbital projection doesn't intersect the surface you won't be able to do atmospheric experiments, the same goes for aerobraking or any other situation where your orbit is escaping the planet's SOI. I don't like this; my new science module fixes this so that any time you're in the atmosphere you can do atmospheric experiments. But because of the weird way the sun behaves it will always return in space low when you are below 1,000,000 km (ie the problem you noted won't be an issue anymore). For now though, the way the RPWS is setup will cause it to not work below 700,000 km above the sun, though it should give the "in space near" results when you are between 700,000 and 1,000,000 km. The magnetometer doesn't seem to have this problem, and the telescope shouldn't either, though I didn't actually check that one. Thanks for bringing that up though, I had never checked those values for the sun and it's interesting to figure out the weird way that it's setup. That's already been taken care of in the 0.7.1 update. The alternate versions of the anomaly scanner and the telescope have both the SCANsat modules and my modules attached to them. Edit: And speaking of the RPWS, here's a quick preview of the new model and texture. It could still use some tweaking, but I think it looks a lot better. I also fixed some bugs with the part and have it working with my new plugin.

I'll have to check on that, it shouldn't be any different in the latest version. The sun might have some differences in where the atmosphere begins and what is considered "near" space. I'm working on a replacement science module for most of my parts, hopefully I can address this issue too. If anyone wants to check it out you can head over to this thread. It's a generic science module that I can use with most of my parts and that can be configured entirely through the part.cfg file. Anyone who wants to is free to use the plugin for their own science mods; it has much more versatile control over how animations work with science experiments. It still has some issues and I'll update it as I go, but it's mostly working and behaves similar to the stock module.

I've been working on a new science module to use for most of my parts, rather than using several modules that are all basically the same. I've come up with something that can be used for science experiments and has much more versatile animation controls than the default ModuleScienceExperiment and ModuleAnimateGeneric modules. --------------------------- Download from GitHub (For KSP 1.8) Version 0.22 Updated for KSP 1.8 Version 0.21 Allow for specified meshes to be activated when a sample is collected or transmitted Allow for an animation to play when a sample is collected or transmitted Allow for a max science value less than the max value specified in the experiment definition (see DMOS reconnaissance parts for reference) Version 0.20 Updated for KSP 1.4 Version 0.19 Add options for using physical mesh transforms to represent samples, which will disappear when data is transmitted or collected Allow for blocking experiment reset by an EVA scientist Version 0.18 Fix a bug allowing scientists to reset experiments on EVA Version 0.17: Updated for KSP 1.3; experiment reset works based on ScienceResetSkill not Kerbal trait Version 0.16: Updated for KSP 1.2.1; adds stock science transfer function; fix compatibility with Science Relay Version 0.15: Updated for KSP 1.2 Version 0.14: Updated for KSP 1.1.2; added new API for external compatibility Version 0.13: Fix science labs and scientist EVA lab resets Version 0.12: Updated for KSP 1.1 Version 0.11: The latest version fixes bugs related to EVA Kerbal detection and EVA data collection and experiment reset. Version 0.9: The latest version is updated for KSP 1.0.5. It adds options to exclude planets with an atmosphere, and the option to require one or more specific parts or part modules on the current vessel. To add a part or part module requirement fill in the requiredParts or requiredModules field (only one can be used, the part requirement takes precedence over the module requirement). You can add multiple requirements by separating each name with a comma, do not add any spaces. All specified parts or modules must be present for the experiment to work, there is currently no method for adding or-type options. For the part field use the actual part name from the config file (the name = myPart field), not the part title. For the part module use the class name (from the MODULE = MyPartModule field in the part config). Version 0.8: The latest version is updated for KSP 1.0.4, and fixes a few problems when parts have errors in their animations. -------------------------- Version 0.7: The primary additions with the latest update are the ability to setup multiple-use experiments. These allow a variable amount of samples/data to be collected by a single part, unlike all stock parts that only allow for one sample to be collected. Set "experimentsLimit" to a value greater than 1 to use this feature. There is also a new field to allow for EVA experiment collection. Set "externalDeploy = true" to use this. A second animation can be used with multiple-use experiments; this allows for a "sample-fill" type of animation where a separate animation plays after you decide to keep or transmit data. The amount of boost in transmission value generated by the science lab can now be altered. To change from the default value (50% of transmission rate) set the "labDataBoost" to something other than 0. --------------------------- Everything is configurable through the part.cfg file. Most of the available fields are the same as those found in the two stock modules. There are a handful of additional fields that control the animation behavior along with a few other things. Included in the package I'm releasing is a reference.cfg file; it is setup with fields for my magnetometer, but shows every available field (or almost every field), their default values, and explains what they are used for. There are a couple that I'm not sure about, and some of them seem to do nothing at all, but most of them are fairly simple. It is unlikely that you'll actually need to include every field in your part.cfg file, most can be left at their default values. The source is available on GitHub, along with a copy of the reference.cfg file. The module inherits from ModuleScienceExperiment, so most of the behavior is the same. The major change is that I am bypassing the base.DeployExperiment() method. Instead I create the science data myself so that I can control the experiment results page and what happens when you push the buttons. This causes a few headaches, but everything is mostly working ok. It does however, let me fix a few of the stock modules bugs; collecting an atmospheric sample while aerobraking for instance, or that annoying way the parts won't complete their animations (they stop on the 2nd to last frame). If anyone wants to try this out and see how it works for them that would be great. Or if anyone has any of their own science parts that don't work well with the stock modules, you can feel free to use this in your mod (though I wouldn't recommend doing anything beyond testing it for now), just include the .dll file and it should work fine. Currently it is only setup to play one animation at a time. I plan on seeing about allowing for multiple or looping animations in the future. It does support one way animations, those that start and end at the same place and don't require reverse animations. Here is the reference.cfg file showing all of the fields. As you can see there are a lot, but again, most shouldn't be necessary to change (it's easier to read this file if you open it in notepad with wordwrap turned off). /* * Version 0.21 * For Reference Only - Do Not Simply Copy All Fields Into Your part.cfg * Most Fields Are Unnecessary - All Fields Have Default Values */ MODULE { name = DMModuleScienceAnimateGeneric //Name of the module - don't change this -------------------------- //Animation Fields**** Similar to ModuleAnimateGeneric (default values shown) animationName = *"your animation name" //Name of your animation - get the name from Unity scene sampleAnim = *"your sample fill animation name" //Name of the animation to be played when a sample is stored in a multiple-use experiment, experimentsLimit must be greater than 1 to function correctly animSpeed = 1 //Speed to play animation endEventGUIName = Retract //Title of retract animation event/action group showEndEvent = true //Do you want to show the retract event/action group - only displayed in-flight after deploy event triggered startEventGUIName = Deploy //Title of deploy animation event/action group showStartEvent = true //Do you want to show the deploy event/action group toggleEventGUIName = Toggle //Title of toggle animation event/action group - Plays deploy or retract animation based on current state - Is reversible while playing showToggleEvent = false //Do you want to show the toggle event/action group - not recommended to be used together with deploy/retract events, too many unnecessary buttons showEditorEvents = true //Do you want to be able to preview the animation in the VAB/SPH useSampleTransforms = false //Do you have mesh transforms that represent physical samples which should be removed when an experiment is collected or transmited sampleTransformName = "transformName" //The name of the mesh transform representing the sample //If collection of more than one sample is allowed then the number of transforms must equal the number of samples //And the transforms must use the same name prefix followed by a .00x number; sampleTransform.000, sampleTransform.001, etc... //Only the tranform prefix should be entered in this field, sampleTransform for this example useReplacementTransforms = false //Do you want to have a mesh that is activated only when a sample is collected or transmitted from the part? replacementTransformScale = 1 //The scale of the replacement mesh replacementTransformName = "transformName" //The name of the replacement mesh transform - the same rules specified for "sampleTransformName" apply when multiple samples can be collected dataRemovalAnimation = false //Do you want to play an animation when a sample is collected or transmitted? dataRemovalAnimationReverse = false //Do you want the animation to play in reverse when the experiment is reset? dataRemovalAnimationName = "Data removal animation name"//The name of the data removal animation waitForDataRemoval = false //Do you want to wait for the animation to complete before sample transforms are disabled or enabled. *****\\ -------------------------- //Science Experiment Fields**** The same as ModuleScienceExperiment (default values shown) collectActionName = Collect Data //Name of the EVA data collection event collectWarningText = *empty string //Warning text to display when retrieving data from the part during EVA - Only applicable with non-rerunnable parts dataIsCollectable = true //Allow EVA Kerbals to collect science reports from the part experimentActionName = Collect Data //Name for action group and right-click data collection function experimentID = *"your experiment id" //Experiment name - from the "id = " field in your ScienceDefs.cfg for this experiment hideUIwhenUnavailable = false //Hide the right-click data collection buttons when experiment cannot be used interactionRange = 1.2 //Range for EVA interaction in meters rerunnable = true //Can the part be used more than once resettable = true //Does nothing??? resettableOnEVA = true //Allow EVA Kerbals to reset the part - removes any existing science reports resourceResetCost = 1 //Multiplier for the resource cost to reset the experiment with a science lab resourceToReset = ElectricCharge //Can't change???? resetActionName = Reset Experiment //Name for action group and right-click reset function reviewActionName = Review Data //Name for action group and right-click review data function transmitWarningText = *empty string //Warning text when transmitting data - only applicable for non-rerunnable parts - do not add anything here unless you want the warning to show useActionGroups = True //Are the VAB/SPH action groups available - does not affect the availability of right-click functions useStaging = False //Control experiment activation through staging (may not actually work) xmitDataScalar = 0.5 //Transmission data value, determines the percentage of the baseValue (from your ScienceDefs.cfg) recovered from a transmission usageReqMaskExternal = -1 //Bit Mask to define external usage conditions; 8 specifies that the EVA kerbal must be a scientist to deploy the experiment; 4 will allow any Kerbal to deploy from EVA; -1 means nothing can use the experiment externally *****\\ -------------------------- //Science Experiment - Animation Fields**** (fields are from my magnetometer setup) customFailMessage = The magnetometer is not suitable for use during atmospheric flight, try again on the ground or in space. //Default = Can't conduct experiment here //Message to be displayed when you attempt an experiment in an unsuitable situation - from the situationMask in your ScienceDefs.cfg file deployingMessage = Close proximity to the craft scrambles the magnetometer's sensors, deploying the scanner now. //Default = empty string //Message to be displayed when you try to conduct experiment with the part undeployed experimentAnimation = true //Default = true //Do you want your experiment to be dependent on the animation playing/already being deployed experimentWaitForAnimation = true //Default = false //Do you want to wait for the animation to complete before you begin the experiment (or any other arbitrary amount of time) keepDeployedMode = 2 //Default = 0 //Determines when to play the retract animation //Value of 0 is the stock behavior (mostly) - Parts retract when the experiment is reset or the data is transmitted //Value of 1 - Retracts the part immediately after conducting the experiment - i.e. when the experiment results page appears - *probably better to set up a one way animation //Value of 2 - Part will not retract - only manual controls can retract the part waitForAnimationTime = -1 //Default = -1 (value set to the length of the animation) //Amount of time to wait after deploying the animation before the experiment begins - 0 will begin immediately, -1 waits for the animation to complete (this does take into account animSpeed specified above) oneWayAnimation = false //Default = false //Do you want the animation to only play in one direction - The animation should begin and end in the same position resourceExperiment = *empty string //Default = ElectricCharge //Do you want to use resources while collecting data, and what type do you want to use //This only functions while waitForAnimationTime and resourceExpCost both != 0, experimentWaitForAnimation can be set to false //Experiment will fail if you run out of the resource resourceExpCost = 0 //Default = 0 //The cost, in units per second, of resources used while collecting data asteroidReports = true //Default = false //Do you want to be able to collect results while landed on and/or near an asteroid //Asteroid reports in the ScienceDefs.cfg file follow the format: "AsteroidSrfLandedClassA" or "AsteroidInSpaceLowClassA" for each asteroid class, A-E //Only SrfLanded and InSpaceLow experimental situations are allowed planetaryMask = 524287 //Default = 524287 //Bitmask defining which planets the experiment can be performed on/around, works everywhere by default planetFailMessage = Can't conduct experiment here //Default = Can't conduct experiment here //Message to be displayed if the experiment can't be performed on the current planet/moon storageFullMessage = No more samples can be collected //Message to play when you can't collect any more data experimentsLimit = 1 //Default = 1 //Sets the limit for how many experiments can be collected and stored by an individual part labDataBoost = 0 //Default = 0 //Set the gain for transmission after lab processing; the default value, 0, will set the boost to 50% of the regular transmission value externalDeploy = true //Default = false //Allow the experiment to be triggered by an EVA Kerbal; still requires power if applicable resetLevel = 0 //Default = 0 //Level of scientist required to reset a used experiment on EVA excludeAtmosphere = false //Default = false //Specify experiments that can only run on planets/moons without an atmosphere excludeAtmosphereMessage = This experiment can't be conducted within an atmosphere //Message to be displayed when an experiment fails because an atmosphere is present requiredParts = *empty string //Default = none //A list of part names that are required to be on the vessel for the experiment to work - separate part names by a , - all specified parts must be on the current vessel - use the actual part name (the name = myPart field in the part config), not the in-game title requiredModules = *empty string //Default = none //A list of part modules that are required to be used by parts on the vessel for the experiment to work - separate modules by a , - all specified modules must be used by parts on the vessel requiredPartsMessage = *empty string //Default = empty string //A message to indicate which parts are required requiredModulesMessage = *empty string //Default = empty string //A message to indicate which part modules are required allowEVACleanUp = true //Default = true //Allow for an EVA scientist to reset a used experiment totalScienceLevel = 1 //Set to less than 1 to allow for experiments that collect less than 100% of an experiments max value; allows for multiple parts to conduct the same experiment with differing levels of max science available *****\\ } ChangeLog: Let me know if anyone has any questions or suggestions. License for software: BSD License

That's a good point. Even if I did make any parts to replace stock experiments I would never name them the same, they would always work alongside stock parts. Once upon a time they actually did have the same names, hence the warnings. I've since tried to get rid of all those, but there might still be a few instructions hanging around about not using both parts. I'm going to leave them with different names though. I want them to remain separate. There are also some issues with the R&D center tech-nodes when you have multiple parts with the same name (that's why I had to change some of my part names). If you end up researching multiple parts with the same name, even if you delete the first version of the part, you can run into problems that will prevent you from being able to actually use the part. If anyone's worried about persistent file loss though, you should check out my backup generator, it's in the bottom of my signature. I have quite a few ideas for more parts, both realistic, and Kerbalized ones, but for now I'm going to wait at least until 0.24 to see what kind of changes it brings and what I can do with my existing parts. But the more I think about it, the more I want to make an EVA anomaly scanner, that will probably be my first project after 0.24. Thanks, hopefully it will keep getting better.

Thanks. I actually haven't really considered that, but thinking about it, I could replace some of the basic science parts, gravity sensor, accelerometer, etc... Those could use some work. I updated to version 0.7.1. The default parts are all unchanged. But I added my module to the SCANsat version of the telescope. You should now be able to use it as a multispectral scanner at the same time as collecting my science reports. The SCANsat module doesn't control any of the animations, so there are some superfluous action groups and right-click buttons, but otherwise it seems to working fine. I did the same with anomaly sensor, so now it can be used as a BTDT scanner alongside my module. You can download the SCANsat parts only at this MediaFire link, or download the full upload from the first page or on Spaceport. The SCANsat parts have different names so they will have to purchased separately at the R&D center and won't affect existing crafts. I think I see what you're getting at. How about this idea? I could make a separate, smaller, anomaly scanner that can only be used by an EVA Kerbal. Preferably it could be something with KAS support, so they could pick it up, walk over to an anomaly and scan it. This could either be a kind of companion part to the regular anomaly scanner, or it could come with its own set of reports (and I would probably have to reduce the science value for both parts). I'm also thinking that I could change it so the anomaly scanner gets boosted to full, or nearly full transmission value at the science lab. I had always though that the 50% boost in transmission value was fixed by the science lab (and I'm still pretty sure that it is), but it should be relatively simple to bypass whatever the science lab is doing to the data and change the transmission value myself. That way I could set it at something like 90 or 95% and then the part could still be reset by the lab. I wouldn't add EVA collection, but I think this would be a good compromise. Also, let me know if anyone runs into any problems with data transmission. When I recompiled the plugin earlier today KSP started spitting out some error I've never seen before in the debug window when I tried to transmit. I'm 90% sure that this is a .NET thing and I just have to be sure to point Visual Studio at .NET 3.5, but if anyone else has problems with transmission let me know (the released plugin shouldn't have this issue). And if you are going to recompile my code for whatever reason, make sure you point it at .NET 3.5, not 4.x.

I'm not going to add the SCANsat module to the new part, though you should be able to do so yourself. It won't interact with the part's animation, but should still function the same way. You'll have a lot of indicators about where the anomaly is that way. The BTDT detects them at 50km away; mine has a maximum range of 30km, which decreases with altitude up to about 15km above the anomaly. I would recommend assigning "collect data" to an action group so you can easily get the distance and direction message (there is some error built into the distance estimate that increases with range). I figured science is already easy enough as is, so I wanted to make this part work a little differently. And my in-game rationale is that you have to study the effects of each anomaly's radiation and what-not on the instrument itself. It's not like my other parts where you're just transferring data, or taking the sample incubator. Here I want it to be the part itself that needs to be returned and studied. I have been thinking about removing the requirement to make repeated observations though; making the base value equal to the science cap. That might be a better solution than putting a bunch of scanners on the same vessel, or making repeat trips out to every location. The other thing I'm thinking about working on is the scanning distance. I didn't test every anomaly on every terrain setting. So there could be some that are buried so far underground that you can't get within range. I could increase the range, or switch from using the straight-line distance to the anomaly to using the horizontal distance (and maybe capping the max vertical height above the anomaly to something like 500m). Sounds like it's time for a repeat. Actually, I should get out to Bop. I haven't been there for any testing and the last time I was there was just briefly to land an ion-engine vessel. Otherwise I haven't been out since 0.19, I think.

Update to V0.7 Download on Spaceport New science part added: Anomalous Signal Scanner This scanner is designed to locate and study anomalies from the surface or while flying low above them. It has a maximum detection range of 30km, which falls off with height above the anomaly. Indications are given for distance and direction to the anomaly (exact values are printed in the debug window). Within about 10km a separate camera module deploys, this will rotate about its z-axis to look at the anomaly (this works best mounted parallel to the surface of the planet, on a rover or plane), and an indicator light turns on when the anomaly is within scanning range. For full science value make repeated observations of the anomaly and return the scanner to Kerbin for detailed analysis. Reports cannot be transferred out of the scanner, it must be returned to Kerbin to study the anomalies' effects on it. Results can however be transmitted for 50% value, or 75% with lab analysis. The scanner can be reset at an operational science lab after transmission. I made new science reports for all anomalies (only the real ones, with PQSCity transforms). I haven't tested every anomaly, but you should be able to get within scanning range for all of them, even if they are underground. There are new textures for the magnetometer and laser, both now resemble the drill and anomaly scanner a little more closely. The RPWS and telescope will have to wait for another update to get new textures and new models. I also made several bug fixes to existing parts. The magnetometer data can now be collected on EVA, and the non-functional right-click button has been removed. The laser description was fixed and the part was moved back to its proper tech node. This will require a repurchase in the R&D center (and may make the part unavailable if you haven't progressed far enough), but won't affect any existing crafts. I'll also be releasing, hopefully in a day or so, a prototype of my new ModuleScienceAnimate plugin. It's meant to replace most of my current modules and act as a generic science module with better animation controls (replacing the stock ModuleScienceExperiment and ModuleAnimateGeneric modules). Everything will be configurable through the part.cfg file only, so anyone will be able to use it. I'll add a link here when I release that (source is available on my GitHub repository now). Check the first post of this thread for a full preview gallery of the update. Change Log: v0.7: - New anomalous signal scanner. Designed for rovers and spaceplanes. - Used to detect and study anomalies. - Single use only; return to Kerbin for complete study of the science report, or transmit and reset with science lab. - New textures for the magnetometer and laser; they fit in better with the recent parts. - Fixed .cfg file and plugin bugs for the laser and magnetometer - Laser returned to its proper tech node - will require repurchase, but should not affect existing vessels. - A few minor changes in other part.cfg files; dropped the mass of the telescope. - New science reports for the anomaly scanner, fixed many typos in old reports. v0.6: - New biological activity core drill. Designed for rovers and landers. - Features multiple storage containers. - Can be used up to six times before needing to be returned to Kerbin or reset with a science lab. - Two different animation modes, used for rovers or landers. Animation dependent on the drill's orientation relative to its parent part - preview animation in the VAB/SPH - use cubic octagonal struts or other small parts to modify animation behavior. - New science reports for core drill. - Included support for Trueborn's Custom Biomes plugin. * Requires separate download - Reports for custom biomes for the laser, optical telescope and core drill. - Reduced values for some science experiments. 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. - 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. v0.4: - New textures for all parts. - Changed non-SCANsat telescope to be the default, for the SCANsat version replace the default scope folder with the alternate folder. - Tweaks to models and animations for the magnetometer and telescope. - Add Langmuir probe to RPWS model (should not break existing crafts). - Added surface reports for the magnetometer, including biome support where available. - Added biome support for non-SCANsat telescope in low orbit. - Rearranged tech tree placement; parts moved to earlier nodes. - Decreased science report values, added and edited science reports. - Added FxModule to part.cfg to force deployment before science reports can be collected. v0.3: Initial upload.

Update to V0.7 Download on Spaceport New science part added: Anomalous Signal Scanner This scanner is designed to locate and study anomalies from the surface or while flying low above them. It has a maximum detection range of 30km, which falls off with height above the anomaly. Indications are given for distance and direction to the anomaly (exact values are printed in the debug window). Within about 10km a separate camera module deploys, this will rotate about its z-axis to look at the anomaly (this works best mounted parallel to the surface of the planet, on a rover or plane), and an indicator light turns on when the anomaly is within scanning range. For full science value make repeated observations of the anomaly and return the scanner to Kerbin for detailed analysis. Reports cannot be transferred out of the scanner, it must be returned to Kerbin to study the anomalies' effects on it. Results can however be transmitted for 50% value, or 75% with lab analysis. The scanner can be reset at an operational science lab after transmission. I made new science reports for all anomalies (only the real ones, with PQSCity transforms). I haven't tested every anomaly, but you should be able to get within scanning range for all of them, even if they are underground. There are new textures for the magnetometer and laser, both now resemble the drill and anomaly scanner a little more closely. The RPWS and telescope will have to wait for another update to get new textures and new models. I also made several bug fixes to existing parts. The magnetometer data can now be collected on EVA, and the non-functional right-click button has been removed. The laser description was fixed and the part was moved back to its proper tech node. This will require a repurchase in the R&D center (and may make the part unavailable if you haven't progressed far enough), but won't affect any existing crafts. I'll also be releasing, hopefully in a day or so, a prototype of my new ModuleScienceAnimate plugin. It's meant to replace most of my current modules and act as a generic science module with better animation controls (replacing the stock ModuleScienceExperiment and ModuleAnimateGeneric modules). Everything will be configurable through the part.cfg file only, so anyone will be able to use it. I'll add a link here when I release that (source is available on my GitHub repository now). Check the first post of this thread for a full preview gallery of the update. Change Log: v0.7: - New anomalous signal scanner. Designed for rovers and spaceplanes. - Used to detect and study anomalies. - Single use only; return to Kerbin for complete study of the science report, or transmit and reset with science lab. - New textures for the magnetometer and laser; they fit in better with the recent parts. - Fixed .cfg file and plugin bugs for the laser and magnetometer - Laser returned to its proper tech node - will require repurchase, but should not affect existing vessels. - A few minor changes in other part.cfg files; dropped the mass of the telescope. - New science reports for the anomaly scanner, fixed many typos in old reports. v0.6: - New biological activity core drill. Designed for rovers and landers. - Features multiple storage containers. - Can be used up to six times before needing to be returned to Kerbin or reset with a science lab. - Two different animation modes, used for rovers or landers. Animation dependent on the drill's orientation relative to its parent part - preview animation in the VAB/SPH - use cubic octagonal struts or other small parts to modify animation behavior. - New science reports for core drill. - Included support for Trueborn's Custom Biomes plugin. * Requires separate download - Reports for custom biomes for the laser, optical telescope and core drill. - Reduced values for some science experiments. 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. - 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. v0.4: - New textures for all parts. - Changed non-SCANsat telescope to be the default, for the SCANsat version replace the default scope folder with the alternate folder. - Tweaks to models and animations for the magnetometer and telescope. - Add Langmuir probe to RPWS model (should not break existing crafts). - Added surface reports for the magnetometer, including biome support where available. - Added biome support for non-SCANsat telescope in low orbit. - Rearranged tech tree placement; parts moved to earlier nodes. - Decreased science report values, added and edited science reports. - Added FxModule to part.cfg to force deployment before science reports can be collected. v0.3: Initial upload.

I think it's terrain detail you want on max. Some anomalies get buried underground with anything below max terrain settings.

ModuleTripLogger stores that information. I think every part with a control-from-here point has a trip logger. According to a post by Harv in some thread that I don't remember, the game takes whichever trip logger has the highest score and uses that one when giving science points after recovering a craft (but I think all trip loggers are maintained separately, so you can undock parts of a craft and end up with different recovery values). How much value each situation has on each planet I don't know. You can probably find out with a plugin using the CelestialBodyScienceParams class.

I don't recommend building something this complex, but this is one of my favorite ground base constructions. It's not really movable, but on Minmus you could easily take kethane to the base. This thing was a little too big and heavy for the Mun, but Minmus' lower gravity should make such huge amounts of mass less of a problem. It's mostly built with Kosmos parts and the large station parts pack with about six launches. Even if this specific example is too complicated, I think the basic design is really good. This is my all-stock fuel depot that was in Minmus orbit (it suffered a tragic demise when it ran out of fuel). It's way more complicated than it needs to be, but I think the basic design of 10 orange tanks and a bunch of docking ports is good.