DMagic

It's probably a side-affect of the dumb way that SCANsat uses ClampForever instead of Clamp at the end of the animations. This causes the animations to continually play through the final frame of the animation instead of just stopping. It's probably time to fix that issue...

Version 2.0 of EVA Transfer is out; get it on Kerbal Stuff. It fixes some problems with persistence and reconnecting transfer lines; it should also handle lost connections more gracefully. I rewrote the window GUI code and transfer logic so that it no longer resembles something created by a fourth grader with a poor understanding of object oriented programming. The results are mostly the same. There are a few minor improvements and resources that aren't present in either vessel won't show up in the drop down menu, making it a bit more manageable.

That's because the dots use a higher quality interpolation when generating maps. I'm not sure why they do this, either method seems fast enough, but it causes the blob and line maps to not match up with the dot maps...

This is for a regular string, something that would go in a GUI.Label? I seem to remember this not working for ScreenMessages, but for regular strings this should work: "<color=\"" + hexCode + "\">" + text + "</color>" Note the additional "" around the hex code. This is what SCANsat uses and it seems to work fine.

I believe that is related to the same problem causing parts not to retract. It's something that should only happen when SCANsat is also installed. I'll release an update soon to fix that and address some balancing issues. Otherwise I think this is fine on 1.0.4.

ScreenMessageStyle.UPPER_LEFT, or something like that will put the message in that corner, like stock messages. The problem with using a GUI.Label is that it won't respect other screen messages. The stock function adds each message on a new line. A GUI label will just draw it on top of any other messages. There might be some way of figuring out if other messages are being displayed, how many there are, and how far down you have to move your own label, but that seems like too much trouble. Though I suppose you could just draw your message somewhere else on the screen so that it won't overlap.

Version 13.3 is out; get it on GitHub. This version introduces a new modified zoom map meant to replace the stock, narrow-band scanner's ModuleHiDefCamera window. The terrain map is slightly lower quality, but much faster to render than the standard zoom map. You can also select which resource to display directly on the zoom map (this applies to the standard zoom map as well). There is also a new terrain planetary overlay and a new background terrain database loader to go along with it. When you start a new KSP session it reads each planet that you have scanned for terrain data and stores it. This is used to generate both the small map and the planetary overlay; the impact on performance while it is loading appears to be negligible, but makes map generation much faster; the big map is unaffected. There are also several improvements to the planetary overlays, tooltips when mousing over the planet in map mode, a resource indicator on the instruments window, and several minor bug fixes. See the first post for the complete change log and details.

If you release on Kerbal Stuff, and mark the addon as being compatible with 1.0.4 CKAN will update it.

The only reliable way to figure out the asteroid size class is by taking the last character of the ModuleAsteroid.prefabBaseURL string: https://github.com/DMagic1/Orbital-Science/blob/master/Source/DMAsteroidScience.cs#L107-L132. As for seeing asteroids the only way I know how is to search all vessels within loading distance for a ModuleAsteroid PartModule.

What resource scanning settings are you using? Did you actually scan the planet? It will probably work fine. Unless there is some major problem I won't update this version. I'll hopefully update the dev version in a day or so. After that it shouldn't take long to update to the next major release.

I agree. I understand why they chose to use delta-V as the magnitude for maneuver nodes (arbitrary units wouldn't make much sense and a percentage scale wouldn't give any point of comparison), it's just the obvious choice, but it makes little sense to provide such a value with no context. If someone doesn't want to use a delta-V indicator that's fine, don't use it if they add it. Guess work (it might be educated guess work, but it's still guess work) is fine when you're just tooling around the Kerbin system and there isn't much of a penalty for screwing up, but once you get further away I think it becomes a problem. Of course, KSP doesn't offer any indication of how much delta-V is required to get anywhere, so you could argue that a delta-V indicator by itself doesn't provide much value, but such information is readily available, even if it can't be found directly in-game. Huh? A car is a poor analogy for a vessel in KSP. You could come up with some scenario where you are sequentially dropping mass out of the car, or carrying an enormous amount of fuel, but during normal driving a car is a relatively consistent object where the fuel accounts for maybe 5% of the total mass. That has nothing to do with KSP's fuel gauge, which, given the almost infinite variety of vessels possible and how rapidly each vessel can change, provides only limited information.

Yep, ATM is awesome... If anyone comes up with a working config to prevent ATM from fiddling with the icon textures I'll include it with the download. And as far as I can tell this is working fine with 1.0.4. I'll update the remote .version file and tell Kerbal Stuff that it's OK, that should let it show up on CKAN again. The same goes for the my other contract system addons. Let me know if anyone finds any bugs in 1.0.4.

You can add parts after starting, just reload the database, use the Module Manager database reloader (Alt + F11?) if it's installed, it will find textures, configs, parts, etc... I don't think it will find things like science experiment definitions, or maybe resource definitions and things like that. But parts work fine. Reloading the database can cause problems with other mods though, it can trigger multiple KSPAddons to start for each class, which can be bad.

I need more info. Pictures, log files.

ScienceUtil.GetExperimentSituation(vessel); Or you can do it manually based on where the vessel is, but the first option is simpler.

I tested out my scaled agency logo theory and it seems that the DDS converter is doing something to muck up scaled logos. Standard size agency flags get converted from png to dds fine, but the small flags don't get loaded by KSP (and they don't show previews in Windows Explorer either), forcing it to try creating a new scaled logo by shrinking the big file and choking when it runs GetPixels. Converting the scaled logo to dds in Photoshop works fine, so I would just suggest that mod authors convert all of their agency and flag icons to dds, using something other than the DDS converter from the forums. Aside from the benefits of dds over png, this would prevent the kind of problems that arise when users try converting all of the png files in their GameData folder.

