DMagic

This is easy to do for a custom module, but a little trickier for a generic one. One way that I can think of is to create one animation field specifically for the looped animation, something like "loopedAnimationName = ". Then have a field for how long you want to wait before the looped animation begins (ie. primary animation.length), a value of 0 would start it immediately. All of this could be controlled with a coroutine that is called when the primary animation trigger is fired. Then it would play the primary animation, start the coroutine, and wait until a given time before starting the looped animation. Then there are a few ways to wind down the looped animation. The ugly way is to let it snap back to its start position then play the primary animation in reverse. The nicer way is to reset the looped animations normalized time to a value between 0 and 1, set it to clamp, and let it finish its last loop (though because of Unity's animation issues, this doesn't always look so great, sometimes an animation stops on the second to last frame), this also has some issues, but I think it's better than snapping it back to zero. There's probably also some way to accomplish this using OnUpdate code, but I try to avoid that whenever I can. I've been making something similar, combining the ModuleScienceExperiment with my own animation code and allowing for as much flexibility as possible using only the part.cfg file. The idea is to make a smarter way for science experiments to control animations. This is as much for my own sake (I have four parts with four custom plugins that are basically the same) as anything else, but I also plan on releasing it for others to use. Right now it can only call one animation, but I think adding at least the looping code shouldn't be too hard.

I've already made a new magnetometer texture, it's basically the same, it just has more detail, better normals, and specular textures that actually make sense. It looks fairly similar to what the drill looks like now, but all of the features are basically the same as before - the blue stripes, the panels, and the details on the instruments themselves are all still there. The RPWS I'm not really satisfied with at all. I haven't started working on it, but I plan on completely rethinking the model (it's mostly that green panel and the grey blocks that I don't like, but the whole thing could really use work). It will still be about the same size, and I expect the texture will end up looking similar to the current one, but we'll have to wait and see. Here's a look at the new texture, on the right. It's about the same, it's mainly the metal borders and the bumpy normals that have changed. I want all of my parts to share a similar style, and the drill texture is good enough for me, so I'll be updating all of the old ones to look more or less like that. I should be able to get to the laser before the next update too.

That seems to have slipped in from when I was trying to figure out how to determine which biome you're in. I guess I never removed it. It doesn't really do anything, you can open the debug window (alt F2) and it should print out the name of the biome you're in, but other than that it's harmless. I'll make sure to check over the plugin modules and .cfg files for everything more carefully next time. That's actually a good idea to keep in mind Cpt. Kipard. All of the other parts are relatively small and should have no problem fitting (I assume you just need to add some KAS code to the .cfg if you want to move them around) or being move around. I'll keep that in mind when I redo that model; I'll rethink the mass, too, especially if I make it smaller. By awkward do you mean the way the laser has a tendency to shoot through whatever is below what it's attached to? My plan is to add an orientation check similar to what I have with the drill and play a different animation to avoid that issue, I only need to make a new animation for it (animating those power cables takes forever, so I've been avoiding it). I'd like to find a smarter way of doing it though, preferably one that detects which direction the ground is relative to the part. And eventually I want to add some kind of detection to check that the laser/drill is actually contacting the ground when it's deployed, but I want to make sure I have a reliable way to play the animation first.

I believe the FOV scaling with distance is (current altitude / ideal altitude) * FOV, so just a linear scale up to the ideal altitude then fixed up to the max altitude (or the SOI for Gilly). I guess it doesn't really make sense for the ideal altitude values to change with planetary radius, the scanner should work the same regardless of how big the planet is. Edit: I see in changelog 4 that FOV scaling works just like I described above. It does also mention that parameters are scaled based on the radius and SOI, but as far as I can see this just refers to changing the FOV based on radius and checking to see if the SOI is less than the ideal scan altitude. I think Gilly is the only planet where this applies, its SOI is only a 100 or so km, so that is where the ideal altitude is.

From what I can gather the FOV definitely changes based on the planets radius. I can't see anything that directly changes the alt values though.

Thanks Wurmi, I updated all the charts. That seems like a pretty powerful machine, it's the best of all the mobile results I have.

Thanks. The RPWS and the telescope are due for a remodel and retexture, which I probably won't get to before the next update. I also plan on updating the textures for the laser and magnetometer to bring them up to the same, not-total-crap level as the drill, those I might be able to get to relatively soon. Thanks for that. I figured there were a few of these kinds of bugs scattered around. I'll do a more thorough check before I release the next update.

I believe the values vary by 600/(radius of the current body), or maybe by the square root of that, I'm not entirely sure. It also seems that the scale doesn't change for anything bigger than Kerbin.

