DoomHawk

I also have experienced this! Sadly I found this mod because my Career mode is having a weird issue where the stock landing gear don't show up but spaceplane contracts are worth $$$$$$. Any ideas?

Thanks! I updated to the most recent candidate release on the GH, and that seems to have fixed it. Cheers on sir for keeping this great mod alive and well!

EDIT: Well, youâ€â€in an imgur albumâ€â€had a better screen shot to use as an example, so I stole it: Just so that I make sure I'm clear before moving forward, what I'm referring to is this (not my screen shot, just using it as an example/template): If using the image above as a guide, when I click 'Analyse Scan' for a SCANSat part (let's assume Lo-Res scanner, and that the body has been > 95% scanned), I would get the above, meaning it would show 0 Mits of data worth 0 science, transmittable for 0%. I am absolutely positive that it isn't only "Recovery: +0.0 Transmission +0.0" as that would indicate I've already collected that science. I have never collected SCANSat data in this save file, this has happened across multiple save files, and that interface shows me Data Size: 0 Mits I was not aware of the debug window, that will come in handy for more than just this troubleshooting! I'm at work right now, so I cannot test this, but I will as soon as I'm home and I will let you know what I see in the debug window. My apologies, as mentioned in my edit, my 'complaint' about this issue appeared hasty. Again, I'll test when I'm home and report my findings. This, I believe, is directly related to the issue regarding getting 0 science data from the SCANSat. Since I never get science data from the sensor, I have nothing to transmit. Since I cannot transmit, I can scan a body and create the map, but I cannot 'save' the map. Example: I send up Surveyor I to map Mun so I can choose a suitable landing site for Apollo I. Surveyor I completely maps Mun and is deorbited. (I believe due to the fact that I cannot transmit the science data) If I then send Apollo I (with the necessary SCANSat hardware) to Mun, when it enters Mun SOI, I will have no mapped area of Mun. Meaning, Mun will say 0% scanned, even though Surveyor I already scanned it to 100%. Maybe it was an 'unintended feature', but previously (before the v6 and 0.23.5 updates for SCANSat and KSP respectively) I could do the above, and (seemingly since I could transmit the data back to KSC) if I sent another craft to the same body's orbit, I would be able to see the map of the body and where my craft currently was in orbit above the surface. In this manner, as it runs right now in my KSP, if I want to have Mun (for instance) mapped 100% so I can choose a specific landing spot before attempting said landing, I must create a craft which is capable of scanning Mun 100% (basically capable of starting in a polar orbit, slowly transitioning to an equatorial orbit to ensure scanning of the entire surface), and THEN capable of landing on the Mun also. TL;DR: If I want to use a map for landing, I have to either leave the vessel which did the mapping in orbit (assuming here, I haven't actually tested this, but I believe that I would see the map in this case), or I would need to map the body first with the vessel I will be landing, then land it. Used to be that once I had 'transmitted' that map back to KSC, every subsequently launched craft would see that map, provided it had the necessary hardware of course. Phew, sorry if that seemed pedantic, but as a software engineer myself, I can't stand bug reports which are completely vague and devoid of any actually useful information/test results.

Has anyone else experienced, since v6 of SCANSat, not getting any science data from SCANSat? I can scan and map an entire body, but when I go to analyze that data and send it back as science data, it shows that there is no science to transmit. Yes, I am using RemoteTech 2, but I do not believe that to be the cause. I have ensured that the connection to the KSC is live and functioning fine. Other science data transfers over the same connection without issue. Any thoughts? I've also found that on IVA, the RPM Asc/Desc screen doesn't always seem to render the mapped area very well. Maybe that's a clue? EDIT: After perusing this thread I found that others are having similar issues regarding RPM and I believe I see why my RPM is not functioning as expected with SCANSat. However, the larger issue of getting science data (and also 'saved maps') from SCANSat persists.

Has anyone had issues with the current build where it loads GameData fine, but when it gets to the black screen with the 'orbiting loading' indicator in the bottom right, the orbits stop moving and the whole game crashes (not a freeze, proper crash with a crash dump). I can submit the crash folder if so desired, just thought I'd see if this was a known issue with a known fix because I bought a 270X4GB mostly for KSP and would love to enjoy these Visual Enhancements!

Something you can try is this: TAC Fuel Balancer I haven't tried it yet, but I found it browsing the SpacePort today and it at least looks to be helpful in this process even if it doesn't make it one easy step. Back to Squad implementing it, I'd be happy if fuel lines were respected when transferring fuel (also allowing 'backward' flow for the fuel lines on the 'destination' craft), not just when an engine is consuming the fuel. All the fuel tanks in a given stage are almost ALWAYS aspargused in my rockets, so that would solve the problem by just transferring out of the middle tank.

^THIS. We can create our own parts with essentially no restrictions, so if you just want a probe that has a goo canister on it, you could use some config file trickery to turn the probe size fuel tank into a goo canister. It is possible, but it isn't done that way now to bring some balance to the game. That being said, I'm all for having an inline one, and actually multiple experiment sizes for different size craft (with a science penalty for smaller experiments obviously) would be a great addition to the game.

A classic boxcar average sounds perfect here. I think the "fudging" concept is what the OP had in mind, and I think this is a great idea. This could also be implemented for nearly circular orbits to get rid of the wobble because for people like me who run RemoteTech and need geo-stationary sattelites, that gets pretty annoying pretty quick. Does anyone have any idea if this would be achievable through a mod? I'm looking to get my hands dirty with a mod (I'm a programmer by hobby and trade) and this would be a great one, but having not worked with any modding of KSP yet I'm not sure what's exposed to our use/manipulation and what isn't.

How about this: we split science parts into two categories: 1. Data collection parts (thermometer, barometer, etc.) 2. Individual experiments (Materials and Goo) The data collection parts would generate a certain amount of data per biome, per time unit (take your pick: min, sec, hour, score, fortnight). Each biome would still be capped like now, and the data collection rate would follow a 'reciprocal function' so that early on you would get a lot of data per second in that biome, but the rate would decrease and level off rather quickly until it becomes a slow, steady data earner. Think about it this way: we still learn new things about our atmosphere from our trips to space, but we learned a LOT more the first few times than we did it. (the cap is necessary in KSP for many obvious reasons and is still fairly realistic) The individual experiments would function as they do now in .23 (along with the lab). Data would only be converted into usable "science" when either: 1. Transmitted back (at a penalty, meaning you must either perform the experiment more times, or spend more time in that biome with that 'sensor') (unmanned probes also have an additional penalty for transmitting as it is obviously much easier to just shoot a probe out into oblivion than it is to get Kerbals there and back again [a Kerbal's tale, by Jebediah Kerman]) 2. Gathered from a recovered capsule at no penalty The lab would function as it does now, reducing the penalty for transmitting data instead of bringing it back home, while requiring to Kerbalnauts for that data boost. This would also make space stations instantly useful as long term science gatherers which the "min/maxers" can ignore by landing on Duna in their 3rd flight, but the rest of us can use earlier on to keep science flowing while we take our sweet time exploring the Mun, Minimus and beyond. Also, this would make unmanned probes much more valueable AND much more realistic. Combining this with the concepts in RemoteTech would make for a very realistic mission progression throughout KSP. Addition: We leave in the ability for us to use EVAs to collect science from individual experiments as this values manned missions over unmanned ones even further. (Manned missions have a higher inherent risk [definitely will once reputation is involved]) Reddit Link