Brotoro

If space is expanding at a CONSTANT rate, then the further away an object is, the greater its redshift, because there is a greater distance of expanding space between us and the object. It doesn't matter that it takes longer for the light to arrive to arrive from more distant objects...you would still observe this. But we have found that the redshifts of distant objects deviate from the linear relationship expected for a constant expansion rate, from which we learned that the expansion rate has been accelerating.

Don't power the ions using solar panels...use fuel cells. Much less drag. It's still not going to work over Kerbin, but it works over Duna.

Is Laythe supposed to have cities? I can't find a way to turn them off. Pictures of what I'm seeing: This is in KSP 1.1.2, with E.V.E. that I downloaded on April 28.

How could Squad possibly not know this by now? It's the first thing I noticed after opening an old save in 1.1 (which other people had been playing for weeks before me).

Absolutely I use standardized boosters. First: more realistic. Second: saves time to just grab a booster from the subassemblies. Third: I like to spend more time building payloads than building lifters.

I have a LOT of ships in my saves... so I waste an inordinate amount of time scrolling through the long list of ship names when I want to open a ship file in the VAB or SPH. Could we PLEASE be able to type a few characters of the ship's name and have the list jump to ship names starting with those letters?? This has been standard practice in graphical user interfaces since the dawn of time (the dawn of GUI time, anyway), and it would make my life easier.

I would like folding grid fins like you see on the Falcon 9 first stage. I make ships that have to fly nose-first going up that I would like to fly tail-first coming down, and small folding grid fins would be great for this. It's possible to some of this with AIRBRAKES, but something smaller would be appreciated...hence the request for small grid fins.

What confuses me about how Squad would calculate wheel slippage is that I control my rovers with a binary state control: I'm either pressing the "i" key to go forward, or I'm not; I don't have a continuously-variable throttle. So if the program calculates the translational force the wheels will apply to the ground (assuming a wheel radius and maximum motor torque), and this exceeds the maximum friction force the wheels can provide (based on normal force per wheel and coefficient of friction between the given wheel and given surface), won't I end up spinning my wheels any time I try to move unless there is some sort of automatic traction control (a torque limiter on the wheels)?

I was back in 1.0.5 yesterday... arrrghh, it's amazing that I used to put up with that 32-bit piece of junk crashing every 20 minutes or so because of hitting the program's memory limit. So frustrating. And the reduced graphic settings required to keep the program from crashing even that often are ugly. Finally getting to play in 64-bit with full graphics quality makes 1.1.2 a sooooo much nicer experience. But my exploration missions are so heavily dependent on rovers and planes that the terrible wheels/landing gear bugs in 1.1.2 make it difficult to do anything serious.

I had the same problem with my Long-term Laythe and Developing Duna missions (lots of ships used the old Mk1 cockpit and would not work with the new Mk1 cockpit because of the repositioned hatch). I used the Kerbal Historical Institute mod to get the necessary files for the old Mk1 cockpit (and interior views), then I did a Find & Replace in my Save game sf file to replace all occurrences of the old Mk1 part name with the slightly different name for the old Mk1 cockpit from the mod (this was all tested on a COPY of my old save file, of course). Then all my ships in flight got to keep their old cockpits, and I can build new ships with either the new Mk1 or the old Mk1. The Kerbal Historical Institute mod has lots of old parts...but I only installed the Mk1 cockpit.