It might be a good idea to have some kind of designated version indicator, not just the [version] text that some people add to the name of their mod. The one, and really only, thing that spaceport does well is that big red download button. There is no other software required, and no pop-up ridden download host to deal with. Having that simplicity in actually getting the files is a huge benefit.

Do you mean that you want to make a different part function as a SCANsat scanner? You don't have to do anything with models to accomplish this. Just open up the .cfg file of the part you want to use and add the SCANsat module to it (copy this information from the default SCANsat scanner that you are using). If you want to make another model that's a different issue. But adding the SCANsat function to any part, whether it's a new model you made or an existing part, only requires adding the required text in the .cfg file.

Thanks for the results Blaster. They actually look really similar to the FX-4350, which isn't too surprising considering that KSP won't actually do anything with the 2 extra cores. Yep, it seems unlikely that we'll see anyone break 30FPS with this rocket until when get some more performance improvements. Top-end, single-core performance on Intel CPUs hasn't changed much in the past few years, and it's unlikely to do so anytime soon. Though I'm actually curious to see how a newer, really high end mobile Intel CPU would do. Their most recent ultrabook CPUs actually perform really well, and all within a really constrained power level. That i7 4770R isn't actually any better than the regular 4770. The reason it's so expensive is that it has Intel's most powerful integrated GPU, I actually don't think you can buy those parts retail, they only come in OEM formats like the BRIX Pro. One of those tiny little things would probably make a really nice KSP computer.

I'm not sure how it easy it is to see, but the basic build order is: Probe core, then sideways rover body, then 1X1 structural panel, then a second 1X1 panel attached to the edge of the first (they were unintentionally clipped into the rover bodies, so you can't see the second panel), then the second rover body on top of that. The wheels are placed on I-beams attached to the ends of the two 1X1 panels. That's my full test version of that rover; when I switch on unlimited fuel and RCS that thing can get in and out of atmospheres with no problem, and it's perfectly stable. I can hover with the main engines and use the RCS thrusters to scoot around. The side mounted parts are all attached to the rover body through an inverted cubic octagonal strut, that way I can separate them for pictures and not have any extra parts hanging off the sides. For how quickly I made that rover it actually turned out really well. It's perfectly stable on Kerbin and can get up to about 25m/s, you have to be a little more careful on Duna or Laythe, but it works really well.

It doesn't change, ISP only varies by elevation in an atmosphere in KSP. The total dV you can get from an engine is based on the ISP and the mass of the vessel before and after using all of the fuel. So if you only look at the mass of the engine (the LV-N is very heavy) you might come to a conclusion like this, but your vessel is never just an engine, you have to take into account the total mass of the vessel. It is true, though, that there is some level where using more than one LV-N (or using an LV-N at all) is less efficient than using some other, lighter engine. But this is only when the mass of the engine itself is a substantial portion of the total vessel mass, like if you tried to put an LV-N on small probe.

You might want to try setting up the animation in your modeler and importing it to Unity, if you haven't already. When I set up my drill animation in Blender I used a handful of keyframes to rotate about the x-axis several times, one big continuous curve (mine isn't a looping animation, just several rotations as part of a larger animation). When I import it into Unity it interpolates keyframes at every frame of the animation, does some crazy bouncing back and forth on the z- and y-axes and rotates 180o around the x-axis before flipping back around. It all turns out as one smooth, continuous rotation, but if you try to duplicate that manually in Unity it might cause problems.

Check here if you want more about all of the changes to the SAS system since 0.21: http://forum.kerbalspaceprogram.com/threads/41941-New-SAS-functionality-and-You%21-0-23-Update It's a fairly major change in the way that vessels are built and controlled.

Did you set the alpha channel right when you imported the texture to Unity? It sounds like your texture has an alpha channel, so you want to set "alpha is transparent", it looks like you might have it set to "alpha from greyscale". The translucent shader allows for varying degrees of transparency based on the alpha level, the cutoff sets everything above a certain alpha level as completely clear. Either way, you need to tell Unity the correct source of the alpha channel.

The Unity Asset folder is wherever you told it to be when you created a new project. To import the 0.23 part tools you create a new project in Unity, note the folder location, navigate to that location, unpack and drag the PartTools folder into the newly created Asset folder in that location, then load or switch to Unity. The part tools should automatically begin loading, then you specify your KSP game directory. You can create as many projects as you want, each with their own directory and each needs to have the part tools manually imported.

Unity 4.2.2 is definitely the version you want, 4.3 made some changes to the animations that KSP doesn't seem to like. I don't think you have to install .20 then overwrite it with .23 part tools. Just download the .23 tools and move them into your asset folder, but I might be wrong about that. I usually import files as .fbx format, but .blend works too, you just have to make sure you take into account the change in the y and z axes when going from Blender to Unity. Also, the naming conventions for collider meshes don't apply anymore, you can name the collider whatever you want, or just add it as a physics component in Unity.

