DMagic

Yep, biome maps for every planet

Considering that all of my science instruments already have reports for the default Custom Biomes set it shouldn't be too much trouble to update those results for the new stock biomes.

Why wouldn't it? It doesn't really care what the biome map for a planet looks like, only that it exists.

A few updates on this. I've made a very rough mockup of a new contract configuration window, something that would allow you to tweak the reward/penalty amounts as well as a few other options for each contract type. In principle this is fairly simple. Just watch for new contracts and adjust their values as needed. I haven't implemented any of that, and I would need to take into account strategies, but this should work fairly simply. Any changes to the rewards etc... for any contract would take place after other types of configs (ie FinePrint's config file, which adjusts values while the contract is being generated, not after), but there is no reason why any mod Contract type and/or Parameter type shouldn't be adjustable. This is a mockup of the config window, the new button on the main window is used to open it. All of the contract/parameter rewards/penalties are adjusted with some kind of mutant log-scale slider. From 0-100% is linear, from 101-1000% is log scale, to push the less useful, really high amounts together toward the right side. This allows for easy adjustment of all these values. Along the bottom are sliders to set the max amount of contracts offered for a given type (contracts offered after reaching this amount would just be deleted before you ever see them, hopefully), and to adjust the max amount of active contracts of that type and its duration once accepted (obviously some special cases will be needed for the contracts that don't expire). Each contract and parameter type can be selected through two scrollable drop-down menus. Obviously many improvements need to be made to the UI and to make the options clearer. But this should provide a nice, graphical interface to adjust all contract and parameter types, stock and addon. These will also be save-game specific, so you can make separate configurations for each game (and I might make a global config file, so that you can adjust the baseline settings for everything, rather than resetting them for every new save file). Nothing has really been implemented yet, so this probably won't be coming until after 0.90. I have also been thinking about adding some kind of indicator for the contracting agency as has been requested several times. I'm thinking that some kind of pop-up window, similar to the part preview window in the editor, could be used to display the agency and flag for each contract without needing to stuff all of that info into the main window somewhere.

SCANsat Version 9 release candidate 3 is out; get it on GitHub The primary changes were mentioned a few posts back, and a full changelog is available in the first post. The in-flight big map has been replaced by an improved version of the KSC map. All resource options are now controlled through the big map and most text boxes have been replaced by icon textures. Improvements have also been made to the color selection window UI along with an additional, fixed-size color palette type to use. Let me know if anyone runs into any problems.

What is the anomaly scanner doing at this point? Are both the rotating dish and moving camera deployed? Are the signal lights active? Does anything get printed out in the debug log? The only way to force this to complete if the anomaly scanner isn't picking up anything is through the debug menu. I know the anomaly you mean. If it's floating too high it might not be possible to get results from the anomaly scanner while on the ground. That alters the science reward for all of my contracts. The required science value can always be bypassed by returning results to Kerbin.

Possible? Yes. Likely? Not anytime soon. The first thing that needs to be done is to convert the resource overlay into a separate RGBA texture, then it can simply be toggled on and off without having to rebuild the entire map each time. But I won't do that until I can improve the memory usage of the big map, because adding a separate texture means more RAM being swallowed up. Layering resources is certainly possible, but it introduces lots of practical issues. Simply finding colors that don't conflict is one issue; using RGB for three resources is a solution, but then it makes gradients difficult. There would need to be an interface for selecting multiple resources, and determining how many can be shown at once, and making sure there's space for the map readout for each resource. This would also be very slow on bigger map sizes, since it would need to go through the calculations multiple times for every pixel.

A new update is approaching. This will complete most of the UI work, at least for the time being. The primary change is adapting the KSC map to the standard, in-flight big map. All of the elements from the KSC map are present in the new big map, including the resource selection drop-down menu, and the planet selection menu (this one probably still needs some work to ensure that it doesn't give errors). All of the resource overlay selection will now be handled through this menu; everything from the settings window has been removed (except the non-functional Kethane database rebuild button). The in-flight map can also be re-sized the same way as before; the zoom map is also present here and has been added to the KSC map. All of the overlay toggles along the left side of the map have been moved from text buttons to icons with tooltips (that can be deactivated through the settings menu), I think these icons are generally clear and work well enough at high dpi (I tried everything at 1080p on a 10.6" screen and 1080p on a 30" screen). A new set of icons have been created for all of the SCANsat windows as well, these are used on both the big map and the small map to open the other windows (instruments, settings, color, big/small map). The color palette management window has also been improved. The text input boxes have been replaced with sliders to control the terrain height range and palette size. A new set of color palettes has also been added (I'm still deciding which to include for the release version), these are fixed size palettes, some of which give a more atlas-like look to the maps. Regolith support will come whenever it is released in the next SCANsat update (v9rc4), probably after 0.90 is released. ORSX support will be dropped at that point. We'll see if the Kethane problems are fixed at that point too.

I think the version problem depends on whether the assembly version number actually changes for the assembly you are referencing, but I've never been very clear on this stuff. I suppose you could try to handle everything through reflection, but I'm not sure how practical that is. The event needs an "active = true" argument on the first line. I think they are all active = false by default. guiActive just means that it will show up in the right-click menu whenever the event is actually active (there are other options to allow visibility when the part isn't on the current vessel or when you're on EVA).

Is this only an issue for the multi-spec? The biome scanner won't show anything on the small map, so it's expected that it will remain blank. The indicator color could be wrong, it's showing 100% scanning (which only accounts for currently active scanners), so the terrain is being scanned. The right-click context menu indicator is based on a much simpler system that is less likely to have bugs and should be correct. If the RADAR or SAR has the same problem and nothing is displayed then there is a more serious issue.

Sure, I have. Go to Kethane's GitHub repo, get the source for Geodesic Grid and Kethane, rebuild both of them, then rebuild SCANsatKethane pointing at the two newly created Kethane assemblies, then put all of those new files in your GameData folder, overwriting the old versions and you're good to go. Except the Geodesic grid code sometimes acts weird when I build it, so it might also break in exciting new ways.

OnVesselRecoveryRequested triggers in-flight when you click the recover button at the top, but not when recovering from the Space Center. OnVesselRecovered triggers after the recovery summary pops up. OnVesselRecoveryProcessing (or whatever it's called) triggers before the summary appears, but it is also used to trigger all of the stock recovery methods, so I'm not sure that it will let you actually interrupt anything. You can, however, change the amount of science/funds/rep after the vessel is recovered. This is kind of clunky, but if you just want to alter or remove the recovery amounts it works.

The only way I've been able to do this is by simply replacing the Unity window background texture with something that has lower transparency. Most of the Unity default skin textures are very simple and you can create something to replicate it fairly easily (the Unity skin set is available to download on the Unity store I think, if you want to have it for reference). Then you have to load these textures and create new GUIstyles using your new textures as a background. There's probably some really simple way that I'm missing though...

There isn't an actual GameScene for the space center buildings. Mission Control, R&D Center, Admin, and the Astronaut Complex are just UIs plastered on top of the current scene. I think there are GameEvents that trigger whenever you enter and exit these buildings though, so you can try using those.

The actual results printed onscreen are from ExperimentResultDialogPage.resultText. You can fetch the results for each experiment from a ScienceSubject ID (the experiment@KerbinSrfLanded string) using ResearchAndDevelopment.GetResults(SubjectID). The results themselves are stored in the Results dictionary for each ScienceExperiment. But that dictionary is only accessible through a read-only property (ScienceExperiment.Results). I'm not sure how you can add results to the dictionary without re-loading the science experiment definition config. And I'm not sure how to do that without breaking the science experiment dictionary used by ResearchAndDevelopment (the thing that gives the dictionary key errors if you try to load duplicate science experiments).

For right now those unlocked dual core Haswell chips might be ok. But that would only be a very short term solution. Unity 5 should eventually improve things greatly when it comes to multi-threading, so I wouldn't get anything below an i5. An i7 (or an 8-core AMD) might end up performing better at some point, but the price difference is pretty big and it's unlikely to help out that much with non-KSP things unless you have some specific use for those extra threads. So an overclocked i5 is pretty much the best choice, especially if you can find a decent deal on one. There's not much of a difference between Haswell and other Intel chips from the past 2 years, but those might be a bit harder to come by, or you might have to get one used. For video cards it doesn't take much, but I would stay away from older GPUs unless you already have one, or can get one really cheap. Even something like a GTX 750, which requires no extra power connection, can handle pretty much anything KSP throws at it. And there are some cheaper options from AMD. Also keep in mind that there are some mods that can really stress the GPU more than stock KSP, and there is always very high resolutions to keep in mind.

Saving and loading the contract list through a scenario module is no problem and gets around having to worry about manually running anything on save/load. The only problem I've run into is that it can take a while for all of the contracts to actually load and the GameEvents.Contract.onContractsLoaded event bafflingly fires before the contracts are actually loaded instead of after. My not-very reliable solution has been to simply wait a second or so after the event fires before I start trying to match up saved GUIDs to loaded contracts; it doesn't work very well...

I had it a little backwards, the ContractID is determined in part by GetHashString(). ContractGUID is just a GUID, a value that has next to 0 chance of ever being repeated, so that's the safest one to use for uniquely identifying a contract.

The first step is to delete, and burn, and bleach, and remove all trace of Tarsier Space Tech. It is broken in the most destructive of ways; there is an unofficial patch somewhere but the current release is totally unsafe to use. Infernal Robotics might also be causing problems. It is giving all sorts of errors about missing something or other; maybe this doesn't matter, but maybe it does. Next is to try 32bit KSP. x64 is a buggy mess, and if Assembly CSharp First Pass is throwing out errors then something deeper is wrong which may be explained by using x64. Edit: Well nevermind about that Windows x64 bit, Linux should be fine if that's what you are using.

What ExplorerKlatt said, did you actually run the ORSX scans? I didn't see any actual problems with ORSX integration in the log files. If everything else with SCANsat and ORSX is working ok that is the only thing I can think of. Can't say much without complete output_log.txt files. Though if you are having errors from Assembly CSharp FirstPass, a stock KSP dll, then something else is definitely going wrong.

You're looking for the unique contract identifier? Contract.ContractGUID is probably the best. It's what gets stored in the persistent file and isn't based any parameters or values of the contract. GetHashString is based (I think) on the contract title, and parameter titles and I think some other things. To make it persistent you would need to use a scenario module and just print out each GUID in a string whenever it saves. Deciding how those GUIDs are sorted and what to do with them is another matter. Edit: Also, keeping track of orbital parameters for a certain duration is fairly straightforward, it's just the details that get in the way. What happens when you dock or undock? Saving and loading which vessel is being tracked, checking if there are any requirements for the vessel, etc... Orbital Science does this in what I think is a pretty sturdy way.

Another minor update released; get it on KerbalStuff This one fixes a minor issue where Universal Storage parts were showing up in the Community Tech Tree even if that addon wasn't installed. It also adds support for future releases of the [thread=99010]Realism Overhaul Career Mode[/thread] project.

I've got my eye (and GitHub's eye) on this. Both releases should be simple to update.

I don't think the CTT is intended to provide nodes for individual addons (except maybe a handful of very large ones), but to add enough new nodes to give some more breathing room compared to the stock tree. If every addon made their own additions to the tree it would get unwieldy very quickly.

I released Version 0.9.0.1: KerbalStuff It is a small patch that should correct the contract system seizures caused by upgrading an existing career save. Nothing else has been changed.