DMagic

Version 1.2 is out; get it on Kerbal Stuff. There are a handful of mostly backend UI changes and tweaks, a new sort-by-time option, an indicator for the currently selected contract, and the ability to select multiple contracts by holding down left ctrl when selecting contracts; these can then all be accepted, declined, or canceled if you have free contract spots or the contract is able to be declined/canceled.

While I'm sure you can find specific examples of such things, KSP in general has been getting much better about exposing code. The resource system, physics config, compound parts, tech node, building upgrades, etc... are all very amenable (or at least more so than they were before) to modding, and I can't see any reason why the relay system wouldn't be, not to mention that RoverDude has already said it would be.

I think the mistaken association of the new stock system with RemoteTech is what causes a lot of concern. From what it sounds like the new system is much closer in concept to Antenna Range than to RemoteTech. Some people, including myself, find the advanced relays, time delay, and flight computer to be interesting for a while, but just tedious after playing long enough. If the stock system does away with that (and provides a simple interface for mods to build upon) then I'll be happy.

That's an interesting idea. I don't really like not being able to switch to the probe at all, but maybe you could just lose control of all SAS systems only after switching away. Restricting maneuver nodes while disconnected might also be interesting, or it might just be tedious... I also like my own idea () of giving advanced probes increasing amounts of autonomy. I think it goes along well with most of the stock career mechanisms where gameplay restrictions are gradually relaxed as you progress. Most importantly, I think, is that there needs to be a very clear indication of connection status, both in-flight and in the map view. There also needs to be clear method for telling players what the loss of connection means (ie greyed out SAS indicator, some simple message about science transmission, etc...).

Just click off of the map while selecting a waypoint.

Embarrassingly little: https://github.com/S-C-A-N/SCANsat/commit/7416afb15dbb3dd2f391d95405dda6466455e1e3

That's a bug in how it's handling collecting and resetting data from parts that can store multiple experiments. Though it looks like the error you saw was triggered when trying to reset the experiment from EVA; it would be easy to click the reset button when trying to click the collect button, given how terrible right-click menus are on EVA. I'll have to go through and see if there are any other instances where it's trying to modify a list in a way that .net doesn't like. Some persistent file editing should get the part working again. I can't say for sure right now which fields need to be adjusted, probably experimentNumber, Deployed, and maybe Inoperable.

This appears to be a stock bug with anything that adds a scenario module. Once the module is added it no longer causes a reset, it's just the first time you load an existing save while adding a new module. I have no idea why it would cause the notifications to reset, but it does. Just find any addon that uses a scenario module (used for storing save-file specific data), install and see. So send any complaints about this to Squad, not me.

It's possible that there is a problem with how SCANsat is checking for biome unlocks. Looking through the code for the resource abundance readout modules I can see where there might be some problems. That said, the instruments window resource abundance readout should work fine and be less terrible than right-click menus.

Some kind of intelligent grouping of part tests is a good idea (I think a lot of the stock contracts are improved by grouping multiple objectives together, like science reports and maybe some of the milestone-type contracts), along with more sensible test conditions. Of course, you'll probably have to ditch a lot of the randomness for test conditions to make more sense, which will be a lot of work. But still, 20 sensible part test contracts would be a lot better than 200 nonsense contracts. What do you mean by asteroid part-test contracts? Objectives that require an asteroid on your vessel? That could be interesting. Free unlocks for test parts is a great idea. Does that mean offering the part for free once a tech node has been researched, or just allowing its use regardless of the tech node state? Both are interesting propositions. The first is easy to implement, I'm not so sure about the second.

Me too. I've never liked the foil look. It's hard to get it to resemble an actual surface rather than a flat texture, even with a normal map.

