DMagic

If people having problems could try out these updated assemblies that would help: https://www.dropbox.com/s/2emopfol0e03pv2/SEPScience.dll?dl=0 https://www.dropbox.com/s/cmeagzved3m1n9c/SEPScience.Unity.dll?dl=0 These are the SEPScience.dll and SEPScience.Unity.dll files (your browser may complain about downloading files like this). Put them in the GameData/SurfaceExperimentPackage/Plugins folder, replacing the existing files. They should fix the problems causing experiments to cross wires with each other, resulting in all experiments having the same calibration level and science data. There were some problems in uniquely identifying each science instrument and linking them up to the data on calibration, experiment, completion level, etc... If this helps then we'll see about getting a proper release.

From the looks of those videos it didn't exactly come out of nowhere. The oldest is almost 9 months old, and presumably a lot of work was done before that. Stripping out everything identifiable as KSP would be a tremendous amount of work; adapting and stripping out the same from a number of mods would be, too. I guess you could argue that the code could potentially violate copyrights, but that would be hard to prove, unless it just directly copies from KSP.

That depends on how the game is actually paused. If the Unity Time is just set to 0 then WaitForSeconds will stop running. If you use something different, like your own timer, or a frame counter, or maybe WaitForSecondsRealTime then the coroutine will continue. And if you're worried about unnecessary performance overhead make sure to cache the WaitForSeconds if you use it. So: private IEnumerator NewYears() { WaitForSeconds wait = new WaitForSeconds(0.3f); while (whatever) { //Do stuff yield return wait; } } Instead of: private IEnumerator NewYears() { while (whatever) { //Do stuff yield return new WaitForSeconds(0.3f); } } But really, all of this is probably either not worth the trouble or more overhead than just checking in Update.

@shdwlrd Do you mean SCANsat maps? Those go into the GameData/SCANsat/PluginData folder. The exact location is printed on screen when you save a map (though the message can sometimes be hidden behind the SCANsat windows - see here to fix that ) and printed in the log files. Also, I just realized that this mod is 4 years old this month. This is the first part released for 0.22 (which still functions in KSP 1.3) together with the RPWS and telescope. I think things have improved a little since then. All of the original parts have been through at least two redesigns, along with completely changing how they function.

I was baffled as to why there was nothing similar in stock when I first ran into this problem in ~0.19, and I'm still baffled as to why they haven't come up with something since then. Docking on the surface is such a known hassle, and the claw has historically been so prone to bugs that it seems like a no-brainer. And this mod took all of about 12 hours to develop (most of which time was spent figuring out the vagaries of how struts and fuel connectors work, which is something Squad developers presumably already know), so I don't think it's an issue of limited development resources.

I just line up the orbits in map view to do this sort of thing. Just center the view on Kerbin, zoom out past the orbit of Minmus, then line up the orbit of the Mun so it's flat, and line up the orbit of Minmus so the the lines overlap, then wait until the vessel at the KSC passes under the center point (you'll probably have to zoom in once the map is lined up). It can be tricky to get everything lined up right, since the map view controls are too coarse to get everything perfect, but it works well enough for me. Like this: It's not the most accurate method, but it's probably the simplest. It should work well enough for vessels, too, you just have to make sure the Mun's orbit is flat, since that represents 0o inclination and serves as a reference point.