Being selectable as a first part only requires that it allow stack attached and surface attached parts, it doesn't have anything to do with control points or trip loggers, that's why all kinds of structural parts and fuel tanks can be used. I assume that if a seat doesn't have an active trip logger by itself that it acquires one when a Kerbal sits down in it. Or maybe the Kerbal itself is the trip logger in that case. I assume that each trip logger keeps its own record of where that specific part has been, so even if you dock and undock all of the records should be maintained. But it's always interesting to test out how it really works to be sure. And a quick look through a persistence file shows that both rover bodies and science labs also have trip loggers. So there might be others that aren't used as a control point.

Did you make the animation in Unity or import it from something else? If you import it from something else I think Unity will interpolate a bunch more frames between the ones you set. But if you made it in Unity I think you need to have less than 180o between keyframes. The Euler angle values that you set get converted internally into Quaternions, which won't necessarily rotate the way you expect them too if the difference is more than 180o between keyframes. I would try three frames set 120o apart and see what happens. The stock science module doesn't interact very well with animations at all. It works ok for the stock parts, but anything more complicated just doesn't come out right. That's why I replaced it on all of my parts. It's not that difficult to do, but it's a lot more complicated than setting a few values in the .cfg file.

Are you using enough keyframes for the rotation animation? I think the conversion from Euler angles to quaternions can screw with rotations that make too much of a change between frames.

Update to V0.6 Download on Spaceport See the first post of this thread and the posts above for a full preview. There are only a few minor bug fixes from 0.5.1. Custom biome support for the laser scanner and optical telescope has been added for all planets. Experiment values have been reduced slightly. Let me know about any bugs or suggestions you might have. Change Log: v0.6: - Minor bug fixes for core drill. - Custom biome science reports added for laser and optical telescope. - Reduced science experiment values. v0.5.1: - New exobiology core drill instrument. Designed for rovers and landers. [INDENT]- Features multiple storage containers.[/INDENT] [INDENT]- Can be used up to six times before needing to be returned to Kerbin or reset.[/INDENT] - New custom science reports [INDENT]- Support included for Trueborn's Custom Biome (Basic biome set) --- * Requires custom biome download[/INDENT] 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: - 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. v0.4.1: - Added plugin for testing. - Custom part module for magnetometer and RPWS. - Changes to animation and science module functions: - Animations are now reversible while playing. - Magnetometer animation slightly faster. - Transmitting or resetting experiment no longer triggers retract animation. - Deploy animation only plays when experiment is possible (no longer displays can't perform experiment dialog after completing animation). - Deploy/Retract button always available by right-clicking part. - Parts must be fully deployed before experiment can proceed. - Collect data button/action group triggers deploy animation if the part is not already deployed. 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: - Added science for RPWS Antenna. - Tweaked magnetometer science values and reports. - Added alternate telescope part folder with science reports that aren't dependent on SCANsat. - Changed default telescope to the multispectral SCANsat module (biomes and anomalies), this seems to make more sense for an optical telescope. - Changed tech tree node positions. - Changed magnetometer texture to match the other parts. v0.2: - Added science for magnetometer boom for the space around all planets and moons. - Added SCANsat SAR sensor (hi resolution map) module for the telescope * Requires damny's SCANsat plugin. - Fixed attachment node placement. v0.1: - Initial upload

Update to V0.6 Download on Spaceport New science part added: Exobiology core drill. This instrument is designed to search for signs of biological activity on atmospheric planets. The idea is based on some of the old Viking experiments and the proposed ExoMars Rover mission from the ESA. The instrument can store and return three samples for full science value. It can transmit up to six reports for reduced value. Transmission, storage and science lab processing all work similar to the stock parts. The only major difference is that the instrument must be manually reset by a science lab. The "Clean Experiment" function accessed by right-clicking the science lab won't do anything to the drill. You must right click the drill itself to reset the experiment count. Also added support for Trueborn's Custom Biome plugin. Science reports with custom biomes are included for the core drill, laser scanner and optical telescope. Check the first post of this thread for a full preview of the update. Change Log: 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.

Everything looks like it's working ok, I've caught a few minor bugs, but otherwise I think it's good. I'll probably try to release tomorrow, I only need to check things over one last time and setup some image albums for release.

Search for mods that use IScienceDataContainer instead of ModuleScienceExperiment. Using the former you can control experimental conditions, which report you collect, the value, what happens when you push the buttons on the science report window etc... Everything that uses it has the same general format, so checking any of them should give you an idea of how to setup your own plugin.