DMagic

@Windspren Does it still have two copies of the plugin files? Where did you download SCANsat from? In any case your log file is filled with errors so it's hard to isolate any one problem. SCANsat is failing to load its UI (I can see no reason why, other than that it's trying to do so twice, since it's failing at a point where SCANsat is looking through some of the stock KSP UI for a few components), so it prevents basically anything from working. If having two copies of the plugin files isn't the problem, then something else is breaking KSP.

@Laythe Dweller You seem to have two copies of the SCANsat plugins installed: [LOG 10:02:17.917] Load(Assembly): SCANsat/SCANsat [LOG 10:02:17.917] AssemblyLoader: Loading assembly at D:\Kerbal Space Program\Kerbal Space Program 1.3.1\GameData\SCANsat\SCANsat.dll [LOG 10:02:17.919] AssemblyLoader: KSPAssembly 'SCANsat' V1.8 [LOG 10:02:17.920] Load(Assembly): SCANsat/SCANsat.Unity [LOG 10:02:17.920] AssemblyLoader: Loading assembly at D:\Kerbal Space Program\Kerbal Space Program 1.3.1\GameData\SCANsat\SCANsat.Unity.dll [LOG 10:02:17.922] Load(Assembly): SCANsat/Plugins/SCANmechjeb [LOG 10:02:17.923] AssemblyLoader: Loading assembly at D:\Kerbal Space Program\Kerbal Space Program 1.3.1\GameData\SCANsat\Plugins\SCANmechjeb.dll [LOG 10:02:17.938] AssemblyLoader: KSPAssembly 'SCANmechjeb' V0.5 [LOG 10:02:17.939] AssemblyLoader: KSPAssemblyDependency 'SCANsat' V1.8 [LOG 10:02:17.939] AssemblyLoader: KSPAssemblyDependency 'MechJeb2' V2.5 [LOG 10:02:17.940] Load(Assembly): SCANsat/Plugins/SCANsat [LOG 10:02:17.940] AssemblyLoader: Loading assembly at D:\Kerbal Space Program\Kerbal Space Program 1.3.1\GameData\SCANsat\Plugins\SCANsat.dll [LOG 10:02:17.943] AssemblyLoader: KSPAssembly 'SCANsat' V1.8 [LOG 10:02:17.943] Load(Assembly): SCANsat/Plugins/SCANsat.Unity [LOG 10:02:17.944] AssemblyLoader: Loading assembly at D:\Kerbal Space Program\Kerbal Space Program 1.3.1\GameData\SCANsat\Plugins\SCANsat.Unity.dll I would start with deleting and reinstalling SCANsat from scratch. Otherwise, if the toolbar doesn't show up it's generally because it got turned off in the main settings window. If the Toolbar mod isn't installed then the only way to open the windows is by starting a scan from a scanning part. Or you could open the settings file in the SCANsat/PluginData folder and change the toolbar setting value to true.

Not unless something has been changed recently. That value, and the others related to closest target approach, is actually one of the more complicated bits of Basic Orbit (not too complicated though, since KSP added in some accessible methods for calculating that information in 1.2).

/ksc is the command for a waypoint at the KSC, though I'm not sure where it actually puts it. /waypoint puts it at your current location, but you can also use "/waypoint kerbin lat long" to put it at a specified location, which I assume puts it at the surface. So you could pretty easily make a simple mod for generating waypoints at specific locations, like the launchpad, either end of the runway, the VAB roof, etc... Actually, I think you can add in your own commands to the console log, but maybe a separate UI would be easier to use.

You can generate a waypoint at the KSC with the debug menu. Just type /waypoint ksc, or /waypoint-ksc, or something like that (/help should tell you the available commands) into the debug console and press submit. /waypoint will generate a waypoint at your current location.

Version 1.3.11 is out; get it on Space Dock. It is updated to support the latest version of Module Manager when using Universal Storage and/or the Community Tech Tree. It also fixes the agency title, updates the stock survey contract titles to match the actual experiment titles requested, and changes the method used to detect orbital parameters for the magnetic field and reconnaissance survey contracts. @insert_name Sun survey contracts should only generate for 3-star contracts, which seems fair given the difficulty of reaching low orbit. It also serves as a nice reason to actually get to low solar orbit. But if you don't want to do those contracts, just make sure not to accept them.

