Gilph

I think you're doing just fine. You are kinda supposed to burn up at Eve. If anything, just do a little more research on the body you wish to visit. You'll find that Eve is probably the hardest planet. So unless you wish to take on the extreme challenge of designing a lander with extensive heat protection, in addition to a monster deltav lifter to get back to orbit, there are better places to visit.

yeah...this is a >7000 deltav ship, so it is not Connected Living Space friendly, although I can move the four Mk1 Crew cabins and docking ports up a bit to make it so, and the large docking ports are for my ore miners mostly, and I can spacewalk the engineer back and forth if I need. But that's a good idea. I should make a new Ceti hab station with SSPXr. I already have the fuel depot station there, so I don't need a lot of tank storage. There are a lot of inflatables, so I should be able to launch a single station without needing construction in orbit. Sounds like a fun project Thanks

OK...Except for Leto, all planets visited, all moons scanned, mining on almost all systems on at least one moon. Even have a probe on a free return from Grannus. Debating on whether to do the 10Y warp to move it along. Updated my boring stick fuel depot/station to a slightly less boring one with @Nerteas excellent Stockalike Station Parts Redux. We are at Minona.

Here is my space station and ore miner around Minona, with Nero in the background. Note that the centrifuge is inflated and I have a deflate choice. I flew it here (13y trip) deflated, and I inflated it when I arrived. Maybe I can do it because my Engineer is named Lefty. Seriously, how cool is that. Ol' Lefty can make anything work. @PlebI updated my usual design to include the viewing port on top, station core, centrifuge, and big science lab. I have the regular docking ports in the middle and the big ones on bottom, well away from the centrifuge. Many will not like that they are attached to fuel tanks, but I dont mind. I make trips to mine ore and fill up the station to support follow-on ships.

When I get home, I can post a pic in one of by glitched posts above, just to make them useful. If you right click the centrifuge, one of the options should be "Inflate". I had even inflated, and deflated around my home world (Gael) before the burn, just to make sure it worked.

Just an engineer onboard. I flew a station with the small centrifuge to a far away moon in GPP and inflated it there.

the efficiency is what it is, based on the rating. I had preferred the curved panels that fit the 2.5 parts because they were more efficient and the extendible ones I treat as more art than function, and I am not a great artist when if comes to vessel building. The curved panels came in very handy when Kopernicus had a bug that caused solar panels to not track the correct sun if more than one light-emitting sun was defined. To get around it, I made all of my stations with curved panels and oriented the stations in a Normal position (perpendicular to the Sun plane). As the station revolved around the planet, the side that faced the sun generated EC, and the part in shade didn't, but I did not have to worry about panel tracking. It worked so well that I no longer use extending panels anymore.

That may have been my post. In my MKS save, I would make Refined Exotics on Iota and return to Gael at a potential profit of about 4M funds per trip. I would not do a powered landing on Gael, so I really needed to land close to what the game thought of as KSC to maximize the recovery percentage. Landing close to Rooks Glory was about 75%, which meant I lost about 1M funds each time. After a lot of test landings, I found a small lake west and a little north of Rooks Glory that got me to like 96%, iirc. It was not near any base, so I always assumed it the KSC reference for recovery was hard coded from stock and GPP and KSC Switcher could not change it. I switched to more of an exploration career save that did not use MKS, so I never really followed up with the issue. Thanks for reporting this. It will be great if there was a simple fix to it.

Hi All, Was just wrapping up scanning Nero's moons and was scanning Julia. On the SCANSAT map, the biome Greater Pigments is being displayed as #LOC_GPP_Planets_Biome_Greater PigmentsDisplayName In looking at Julia.cfg, I noticed that the Greater Pigments displayName is the only one with a space in it. Could that be the reason?

OK...worth a shot The only other thought I have is that a mod patch may have been included to add some other requirement for inflation, which may not be reflected in the error message. For example, I think there is a patch for MKS that requires MaterialKits to inflate these parts, just like the MKS parts. Since it's a MM patch, it would not necessarily give the error that you don't have MaterialKits, it may just throw the error in the base code, complaining about engineers. Maybe temporarily remove the MM patches to test?

Hi, and welcome to the forums. I have been testing this myself in the last few days. I updated my stations to use some of the new parts, including the small centrifuge. I had launched as a test with a pilot, scientist, and engineer. It worked fine, the centrifuge inflated with no problems. I noticed you did not mention if you had a pilot. I noticed that the station control modules say they require 1-2 pilots. Does this mean that if you do not have a pilot in the control pod, then you do not have control of the station, including the ability to inflate modules? I have not tested that yet.

yeah...but that's the fun part of MKS. It's like playing a whole new game. USI-LS has a very similar vibe to Snacks. Instead of Snacks, you have Supplies. It does not have the individual resource complexity that TAC has, with respect to feeding Kerbals. Both MKS and USI-LS have ways to deal with Supplies management, from the simple to the complex. Also, configuration changes can be made to tailor it even further to your liking.