Chapter 1: Radio and Plasma Wave Science Chapter 2: Magnetometer Chapter 3: Telescopes and Imaging Systems Chapter 4: Laser Ablation Chapter 5: Core Drill and Biological Experiments Chapter 6: Neutron Reflections and Subsurface Water Chapter 7: X-Ray Diffraction and Surface Composition The dynamic albedo of neutrons (DAN) experiment included in my parts (and inspired by Sethnizzle's experiments) is taken directly from one of the Curiosity rover's instruments. The Instrument The instrument is made of two separate components. An elongated flat object mounted within the body on one corner of the rover is the neutron generator. The other component is made up of two partially exposed, helium-filled cylindrical detectors and the electronics package, it is mounted on the other side of the rover. The figure below shows each component and their placement in the rover. Pulsed Neutron Generator Passive neutron measurements can be made using cosmic-ray radiation, but these provide only rough estimates of subsurface hydrogen, as the energy, number, and direction of the neutrons can't be controlled. By using an active neutron source all of these factors can be controlled to give much more accurate measurements. The DAN neutron generator is basically a small particle accelerator, which bombards a tritium target with deuterium ions through a vacuum tube. This reaction produces helium and neutrons. Short pulses of neutrons are generated with a duration of about 1 microsecond with a well-controlled energy, scattered neutrons from this pulse can then be measured by the detector. Detector Each of the two cylinders in the detector module is used to measure neutrons through scintillation counters based on products of the helium-neutron interaction. Relatively slow moving neutrons (thermal neutrons) interact with the helium nucleus (specifically, helium-3, which has two protons and only one neutron) to produce a proton and a tritium atom. That proton is detected by the scintillation counters. One of the detectors is coated with a thin layer of cadmium, which blocks the slow moving, thermal neutrons, while the other is transparent to them. Both detectors will measure the background, high-energy neutrons, this allows for an accurate count of thermal neutrons. Neutron Scattering The purpose of this controlled release and detection of neutrons is to measure the amount of subsurface hydrogen, and to generate an accurate representation of the layering structure of hydrogen up to 1m below the surface. Hydrogen concentration is inferred through neutron scattering based on the amount of low-energy, thermal neutrons detected by the instrument. Neutrons are slowed down and scattered by interacting with hydrogen molecules, this both lowers the energy of the neutrons and delays their return to the surface and subsequent detection. By comparing the amount and timing of low energy neutrons detected with the amount of higher energy neutrons, an estimate of subsurface hydrogen can be obtained. Note that despite what this image implies, thermal neutrons are slower and of a lower energy than epithermal neutrons. Since most of the hydrogen bearing compounds detected on Mars have been either water or hydrated minerals, this method generates a good estimate of the amount of water just under the surface. By fitting the results of repeated measurements to complex mathematical models (and making some assumptions about surface composition) a detailed map of both the amount of hydrogen, and therefore water, and its distribution in the soil stack can be obtained. The figure below show a hypothetical, two-layer scenario. The neutrons pass through the low water content area with relatively little scattering, but are quickly scattered and returned to the surface by the higher water content in the lower layer. The figure on the right shows real-world measurements made by Curiosity over its time on the surface. Both active (using the neutron generator) and passive (neutrons from natural sources, which produces results while using far less power) have been made repeatedly by Curiosity. These show how different regions produce different rations of low to high energy neutrons. We'll try to dig into X-ray diffraction and surface composition for the next segment.

Try adding or changing the following fields. Also get rid of the actionGUIName field. experimentAnimation = true experimentWaitForAnimation = true //will wait for the doors to open before giving results waitForAnimationTime = -1 //will wait for the duration of the animation keepDeployedMode = 0 //will behave like the stock part, resetting the animation after resetting the experiment showEndEvent = false showStartEvent = false showToggleEvent = true

Version 14.1 is out; get it on Kerbal Stuff. It includes the performance increase described above and a fix for resource scanners while landed.

You might have noticed some performance problems in the latest release, particularly with low resolution and/or greyscale terrain maps. I should be a little embarrassed and mad about missing such a dumb thing, but in the process of figuring out why performance was so bad I stumbled on a huge performance boost across the board. It turns out that one of SCANsat's older bits of code (the instance getter property for the scenario module, to be specific) was using a terrifically inefficient method. And since that property is called hundreds to thousands of times per frame by the map generator it was having a huge impact. Simply using a saner approach to accessing the scenario module instance yields significant improvements to map rendering speed. The following are rendering time differences for a 1000 * 500 pixel big map: Full terrain map (terrain data pulled from KSP): 20s to 13.5s Terrain map regen (terrain data from cache): 13s to 6.5s Stock style biome map: 34s to 5.5s SCANsat style biome map: 31s to 5.5s Slope map: 20s to 5.5s Times for the zoom map improve, too: a terrain map at the standard zoom map size goes from 5s to 3s (little/no drop in frame rate) As you may notice, 5 - 6 seconds is about the time that it takes for the red line to move up the map at 60 FPS. Almost as important as rendering time, is that there is little to no impact on frame rate while redrawing the map. To be clear, reading the terrain data directly from KSP is still slow and still has a significant frame rate impact; there isn't much to be done about this aside from distributing SCANsat with some kind of pre-computed height maps, which I am not at all a fan of doing. But once the terrain data is read it will remain cached until you change the planet being displayed or change the map size. After that the maps generate with little delay. As you've probably noticed I'm not a big fan of incremental SCANsat releases, I've only uploaded 7 or 8 primary release versions of SCANsat in the past year or so. But I think this warrants a quick release, I'll see about getting it out tomorrow.

Capcom provides the functionality of the mission control center without having to switch back to the space center scene. It can technically be used to monitor active contracts, but it provides the least efficient and least effective way of doing so. The Capcom forum page has details on what it does and doesn't do. Contracts Window + is only for monitoring active contracts. It is designed so that it can be on-screen all of the time; it is very compact, the size can easily be changed to show more or less information, and includes as much information about contracts as possible. It has many tools for grouping, managing, and ordering contracts, none of which can are found in the stock contract window. Agreed. I have in mind a few simple changes that should improve this.

All of my parts use or inherit from DMModuleScienceAnimate which allows for the experimentLimit field. Just add that field, specify a number, and it should allow you to collect multiple experiments from a single part before needing to transmit/collect/reset the instrument. You can use DMModuleScienceAnimate for the stock science parts, just remove the standard ModuleScienceExperiment, replace it with mine, and make sure all of the fields are filled out correctly. Most fields are the same as for stock science parts, there are just a handful of extras that need to be filled out, most of which you can probably figure out by looking at my standard parts (ie not, US science and not anything that doesn't use DMModuleScienceAnimate).

I can see it happen, the NRE when boarding a vessel with science, both in your save (which seems to have some other weird bugs when going on EVA) and in a new save. And I've seen that happen before several times. It's no surprise that weird things happen when a part's destroy method fails like that (I managed to trigger an error that interrupted a part's destroy method for dropped stages during launch, after that the parts would continually respawn above me and drop back to the ground, it was kind of hilarious). So I'm sure that all of the weird Kerbal portrait and other errors stem from the initial failure upon boarding. Why that happens I still don't have any idea. I don't do anything unusual to the Science Data. Once it gets transferred to a Kerbal it should be treated the same as any other, the same way that it does when it gets transmitted or recovered. The only difference between my data and stock data is that stock science somehow takes Kerbal scientist level into account. The value that controls the science research level (detailed, thorough, ect... that shows up in the results page), ScienceData.labBoost is being set to 0 by me. I should probably set it to 1 (which is the lowest research level, that doesn't show any special name). It's possible that the 0 value is breaking something, but I would expect that to happen every time if that were the case. I'll try it out though. Edit: Nope, that didn't help. Not that I expected it to based on the error log. That error is typical when someone isn't being careful about modifying a list of something while enumerating through each element of the list. Which is exactly what KSP appears to be doing in the part's destroy method.

