RoverDude

Surface is better (except for Kerbin)

The amount of data affects the conversion speed (you have a very long tail), the amount of science is irrelevant (it's just a cap).

Actually there is. If you have samples from Duna - feed them to a lab around Duna, etc. - there is a specific bonus for feeding data into a lab in the same SOI the data came from.

Rest assured I've been through all of this (To expand a bit) The way in which the texture is rendered, and the resolution that we are working with, given the performance constraints, etc. result in tradeoffs in how interpolation is done - the net result is the fellow in the post above got a bit unlucky with which dots got picked for polar interpolation. You are more than welcome to fiddle with the settings - I left them there so folks could adjust the stock experience if so desired. Our initial cut represents what I felt was a good compromise between performance, aesthetics, and accuracy. YMMV.

Each biome.

So here's how the three scanners work. And as a preface - don't use the large survey scanner as your main source for determining a landing spot. You pretty much always want to follow up to get better data (probably some of the few exceptions being very clear biomes like the minmus flats and the mun craters). Use the big survey scanner to get a rough idea of what's even on a planet. Identify some interesting places to investigate. Drop in a rover with a surface scanner. This makes both the orbital and the NBS more accurate. Not by much tbh in the case of the orbital (it just replaces average with precise values when it does its check, but resolution is the same). If you're happy with the spot, awesome, you're done. If not, use the NBS to do flybys of areas of interest till you find something you like.

Ahhh! What you're seeing there is polar pinching. It gets a bit wonky with interpolation because of how the poles pinch, etc. Note that the rest of the planet is pretty much in-line. (edit) To add a bit more, the interpolation at the poles gets pretty extreme, because otherwise we end up with weird stretchy/smeared textures. That polar region is interpolated from a very tiny subset of data points - so one pixel off (especially as weird as the poles are anyway) and you get a different interpolation. This in turn affects the blending as you come off the poles. If you want to see how this affects the different overlays, feel free to fiddle with your overlay config file - it has comments. Just be sure to back it up first.

Actually this mod came first - and this and many mods before it all use the same ZZZ greenhouse model as it's public domain.

Let's be clear, since it seems you are putting words in my mouth. Perhaps a better term vs. inaccurate would be 'low resolution'. They are not by any stretch pixel perfect. But the data is not, in any way. 'Wrong'. I explained, very nicely, that because the dots are in different places you will have some variance in the interpolation, but it should be very minor (unless you happen to ping a weird biome, like Kerbin's shores. But even then I get enough data for interpolation. They also have different levels of contrast (i.e. your monochrome displays vary by intensity but your heat maps vary by color). That I expect is what is causing you confusion. Your dark patch is probably at the low end of the monochrome threshold, but showing up a vivid green on the heat map (it's low-end threshold). There's a similar variance with lines vs dots vs solid, so again, I expect you have a visual/contrast concern. Funny thing, in my save game just as a sanity check I did a resource comparison accross the mun with all three overlay types. The data result was pretty much the same regardless of what I picked. I did this accross about ten resources, and each one gave me an appropriate idea of where to place my base (turns out water was only in two craters... substrate was nearby one of these, so I landed, ground truth'd, and now have a fairly decent base after some poking around. So to put this to bed. And again, this is coming from the guy that wrote the code. The overlays use the same set of data points. Any variance you see is visual, and likely due to color intensity levels. But you're going to get roughly the same map no matter how you choose to visualize the data. But as noted, this data is not pixel perfect. It is not WRONG, it's just very low resolution, and gives you a pointer in the right direction. The narrow band scanner is the pixel perfect one (and also later in the tech tree).

To hop in. As the guy who wrote that code. The same interpolation data is fed to the rendering engine. Precisely the same. But dots/lines/splotches interpolate it in different ways by filling in different dots. Because they interpolate different things you will get slightly different patterns. These things are *shockingly* inaccurate. They just give you a rough idea of what is there. Hence the other scanners. If you want to fiddle with the settings, by the way, you can. And can get neat things like this (assuming you want to wait 20 seconds for a render on a high-end computer)

CRP is not unstable. What you saw was a pretty massive conversion in anticipation of 1.0 breaking everything - also the conversion of everything from 5L units to 1L units, integration with RealFuels, etc. 1.0 was chosen as the time to do this for pretty obvious reasons There are pretty sound reasons for all of the bits you see there (there were interesting times sorting this). So at this point it's just the odd addition here or there, or minor correction that slipped through QA. And yes, there is a reason for the density mix (talk to the RealFuels guys about that). Probably the one bit you will see change is that resources will likely get HSP at some point. - - - Updated - - - So, for a reboot, you have three choices. 1. Use CRP, and convert all tanks, engines, etc. to the adjusted units and resources (i.e. we all share the same nuclear fuels now). 2. Use resources that do not conflict with CRP and do whatever you'd like with them, but maintain compatibility with CRP-based mods. 3. Do whatever you want with the same (legacy) resource names (at which point you should not bundle CRP because there will be horrible conflicts) and have KSPI be a stand-alone mod incompatible with CRP mods. All of these are valid choices.

DDS is coming. Will look at breaking force/torque (those came from the fine B9 people) Log a github issue for landing gear or any other goodies you want (and why you want them)

Can you log a github issue please? Thanks!

Firespitter version current?

Agree with what Wave just said... don't patch CRP. The entire point is that stuff is compatible and does not change between mods. And messing with densities is going to break lots of stuff that depends on it.

Your install sounds borked. Try a clean install. Orange balls have been gone for ages.

FYI if this is in relation to the IXS enterprise mod, I whole heartedly approve - let me know if you need any assistance.

Remove all EPL parts other than the survey stake and the mallet. And lqdoxygen is very different than oxygen

The radial tanks have that, FTT has kontainers, and new ones are in the works... http://imgur.com/F3Vy4Xv

MetalOre is EL, MetallicOre is CRP. The reason for the distinction is that in EL, you can make RocketParts from a single resource. With the USI/MKS stuff, we require three different resources. Hence the difference.

Logging a github issue is the best way to get these things addressed

Probably need to bring that up in the KIS thread

Dunno, I had a heck of a time breaking one in an atmosphere. but I'll look at the lift numbers.

The stock resource system (and ModuleResourceConverter) work perfectly well

Oh... and you jettison the engine right? When I test it by the time I am gliding in, the only thing left on there is the pod itself, kickstand out.