DMagic

This thread has a lot of info on using Model {} nodes, mostly about placement for multiple meshes, and there is some more info in the PartTools thread.

Have you considered using Model {} nodes with these parts, instead of repeating the empty wedge mesh and texture for every part? I've never tried this with animated parts (though I think I've seen it done before), so there might be a problem there, but it seems like this could save a lot of space. You could put the empty wedge on one mesh with one 512*512 texture and put the interior sections on separate meshes. Then you could either fit multiple parts' textures on one file, or make higher quality textures for each wedge without really taking up more memory. It probably doesn't really matter now, but if you keep on adding parts you'll ending up needlessly consuming a lot of space.

You have to be controlling the Kerbal, on EVA, and you have to be fairly close (maybe 4 or 5 Kerbal height units away).

That's right. The asteroid science collection works basically the same way that any right click option does (like manually lowering landing gear) so it's different from the regular experiments, which have no way of knowing that you are at an asteroid. But since the asteroid experiment still has the same general behavior as others it requires that things like the planet and your current situation be specified.

I haven't checked in a while, but everything in here should still be valid: http://forum.kerbalspaceprogram.com/threads/35664-Kethane-Usage-and-Proper-Fuel-Routing The short answer is, if you don't have a direct connection between your converter and fuel tanks then you need to put fuel lines going from the tank to the converter.

Um... I didn't participate, but I think I know how to make a mod/parts. Restricting voting to those who participates seems entirely unnecessary and far too restrictive. We don't make mods only for other modders, we make them for everyone, and anyone who wants to is able to comment, make suggestions, or criticize our work. So I'm not sure why this should be any different. In any event, the addon development subforum acts as its own filter to some extent. This is a busy subforum, but one that probably gets visited primarily by people who have some experience with either making or using a variety of mods.

Whoops, I forgot about that. This link has updated license info for the textures and the plugin (which is also included in the source), nothing else is changed: Edit: Go back to the original post if anyone wants to download this. As for toolbar, I think I can easily solve that. The toolbar wrapper can easily be integrated into the code instead of making a hard dependency on the toolbar.dll. Rather than relying on the old icon, it should be simple to make the "open map" or "start scanning" buttons open the small map instead. I've already made a version that uses ToolbarWrapper, I haven't tested it much but I think it works ok. Allowing the buttons to open the map should not be an issue.

I think one post per contest is probably ok. That way it is less likely to get lost on page five or six of the subforum, this forum can be really busy, so it doesn't take log to get pushed off of the first page. If a huge number of people start joining it might become a problem, but until then one post seems ok. I do have one suggestion though, if the contest is going to start on Friday it should end the Monday after next. That would give people two weekends to work on it. Voting doesn't take much time, so allowing only three or four days for that shouldn't be an issue, but having two weekends could really help with people who don't have much time during the week.

Ha, I spent a lot of time in the SCANsat code when I was learning how to detect anomalies (though my method ended up being fairly different), since I didn't really know what was what I kind of looked around just about everywhere in the code. Also, there is a lot of SCANsat that is completely over my head, which was why I was hesitant to do much more than adding the toolbar support.

I went ahead and made a handful of changes to allow for experiments to work without any animations. Except for the five animation-related fields described below you can setup experiments just as you normally would. You should be able to use any resource you want. The only limitation is that the resource usage is based on time, so there must be a delay from when you click the button to start the experiment until it actually finishes. This can safely be set to 0.1 or 0.2 seconds, but any lower than that and you might get some inconsistencies in the amount of resources used. Feel free to use this module if you want (don't use DMagic.dll, that one has many other functions and is likely to shift under your feet to something that will no longer work for you): http://www./download/n3nk52x8zf12ltd/DMModuleScienceAnimateGeneric.dll (put that somewhere in GameData, I'll make a proper release of this new version sometime soon). Here is a fragment of your MM code that I used to test my module with your experiment. // Mark-1 Pod Changes @PART[*]:HAS[#CrewCapacity[1]] { MODULE { name = DMModuleScienceAnimateGeneric experimentID = LifeSci01 experimentActionName = Measure Vital Signs resetActionName = Discard Data reviewActionName = Review Data showEndEvent = false //These five fields should be included to showStartEvent = false //prevent animation related errors showEditorEvents = false experimentAnimation = false keepDeployedMode = 2 waitForAnimationTime = 0.2 //These three fields determine resource usage resourceExperiment = ElectricCharge //This will use 20 units of electricity over 0.2 seconds resourceExpCost = 100 useStaging = False useActionGroups = True hideUIwhenUnavailable = True rerunnable = True xmitDataScalar = 1.0 } } The only other fields you might want to use are "deployingMessage = " which will display a message on-screen (useful if you want to wait more than a second or so before your experiment completes) or "asteroidReports =", set that to true if you want to make any asteroid specific experiments. For complete instructions you can go to this thread (the version linked to there is different from the one above).

