DMagic

I don't know about shape keys, I swear I read something about shape keys working in Unity, but that they had to be set up in Unity, not imported; I have no idea where I might have read that though, or if I actually did. As far as I know the only types of animations that Unity understands are standard object manipulations (translate, rotate, or scale object 1 relative to object 2) and armature rigs (bones and skinned meshes). Unity doesn't understand bone constraints on armatures, but it is still possible to do all sorts of interesting things by simply baking down the constraints into a regular animation. For instance, making a flexible tube with fixed ends, or any type of kinematics animations. For that specific dish animation I think an armature animation would work fine, it might just be very tedious to setup and animate all of the rigs.

@Rodger Sounds unrelated to CapCom, since this doesn't do anything to the mission control center. @nightingale It's possible that too many query events are run. Each contract generates three (advance, reward, penalty) for the contract and two for each parameter (reward, penalty), which can add up. The code for it is on GitHub; for the contracts; and for the parameters. Each contract is checked once immediately after the contracts finish loading.

@Kill_off There is a short explanation of how asteroid science works near the top of the first post in this thread. Basically, asteroids are split up into nine different groups, independent of size, which are used to generate pools of science for each asteroid experiment. @Napseis "Hammer Test" as in, test the hammer. There should be another button called "Collect Seismic Data", or something like that.

@Neutrinovore I think you misunderstood. It's not about visually confirming the position of the hammer. The seismic hammer doesn't use visual cues to determine the angle about which it must rotate to face exactly down, or to determine the distance that the variable length section of the hammer must be extended. As you can see in this picture, the hammer can be theoretically placed in any orientation, and at a variety of heights and still work. Figuring out the angle that the hammer must be rotated requires figuring out the location of the point on the surface directly below the hammer. I'm not really sure how to do that in the editor (figuring out the distance from the end of the hammer to the floor is probably simple though). I could play the deploy animation without any changes, but then the hammer would just point straight out and would give the misleading impression that it can't be used in any orientations other than vertically mounted. It's probably possible to get it working right in the editor, I just don't really want to spend that much time on it when testing it on the launchpad is so much easier.