For the rover mission up the mountain with the standard wheels, I used the default Traction Control (and friction override to 5). I didn't do as well that time as I did later with the Grippy Tires when I was using Traction Control set to zero (and friction override set to 5)...but part of that may have had to do with the different wheels, and part of it may have been experience from the previous climb (and being more careful when needed). Certainly RTGs are expensive, and fuel cells are the poor man's option...although refueling would be a bother if you want to do long-range rover missions since we lack hoses (but I assume most people don't do drives as long as mine). I've never played career, and my whole kerbal society is dedicated to space travel and a strong nuclear industry...so I like RTGs and have all the money I need to pay for them in my sandbox. The price on RTGs would BE cheaper if your nuclear industry was geared up to crank out thousands and thousands of the things. Also, you don't need to have as many RTGs as you might think if you just divide the wheel energy needs by the RTG output...because that's a maximum energy draw by the wheels, so for a lot of places (like mostly level areas) you won't draw that much. And in the places where you DO draw lots of power, batteries and frequent breaks can get you through. Still, I miss the good ol' days when rover wheels were more effective. I was testing the new BirdDog 1.1 on Laythe, and the wheels simply can't drag that plane up slopes like they used to be able to do. It takes a lot more contour driving...and I can't use Phys Warp to make things take less time for me because the rover/plane jitters crazily at 2X with 1.1.2 wheel physics.

18 tons? The BirdDog 1.1 only masses 7.5 tons. And 38 RTGs is only 3 tons... so what else did you put on that bird? I think if you want that much power, you might want to consider fuel cells.

Sure, I have a backup to my settings.cfg file, too... but I never know if it's safe to just use an old settings file with a new version of the program. Who knows what they may have changed.

I don't think that "fade to black" is a desirable solution because it's not just visibility against planets that is a problem -- I've also run into visibility problems when trying to adjust an orbit to touch another orbit (which was hard to see against the background of space because, well, space is black). But I'm perfectly happy with the adjustable orbit shading that Squad gave us. I set mine to reversed, but with 50% fading...so I get essentially solid orbits like the good ol' days, so I'm a happy camper.

I haven't noticed much of a change from 1.1.1 to 1.1.2, except that now in 1.1.2 my airplanes (exactly the same ones that worked fine in 1.1.1) are showing tendencies to yaw during takeoff and after landing.

After playing around in 1.1.2 tonight, I haven't seen anything that improves any problems that I had in 1.1.1. But 1.1.2 has added a tendency for my planes to veer in yaw when trying to take off or after landing. Same plane designs, unchanged since 1.1.1. Sigh.

"Trailing like a comet" is not a correct explanation. Comet tails do NOT trail behind comets. Comet tails are blown away from the Sun by radiation pressure and solar wind, independent of whether the comet is approaching or receding from the Sun.

No, the wheel collision problem is apparently an issue with Unity...so 1.1.2 did nothing for that. I'm suffering from "update fatigue" again, just as happened after the release of 1.0 and subsequent patches. Install..get all the settings set the way I like...see what mods are broken...test stuff again in the new version... ...I need a break.

Ho, hey... another Parts Request thread. I'll make my usual request: Refueling Hoses!

The standard convention in Astronomy is to show the revolution of planets around the Sun from "above" the plane of the solar system ("above" being taken as the side of the plane where the Earth's north polar axis points out), and in that convention the planets revolve around the Sun in a counterclockwise direction. Also, the orbits in the little animation are shown with the line thickness fading (the effect that was later built into map view), which most commonly adopts the convention of showing the direction of motion with the thicker part of the line behind the planet (as Squad adopted for map view...much to the displeasure of some because it made the forward part of the orbits difficult to see). The planets in the "wait animation" were moving backward by both conventions. The outer planet was also moving faster than the inner planets, which does not happen in reality. So I found it distracting (for the same reason that I would find "wait animation" of an hourglass that showed the sand flowing upward to be distracting). Side note: By the standard convention of displaying rotation/revolution, our Milky Way Galaxy rotates in the CLOCKWISE direction as seen from "above" (the side of the galactic plane the Earth's north polar axis points out).

Yes, the old version had the outer planet moving too fast as well as all of them going the wrong direction. But, as I said, they are revolving properly now (this includes speed as well as direction)... although the code optimizations result in the animation staying on the screen for a shorter time...on my new machine, anyway. But I'm glad it was fixed. Attention to the little details as well as the big bugs is appreciated.

Oh, hey... The planets in the little "Loading" animation now revolve around properly in the counterclockwise direction. Good job, Squad.

When I docked a rover to a plane to refuel it, the rover went through a brief epileptic fit that resulted in blowing a few of its ruggedized tires. It wouldn't surprise me at all if a similar shudder would destroy the weaker small wheels.

Thank you for the reply. Then this "issue in our current version of Unity" is now the bane of my existence, a thorn in my side, and the focus of my ire for having made me unhappy. Hopefully you can convince Unity to slay this demon. But if you have to wait around for Unity to fix this issue... in the meantime you could increase my happiness by giving my kerbals surface refueling hoses. Please. Thank you.

And if you have a rover docked in your cargo bay, are the wheels blocked because they are in contact with the floor of the bay? Why should it care about the interaction with the floor if the cargo bay until it is undocked and becomes a separate craft (at which point it can be settled onto the floor)? This seems like an edge case that is messing up all the rest of the world of rover usage. They can make a special exception for checking the interaction of wheels with the floor piece of a cargo bay if they want, as long as it solves the other problems to remove all other self interactions.