Using only ModuleScienceExperiment? I don't think so. It's really easy to do with a plugin, some of my parts do it, but if you don't want to use plugins it might not be possible. Edit: Though now that I think about it, if you are already going to replace the default experiments, you could include my science module, which was made for just this kind of flexibility, instead of the regular one. It would require a little bit of modifying to allow for resource usage without using animations, but that shouldn't take more than about 10 minutes.

I never realized that, it looks like it appends the asteroid id number to the end of the report title. I guess it makes some sense that each asteroid could give you different science, but from a game-play perspective that seems like a terrible idea. For now it's true that most asteroids will only be easily accessible in Kerbin or solar orbit. But if they add it asteroids spawning further away they could easily be brought into orbit around other planets. A single asteroid taken on a tour of Jool's three large moons (both low and high space for each, and Jool) could net over 3k science, or one quarter of the total needed for the tech tree. And given enough time and patience with gravity assists that wouldn't be too difficult. I guess extra biomes would be just as much of a problem for regular experiments, so they'll need to do something about it eventually. Edit: Or do asteroid samples just ignore the regular science value multipliers? A sample from in orbit around the sun gives me the same as one from in orbit around Kerbin.

It just needs a special case for very high latitudes. Check near the very end of SCANcontroller, where the fov value is being added to the current latitude to create the scan width before passing it off to data.registerPass. Adding or subtracting the fov value can result in latitudes higher or lower than +-90o which creates this issue. I added in this to get rid of it double laty = lat + y; if (laty > 90) laty = 90; if (laty < -90) laty = -90; then replace 'lat + y' with 'laty' in the next line. It seemed to be enough to fix it for me. The same thing is happening for longitude, this shouldn't matter though since longitude uses a complete circle, not a half circle like latitude.

Oh yeah, I guess I haven't actually used it in a really long time.

I think this has come up before a few times. I'm guessing it's due to the shoddy way that KSP reports latitude and longitude. It doesn't limit the results to 0-180 and 0-360 (or -90 - 90 and -180 - 180) like it should. Sometimes it will tell you that you are at 450o east instead of 90o east for example. It also might have something to do with the way SCANsat has to convert lat/long to integer values at some points during scanning rather than using more precise values. Maybe it's rounding values off in the wrong direction.