@Brigadier Editor as in vessel editor. It's the generic and internal name, and is easier to type than VAB/SPH. It appears that the messages only show up there, which is fine. But I should probably make sure that they don't, since I know that test is going to fail anyway. @Neutrinovore I don't want to put in the 'systems check' for the seismic hammer in the editor because I think it would be misleading. The logic that determines how the hammer is deployed depends on there being an actual planet underneath the vessel and for the distance to the surface to be accurate. None of that really happens in the editor. The best way to check the hammer is to test the final lander craft on the launchpad. The only other part that doesn't really have an editor deploy is the SIGINT dish, which is for technical reasons (the dish part isn't actually there in the editor). @JPLRepo That looks like a really old error. I think it was a 0.90 error that broke the scenario module loader. I haven't seen it again since you picked up TST.

@Brigadier When does the first error happen? The recon contracts rely on the stock specific orbit parameters in part, but there are some cases where the orbit doesn't get initialized so I have to do it myself. That error comes from when there is a problem with that orbit. I think it might always happen once in the editor. But if it's happening somewhere else, or repeatedly, that could be a problem. Have there been any problems with the recon contracts resetting it not recognizing the orbit? I'm not sure about the CC errors, though I do seem to remember that it uses stand in names for contracts that ask for a specific vessel. And if it's right about a scenario module crashing you probably have bigger problems. I'll check the log file when I get a chance.

@armegeddon ModuleOrbitalSurveyor has two extra fields: minThreshold and maxThreshold. They aren't specified in the M700 config, but they can be added. Their default values are 25000 and 1500000. The editor tooltips are generated during initial loading (I think; I only looked into this once, a while ago), so unless there is a way for MM to get to it before that I don't think there is anything that can be done about it. Edit: Also, the stock ModuleOrbitalSurveyor does take the planetary size into account to some degree. So it might not be necessary to change those values.

@Sigma88 In stock. The values for SCANsat are in the ModuleSCANResourceScanner.

@Sigma88 I know the feeling... The M700 also has min and max scanning altitudes, I'm not sure of the exact module off the top of my head, but it's something obvious.

@Sigma88 Yeah. So if a stock planet has a max altitude of 4000m, then there is a MM multiplier of 4, the max will be 20000m. If you start a new game that planet will then have its max altitude set at 20000m, if you save the values from in-game that value of 20000m will be written to the config. The next time you load it will then get multiplied again, to 80000m; this could go on endlessly, so not saving would be the best option. The only players that this would really affect are those that like to customize terrain and resource values a lot, and that play multiple different saves. The best option for them might be to customize everything to their liking before installing Sigma Dimensions. Or just save everything then delete the MM config. Maybe making two configs for SCANsat would be best, one for the scanners and one for the color config file.

That is found in the stock ModuleResourceScanner Module to specify the maximum altitude for that scanner. I think it only affects the readout in the right-click menu. SCANsat also uses that value for its replacement right-click readout, but it doesn't affect the actual scanning altitude for SCANsat resource scanners.

@Sigma88 Those look fine, and are the only SCANsat values that should need changing. The only potential problem is that the values in the SCAN_Color_Config can be saved from in-game. So if they are multiplied by MM, then saved in-game, the multiplied values will end up as the base value in the config file, which will then be multiplied again. This won't affect existing saves, their values are loaded from the save file itself. The values in the config file are used for new save files and for reverting to default values. I'm not sure of the best way to handle altering the terrain values, other than specifying exactly what the min and max height should be, rather than using a multiplier. But that's a bit of a pain, and won't really be able to take additional planets into account. For the majority of users a simple multiplier MM config should work fine though. You might just want to add a note about not overwriting the config file from in-game.

@jcthemc Are you using one of the goo pod instruments from my pack, or the stock part? The anomaly contract will only complete when using my parts. I thought I had put a note about that into the anomaly contracts (there is one for the asteroid contracts), but apparently not. You don't have to complete all of those requests though, so if you can finish the other ones it should work fine, or you can just manually complete the contract in the Alt+F12 menu. @Jimmy P DropBox isn't cooperating now, I'll edit this if I find anything when it's working. If you Remote Tech installed (I don't think it's a requirement of RO, but is suggested) that is known to have problems with science transmission in some cases. There is a patch available somewhere in the Remote Tech thread somewhere that I think fixes the issue.

@Corvorosso Top line of the the log file: Kerbal Space Program - 1.0.5.1024 (WindowsPlayer) You need to get the latest version of KSP (1.0.5.1028). Steam will update automatically if you allow it, I'm not sure what the process is for the store version. Send regards to Squad.

@Corvorosso I need to see the complete log files, and preferably a picture of the orbits from map view. Also, which version of KSP are you on? A MissingMethodException implies that this might not be 1.0.5. Edit: Also, a complete view of the contract status would also help. It looks like the part request parameter isn't complete; the orbit parameter can't be complete until the part check is complete.

@SpaceNomad As it says in the editor description, all of the recon parts can be used for low space results at up to five times the normal altitude. This is specifically so that different orbits are allowed while still allowing for the science collection part of the contract to be fulfilled.

@5thHorseman It's not even difficult to implement a fuel transfer system... Though I would suggest a slightly less absurd method, like reskinning the fuel line.

There is a record kept of all your progress achievements, and it is relatively straight forward to go through the existing archive and figure out what reward was given, when it was completed, and some other relevant information. Whether Squad wants to do anything about that I don't know. But there are a few options for viewing progress rewards right now: @Snark This displays progress records, too:

@eberkain The exception only pops up once, and only after a scene change? That is normal, and it happens with many UI mods; is has something to do with Unity trying to draw the window before everything is ready. I have no idea exactly what causes the issue. For SCANsat there is one UI element that, if left out, makes this error disappear. The solution is probably something like adding a small delay, but I don't think it actually harms anything. The Unity window drawing method seems to fail once, but then works fine in subsequent calls.

@Deimos Rast SCANsat actually logs some info about the science amount when you collect data, you can see it at the very end of the log file you submitted. What it's showing is, first: The scanning coverage amount, then the science cap for that planet, the science multiplier for that planet, the scientific value (which is always 1 and can be ignored) and the resulting science amount for that scan before accounting for any previous data transmissions. The second line shows how much science points you should receive for the data (after accounting for previous results), and the base experiment value (the value defined in the science defs file, which isn't actually used ). The third line shows the total amount of data. This is the value shown in small print in the results windows, not the science value amount (that is shown by the colored bars); it affects transmission time and power requirements. These logs need to be updated so that they show more relevant data. But in your case it's showing that you are collecting data from a full scan, with a science value cap of 150 (from the science defs file) and a planetary multiplier of 1.5 (so I'm assuming this is a Kerbin scan). That results in a max possible value of 225 science, but it seems you already have that amount collected, so the end result is 0 science. It is also possible that having different science base and cap levels affects the resulting science value shown in the results window. There are several aspects of this that I can fix, and several that can be made more intuitive; though in general KSP doesn't seem to like this kind of manual manipulation of science values. @smjjames Well, I did say some issues were fixed. The specific issue was that contracts might not have been generating if you had never visited a planet outside of Kerbin space (I don't think the sun counts). The problem with contracts appearing then immediately vanishing might be a CC issue combined with the way that stock periodically prunes the contract list to make sure there aren't too many. @Loren Pechtel For Kerbin results you don't even have to go anywhere. Just put a scanner on the pad, collect data, and recover the craft.

If it's really meant to be a science value multiplier then I think it's probably just an un-implemented feature. You could use it in a mod to generate your own science data, but otherwise it probably won't do anything.

@Deimos Rast The zoom map isn't new, it was opened by right clicking on the big map in previous versions. For the science it takes the cap value defined in the sciencedefs.cfg file, multiplies that by the scanning coverage value (so you only get 100% science when you have scanned at least 95% of the planet), then multiplies that by the standard planetary situation modifier for high orbit (1.5 for Kerbin, 2.5 for Minmus, 5 for Eve...). So with the standard cap value of 20 you should get 30 science for a 100% scan of Kerbin, 50 for Minmus, etc... but less if you haven't fully scanned the planet. I don't think changing the base value will have any effect. The only way I can think of for it to give you less than the full cap value is for the scan not to be complete. But, then again, the science system is kind-of confusing under the hood, so weird things might happen if the base and cap values don't match.

@Loren Pechtel Yep EVA over.

@CobaltWolf It was exported correctly, the problem is that Unity seems to treat SkinnedMeshRenderers as if they are fully extended, at least for setting the bounds. It is possible to manually edit the bounds values, I never tried it to see if it would fix some of the problems though (xEvilReeperx's part icon fixer does basically the same thing, it recomputes the bounds for a SkinnerMeshRendered in the closed state). I don't think it would fix the remaining size error in the editor though, I set the dish transforms as inactive in the editor. I think that I just need to set all of the interior transforms inactive to get the part to register as the correct size. I made a dummy part, with no interior components, for setting the drag cubes, and that registers the correct size in the VAB.

@smjjames The terrain map error was caused bya problem in the way SCANsat precomputes some of the terrain data. That wouldn't be problem with biome maps. That's why I thought there might be something wrong with the actual biome map. @Loren Pechtel You can always send a Kerbal up to collect the data.