All three of these mods have been updated: Basic Orbit has new options to specify label and readout text color, which can be found in the settings file (you'll have to run KSP once before the settings file is generated). The two new fields at the bottom can be used for color using standard, 0-1 RGB values. It also fixes an error displaying periapsis while in atmospheric flight. Basic DeltaV also has options for text color, and it changes the default crew requirement skill to AutoPilot instead of Repair, this will only affect new or clean installations where the settings file is deleted. Maneuver Node Evolved has been updated to fix some potential errors that would allow multiple UI windows to be opened then orphaned and unable to be closed.

I think I remember them adding a simple way to access those icons somewhere, but the only thing I can find is this dumb way of searching through all of the loaded textures to cache the updated icon atlas: https://github.com/S-C-A-N/SCANsat/commit/01f37a1dab046e7ce9b3ffadfaa09231526eb38a#diff-05a39d3cea4503e4a4e34e8be5fde470 I think the layout of that atlas is the same, it just has the new vessel types added. @JPLRepo might be able to help.

@DStaal That would help fill in those gaps at the pole quickly. What I really need to do is change the scanning coverage calculations so that they measure actual surface area scanned, rather than a percentage of a rectangular map. The way it's currently setup gives way too much weight to the high latitudes. Changing that would lessen the need to worry about those gaps in the first place.

@TaintedLion There used to be some ideal orbit calculators around, but they were only setup for the stock planets and I think are out of date because of some changes to the stock planet orbits, so you would have to figure out how to calculate them yourself. But really, it's usually not very hard to get into a reasonable orbit, there are some basic instructions on the wiki and the KSPedia entry. The only real problem is planets or moons that rotate very slowly, but there isn't much you can do about that, they just take a long time to scan.

@maja I'll update soon to fix the MM problems. @Stratickus Orbital Science contracts predate Contract Configurator, so they don't use it in any way. In the Resources folder (GameData/DMagicOrbitalScience/Resources) there is a DMContracts.cfg file that allows for modifying several aspects of the contracts, either through MM patches or directly editing the file. It is setup in a similar manner to the stock contracts config file, and at the top of each contract section are values for the max number of contracts that can be offered or active at the same time.

You can do that, or, if you really want to avoid unnecessary checks in the Update method you can attach a little listener script to the UI window prefab. The script then fires an event whenever it is created alongside the part action window, then your Part Module can subscribe to that event to turn on whatever it needs to update the field. Script: https://github.com/CobaltWolf/Surface-Experiment-Pack/blob/master/Source/SEPScience/SEP_UIWindow.cs Code to attach the script (just run it sometime after the flight scene has started): https://github.com/CobaltWolf/Surface-Experiment-Pack/blob/master/Source/SEPScience/SEP_Utilities.cs#L131-L142 Part Module subscribing to the window creation event (just a simple Game Event defined at the top of the previously linked file) with the methods to check if the window belongs to its part, and the code in LateUpdate to fiddle with the window (adding an EC counter to a part clicked on while on EVA): https://github.com/CobaltWolf/Surface-Experiment-Pack/blob/master/Source/SEPScience/ModuleSEPECViewer.cs

@Phoenix84 What version is this? There were some problems that were supposed to have been fixed, but it's possible that something else is going wrong and preventing the windows from closing when you click the button again. Do you have log files? It's possible that something is interrupting the window opening process and preventing them from being recognized as actually open.

This definitely doesn't look right, that's 100 nanometers. Is the probe controllable? I have no idea why it would come up with that value, but I guess it could potentially either cause problems on its own, or signal some deeper issue that's tripping up CommNet somewhere. The methods used for checking the Comms path (where the log indicates it's freezing) do involve some loops, so it's possible something is causing it to get stuck there. @LaureeGrd It will work with RemoteTech, it just won't respect any of RT's connection status. It will basically just assume that data can be sent to any vessel with a valid science container.

You can do the same thing with KSPedia or a UI project. Just make one Canvas then add everything under that object and disable all but the page you are working on. The asset exporter doesn't care about how things look in your hierarchy window, or even if the scene is loaded, it only works from the prefabs you have saved on disk.

What Stone Blue said, but you can also have objects above the ones containing the Part Tools, so: - Scene Engines Engine 1 (w/Part Tools) Child objects Engine 2 (w/Part Tools) ... Tanks Tank 1 (w/Part Tools) ... That way you can organize things better if you have a log of parts You can disable the top level empty gameobject to hide all of the parts below it, or collapse it so you don't see them in the list.

Yes parts will overlap, but you can disable all but the one you are working on. In the upper left corner of the Inspector window tab there is a little checkbox that will disable the currently selected object (and all of its children). I use that to focus on one thing at a time. And if you want to look at multiple parts at the same time for whatever reason you can move them around, just make sure to move them back to 0,0,0 before exporting them. Keeping everything in one scene means that you never have to load scenes when switching parts, depending on how you work it could be a minor problem, but I always like having everything in one place whenever possible. You can also create a more complex hierarchy of parts in a scene, essentially making "folders" using empty game objects (right click on the hierarchy window to make a new empty object). That way you can keep your scene more organized if you have lots of parts. As long as the Part Tools script is added to each individual part (the object created when you drag the model into the scene) then it doesn't matter how any upstream objects are organized, it just exports from the object that the script is on.

Making separate projects for each part seems like a nightmare for anything more than a handful of parts. Doing any work would required constantly opening new instances of Unity to work on a different part. And each project takes up a fair amount of space just by itself, several 100 MB I think. Separate scenes is ok, but I don't see any real reason to not just have all parts under the same scene. As long as you are careful and don't have things like parts parented to each other it shouldn't be a problem. Just turn off the parent object for whichever parts you aren't working on at the time. If you have a lot of parts it might make sense to have groups of related parts in separate scenes, maybe something like having all parts that share a texture map in the same scene. I'm not sure why loading time would be much of a problem. You just open Unity once and everything is there. I've never noticed a significant difference in Unity loading time based on project size. But really, the best option is whatever works best for you.

