DMagic

The latest GitHub release has been updated for Kethane 8.6. Older versions are not supported (I haven't tested them, but they may work). Further support for Modular Kolonization System has been added. Both ORS and Kethane-type resources should be working. The MKS Module Manager config file has been updated with the appropriate SCANsat module. There are a still a few issues, but mostly on the MKS side, the display threshold for Ore and Substrate is a little low, so they don't really show up on the map. There is also a mismatch between Kethane and ORS type resources with water. Kethane uses the resource named "Water", ORS uses "Aquifer". I'm not sure if that's intentional, but it means that the scans of one type won't be compatible with scans of the other type. For all of the other resources you can scan with either the ORS scanner or the Kethane scanner and both resource overlay types will be updated. I also changed it so that all of the scanable resource types are now displayed in the settings menu, even if they aren't actually present on the current planet. No more cheating by checking the settings menu (or looking in the resource folder).

I'll take a look at that. In the mean time, if Kethane is ever causing problems you can always delete (or move out of GameData) the SCANsatKethane.dll file. SCANsat will function fine without it (not the kethane overlays obviously), and that is the only element that interacts directly with Kethane. Edit: It probably just needs a recompile. The top three lines of the error message are referring to activating the SCANsatKethane object. This is where SCANsat refers to the Kethane.dll, so it probably just won't accept the updated version and instead crashes. I'll see about adding some kind of version check as well, so that future updates will cause SCANsatKethane to simply not be loaded, rather than just crashing.

I think that anything with the old PID parameters (ki, kp, kd) will still function as an old-style SAS. You just have to get rid of those. The stock hex probe core actually still has some of those values in its .cfg file, though they don't seem to do anything in that case, maybe it requires all three values.

If I tried to put an Advanced Animator module on the same part as a DMModuleScienceAnimate module, and added the animation to both of them, then it would be a problem (actually I'm not sure what would happen). But the Advanced Animator module on the standard, empty science bay actually doesn't do anything to my parts. I'm using model nodes so it just refers to the file location of the SIM model, it doesn't do anything the with the SIM's part.cfg file. Here's what my the model nodes in my config file looks like: MODEL { model = US_Core/Parts/US_R90_Wedge_ScienceBay/model position = 0, 0, 0 rotation = 0, 0, 0 } MODEL { model=DMagic Orbital Science/Universal Storage/US Probe Sci/modelMAG position = 0.0, 0.0, 0.0 scale = 1.0, 1.0, 1.0 rotation = 0, 180, 0 } I just add DMModuleScienceAnimate to the bottom and everything works fine. The plugin just searches for an animation in the model using the name defined in the config file. It combines all of the individual meshes into one model, and the plugin has no problem finding your Take 001 animation and my magBoom animation.

Well, it would be technically possible, but my plugin is tied together with ModuleScienceExperiment. It wouldn't be difficult to come up with something more dedicated for the non-science parts, but only if there's really a reason for it. I really do need to go through the animation part of my plugin and clean it up though, there is a lot of room for improvement, and for now advanced animator is probably better for the basic wedges.

Excellent. Now I can finally get my hands on MapOverlay.

The new Universal Storage parts are working well. I've got most of the old parts transferred over to use the new science bay. In most cases I'm trying not to change too much, just moving components around a little and touching up the textures. The RPWS has a new, more plausible mounting system though, more similar to what the telescope will have whenever I finish that one (and probably any other parts that won't stay inside the science bay). More importantly I can control everything from my own plugin, with a single part module, no need for multiple animation modules or other such shenanigans. Everything seems to working using two animations together (three in some cases), and it's setup in a flexible enough manner so that I don't need to make any new modules or change any of the existing part config files. It plays well in reverse too, waiting for the boom to retract before the doors close. After I finish with the existing parts I want to try to come up with something for the atmospheric sensor. I don't have any ideas, but I guess it doesn't need to be complicated; I just want to make a complete set of all the stock science parts. I'm also going through all of the old animations and cleaning out the unneeded keyframes. Unity adds an absurd amount of frames when importing animations, so it's probably best if I get rid of as many of those as possible.

Or just drag the mbm texture file onto the mbm2png.exe. The only problem I've run into using the converter rather than manually editing the .RAW file is that it doesn't always handle transparency well. Sometimes the texture will end up with the transparency layer applied on top with no obvious way to remove it.

Yes, I think everyone should refrain from linking to that site. My mod is on there and I can assure you I didn't upload it (though the license would permit it if properly attributed), it's also very out-of-date. I really like this pack too, but it's obviously not complete and it seems unlikely to ever be completed. So this might give someone the impetus to just make a better version.

This is what the comparison between a surface pro 2 and my desktop looks like from my CPU performance thread. This is a decent desktop, but it's by no means high-end. I think they are both from 0.23.5. The desktop was run with settings at max, on the surface I think the terrain was set to medium and AA was turned off, otherwise the settings were the same and the resolution was about the same (both were in windowed mode on a 1080p screen). For a mobile computer the surface pro 2 is alright, but any halfway-decent desktop will blow it away. Some of the higher end mobile setups come much closer to desktop levels of performance.

That's probably a good idea. I've been trying to avoid any dependencies, but since I'm already relying on Module Manager to add science reports for my replacement stock science parts (I'm also planning on offering a stock ScienceDefs.cfg with the added reports as another option, similar to how the crowd sourced science logs work) I might as well add it for the SCANsat parts. I'll be using model nodes to load my parts with the new Universal Storage science bay model. I'd like to have my parts simply fail to load if the science bay isn't found, but I'm not sure if that will actually work. The parts seem to load even if the US parts aren't there, they just float in the air and don't work properly because it can't load all of the required information.

I think I like Faark's idea better, having a dedicated sub-forum. A single thread might have the same problem that the release forum has, too frequent updates that would push everything off onto previous pages. A dedicated forum would allow for easier tracking of the mods you actually care about through subscriptions and/or signature links. How you would moderate something like that might be a problem though. Is it possible to allow only the original author to post in a thread? You wouldn't want to get updates on a thread whenever someone makes a "great update" post (which will always happen despite any instructions not to do so), and forcing moderators to closely watch over such a sub-forum doesn't seem feasible. Locking a thread and unlocking only for updates by the author also doesn't seem like something moderators would like.

None of the Surface Pros have an HD5000, the 2 and 3 have an HD4400, which is quite a bit weaker. Though in this case everything is so power-limited that it's not as big of a difference as it could be. The new top end Surface Pro 3 has a slightly better CPU, and it looks like those might have an HD5000, but they won't be available for a long time. I get around the same performance on a Surface Pro 2 as I did on a 2013 MacBook Air, which does have an HD5000 GPU. I use it all the time (Surface Pro 2, i5 4200U, there are some newer Pro 2s that use the 4300U) and it runs fairly well, though I wouldn't say you can max out all of the settings. And if you run at full screen (without any of Windows scaling options) you might really run into performance problems, which will be much worse on the higher resolution Surface Pro 3. And yes, you really need a mouse, the terrible touch pad on a type cover and the pen just don't cut it.

I released an update, Curse seems to have accepted it already, so it should be good to go. I updated DMModuleScienceAnimateGeneric too if anyone is interested. Everything else is the same, no changes to the parts, but this problem should be fixed, mostly at least. I'll come up with a better solution later, but this seems to prevent the science reports from disappearing. It was affecting everything but the drill. I suspect that in most cases it doesn't really matter because people probably transmit data as soon as they collect it, it's still bad enough to release an update though. Thanks for bringing this up.

Holy cow, thanks for bringing this to my attention. It seems that it's resetting the right-click menu options whenever the vessel situation changes. So if you land, take-off, go into an escape orbit, etc... the options to review or collect data disappear. The data doesn't go anywhere and if you click log experiment again it should just show the currently stored data, not collect new data. I think this is because I'm inheriting from the stock ModuleScienceExperiment, so it might be doing unintended things to my parts. I'll see about fixing this. Edit: Yes, it seems ModuleScienceExperiment is doing something dumb. I have a simple fix that I'll release today and I'll see about something a little better for the next update. The review data and collect data options and so on still disappear if you actually have the right-click menu open while changing vessel situations, but as soon as you close it and open it again everything should show up properly. And EVA collection seems to work ok too.

Texturing the goo pod and mat bay now. Then I'll be converting all of my old US parts to the new science bay and wrangling all of the animation stuff to work together. Then, I hope, on to making an atmospheric sensor to complete the set.

The problem here is that you're using a duplicate copy of some of my experiment definitions. KSP doesn't like it when you add multiple science experiments with the same id and it throws out the error: [Exception]: ArgumentException: An element with the same key already exists in the dictionary. System.Collections.Generic.Dictionary`2[system.String,ScienceExperiment].Add (System.String key, .ScienceExperiment value) This seems to have the effect of breaking some experiments but not others. I think which experiments are affected has something to do with load order (anything loaded before the duplicate experiment is ok), but I'm not really sure. In any event you need to change the experiment id value for the magScan, rpwsScan and scopeScan. Those are using my definitions and will break things when these two mods are installed together.

I believe the whole point of all this is that simple download numbers aren't very valuable. They tell you very little about actual usage. Does this generate a file with the info being sent? I think that might help assuage some of people's worries about data privacy.

We should have a fix for the map width thing in the next version, but the conflicting UI thing is really annoying (and really widespread, it happens all of the time with a huge number of mods), but probably much more difficult to fix.

That's very strange. It's not too surprising that EVA collection might have problems, the method I'm using isn't very good and I've already fixed it for the next update. But that doesn't sound like it's the problem here. I don't know why landing would trigger the part to dump its data. Does this happen for any other part, or just the telescope? When you see that you've lost the data do the "review data" and "reset" buttons also disappear, or do they remain but not do anything? Do you have any mods that deal with transferring, transmitting, or otherwise manipulating science data on your vessel? Most of those aren't setup correctly to handle mod experiments (Science Alert and Tarsier's hard drive mods are the only ones I know of that should handle them correctly) so those might be doing something weird.

Only the resources that are actually available on a given planet are able to be selected. Uranium and thorium are present on most or all planets, but alumina isn't so its button isn't always visible. Try the Mun if you want to confirm it, it should have alumina, while Kerbin doesn't.

Actually you've got two bugs in that picture. Normally when the re-size button overlaps the projection buttons there is still a small sliver that you can click on to drag it. But some other mod's UI is screwing with SCANsat's UI, causing the smaller Unity style buttons (like the 'close' button on the left) to turn into the bigger KSP style buttons. In my experience this is usually caused by bugs in another mod, but it can be very difficult to track down exactly what is causing it. And it is very annoying that bugs in one mod's UI can affect other mods' UIs. The big map width is stored in the persistent file, so restarting or re-installing won't help. You're best option is to open the persistent.sfs file (make a backup first), search for the line "name = SCANcontroller" (without ""), then scroll down looking for the line "map_width = 400", or whatever number it's at. Change that number to something like 500 or 600 and it should be ok. Both of these are known bugs. There isn't much that can be done about the broken UI thing without a complete overhaul, at least not that I know of, and the button overlap has already been partially fixed, though there are probably other ways to improve it. Also, thanks for including a picture, that makes diagnosing the problem much easier.

Um, yeah, I meant to distinguish it from aerobraking, not re-entry.

I updated GitHub with the latest version: https://github.com/S-C-A-N/SCANsat/releases/tag/v7.0rc2.2 It fixes the low-resolution scanner problem. I also consolidated the Interstellar and Modular Kolonization scanners into one module for each mod. You should only see one button on the right-click menu for each part now, instead of one button for each resource type. If you want to break them out into separate modules (or to put them onto different parts) you can create individual SCANsad modules with each sensorType. It should also be noted that you probably shouldn't use sensorType = 255 anymore as an "everything" scanner. If you want something that covers all of the default SCANsat sensors use sensorType = 63. If you want something that can cover all supported resource types and the default SCANsat sensors you should use sensorType = 131071. I wouldn't recommend using the full 32-bit value for an everything sensor (2^32 - 1), it might cause performance problems because each scanner would be counted 32 times while scanning. The value given above covers 17 sensor types, which still might not be a good idea, but is better than all 32. This is an interesting idea, but I can imagine it might add to the big map's performance problems. If it needs to do anything beyond looking up intensity values it might be very slow.

Or a missing (), whoops. That's the danger of making late changes without testing them. I'll update it later tonight.