DMagic

It's a bit tough to compare a MacBook to a Windows laptop, there's a lot more than performance that is different between the two, but I would say the Windows machine looks much better. That looks like a pretty high-end mobile CPU, and the added RAM and the better GPU (and a decent resolution screen) will make a big difference; not just for KSP, but for everything. The spinning disk hard drive sucks, but there isn't much you can do about that without spending a lot more.

Perhaps. What does it do? The Kerbal Stuff link doesn't seem to be active yet, so I can't find out for myself.

Are you talking about clicking through a Unity GUI into the KSP UI, or clicking through different layers of Unity GUI? The EditorLogic stuff works for clicking through to the KSP UI, though there can be some issues with that; in the spacecenter and tracking station it can make timewarp wonky when you try to lock the KSP UI. I'm not sure if there's an easy way to lock out different layers of your own UI, other than just disabling them when one window overlaps another (turn a button into a label with the same GUIStyle as the button). Also, is there a simple way to lock out things like right-click buttons? The only method I'm aware of is to go through each PartActionWindow and disable it: https://github.com/DMagic1/KSP_Contract_Window/blob/master/contractsWindow.cs#L169-L182

I've considered something like this before, but there are a few complicating factors for SCANsat. The map is re-sizable, so you would need one very large data file for each planet. Most of the time you could just interpolate a smaller map from the bigger data file. But if you wanted something bigger it wouldn't be possible, or you would have to revert to the slow method. It might be best just to impose some certain maximum size, and if someone wants to export a larger map maybe a separate interface could be provided. There is also potentially a problem with on-disk size of all the data files. With mod planets such databases could easily run into the 100s of MB. 16 bits per position (~65000 possible values) would probably be enough to cover the height range of most planets, so that would help keep the size down to some extent, but it's still a lot of space.

That's definitely strange. Full log files would help here. What do you mean when say the positions was being reported incorrectly? Pictures would really help out here. That's normal, the zoom map doesn't account for different projections.

Yeah, that can happen. It doesn't run the experiment until the animation is finished, so if you change situations in those few seconds you'll get weird results. It will probably give you default results whenever that happens.

I don't see anything specific to SCANsat in those logs, but the fact that the orbit overlay isn't working probably means that either something else is wrong, or that you just haven't upgraded from the first level tracking station. If the tracking station has been updated then there is something wrong, but the presence of the equatorial crossing lines means that the method is at least partly working. Have you tried turning off the orbit overlay? Does that affect performance? Have you tried this without any other addons?

That's not normal. I need to see your log files. The only currently available source of resource distribution data that SCANsat functions with is Regolith. Karbonite and MKS both work fine with SCANsat via Regolith without any modifications. Regolith resources are those resources that are configured work with Regolith. The Community Resource Pack is the only commonly available source of these resources that I am aware of. More can be added by writing the proper config files. The planetary KSPI resources (the ones that can be found on the surface and can be scanned for) are included in the CRP, but Interstellar itself would have to be configured to actually use those resources in conjunction with Regolith. There is currently no compatibility with SCANsat and any Kethane resource configs.

I'm not entirely sure what you are trying to do. SCANsat is setup to recognize all of the crustal resources in the Community Resource Pack (except Karborundum, which was intentionally left out), Kethane, and the KSPI planetary resources. It also requires SCANsat modules with the proper scanner type to be used to actually scan for each resource; these are generally provided by the resource addon. The only way that SCANsat can read abundance levels for these resources is through Regolith. Kethane integration is broken because of some error in the Geodesic Grid code, which hasn't been updated since 0.25. KSPI is all sorts of a mess and is still using ORS. Unless someone wants to convert those resources to run under Regolith they won't work under SCANsat.

