Tebryn

regarding the polar texture compression, you can create your texture in a polar alignment for text and lines near the poles, then use Polar coordinate distortion to convert it from a circular image of the pole to a rectangular image with the correct distortion for your texture to get wrapped around the sphere later. Only tutorial video I could find quickly using GIMP: it's a bit old but covers the basics. once you have your equirectangular projection, you can clean up your equatorial section and finish out your texture. and everything should look clean. Currently fiddling around creating multiple independent layers that I can work with to make navball creation a bit easier. not sure what look I'm going to go for yet though.

NavBall I just got done playing with if anyone is interested: Proot originally sourced the Apollo texture back in the old Navball texture exporter thread. I had played around with converting it to KSP navigation style for some time but never got around to finishing it. Fortunately I stumbled across Yarbrough08's work: http://forum.kerbalspaceprogram.com/threads/98250?p=1541279&viewfull=1#post1541279 So I fiddled a little bit with the numbers and converted it to DDS. Dropbox link is in the Imgur description, figured I'd bring it here since the other thread is kinda obscure for someone searching for NavBall textures. Included Red and Green Versions, The Pitch numbers are kinda small, without navball enhancer I wouldn't be able to read them at my native resolution. So I might play with them some to find a better size. (Font used is Bitwise, by Digital Graphics Labs. If you feel like messing around) Obviously you can use the Imgur copies if you don't want DDS files. just remember to flip the IVA version Horizontally. CC BY-NC 4.0

the price on the sphere is 99% from the K+, which since it starts empty, means the tank is only a few thousand. If you manage to fill it and recover it back at the KSC though you are set.

it's referring to the 'MODULE = ModuleScienceContainer' definition in the part configs that tells the game you can store experiments. Which all the command pods and the mobile science lab have in stock. Many mods may have their own parts with that module as well, including some parts without crew space.

sounds like it's the bug from Science Alert, It was killing science transmissions silently. Had this same problem and wondered if they had nerfed repeat science. check the new version. http://forum.kerbalspaceprogram.com/threads/76793-1-0-ScienceAlert-1-8-6-Experiment-availability-feedback-%28April-28%29?p=1878092&viewfull=1#post1878092

navball skins were generally done via NavballTextureExport : https://bitbucket.org/xEvilReeperx/ksp_navballtexturechanger/downloads (http://forum.kerbalspaceprogram.com/threads/69540-Making-high-contrast-nav-ball!?p=969741&viewfull=1#post969741) no update for 1.0 yet, may or may not work (haven't gotten around to testing it myself yet)

So... with solar heating, does anyone have ideas to make solar harvesting feasible again?

Loaded up and running on 1.0 for a few hours, no log exceptions, no problems. Resize and position shifting still working fine. Thanks for the great mod Kitoban!

I was going to create a Github issue about this, but wasn't sure where this was going post 1.0 release. so I figured I'd throw it here. Is there any plans at this time to include a way in game to see and change/reset your game regolith game seed? Since large portions of this are getting baked into stock, I would imagine that adding a section to the debug menu would work. as it stands it's not an easy thing to get to and change if you are testing configs and want to verify that changes work across multiple seeds. (Or just want to try for a seed that actually gives you K+ in a harvestable solar region )

You shouldn't have any atmosphere decay effects anywhere around the sun. But you do need to stay above 1340 meters. which is where you start blowing up. (and just rotating your ship when you are low around the star can change your periapsis by thousands of meters. so you need to keep an eye on it.) if you wanted it to be as high as 200km, then you would be looking at a max altitude setting of about 0.00764526. This will give you resource bands about 2,616m thick of varying yields from surface to 200km EDIT: tested this instead of just talking out the other end. and it seems the code will not generate multiple bands, so the easiest way to do this would be to instead just generate an extra wide band centered in the default min/max altitude. once I figure out the exact size needed i'll update this post. (time for sleep now...) EDIT 2: after extensive testing, it would seem your individual game seed has a much more significant impact to the resources than what I was expecting. so any numbers I give could be vastly inadequate, or incredibly over done. my own seed seems to crush any resource definition for interplanetary bands to almost nothing (the K+ solar band for me by default is 1430 or lower) so any numbers I give aiming for a specific altitude will tend to create huge swaths of resources for everyone else. My own game seed is 429779331, if rover or someone else wants to test things.

You are using an outdated regolith. Update to the latest version https://github.com/BobPalmer/Regolith/releases there was a problem where the exoplanetary resources were ignoring some of the boundary definitions.

sounds like your doing it wrong. and works when I tested. Ejector module functions and always equipped parachute plugin still working. debug open to prove .90 (biome in map view display)

ah, glad it worked. started to get worried that you were taking an axe to any line with scansat. It sounded like surgery with a chainsaw.

catching up on your edit, nothing under the ResearchAndDevelopment SCENARIO entry should be affecting map rendering in any way. Killing entries there get's rid of your experiment history and researched parts, which only affects future calculations for science value and what you have unlocked. the only parts that would affect map rendering would be under the SCANcontroller SCENARIO entry. Which will be in one large-ish chunk all in one spot. tell you what, put the persistence.sfs file up on dropbox and I'll take a quick look and see what I can find. no promises. preferably the backup, before any edits or purges. edit: and I have no idea why this didn't just update instead of making a new post. sorry for the spam DMagic.

Alright... MAKE SURE YOU BACKUP YOUR SAVE before you go into this. Open up your saves persistence.sfs file in notepad (or preferably notepad++ but not required) you are going to searching for SCENARIO { name = SCANcontroller scene = 7, 5, 8 colours = 0 map_markers = True map_flags = True map_orbit = True map_asteroids = True map_grid = True map_ResourceOverlay = True projection = 0 ETC... Just search for 'name = SCANcontroller' there should only be one entry. (although if you have more than one there is more weirdness going on than I thought... eh, kill them all you made a backup right?) you're going to delete all the nested information under that SCENARIO module. Everything from that { to the corresponding ending }. There will be nested brackets with more information, they all go too. once you have killed all the nested information, you can then delete that empty SCENERIO module (killing everything inside first helps keep track and prevent you from going too far) Make sure that you do not go into the next SCENARIO module in the persistence.sfs file, as you will likely corrupt other parts of your game. again MAKE SURE YOU BACK UP YOUR SAVE what you are doing here is removing ALL the information that SCANsat saves into your game. all the information on vessels with active and inactive scanners, settings for your windows, current progress for all scanning, all of it. Which might get rid of whatever corruption you have going on. I would think that the reset all data button would already do this, but who knows. If this doesn't work, then you are going to need more professional help, since you said it's working on other saves.