Is there a completion message in the little notifications window? There should be something if it completed. There should be something in the log file about it being completed, too, if you haven't already started KSP again. Also, Contracts Window + has some logic for automatically removing completed contracts, so it's not always necessary to actually click the "x" remove button.

Yeah, I'll probably get around to adding another toolbar button for that. For some reason I thought that I had fixed that, but apparently not. I guess the solution here is to stop relying on those garbage right-click menus (I really, really hope that making PS4 version forces them to come up with something better than this), use the SCANsat instruments display instead. Another thing, I'm not entirely sure what to do about Karborundum. It's not a SCANsat resource, and there is no way to display or scan for it using SCANsat. I haven't tried using it so I don't know how it works with the stock scanning mechanism, but my understanding was that you aren't supposed to be able to scan for it from orbit, you have to be very close. Does it show up on stock resource overlays at all, or is it just scanned for using a narrow-band-type scanner?

I updated the Celestial Body Science Editor; get it on Kerbal Stuff. Be aware that the installation folder has changed for this update. The old editor was placed in GameData/ScienceParamLoader, while the new version is in GameData/ScienceParamModifier. It shouldn't cause a problem to use both at the same time, the new version will simply override any values set using the old version. I spent a few hours ripping out the guts of the Contract Reward Modifier and replacing it with a much simpler system for editing the science multipliers for each body. You simply select a body from the drop down menu, input the desired multipliers into the text boxes and hit Apply. The values will then be updated for that body and stored for that save-file. If you want to use those values as the default settings for all new games (and as the values to be applied when reverting to default; you can also revert to stock values at any time), go into the settings window and push the Save To Config button. You can deactivate the toolbar button when you are done setting values if you want. Simply change the "disableToolbar" field in the config file to False if you want to reactivate the toolbar. The recovered craft data value is used by the contract system for generating rewards and other parameters, as such you have to force the option to edit this value using the settings window.