@Rodhern There was never a separate wrapper or description for accessing SCANsat data, but there is a small API in SCANsat that allows for somewhat easy access to the scanning data. It's designed to work through reflection so that you don't need any hard dependencies. The first section of this class has commented methods for external access to SCANsat. Contract Configurator uses this to check scanning coverage: https://github.com/jrossignol/ContractConfigurator/blob/master/source/ContractConfigurator/Util/SCANsatUtil.cs And Kerbalism uses it to start and stop scanners based on background EC usage: https://github.com/ShotgunNinja/Kerbalism/blob/master/src/External/SCANsat.cs

@Noromier It replaces the existing file in the GameData/ScienceRelay folder. @wile1411 Do you have a vessel with that name somewhere? KSP seems to think you do, and Science Relay filters out anything marked as debris, flag, unknown, or spaceobject (asteroid). If not, then can you send a copy of your save file? Maybe there is some corrupted vessel entry that's causing problems. In any event that log helps to narrow down the problem to the point where it's checking the network pathway between the source vessel and each other vessel. While I can't do much about the method itself, I might be able to check something about the vessel to make sure it won't cause a problem by running that method.

@Kerbal101 For Basic Orbit it looks like I missed a check for the periapsis while in atmospheric flight, it will only show up when your periapsis is above 0. For Basic DeltaV what do you mean by toolbox background? The toolbar button window, or the panels that appear alongside the staging display? And the text flickering is normal, I think it has to with reordering the readouts whenever something about the vessel is changed; unless you mean something different.

@Noromier @wile1411 I've been trying to trigger the error using the common mods in your lists, in addition to Kopernicus, OPM, MOLE, and CommNet Constellation, but I'm not seeing anything. I've tried it with a variety of vessels and connections, and even after collecting, transmitting and recollecting data dozens of times, from different vessels, and in different situations, I still never see a freeze. Here is a link to a modified version of the assembly with a lot of extra logging. It basically logs each step of the connection check for each vessel, which comes out to a lot of lines, so it may cause some stutter when the science results window is opened: https://www.dropbox.com/s/tsesw0e8hgpz7uk/ScienceRelay.dll?dl=0

@Brigadier Existing SCANsat contracts will probably disappear (I think CC will complain in the log files when it's loading), and you won't be able to redo any equivalent contracts since the scanning has already been done (unless you want to reset scanning data), but otherwise it shouldn't have any effect.

SCANsat version 18.2 is out; get it on Space Dock. This version completely overhauls the included contracts (Contract Configurator is still required for all contracts). They are now organized based on difficulty: One star contracts are generated for home-system bodies only and ask for one scan each Two star contracts are generated for non-home-system bodies and ask for a group of scans Low resolution altimetry, biome, and M700 resource scan (this can still be completed if you are using stock resource scanning, it just might not update right away) Generated for bodies that you have already orbited Must not have already completed all of the scans Three star contracts are generated for non-home-system bodies and ask for a different group of scans High resolution altimetry, and Narrow band ore scans (also should work fine with stock scanning, just scan once with the M700 and it will cover all resource types) Generated for bodies you have orbited or that KSP determines are "next" on the list of planets Some potential bug fixes and errors related to the survey contract waypoints updating (these are for survey contracts where each waypoint is generated one after the other) have been addressed. Also a KSPedia button has been added to the top of the Settings window. It will open to the SCANsat page if you have already opened KSPedia in the current scene, otherwise it will just open to the first entry (KSPedia doesn't load anything until the first time it is opened). A bug with the background scanning toggles in the settings window has also been fixed, along with some minor UI performance tweaks. And some improvements have been made to the slope maps. Before they did not take the map scale or zoom factor into account, and so were generated expecting that each pixel on the map would represent a very large area of the surface. This has been fixed. Here is the difference zoomed in at the KSC with the slope cutoff all the way down (this reduces the slope level at which the brighter colors are applied): And here is one on the Mun, where you can see these weird terrain artifacts appear in the map. These lines and patterns in the terrain are real and fairly obvious if you just zoom out a bit while on the surface, I only noticed this square pattern on the Mun, presumably it has something to do with the crater generation system:

@Psycho_zs Those values can't be changed, the translation and rotation values are baked into the part models, they are specified in the part config file just because that's easier than hard-coding them or making different part modules for each size. I believe increasing them might actually decrease the amount of rotation applied, but I'm not sure. I actually have a method for significantly increasing the allowed rotation, to about 30 - 35o, but it somehow screws up the positioning and rotation math, so I decided it wasn't worth the effort to implement it. @Noromier @wile1411 Can you send your mod lists. I think I have a few other lists with the same problem, so I might be able to combine them and narrow it down to a reasonable number of mods.