Hi, I've been there...especially when building SpaceY fuel freighters. The heavy duty RCS modules are like 12 -15 times more powerful than stock and they consume 12 - 15 times the monoprop. I was faced with the choice of using those monster monoprop tanks or make smaller fuel transports. I settled on going back to a smaller vessel, using the regular 5 way RCS part and using verniers, since I have a lot of fuel onboard. A workaround to the MJ issue (latest dev build) is that I use warp. I use MJ to get the ship moving to get it aligned to the starting point with a .4 speed limit, and hit a x5 warp. The ship drifts towards the target spot but uses no monoprop. Looking at the MJ docking screen, when the doc axis difference gets small, I stop warp. There's a burst of monoprop to stop lateral movement and pushes forward to dock. Hit warp again to get close and then stop. Another alignment burst at the end, and you're done. It can save a lot under the right circumstances. It looks like the MJ team knows the issues, but I would like them to consider that, during the docking process, MJ never seems happy with the speed of the ship. It always feels the need to correct something, especially the scenario when you are lined up and moving forward from about 30m. RCS will burn to accelerate to the speed limit, which stops at about 20m, then will actively burn to decelerate to close to 0. If the target is stable, there should be a coast window where no RCS is needed. The burn just before dock can also be very extreme. I've had vessels at .1m not dock because the RCS is burning in the opposite direction harder than the docking port pull force. Hope this helps

Hi, been catching up on this forum and looking at the V18 upgrade discussions. Sorry if this is a silly question: With respect to background processing, after a body has been scanned, is it OK to turn off the toggle for background scanning for that body to save the processing overhead? Will disabling the individual scanners on the orbiting platform essentially be the same thing as turning off the radio button for background for that body? For example, I use GPP and have scanned about 15 bodies to 80% completion (I don't do BTDT scanning, so it's 100% for me). Once the scanning is completed, I turn off the scanner hardware on the orbiting vessel and leave it there in orbit because I also have a relay attached. But, I still have background scanning enabled for all of those 15 bodies. Is that a waste of processing? Thanks

Working hard on new Geminus, hauling ore to station with Gratian in background

Hmmm...is it a concern that the error text referenced that MaterialKits were missing when it was only EC that was missing? I would have thought that it would say only: "Missing resources to assemble module: 4000 electric charge"

My bad...while my post did say my upgrade was very smooth, @linuxgurugamer reminded me that I failed to mention that I made a full backup of my entire KSP directory and had a few copies of my persistent file saved on OneDrive before I applied the upgrades. Please perform whatever backups you need before upgrading. “Luck is what happens when preparation meets opportunity.” – Seneca

Updated everything, including Kopernicus. No broken saves. Very excellent. Thanks

Here it is. The gray section was labeled as south pole and is pretty extensive. It actually extends all the way to North Pole. I also updated Scansat and got the same result. If the Eta map is not correct, I can do some things with Scansat to see if I need to rescan the bodies that changed. Thanks

Hi, All Was able to upgrade to 1.6.0.1 successfully today, mainly because I haven't built any surface bases and was able to get all ships in orbit. Went to look at new landing spots on Eta, and noticed that the South Pole biome stretched past the equator, all the way up to around 40 deg N in some spots. Is that correct or is it an artifact of the upgrade? Thanks

I assume what didn't work was to limit the speed to 0.1? That was my workaround also, as any speed that is not in the exact forward direction toward the target port is not recognized. So, if you need lots of lateral movement to line up, you end up going too fast and causes the back and forth. Not sure what "flip around like a madman" is trying to describe, but have you made sure that the part that performs the control function is oriented correctly? That has screwed me up in the past.

I've done two advanced xfer calcs using 771-773. They worked really well, but have not done anything with asteroids.

Hi, is this new work DirectX11 friendly? Searches in this topic did not have any hits since early 2016 and I'm trying to use only DX11 friendly mods. Thanks

The Kopernicus fix that addressed the solar panel tracking seemed somewhat incomplete. In GPP, the panels now track the brightest source at any given point (Ciro in almost all cases), but the "Status" field on the panels still reflect the status as if Grannus was the source. I see panels that completely face Ciro on a direct line of sight and generate the correct amount of EC, but the status will say it's blocked by a vessel part behind it because Grannus is in that direction. So, i can believe there may be some issues remaining.

This is a known issue and I believe an open issue in github (not able to check atm). I seem to remember that this started when a change from a few KSP versions ago was implemented that had a comment that mentioned waiting to warp until the attitude was more precise. I thought it was a little strange at the time because after the warp starts, things immediately drift from the maneuver marker, so why should there be tighter tolerances beforehand? But, as you mentioned, I was always able to give it a little kick by hitting the warp key, so I never really thought about it much. It would be interesting if someone remembers that change and looks at it to see if the issue is there.