DMagic

@paranoider.ninja Did you turn on the scanner? According to the small map in your screenshot you only have the low resolution altimetry scanner and the multispectral scanner active. Your resource settings are correct for using SCANsat-style scanning for resources, but you need to deploy the M700 scanner (so the dish is open) then start the resource scan. Sometimes you might have to retract and re-deploy the scanner to get the correct options to show up if you change the SCANsat resource scan settings. Either that or re-load the scene.

@Mattasmack It currently only works with KAS 0.6. When that is replaced by KAS 1.0, then this will have to transition. It would help if someone who knows the new system could explain how the equivalent functions could be performed (connecting multiple parts into one vessel on the surface using some type of hose/pipe).

I think setting the value for the Available Part prefab to should work. (0 is full, 1 is none). part.partInfo.partPrefab.PhysicsSignificance = 0; That should make any new copies of the part, anything that is spawned in the editor after making that change or anything that is loaded in flight, behave as a normal part. There is also part.PromoteToPhysicalPart(), you might have to call that on the available part prefab before it works right.

@KerbolExplorer Just post the KSP.log, no need to go digging through the appdata folder to find the output_log file. What version of SCANsat are you using? A MissingMethodException implies that there is a mismatch between KSP and SCANsat versions.

Version 9.2 is out; get it on Space Dock. It prevents the window from always opening on scene load, even if you had previously turned it off for that scene. It also prevents you from switching to progress node display mode during loading, which can interrupt the loading process. This takes place over about 1-2 seconds immediately after a scene loads, so you would have to try pretty hard to switch modes fast enough for this to matter anyway.