There is a contract config file in GameData/Squad/Contracts, or something to that effect. It lets you edit things like the number of each contract that can be generated, the reward values, and a few other values for each contract type. But there isn't a whole lot that you can do to customize stock contracts. Parameters can be tweaked, but the problem with the contract system goes deeper than that. I don't know what you have in mind, but Contract Configurator is your best bet for trying to improve on contracts within the existing system. Anything more would be very complicated.

Initialize engine version: 4.6.4f1 It's always the first line in the output_log file.

Anyone know how to get the actual Scale space texture drawn over the surface of the planet? It's easy to get the individual textures used for scaled space: Texture diffuseMap = body.scaledBody.renderer.material.mainTexture; //or Texture diffuseMap = body.scaledBody.renderer.material.GetTexture("_MainTex"); //Substitute _BumpMap to get the normal. //or Texture diffuseMap = body.scaledBody.GetComponent<MeshRenderer>().material.mainTexture; For the non-ocean planets this works fine and gives you the flat color map. For ocean planets you get a map that's black on the surface and clear on the ocean. Using xEvilReeperx's snippet (which I now seem to find everywhere after I know what it is...) I can use the material to get ocean planet textures that look right in some cases. Also note that you need to use Apply() to the final texture before you can actually use it, you could do that with the texture returned by that method, or before the last line in that snippet: finalTexture.Apply(); var renderer = body.scaledBody.GetComponent<MeshRenderer>(); var diffuseMap = renderer.material.mainTexture; var finalTexture = new Texture2D(diffuseMap.width, diffuseMap.height); var rt = RenderTexture.GetTemporary(diffuseMap.width, diffuseMap.height, 0, RenderTextureFormat.ARGB32, RenderTextureReadWrite.sRGB, 1); Graphics.Blit(original, rt, renderer.material); //Note the addition of the material using a different overload here RenderTexture.active = rt; finalTexture.ReadPixels(new Rect(0, 0, finalTexture.width, finalTexture.height), 0, 0); RenderTexture.active = null; RenderTexture.ReleaseTemporary(rt); finalTexture.Apply(); GUI.DrawTexture(Rect, finalTexture); This will give a texture for Eve that has the right color and looks like it has some specular shader applied. Kerbin and Laythe are still screwed up, but in a different way than before. The other planet textures look no different from the flat diffuse map. So is there some way to have the normal map applied to the diffuse map? Or does that even work without some 3D mesh to wrap it around and apply a light source to? And any ideas about what makes the Kerbin and Laythe scaled space maps different?

What do you mean by not getting resource scanning to work? Do you have Module Manager installed? It is necessary for resource scanning. For the resource settings see here. Using the surface scanner works exactly the same is with stock resource scanning; you will get less accurate results for resource abundance until you scan each biome from the surface, or you can turn off the resource biome lock and ignore that aspect of it completely.