KerbNetMode is not a PartModule, it's just a class that serves as the base for each different mode to determine how the map is actually drawn. What you would need is to use MM to add your new slope mode to whichever KerbNet part you want to have it. So, for example, in the probeCoreHex part config you would need to use MM to add to the DISPLAY_MODES node: MODULE { name = ModuleKerbNetAccess MinimumFoV = 17 MaximumFoV = 63 AnomalyDetection = 0.12 DISPLAY_MODES { Mode = Terrain,#autoLOC_438839 //#autoLOC_438839 = Terrain Mode = Slope,Slope //the second word is the translated term used for the actual display } } To generate a slope map you would need to make a new class that inherits KerbNetMode and overrides the relevant methods: CustomPass - this looks like where you would take the terrain data and convert it slope (I'm pretty sure that all KerbNet modes generate terrain data); you would have to convert pixel color to an altitude value, then calculate slope from there, or something along those lines. LocalCoordinateInfo - this is where you would get slope info for the center or cursor point to print in the KerbNet window. The problem here is that the terrain altitude data is interpolated, only every x pixel on every y row (2 or 4 pixels probably) is actually calculated, so the default terrain map is not very accurate. I'm also not sure of how you would figure out what the min and max altitude is for a given map (you would need this to convert pixel color back to altitude). I think you can disable the stock terrain data generation by setting the "doTerrainContourPass" field for you KerbNetMode class to false. Then you would have to calculate the terrain altitude data yourself in the CustomPass method, convert terrain data to slope, convert slope data to color and apply that to the map texture. Getting terrain data is pretty slow, even for the relatively small KerbNet map (that's why the stock modes interpolate the data). So you would have to balance the trade off of slow map generation with the accuracy of the slope calculation. The slope calculation itself can also be a bit math heavy, so you have to decide how accurate you want that part to be, too. SCANsat uses two methods for calculating slope, one for drawing the map, which isn't very accurate, but produces decent results: https://github.com/S-C-A-N/SCANsat/blob/release/SCANsat/SCAN_Map/SCANmap.cs#L908-L939 (this one is probably indecipherable without knowing how the map code works overall ). And the other for finding the slope at a highly localized locations, like the current vessel location or when the mouse is over a pixel on the map: https://github.com/S-C-A-N/SCANsat/blob/release/SCANsat/SCANutil.cs#L699-L753 (this one calculates the slope by comparing the altitude at the 8 points surrounding the location).

In response to the last half page of posts:

That icon atlas isn't actually used, you can see that it doesn't even have the new plane and relay icons. The actual icons are stored in a different sprite atlas, I'm not sure exactly where or what its name is.

@LEGIONBOSS FINAL just means that the MM patch is applied at the end of loading. To get it to apply to these modules you would need to add another patch for the FlexoTube modules. And there are a lot of unused customization fields for docking ports, so I don't really know what each one does, there might be documentation out there somewhere.

@LEGIONBOSS Those same fields (and all of the others for ModuleDockingNode) exist for this mod. Setting those values just makes it so that both docking ports need to be rotationally aligned, which can be a little tricky since there are no visual indicators on the docking ports. So you could set the same values for the FlexoTube module and it should work, though I've never actually tested it.

@LEGIONBOSS It should work fine, the docking port mechanics of the flexible ports are basically the same as the stock ports. What does the flexible port say when you right click on it? There should be a status field with information about whether the docking port is in Acquire mode. You can also check if the magnets are turned off, but that wouldn't stop the flexible port from reaching out for the target port. @boeserwolf93 Direct connections should work fine, but you need antennas on both vessels that are strong enough to make the connection and an un-obstructed line-of-sight between the vessels. Direct connections can also work through relays, so the source vessel connects to a relay (or multiple relays), then the relay connects to the vessel with only a direct connection antenna. It can sometimes be hard to know if there is or should be a direct connection between vessels, as those aren't shown in the map view network graph. It's also possible the vessels close to Kerbin might not always work as expected. A lot of the network code seems to work on the assumption that you are trying to find a connection between a vessel and Kerbin, so the system might be getting tripped up because it keeps finding Kerbin in the network graph, which is considered an end-point connection. That shouldn't be a problem, but it could be; it can be hard to test all of the various possible network connection possibilities.

@boeserwolf93 Science Relay gets most of its connection information from KSP's relay system. So there are probably some cases where a satellite looks like it should be connected through relays, but it might not be. Direct, line-of-sight connections between two vessels that don't have relay antennas aren't actually considered by KSP (there are really only two connection types, direct to home/control source, or a connection through relays), but are by Science Relay. So unless you have the "Require Relay" option enabled in Science Relay's settings (found in the stock difficulty panel settings), you should be able to transmit directly between two vessels if the antennas are strong enough. Again, this can be tricky, since KSP doesn't show those direct connection lines in the map view's network graph.