Do you have the log files for when this happens? That's a strange bug, but the stock toolbar is full of strange bugs, so it's not exactly surprising. Blizzy's toolbar is always my first choice. I'll see about adding a check to see if the stock contracts app is actually being replaced when that option is selected, so that it can at least fall back to using the regular stock toolbar button. To fix this you'll have to edit your save file (make backups and don't complain to me if something gets broken ). Search for the section shown below in your persistent.sfs file. Switch the replaceStockToolbar = True to replaceStockToolbar = False (you can also set stockToolbar = false to switch back to Blizzy's toolbar), load up KSP, and it should be back to normal. SCENARIO { name = contractScenario scene = 7, 6, 8, 5 version = 1.0.3.3 allowZero = True warnedZero = True alterActive = True stockToolbar = True replaceStockToolbar = True Contracts_Window_Parameters {

Tweakscale stores the scaled value as a KSPField in its module. I account for this by checking for a TweakScale module on my part, checking for the "currentScale" field and modifying values as needed. The only problem is that Tweakscale stores the value differently depending on what type of scale you are using. The typical 1X, 2X, 3X type of scale just stores the value as a multiplier, but the free sliding scale stores it as a percentage, 0-100% or higher. Unless something has changed you might have to find a way to account for users with both types of scaling. if (part.Modules.Contains("TweakScale")) { PartModule pM = part.Modules["TweakScale"]; if (pM.Fields.GetValue("currentScale") != null) { float tweakedScale = 1f; try { tweakedScale = pM.Fields.GetValue<float>("currentScale"); DMUtils.Logging("TweakScale Value Detected On XRay Instrument; Drill Length Set To 8.8m * {0}", tweakedScale); } catch { DMUtils.Logging("Error in TweakScale PartModule Field; Resetting TweakScale Factor to 1"); } scale *= tweakedScale; } }

Yes it's normal; everything but the big map will reset its position. This is something that should probably be changed so that everything only reverts when restarting KSP (except for the big map, the size and position of which is saved in the persistent file), instead of every time you load or change scenes. That's strange. I don't know why that would happen, but it sounds like something was corrupted in the save data. I'd be interested to see the save file if you still have it. I believe there is a biome scanning part in one of the USI addons that can be used for biome unlocking. There was some confusion about where those reports came from originally, but I wanted to make sure I got the source right. Thanks for this; though it should be noted that this is damny's mod, not mine. I've just been gluing stuff on top of an already great addon. I'll see about adding this video to the first post and the docs. It should serve as a great overview and a quick tutorial, too.

I think if you remove the term navigators and maybe rethink the last few levels this makes great sense. Science is intrinsically tied up with your current vessel situation and biome. Having a scientist be able to say what situation and biome you are in makes perfect sense; the scientist knows best when to collect valuable data. This kind of simple suggestion also doesn't require reworking the science system (whether or not that is a good idea is a different topic), but improves the current system. Having data on orbital parameters would be great, but I agree that engineers might be more well suited to this, and it would go along well with them providing a dV readout. The upper levels for scientists could incorporate something like Science Alert's data. Not just telling you what situation you're in, but also how much science is remaining for that area.

One of the Mun arches has a fairly flat region just to the West. It's not an enormous site, but it's big enough for most any base.

I've never been big on buying used PC components, so someone else will probably have to help out there. There are some reputable places to get parts(HardForum is one, I sell all of my used stuff there, but I think you have to be a member for a while before you can use their 'for sale' forums), I've just found that it can be a lot of trouble and buying new with a manufacturer's and/or retailers warranty provides peace-of-mind. I can sympathize about not knowing which components are better. Back in the day it was mostly a matter of looking at CPU clock speed, but now you can't really do that, clock speed has basically remained unchanged for desktop PC's in the past 10 or so years. In general, for KSP, or basically any type of PC gaming, a recent Intel i5 desktop CPU will be pretty good. Anything from the past four years (the i5 2x00, 3x00, 4x00 series) will handle games and most everything else well enough. The more expensive i7's don't really make a difference for games and normal usage, and the dual-core i3's probably aren't a good idea for any kind of long-term build. A first-time PC build can be a little tough, since you need to buy basically everything. It's mostly a matter of figuring out your budget and going from there.

Finalize means collect science, as in using an action group or the right-click menu, or is this transmitting data? Theoretically using ForScience (or ScienceAlert, since they both use the same method) to collect data should do the same thing as using the right-click menu, but there could be something else going on. Which contracts are these affecting? The stock contracts, or one of mine?

I'm not sure if there is any way to do this using the standard ModuleScienceExperiment, at least not through the config alone.

Asteroids are vesselType = SpaceObject if they have been tracked, and vesselType = Unknown if they haven't been (these are the question mark objects in the tracking station). There is a DiscoveryInfo field for every vessel which has data about whether or not an asteroid has been tracked, or visited before (I can't remember which values correspond to which state, but they are stored in the persistent file). It also has info about the asteroids size class, but this is only really reliable for asteroids that haven't been visited before (ie haven't been within loading range), since docking to an asteroid permanently changes this value. The only reliable way to get the size class after visiting an asteroid (it isn't available before the asteroid is loaded for the first time...) can be found here: https://github.com/DMagic1/Orbital-Science/blob/master/Source/DMAsteroidScience.cs#L76-L92. It basically takes the last character in the ModuleAsteroid.prefabBaseURL string, which corresponds to the size class and doesn't change.

That's interesting, I guess the part's COM is never updated in the VAB. Does this affect things like landing gear, or any other stock parts that are able to move in the editor? It might be worth filing this as a bug report, if it hasn't already been, since small changes in COM can have a big effect.

The shift in the center of mass is due to the boom's extending collider box, which I assume changes the part's center of mass, and therefore the vessel's. I'm guessing that the COM in the editor is not updated in real time, only when a part is added or removed. You could try extending the boom, taking the part off, then putting it back on, that might show the correct COM.

All of the contracts have a requirements before they will be offered; most are fairly simple, reach orbit, escape Kerbin's SOI, etc... There are lots of situations and biomes that don't have reports made specifically for them. Doing otherwise would require hundreds more science reports. This was never an issues with this addon. It was always something else adding duplicate science experiment definitions. As long as nothing does that you'll be fine.

Version 3.4 is out; get it on Kerbal Stuff. This update addresses a few minor issues with updating sub-parameters; titles, notes and rewards (modified through the config window) are updated appropriately. It also addresses compatibility issues with Contract Configurator when updating sub-parameters.

Well, that's how it works in theory. But you need to add up the numbers correctly, and both altimetries are 3, not 2; 8347 not 8474. Yes, you do, and everyone who has downloaded SCANsat does. It's in the SCANsat/resources folder.

Version 3.3 is out; get it on Kerbal Stuff. This update addresses several performance issues. Most of the problem was being caused by repeatedly requesting the contract parameter title from certain contracts. Some of them have complicated methods for generating those titles and this was really slowing things down. The overall GUI code should be more efficient now, with more manual positioning of elements and less reliance on the slow, automatic layout functions.

Yes, that's a good idea. The big map and KSC map will show scanning coverage (altimetry, both high and low, for the elevation and slope map, and biome & anomaly for the biome map) and if you have a resource overlay turned on it will take that into account too. The stock biome map thing is also simple to add, I'll probably add a global toggle to switch between that and the default style (which I want to improve a bit, too).