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.

https://github.com/S-C-A-N/SCANsat/blob/release/SCANassets/Resources/SCANresource.cfg (you can also find a local copy in gamedata\SCANsat\Resources\SCANresource.cfg) and for the default scanners: [TABLE=width: 595] [TR] [TD]Nothing = 0 // MapTraq (Legacy Background Scanning - Depreciated)[/TD] [TD=align: right]0[/TD] [/TR] [TR] [TD]AltimetryLoRes = 1 // low resolution altimetry - RADAR (limited zoom)[/TD] [TD=align: right]1[/TD] [/TR] [TR] [TD]AltimetryHiRes = 2^1 // high resolution altimetry - SAR (unlimited zoom)[/TD] [TD=align: right]2[/TD] [/TR] [TR] [TD]SCANsat_1 = 2^2 // Unused, Reserved for future SCANsat scanner[/TD] [TD=align: right]4[/TD] [/TR] [TR] [TD]Biome = 2^3 // biome data - Multispectral[/TD] [TD=align: right]8[/TD] [/TR] [TR] [TD]Anomaly = 2^4 // anomalies - Multispectral (position of anomaly)[/TD] [TD=align: right]16[/TD] [/TR] [TR] [TD]AnomalyDetail = 2^5 // anomaly detail - BTDT (name of anomaly, etc.)[/TD] [TD=align: right]32[/TD] [/TR] [/TABLE] - - - Updated - - - Edit: Note to self, read to completion not satisfaction... Clearing the map data should have done it. since the data is saved in the persistence file.... you used this, <=- right there, under data management to purge it right? If that is what didn't work about the only thing I can think of is removing it from your persistence file by hand in notepad. But I'm not sure how well that will go for you. I'll get back in a sec to see what you would need to look for and delete to do it manually...

I've noticed that CIT and KERT are no longer being distributed in the pack, but the HERP_MaintPod still has ModuleResourceTransferEnabler. Has this functionality been folded into USI in some way or do we need to install KERT separately? I'm trying to catch up on changes since I took a break from KSP. I have seen that MKS/OKS now has automated distributors with matching resources based on the module type, and a EVA (engineer) operated ModuleFieldRepair that pulls from/pushes to attached parts on the same vessel defined as a warehouse, but nothing that would allow transfer between an unattached HERP_MaintPod to another vessel nearby. I feel like I am missing something and my usual google mastery is failing me.

Thanks for the quick turn around!

Love the mod and how useful it is, but I have encountered a bug with kerbals on EVA. I can take data from science modules and science report containers, and store data taken this way into parts that have ProbeScienceContainer or CapsuleScienceContainer, but the data stored in the Kerbal EVA report and surface sample 'slots' don't get stored, I have to enter the vessel to store them. tested this in a clean KSP install and with only Science Containers and Module manager installed. (Storing EVA and surface samples work normally when science containers is removed, although I had to launch a new vessel to get right-click GUI back) I have also noticed that the parts with ProbeScienceContainer or CapsuleScienceContainer modules don't respect ModuleScienceContainer{ allowRepeatedSubjects = False EDIT: Reading back through more of the thread I see that this may be intended, if so disregard. If I take multiple reports from the same area via multiple goo canisters for instance, when I run collect (or have automatic collection on) it will pull all the reports into the command pod even though it normally should only be able to take one of them. Entering a capsule with the repeated reports will act as normal, storing what it can and throwing a GUI to board anyway (dumping extra science) or cancel. (I can even use take data and pull all the duplicate reports and get the error trying to go back into the pod, but still store that data with the rightclick GUI then enter without problems) I was able to test and confirm both of these from the launch pad in a new game, take an EVA report and try and store it from outside the capsule and it failed to store (entering the pod stores it normally, then I can pull and store it normally while on EVA). and if I turn auto collect on, run a bunch of crew reports and have them all stored in the capsule (even though they are repeats from 'on launchpad') Recovering the vessel shows all the individual repeated reports in the mission summary screen, and reviewing data in flight mode shows them all as well. I'd post log files if any of these events threw an error or got logged in anyway. Sadly the output_log had nothing useful to share. All tests conducted on KSP .90 Win32 client , MM 2.5.6 and Science Container v.08.1 (ScienceContainers.dll file properties says v1.0.0.0 btw) Hope this was helpful and thanks for the mod!

when you inflate the pod the resources 'unpack' and you get the advertised values.

There hasn't been any commits to the NEAR branch yet. IIRC he tests and does all his dev builds on FAR then after a release he updates NEAR to match. Edit: Shouldn't be long though for NEAR, since he pushed a FAR 0.14.6 now. https://github.com/ferram4/Ferram-Aerospace-Research/releases/tag/v0.14.6

pretty sure it is a stock bug, as I have managed something like what your talking about without science alert (at the time). I was able to get it to work by waiting for any animation on the antennas to complete, then pushing another single report out (just run another re-runable if you happen to be out. doesn't have to actually give a science return) it would then push all the extra reports that got 'lost' with that new report. mine doesn't sound exactly like yours though, mine came from sending another report to transmit when another had ended and the antenna was running the close animation. the report(s) would just vanish until I pushed another. hopefully this fix works for you anyway.

no need to recompile, just pull his dev version from his github https://github.com/ferram4/Ferram-Aerospace-Research/tree/master/GameData/FerramAerospaceResearch/Plugins when he pushes a commit he also pushes an updated DLL, he just doesn't package a release for it.

except when you have a MM config that blanks out all the TechRequired nodes when CTT and TechManager are present. https://github.com/BobPalmer/FTT/blob/master/GameData/UmbraSpaceIndustries/FTT/CTT.cfg

it's not a problem with SCANsat its a misconfigured part on USI's side. it has been corrected for next release. and without more details it's hard to say why you see something on Mun but not minmus.