This mod removes the stock KSP UI elements, but does not replace all of the elements present (some of the toggle UI components, to be specific) with new versions. SCANsat relies on those UI elements being found, and when they aren't its loading process breaks. I might make some fixes to make sure those missing elements don't break the loading process, but I won't change SCANsat to accommodate alternative UIs (it will load correctly and function, but the UI will be screwed up). So, basically you can consider SCANsat incompatible with OverDrive.

Bones and armature animations work fine in KSP, but Unity doesn't understand bone constraints from modelling programs, that information all just gets dropped in Unity. To get armature animations working properly you have to bake any bone animations before exporting the model to Unity. The flexible docking ports from this mod use some ridiculous bone setups to work by simply baking several animations and blending them manually in KSP. There are some instructions in Unity for importing humanoid models to work the IK in Unity, but I don't think that translates in any way to something generic, it's just for human legs and arms. There are almost certainly ways of getting IK chains to work, at least for relatively simple cases where the joints are constrained and don't have much freedom of movement (my understanding is that long IK chains can have a large performance impact), but CobaltWolf is probably right that such information would be lost in the .mu files. I found this a while ago discussing how to set up your own IK chain in Unity, it seems somewhat similar to the wheel joint setup you have: https://www.alanzucconi.com/2017/04/10/robotic-arms/ But it would require some coding to get everything integrated and working in KSP.

@Jodo42 Nope, there is nothing SCANsat does to record where the highest/lowest points are. For stock planets you can look them up, but for non-stock planets there isn't much you can do. The big map legend will tell you what the highest and lowest points are, to the nearest 500m, I think, but finding where those points are is another matter.

I think Waypoint Manager handles showing waypoints in flight and gives a better UI for creating custom waypoints. It's a shame Nightingale wasn't able to bring in any of it to stock KSP, but I think it handles most of what this thread is asking for. What would be most relevant, though, would be the ability to add in custom waypoint locations (launchpad, runway ends, etc...) so that waypoints for those locations could be easily added.

@The-Grim-Sleeper That's a stock contract setting. It can be changed in a file in the GameData/Squad/Contracts folder. I can't remember the exact line that needs to be changed, but I think it's something obvious.

@OhioBob It only checks the position of what KSP considers the sun. So unless Kopernicus comes up with some simple way of communicating which star is the primary light source then this is likely to remain a problem.

The total mass to LEO has always seemed like an academic argument. I've heard lots of times that the fairings are about the size of a regular bus, which sounds big, but consider that an actual bus only weighs 10-15000 kg.

@OhioBob Does this system have more than one star? I can't think of any other reason why it wouldn't work, as it just tracks the latitude and longitude above which the sun is centered for a planet.

I was about to suggest just editing the actual file to see if it works properly, which would narrow the problem down to a MM syntax issue. But if that syntax works that would solve the problem.

It looks like it's not so much of a bug as an incompatibility. Overdrive roots around in the KSP UI and screws things up for how SCANsat expects things to be. I could probably prevent the error so that it doesn't completely break SCANsat, but the UI would still not be right in some areas.

@linuxgurugamer It looks like X Science (it also supports the generic DMScienceAnimateGeneric modules using a similar API) works through reflection: https://github.com/thewebbooth/KSP-X-Science/blob/master/X-Science/DMagic.cs And Automated Science Sampler works through a hard dependency: https://github.com/KerboKatz/AutomatedScienceSampler/blob/master/source/Plugins/DMagic Orbital Science/Activator.cs

@linuxgurugamer There is an API for this purpose: https://github.com/DMagic1/Orbital-Science/blob/master/Source/DMAPI.cs It takes IScienceDataContainer references and figures out which module it belongs to, as not all use the base DMModuleScienceAnimate (and some don't extend from ModuleScienceExperiment at all). It has methods for checking the biome, and situation for non-standard experiments, and a method for checking if the experiment can actually be run for experiments with extra limitations. The main method calls the internal deploy experiment method to make sure everything runs properly. And there are also several methods for things related to asteroid science. I think a few of the other science helper mods (X Science, and one of those auto-collect mods) implement it if you want to see how it is used.