@Tonka Crash Whoops, that's what happens when you change a 1000 things then stop working on it for several months and forget what remains to be done. Version 9.1 is out; get it on Space Dock. It fixes contracts and parameters not updating. The code for all of that was already there, it just wasn't implemented . Contracts and parameters will update their states when they should, changing text color, displaying/hiding sub-parameters, updating contract/parameter titles. It also fixes some new and old bugs with window positioning. It will now work properly when dragging the window around the screen; it clamps the window to the edges of the screen to prevent it from getting lost (it only leaves a fairly small portion of the window on screen if you drag it all the way into a corner, so be aware of that). It also checks if the window is on-screen when loading (it was doing that in the last version, too, it just didn't actually do anything about it if the window was off-screen). The thing with the window being blank isn't entirely new, it just seems worse than it was before. I've fixed it so that it uses an older method for masking the contents of the scroll view (the part where all of the contracts go). It's less efficient when you have a large number of contracts displayed, but it should get around the problem of the window being blank.

Version 9.0 of Contracts Window + is out; get it on Space Dock. It is updated for KSP 1.4.5 and for version 10 of Progress Parser (@Tonka Crash, this fixes the problem you are seeing). Only versions 1.4.4 and 1.4.5 of KSP are supported. It contains a major overhaul of how contract data is loaded and displayed in the UI, among many other, mostly internal, changes. This results in better performance and less garbage generation when switching between different contract mission lists or between different window modes. It also has changes to make sure that all contract mission data and contract data is fully loaded before initializing the window.

CapCom version 2.9 is out; get it on Space Dock. It is updated for KSP 1.4.5 and for version 10 of Progress Parser. Only versions 1.4.4 and 1.4.5 of KSP are supported. This fixes some errors that causes a lot of log spam to be generated whenever a scene was loaded. It also ensures that the progress logs for discovering anomalies will display correctly.

I should have an update for this (and CapCom, there were some changes to how Progress Nodes are handled in 1.4.4) today or tomorrow, now that there is a semi-not-broken version of KSP to work with. It will drastically improve the performance (remove the little stutter or delay) of switching modes or contract lists and has a much more robust loading method that isn't susceptible to weird timing issues that might have been causing elements of the mod to be loaded in the wrong order (which would generally result in everything being reset). But there are lots of changes, as the backend of how contracts are loaded and displayed has essentially been re-written, so it may take a while to test everything.

You can't use Unity as a 3d modelling program. It's just an awkward step between making the model and getting it into KSP. An official plugin for Blender/Maya for exporting directly to .mu files would be great. Anyone who just cares about making parts wouldn't have to jump through the extra hoops of downloading Unity (a fairly large program, without about a thousand different versions), dealing with the KSP Part Tools (which people frequently run into problems with when installing), and learning Unity's interface, which is just different enough from some modelling programs to make it difficult. KSP already allows for re-loading of part configs from in-game. It's just a matter of allowing for a method to specify a specific config to reload, rather than doing all of them. It's not (easily) possible to allow for code changes without restarting KSP, but simple config changes are not a problem.

SCANsat version 18.7 is out; get it on Space Dock. It is updated for KSP 1.4.5 but should work fine on other 1.4.x versions. It fixes the problem with lat/long coordinate displays and includes Russian translations of the contract text by RarogCmex. @tsaven I think that was supposed to be fixed by version 18.0. Are you using MKS by itself or with KSP Interstellar? You can check the SCANsat files to make sure they have the right values. In GameData/SCANsat/Resources/SCANresource.cfg the last entry should be for Silicates: SCANSAT_SENSOR { name = Silicates SCANtype = 268435456 //2^28 } and in GameData/SCANsat/MM_Parts/SCANsat_Resource_Scanner.cfg look for the tags for @PART[OrbitalScanner], that's the Narrow Band Scanner. It should have the patch to adjust the resource scanner module: @MODULE[ModuleSCANresourceScanner] { @sensorType += 301048960 @scanName = Resource Scan } That sensor type is for all MKS resource; it includes the Silicates type and was added in version 17.something. It should also have the SCANresourceDisplay module for Silicates, but that seems to be there since it shows up in your right-click menu.

Basic Orbit version 8.2 and Basic DeltaV version 3.1 are out; get them on Space Dock. They work in KSP 1.4.5, but should also work fine in any 1.4.x version. Both have some minor performance improvements aimed at further reducing garbage allocation. This is primarily accomplished by only updating one panel for each frame, instead of updating each panel on each frame. So if you are using Basic Orbit with a target selected and a maneuver node planned, with all three panels open, then it will go through one panel each frame and update it. If you only have one panel open it will update it every frame. The same is done for Basic DeltaV. This basically means that there is no difference in terms of garbage allocation for having more than one panel open at the same time. It cuts the already very low garbage allocation levels to about as low as you can get without doing some really crazy things with string allocations (converting a number to a string always allocates garbage, there are ways of getting around this, but for desktop usage it's a little bit over the top). Basic DeltaV also now stores the activation state of the panels separately for flight and the VAB/SPH. So you can turn them off in flight (without disabling them in flight completely, using the in-game settings menu) and not have to turn them on again when you go back to the editor.

@c4ooo You can use the similarly brute force GameObject.FindObjectsOfType<NavBall>() to get the NavBall instance (it might not be active or present immediately after a scene loads, so you may have to wait a bit to do this). But I don't know about how accessible or not the target vectors are.

@Doxel For unloaded vessels you have to check the protovessel situation: vessel.protovessel.situation, or something like that. It should give the correct value, though I'm not sure if it gives the correct value for a loaded vessel, so you might need to check if the vessel is loaded before checking its situation.

I think OnCrash is when a vessel crashes into another vessel. Maybe other things too, like buildings. Have you tried onVesselWillDestroy? That might work. Though it might require waiting a frame or two for the vessel to actually be removed. I know onVesselDestroy is not what you are looking for. That is fired when the vessel monobehaviour is destroyed, passing out of loading range would trigger it.

@ExtremeSquared You can do that or just delete the DataTransmitter module if you want to get rid of it completely (though if you do that you should set the ""noAntenna" field in the DMSIGINT module to true). @Reverie_39 All of the contracts require certain parts to be unlocked before they are offered, these are generally required for the contract in question. Some of them also have some other simple requirements like orbit Kerbin at least once, or escape Kerbin orbit, or, for the asteroid contracts you have to upgrade the tracking station.

@JoE Smash If the SAR 15 has the right part modules in its config then it can act as either an M700 scanner (stock resource scan), a low res SCANsat resource scanner, or both, depending on your settings. And maybe also a hi res altimetry SCANsat scanner. In any case, the scanning modules attached to that part should be specified in the VAB part icon tooltip. There are two options related to this in SCANsat. One is to simply disable instant scanning, this will allow you to use the part as a SCANsat scanner, but will not effect the stock functions (disable instant scan here refers to disabling instant resource scanning for SCANsat maps, not disabling it for stock). The stock scan won't affect SCANsat maps in any way with this the instant scan option disabled. The other option is to disable stock scanning altogether. This disables the stock functions of the M700 entirely, so that you can only use SCANsat to scan for resources (you can still trigger the stock resource scan by completing enough of the SCANsat resource scan, in case there are contracts or other functions related to stock resource scans that you rely on). For these parts to trigger the SCANsat contract availability you would need to modify the SCANsat contract configs. Specifically the Exceptional.cfg (for hi res altimetry) file, or the Significant.cfg (for the resource scans) file in the GameData/SCANsat/Resources/Contracts folder. These nodes specify which parts need to be unlocked to allow the contract to be offered: REQUIREMENT { name = PartUnlocked_1 type = PartUnlocked part = SCANsat_Scanner2 } I'm not sure about the specific Contract Configurator syntax required to allow for different part unlocks to allow for the contract to proceed. Edit: Looking at the part config for the CAE-SAR15 it looks like it has both of the orbital stock resource scanner modules, but only the SCANsat hi res altimetry scan module. You could add these modules, or some variant of them, to add the SCANsat lo res resource scan function to the part: MODULE { name = ModuleSCANresourceScanner sensorType = 524288 fov = 5 min_alt = 15000 max_alt = 1000000 best_alt = 150000 scanName = Resource Scan RESOURCE { name = ElectricCharge rate = 0.5 } } MODULE { name = SCANexperiment experimentType = SCANsatResources }

@4x4cheesecake You might want to clean out everything and start over. That interval between the min and max heap is definitely not normal and will make KSP basically unplayable. And it makes diagnosing any problems with click through blocker very difficult. The earlier screenshot shows a min of 1703MB and a max of 1706MB. That means that Unity has allocated 1706MB of RAM for the heap (which is a lot, but more or less normal for KSP), but when the GC runs it only finds 3MB of unused memory to clean up. That's an amount you might expect for mobile, where you might have 15MB allocated to heap memory, but not for KSP. With so little overhead Unity should be asking for more heap space, but based on your second screenshot that seems to be immediately filled up, too, which is also not normal. You might try installing GC Monitor, which can show the absolute memory usage for the heap, instead of just the allocation rate. That would show if there is some continual increase in the total space reserved for the heap. But, again, it's not normal for there to be such a small interval between the min amount used and the max amount of space reserved.

It seems like you are having some weird memory problems. The GC is constantly running because you have basically no padding for the heap memory, the min amount is 1703 MB and the max is 1706 MB (the garbage allocation from the KER windows alone will be enough to fill this up basically every second). There should be at least several 100 MB between them unless you are running out of RAM. Do you have some weird settings for MemGraph that is cutting the padding to nearly nothing?

@Victor3 Maybe screenshots of what you are seeing would help. As 4x4 said, there is no saving to be done, once you scan an area with a SCANsat part it is scanned. You just have to open the map and select the right map. You might have to switch the map to the right planet/moon and/or to the right type (altimetry, slope, biome). In flight you can open either the big map (with all of its options to show each planet and map type), the small, fixed size map (which will only show the planet you are currently orbiting), and the zoom map (you can use the little vessel button in the top-left corner to center that map on your current position). In flight you can also use the map overlay window to draw the maps directly over the planet surface (this may not be visible in the regular flight view if you are too close to the planet, switch to map view to always be able to see it).

@c4ooo You have to specifically tell it not to be destroyed. private void Awake() { DontDestroyOnLoad(gameObject); } Put that in the MonoBehaviour you are creating and it won't be destroyed unless you do it manually.

@Victor3 I have no idea about the Best Orbits, they are probably out of date anyway. There are instructions on how to find a good enough orbit in the KSPedia entry. Scanning data is saved along with your save file, it doesn't care about what scanners are where, or whether they are active or not. Once an area is scanned then it stays that way. When in doubt, just try something and see what happens.

@canisin That's the expected behavior. Like I said, they are meant to be operated by a Kerbal.

@canisin How are you trying to check the results? You need an EVA Kerbal to do most interactions with the instruments. @JoE Smash Kerbin Side uses a different system to place objects on the surface. It is the same as that used for all of the stock structures, KSC, launchpad, anomalies, etc... Those aren't the same as parts. I'm sure that there are ways of making sure that parts attached to the surface are more secure, but that is something that would be done by KIS.

No. Colliders are what allow you to click on the part and are used when attaching the part to anything else. Without them the game has no way of knowing when the mouse is over the part, so you can't select it or do anything with it. And colliders are used by stock KSP, and I assume KIS when you want to attach the part to anything other than a connection node. I think the problem lies in attaching the part to terrain of a planet. The terrain is not like any other physical surface in the game (including launchpads and runways, which are not physically part of the terrain). It uses a different type of collider, and is procedurally generated based on the planet's height map, the terrain detail settings, how close you are to the surface, and probably a bunch of other things. So it's not terribly surprising that there are problems that arise when you have a collider attached to the terrain surface. The physics engine tends to freak out when colliders are forced together in some way (that is how some of the wackier bugs that streamers sometimes find work; basically breaking the physics system) and I think KSP (and maybe KIS) has many systems that directly involve trying to prevent vessels and parts from freaking out when you load something on the surface.