DMagic

I can understand why modders that don't have access to Steam might not be happy, but I also assume that anyone who wants to update or develop a mod can probably get a copy by just asking Ted; there aren't that many modders and providing access to those not on Steam is unlikely to be a huge burden. It might also be likely that anyone who truly wants to help in searching out bugs could get a copy. But as for the rest, get over it. It's been nearly a year since the last major update, I don't think waiting a few weeks for the release should be that painful; a release that just maybe won't be followed by weeks or months of waiting for a hotfix to address the critical issues that were missed because of the limited testing capabilities of a relatively small testing team.

Yeah, there are probably lots of ways to handle it (and an absolute ton of information is available on data visualization and mapping). One simple step that would probably help a bit, but not require much work from me, is to allow the mouse-over info and tooltips to show all available resource concentrations, instead of just the one.

You mean like for a satellite contract where it asks for a new vessel and a specific part and so on? KSP only tracks the active vessel, so as soon as you switch it thinks that you are trying to complete the contract with your current vessel, which may not meet any of the requirements. Stock KSP doesn't really have any logic for assigning specific vessels to a specific contract; the satellite contracts that ask you to move a specific vessel won't complete with any other vessel, but it still only tracks the active vessel when deciding whether a contract parameter meets the requirements. A new update should be ready in the next few days. It adds a passive mode when in the Editor (you can already access CapCom in the editor if you are using Blizzy's Toolbar, but it might not work right), and should fix most of the issues with contracts not working right when accepting them while in flight.

@Angel-125 One thing that I'm not sure of is any modifications that Pathfinder does to the scanner parts. Does it simply add extra modules to the M700 or, replace the stock module? SCANsat disable some functions of the stock scanner when stock scanning is disabled, so there could be some issues there. I see that you add a planetary resource too. There is a section in the SCANsat wiki about adding resources, but I can also add it in the next update (which should hopefully happen before 1.1).

If I understand right, you are just looking for something to tell you when SCANsat has performed a resource scan? When stock scanning is not disabled SCANsat just looks at the ResourceMap like you do, and fills in the internal SCANsat records from there. When instant scan is disabled there just isn't any interaction between stock and SCANsat resource scans. When stock scanning is disabled there are two methods that are used. One is something I set up with Pathfinder in mind. If you have stock scanning disabled a new option will be presented in the SCANsat resource settings window. This option allows the user to set a threshold for when SCANsat resource scanning will trigger the stock resource scan. By default, once you pass 90% (I think) coverage with a SCANsat all-resource scan (using the clamshell scanner) the stock scan will automatically be completed. It can be disabled though, which might screw things up with Pathfinder. The other method is to use reflection to ask SCANsat what the resource scanning coverage is for a planet. That's a bit of a pain, though if you want to look into it Contract Configurator uses it. The best option would be to instruct your users to set the SCANsat resource scanning threshold level to some amount and to perform a scan with the M700. You can see the resource settings window along with a description in the SCANsat wiki. Not really. The only option is to export maps with different resources turned on and line them up, or try to layer them on top of each other. I plan on adding a section in the wiki about handling this. There isn't really a practical way to handle it in-game. Two or three resources at a time might be manageable, but an arbitrary amount is tough.

I didn't look too carefully, but I'm assuming that the large arrays causing the memory issues are the big Color arrays used to set some texture. There are a few things that might be of interest regarding Color vs Color32: Using Color32 rather than Color saves a lot of memory. Since a Color object uses 4*32 bit floats, it takes up four times the memory of a Color32 object, which uses 4*8 bit bytes. If the end result is to apply this Color array to a texture then there is no difference in the resulting texture colors as Unity converts all Color references to Color32. Using Texture.SetPixels is considerably slower than Texture.SetPixels32; that internal Color -> Color32 conversion is actually quite slow, so cutting out that step can speed things up. The only drawback is that in Unity 4.x you have to set the entire texture's colors when using SetPixels32, whereas SetPixels allows for setting any arbitrary number of pixels; this is fixed in Unity 5; it looks like this isn't a problem here. The only issue that I can think of is about the source of the colors in the first place. If they are all float Color values then you would have to convert them to Color32 and so would lose some of the speed advantage.

I agree. Just look at how tags are used on this forum. Half of the time people just separate the title of the topic into 3 or 4 tags. The same goes for thread ratings. I've said it on the GitHub issue, but I'll repeat it here. I don't think there should be any form of user-feedback on the site. I think downloads and follower count (which could be seen as a type of user-feedback, but also provides and useful and practical purpose) are good enough for determining popularity. Anywhere that users are allowed to enter text will end up as another complaint box, just like the user review/feedback things on Curse, and another thing for me to ignore. Maintaining a single, obvious link to the addon forum thread (or maybe GitHub issue tracker) seems like the best option to me.

You want a resource transfer cable and nothing else? The first mod listed here will do that.

Just use a GUI.Label (or GUILayout.Label) for regular text. Text area and text fields are for input (i'm not sure what the difference is for the two).

@Gaiiden There is a GitHub issue for this from way back. I've never really considered it a priority. There are a few issues that complicate the idea: There isn't always an immediately available scaled space map, Kerbin, for example, just has this weird grey-scale thing. I'm not sure how well the different map projections would turn out when using a rectangular map as the source. It might be a bit of a memory hog, since multiple large textures are involved. Adding new scanners through MM won't work. Only resources can be added this way, since they are just variations on the same thing.

That duplicate key exception has a way of popping up whenever you least expect it. I've always thought that if it was going to show up it would happen when experiments were first loading at the initial load screen. But there are times when it doesn't happen there but it still happens elsewhere. Basically I've found that you just have to wrap calls to ResearchAndDevelopment.GetExperiment in a Try/Catch or else you might end up with this error. What happens is that, for some unknown reason, you try to load an experiment using its ID, then the R&D method can't find it, then it tries to reload it, but it's already been loaded (!!! which means that it should have been able to find it in the first place !??!). The obvious reason is that you have duplicate science definitions somewhere, but it seems like it can happen sometimes even without them.

I don't know how Contract Configurator is handling orbit generation (ie if there is any further customizing the orbit after generating it), but the stock generator can be a little weird. Most of the orbit types have relatively little variation outside of the altitude factor. Obviously the Molniya and Tundra orbits are fairly limited, so that's not a surprise. But equatorial and polar orbits seem to be locked to 0o and 90o, the inclination factor just seems to change the chance of a reverse orbit. So I think you are basically stuck with random and synchronous orbits for inclination variety. It would be nice, for instance, to adjust a polar orbit to be not-quite polar, or the same with equatorial. Also, the final Eccentricity argument in the orbit generator doesn't do anything for most orbits. That seems to come from the altitude factor. Which, as you've seen, is another tricky parameter. I've found that it's hard to get low orbits for both planets and moons. For instance, a very low altitude factor is required to get orbits below 1000km for Kerbin, but will give orbits of around 10km for the Mun or Minmus. If you want, say, something similar to the low/high orbit cutoff you just have to adjust the SMA yourself. All that said, much of this can be altered after the orbit is generated. Contract Configurator could be modified to allow for a second inclination adjustment (which is trivial, just change the orbit.inclination value after you have a generated orbit) and/or change the SMA and eccentricity (which is a bit trickier and might end up with your Pe being too low).

It's only 10 simple buttons, but it was a pain to create. I actually made a working version of portrait stats using the new UI too, but OnGUI gets drawn on top of everything and I could never find a way to force the new UI to go over the crew portraits.

I'm not too enthusiastic about this. It seems like a lot of work and there generally aren't enough contracts to necessitate an actual search function. There are plenty of sorting and grouping functions in Contracts Window + that should alleviate most of the need for a search function. The little pencil icon to the right of the mission title can be used to edit the mission name or delete it. Re-sizing or dragging the window shouldn't cause any problems. Blizzy's toolbar does something very strange when you activate the move/edit mode; Unity has standard methods for dragging a window that don't cause anything to slow down. I've never seen any kind of slow down with this when moving or re-sizing the window.

To answer my own question, it seems that you must look at the second child of the root part transform. part.transform.getChild(0).getChild(0).localScale; or part.FindModelTransform("model").getChild(0).localScale; or part.FindModelTransform(fullPartURL + (Clone)).localScale; Also note that TweakScale changes the localScale for the "model" transform, the first child of the root part transform. So if you want to take both into account, and you don't want to deal with TweakScale KSPField values, you can access that scale value as well (and probably part.rescaleFactor in case somebody changes that, too).

You might not want to edit the actual part config to remove the MaxQ value, but since it is a KSPField you could just cache all of the values for loaded modules, set them to -1, then set them back after you have finished moving the vessel. It seems like the least invasive method without any action from RT.

The parameter type in question is FinePrint.Contracts.Parameters.CrewCapacityParameter. But you probably don't have to do anything with the contracts specifically. All of these contract parameters have to check for any changes to the vessel (docking, decoupling, parts blowing up, etc...). Try firing the GameEvents.onVesselWasModified event with the current vessel as the argument (GameEvents.onVesselWasModified.Fire(yourVessel);). That should trigger the parameter to check the vessel again. And I have an unrelated question. How do you get the scale value in-game as modified by a part config MODEL{} node?

Why would any of this be a problem, or something for SpaceDock to handle? The thing about collecting statistics or gathering personal info has already been addressed in the addon rules. I guess someone could create such a mod, upload to SpaceDock, but not release it on the forums, but that doesn't seem too likely and there could be a more detailed discussion of what to do about it when it actually happens. As for interfering with other mods; why should SpaceDock have any say about that? I can understand why a mod creator might be unhappy when someone creates something meant to alter their mod (like a 64-bit unlocker), but I don't see why a hosting site should do anything about it. The same goes for someone releasing a fork of a non-restrictively licensed mod (which also doesn't seem like something that is very likely to happen); I guess some measures could be taken to clarify that the fork is not the same as the original and may not be supported.

Is it a complex window? With lots of elements? And is it a scrollable window? When using GUILayout all elements in scroll window are drawn regardless of whether they are actually on-screen.

What's the best way to handle moving all of our old CKAN references to SpaceDock? Wait a few days for things to shake out. PRs to NetKAN to change things over Some automated system for changing them over Asking this question in the CKAN thread

You can edit the rangeAboveMaxHeight field in the SCANsat/Resources/SCANcolors.cfg file to something higher than 10000. This will increase the slider limit for each planet. You can also load your game, use the Save To Config button in the Color Management window (this will override the SCANcolors.cfg file with the values from your current save), then manually edit the maxHeightRange field for each planet. You might also be able to get away with using a Module Manager config to accomplish the same without editing the file; if the system only has the stock planets then they should be recognized without adding anything new to the config file. After changes are made to the config file you will have to select the Reset To Default button for each planet to get those values to apply in-game (they will apply automatically when starting a new game though). Not really because the slope map doesn't really measure slope and isn't actually very useful. Using a zoomed in, high resolution altimetry map will probably give you a better indication of how flat an area is.

Well, the log seems to think the vessel transitioned from the Sun to the Sun after the SOI change, so I'm guessing something about high timewarp may have screwed things up. Also, I've switched the forum links for all of my mods to Space Dock, let me know if there are any problems with them. I'll get around to the KSP-AVC file links later; SCANsat's CKAN link was already switched to GitHub, so it should be fine.

That's an Orbital Science message from the magnetic field contract. I can fix the method so that it doesn't spam the error, but something deeper is the real problem. Something is making the OnOrbit Event repeatedly fire with a null celestial body or vessel object. I'm not sure what would cause that.

For the sun it should be 0.

6.0 is the latest version, unless you have a .version file pointed at the dev branch for some reason. I'll get around to fixing all of the download locations when I can upload to SpaceDock.