Thanks for the heads up; not sure how that bug made it in there... Fuel line persistence definitely has some problems (which seem to be worse in 1.0.4, but I'm not sure) and there are also problems when changing scenes or boarding a vessel while carrying the fuel line. Edit: Version 1.1 is out; get it on Kerbal Stuff. It fixes a bug that was preventing resource transfer.

The only reason agencies seem to have a problem is when the scaled logo gets screwed up somehow. GetPixels gets called presumably when it tries to make a scaled logo out of the big logo. Why the scaled logo gets screwed up when using .dds files (maybe it's a problem with the DDS converter) I don't know. But properly made agency definitions and dds agency logos shouldn't have a problem. Squad seems to have no problem using dds agency logos (I don't know what the deal with those True Color scaled logos is), so there isn't really any reason why they shouldn't have dds flags. Then again, the flag logos are the least of KSP's texture problems. I really wish they would spend some time optimizing some of their more gratuitously over-sized textures... The materials bay, the atmospheric sensor, about a dozen fuel tank textures (which could really just share two or three textures for each set)... the list goes on.

Huh? I thought it was that they be divisible by four, that's what Photoshop always tells me. Flags are 256 * 160, this goes for standard flags and the large size agency flags. All of the large agency flag images are already in .dds format, so I don't see any reason why the regular flags folder couldn't also be. I keep hearing people having issues when converting agency and/or flag files to .dds, something about it screwing up the agency loading by the contract system. But I've been distributing and using agency (large and small files) and flag images in .dds format for some time now without a single problem.

You seem to be conflating two different contracts. As far as I know only the SCANsat lite pack requires 95% scanning completion, but has no specific orbital requirement. The old SCANsat contract pack has specified orbital parameters, but only requires 50% completion. This is why screenshots of the problem at hand would help (ie the contracts involved, images of the scanning map, vessel, etc...).

Fuel lines: http://forum.kerbalspaceprogram.com/threads/120731 It's not stock, but it's a standalone addon.

I'll post this here too since I've seen this question come up a few times. This method works for waypoint icons, I haven't tried it with tech tree icons, but it should work.

You should be able to put them somewhere else, you just have to trick KSP into thinking that it's in the correct location: https://github.com/DMagic1/Orbital-Science/blob/master/Source/DMConfigLoader.cs#L316-L327 At least that's how it works with the waypoint icons, I'm pretty sure that tech tree icons should work the same way, just change the path location to fit.

It still needs some work, but for the most part, if you are just looking at resource and maybe biome scanning, there is no need to use SCANsat's slow, CPU hungry big map (I've got a few ideas for improving this, one of which requires Unity 5, another requires learning lots of new C#...). The planetary overlays, along with the instrument readout provide much of what you need. I still need to add a simpler method for opening up a zoom map, something similar to how the high def camera works on stock narrow-band scanners, so that you can easily see the resource abundance below your current location. I also want to add resource abundance to the instrument readout (because staring at right-click menus for important information is the worst ), and I'm thinking maybe some kind of mouse-over readout for the planetary overlays when in map mode.

This thread seems mostly to be focused on part/texture making. For plugin help you're better off checking the plugin development sub-forum. TriggerAu has a [thread=66503]pretty good resource[/thread] for taking care of some of the trickier parts of GUI work, among many other things. There is also a [thread=122385]tool from nalitia[/thread] from a few weeks ago that helps to abstract away a lot of the non-sense involved with GUI creation. If you aren't in a hurry though it might be best to just wait for KSP 1.1 to do any UI stuff. OnGUI is atrocious as far as performance goes and has many other limitations. The Unity 4.6 UI doesn't have much documentation for scripting, but hopefully that will change soon. And according to Mu we will have easy access to all of KSP's UI prefabs, so it should be easy to create windows, buttons, labels, etc... that match the KSP style.