The practical issues? Is there some kind of user control, or does it run all of the time? Is it safe to allow it to run all of the time, will it affect performance, will it clash with something else? Should I rely on users to uninstall it after collecting data (a terrible idea)? Should it append results to a single file, create a new file for each run, or overwrite a single file? And so on. None of these are really problems, I've already come up with something that seems to work and gives results that are identical to FRAPS. I think the best, and safest, solution is to make it as restricted as possible. The way I have it setup currently will only run when you are using my CPU rocket (it relies on the craft name, so any changes will cause it not to run) and only starts once you have activated the first stage. I don't see any reason to collect any time data (game time vs. real time, fixedUpdateTime, ect...) because like you said before, it's all directly related to FPS anyway and that's the simplest method of displaying results. The framerate is the end result anyway and it's what actually affects how smooth or stuttery the game feels. The plugin starts up in the flight scene, checks the craft name (and does nothing if it doesn't match), then starts a timer (based on the computer's clock, not Unity's) and collects the amount of frames rendered each second, outputting these to a single log file in the GameData folder (we aren't allowed to create files elsewhere). I need to test it to make sure it's working properly, gets destroyed without issues, and to see if works on multiple platforms.

This was fixed a long time ago. All of the reaction wheel parts (the inline reaction wheel, the IAS, and the big ASAS unit) provide both torque and the SAS function. The IAS and IRW have the same exact function, only the mass is different. You can already do this to some degree. Switching to fine control mode (with the "Tab" key) alters RCS strength based on the distance of the thruster from the center of mass. It does a fairly good job of accommodating unbalanced RCS placement.

Have you read this before: http://forum.kerbalspaceprogram.com/threads/62657-Understanding-Science-Points. It's really helpful for this kind of thing. The transmission cost (or the data size to be more precise, which also affects the reset cost) is baseValue * dataScale * subjectValue (the per biome/per situation multiplier) * scienceValue (the diminishing returns multiplier). And the total science points for a report is the same but without the dataScale multiplier.

The numbers I've heard have been around 60-70k, but that was before 0.23.5. Because asteroid samples can be collected in every situation, around every planet, and, I think, with biome support in some cases, this probably adds another 10-30k to the total amount of science.

I don't think there's any direct way around this. You could change the DeployFXModule value in the .cfg file, but I think this will also prevent the transmitter from opening automatically. It's probably an easy thing to fix with a mod, but I don't know of anything that does only that.

Basically. Here is the complete breakdown of how it all works: http://forum.kerbalspaceprogram.com/threads/62657-Understanding-Science-Points

I believe you're looking for the 'dataScale' value in the ScienceDefs.cfg file. This is multiplied by the total science value for that experiment to give the total data size. Most experiments use dataScale = 1, but a few of the later ones use much higher values. Reducing the 'baseValue' setting will also lower the amount of data, but it will obviously lower the amount of science too.

This would be tricky to do anyway. As far as I know the only identifier of asteroid class is the "size" value from DiscoveryInfo (0-4 for classes A-E). But regular vessels also have that value and once you dock to asteroid its value is overwritten by the vessel's size info, which I think defaults to 2. I'm getting around this by classifying asteroids by mass, but that only works once the actual asteroid part has been loaded at least once. One thing that should definitely be added (because it gets asked about every other page on this thread) is to work the altitudes for each scanner into the VAB tooltip. I think putting them into GetInfo (the right-click-for-more-info button) would be the best idea since it would accurately reflect any changes made by users. Maybe the MapTraq button should say "Start Scanners" or something to that effect instead of "Open Map", since it doesn't actually do that. Or you could make it actually open the map window. Also, and I'm not sure if anyone cares about this, if you collect science results, save the game then quit, I think those results will be erased. I don't think this matters much, but if you didn't have a transmitter for some reason, or aren't able to transmit your results this would mean you would have to make a return trip to Kerbin without saving and loading (adding an EVA data collection method is also an option). It's very easy to save this information to the persistent file and pull it out again upon loading. There is also a better way of transmitting data, using the current method, if your transmitters are all busy when you try to transmit SCANsat data it just won't be sent. It's not difficult to add data to the transmitter queue the way it's supposed to be. I'm sure there are some other things that will come to mind later.

Well to some degree, yes, a drill is a drill. But you need to have some purpose for drilling into the surface. By itself drilling through rock would be rather pointless. The obvious reasons for doing so are either to drill through the outer layer of rock to reveal something below it, or to take a core sample. Taking a core sample by itself seems pretty similar to the stock surface sample experiment to me and I don't want to create alternate methods for collecting stock experiments, and besides, there are several other mods that already do just that. So the idea I went with, which was inspired by the old Viking landers and the planned ExoMars mission, was to collect samples to test for biological activity. The methods used by the Viking lander and the ExoMars rover destroy the samples they collect, but since I wanted to allow these samples to be returned for higher value I got a little hand-wavy and made up something about incubation chambers and allowing time for gasses associated with biological activity time to be generated. I really did intend to include this limitation in the part description though, and I've already added it to my latest build. And aside from all that I really like the idea of very specifically targeted experiments. For orbiters there are a lot of instruments that work well in any situation. Pretty much every major interplanetary probe has some kind of radio plasma instrument and a magnetometer and usually several imagers of some kind. But for landers and rovers it makes more sense to come with highly targeted instruments. Obviously I don't want to make this mod bloated with a bunch of semi-useless parts taking up RAM, but I think the drill is a decent enough compromise. We already have the barometer and the nose cone, but this actually brings up an idea for another interesting part. The ExoMars Trace Gas Orbiter is designed to detect certain gases from orbit, among other things, which could be an interesting experiment to make.

Based on the presence of the "animator" window on the right, I'm guessing that you're using Unity 4.3. You need to use Unity 4.2 if you want emissive animations to work. Check the stickied thread on emissives at the top of this forum for more.