Dunbaratu

I'm trying a larger payload. I knew it would need more reinforcement but the chief problem I was having was the inability to connect anything to an engine so strutting was impossible. Finding out that it works when the engine is the endpoint but not the startpoint of the strut made all the difference. It's not a thing anyone can be expected to learn by experience because it is a very weird non-intuative workaround for a finicky user interface problem rather than something you can work out by any logic.

Thanks for the advice on making a strut that ends on the engine instead of starting on it. That works. Even though it makes no sense why the editor makes you do it that way. I can't see any real difference between strutting from engine to tank versus from tank to engine other than just a weird bug in the user interface. Shouldn't the engine become just as "immobile" when the fuel tank disconnected? It's just as dead in the water as the tank is when it has no fuel. None of that is properly described by the word "collide" though. Things that were already touching each other aren't colliding, they're pushing. It's the difference between boxing and wrestling.

I've been trying now for quite a while and the chief problem seems to be that the game utterly refuses to ever attach ANYTHING to a mainsail engine. I can't attach struts, girders, I-beams, or anything at all. Whatever I try to attach to it just stays red and won't go "green". When I thought I was attaching something to the mainsail engine, I was actually attaching it to the very bottom of the fuel tank above it. It seems the yellow ring around the top of the mainsail engine is just simply NOT a clickable surface - at least that's how the VAB is acting.

My TWR is very low. Max throttle all the way still only has me going 100 m/s at an altitude of 5000. It *barely* moves up until it gets into the thinner air, and the "collision" usually happens under 10,000 feet before it gets to where I can do that. The mainsail engine is used because I'm launching something heavy. The problem is just how do I strut it? There's nothing sticking out, and if I add girders to make the strutting work, I end up breaking the bits then.

When the ship breaks apart and the after-crash report shows the first failure as being an engine "colliding" with its OWN fuel tank, how on earth do you change the design to fix that? First off, "collide" is probably the wrong word to use since it implies that two things start off NOT touching and then touch each other through movement, and this is the exact opposite - this is two things that already are connected and the connection breaks and they become disconnected. That's sort of the exact opposite of a collision. Secondly, what on earth am I supposed to do about it? How do I make a connection stronger than simply attaching the engine directly to the tank? Struts don't work because there's no bits sticking out to strut to.

How do you strut between engine and fuel tank? They're both in-line and no bits stick out to attach to.

I ended up giving up and letting the station be deleted and I rebuilt a new one. When I tried copying the station from the old save back in, and then delete just the Buran Arm part from it in the file, It did load the station but something must have been wrong with it because when I try to focus on the station and move control to it, the game crashes, so I assume just deleting the PART section wasn't good enough and created some sort of invalid hanging reference.

I accidentally deleted my space station because it had a robot arm on it, and I had to de-install the robot arm mod to make .20 launch things correctly, and in so doing the program deleted my space station because it refused to load a station with a missing part definition, and then it immediately wrote a new persistence file with the station missing. Sigh - that's a downside of buying the game through Steam. I didn't choose to upgrade. It upgraded for me when I tried running the game today. That ended up meaning I didn't know ahead of time an upgrade was coming until it was already in the midst of happening, and therefore I didn't have a chance to remove all mods first.

Just tried it - it's terrible! Not only does it fail to load the space station but it DELETED it because of it. Lucky I had 'cheated' and save-scummed before hand. I'll have to edit the save file by hand to remove the part.

I was going to ask which "year" was meant. An Earth Year, a Kerbin Year or a Duna Year? (And of course if you assume Earth year because of the "364" days being one day shy of an Earth year, you then have to ask WHICH specific Earth years you meant. Some spans of 11 years are going to include 2 leap years, and others are going to include 3 leap years, depending on exactly when those 11 years start in the leap year cycle.) Perhaps it would just be better to issue the challenge in terms of total number of days period.

Thank you. This is most handy. Now my kerbals can exit the craft and repair a blown tire without having to watch the rover roll away from them and leave them stranded as they try to do it.

Landing legs on the roof, positioned upside down. can act as levers to try to flip the rover over. Test your design on Kerbin on the lauchpad first, before attaching the rest of the rocket stages to it. I can often deliberately cause a rover to fall on its roof by driving it off the launchpad very slowly so it falls off the edge of the platform and rotates as it does so. Then once on the roof you can test your self-righting mechanism.

I can't figure out how to make a rover stop and stay stopped. As long as there's the slightest slope, the rover will start to roll. There seems to be no way to park it other than deliberately breaking the tires so the wheel no longer works like a wheel. Even rightclicking and disabling the wheel simply removes the ability to control it rather than stopping it, it still rolls freely after doing that. You can lock the wheel to stop it steering but that's not the same as locking it from rolling.

So wait, when this effect is described as "skipping back into space" by the popular press, they're lying then? Because if all that's really happening is "the air slowed it down some, but not enough to completely kill the orbit" in no way is that even close to the act of "skipping" a stone on water. When skipping a stone, the stone would not have bounced up entirely on its own without the water being present. It still would have fallen and hit the ground of the water was missing. Therefore the water's presence is in fact *causing* the stone to bounce upward, imparting a force upward on the stone (and not just drag in the retrograde direction, but in fact a force that is actually upward). This is a terrible, terrible analogy if what's actually happening in shallow re-entries is that the air exerted no upward force whatsoever on the craft and instead exerted entirely retrograde force only on the craft (drag), and the air is not the slightest bit responsible for making the craft go back up into orbit at all, but rather the craft would have done that anyway and the air just failed to prevent it. Water *causes* a skipping stone to bounce upward. That's not the same thing as air failing to STOP a craft from the going upward it normally would have done anyway on its own. Is this another case where, when science is dumbed down for public consumption, it becomes incorrect?

But a related question I have is this: If you Do remove parts from the parts folder for a ship that currently exists in flight, what happens? Does it keep the ship around but remove those parts from that ship? Does it keep the ship and NOT remove the parts, therefore causing a bug where it potentially crashes the program because the vehicle is making a reference to nonexistent data? Does it remove the ship entirely if it references nonexistent parts? And similarly, what does it do to ship designs you've already saved in the VAB using the deleted parts? Will it crash the game if you try to load those ships?

The only reason for wanting a high thrust once you're in orbit is to cause your burns to be closer to pinpoint accurate. The maneuver nodes are calculated based on the assumption that you can provide all the delta-V you want in a single instant at a single location on your flight path, which isn't entirely true but is often close enough to true when doing very large orbital movements where you're still close to the same point in your elliptical geometry after several minutes of thrusting. But the downside to having high thrust is that it makes it hard to "STOP" your burn at exactly the point you wanted to. It starts to become hard to control when even at the lowest throttle setting the difference between burning 1 second versus burning 1.5 seconds makes the difference between hitting or missing your target. So it's a tradeoff how high you want your thrust to be. I find that I prefer low thrust, with the caveat that I have to remember to "straddle" the maneuver point time mark because of how slow it is. i.e. if it predicts that I will be burning for 2 minutes, then I want to start my burn at T minus 1 minute, rather than start it at T zero, so that the *middle* of the burn time is at T zero, rather than the start of the burn time. Also, when doing a slow burn at Apopsis or Periopsis where I know my maneuver node is entirely prograde or retrograde without the other two axis "knobs" having been twiddled, I find that I tend to ignore the blue maneuver marker and instead just burn using the retrograde and prograde marks themselves because I know the blue mark is only correct at one pinpoint time during the burn. I start my 4 minute burn and then keep a careful watch on the prograde mark and slightly rotate to follow it as it moves while I burn, so I'm never burning "up" or "down" during the slow burn.

The success rate of rocket launches is nowhere NEAR good enough to risk carrying radioactive waste by rocket. Once it's in orbit, then yes it's a great way to keep it from contaminating anything and in space you won't even notice the radiation compared to what the sun already puts out. In fact there's not much reason to bother sending it to the sun. Just get it away from earth and that's good enough. The problem is what happens during those first few minutes of flight trying to get it up out of Earth's gravity well. A success rate as high as 99% would still be too risky, and in reality it's not anywhere near even that good. Here's a report just from a portion of 2012. Note: 78 successes and 6 failures. You don't want one of those 6 failures to be one that showers fallout from radioactive waste down onto the planet. ========================================================= Vehicle Overall By Orbit Type Launches Earth-Orbit Earth-Escape (Failures) LEO >LEO Deep Space ========================================================= CZ 19(0) 10(0) 9(0) - R-7 14(0) 12(0) 2(0) - Proton 11(2) - 11(2) - Ariane 5 7(0) 1(0) 6(0) - Atlas 5 6(0) 2(0) 4(0) - Delta 4 4(0) 1(0) 3(0) - Zenit 3(0) - 3(0) - PSLV 2(0) 2(0) - - Falcon 9 2(1) 2(1) - - Unha 2(1) 2(1) - - H-2B 1(0) 1(0) - - H-2A 1(0) 1(0) - - Rokot/Briz KM 1(0) 1(0) - - Vega 1(0) 1(0) - - Safir 3(2) 3(2) - - Pegasus XL 1(0) 1(0) - - --------------------------------------------------------- Total 78(6) 40(4) 38(2) - [a] Assumes that two unsuccessful, unreported Safir launch attempts occurred. (Source: http://www.spacelaunchreport.com/log2012.html )

How are people making rovers that the Kerbonauts are sitting in and driving around? I can't figure out how to make a Kerbal stay on board like that.

I was trying to avoid the problem of carrying around the takeoff fuel on the rover itself.

Build your rovers with a self righting mechanism (haven't any of you watched Robot Wars in the 90's?) like in these pictures: Mine are built from stock landing legs parts - mounted on the roof of the vehicle. To get mine to work I had to rightclick them and operate them selectively one at a time instead of using the "G" key to do all at once, because I had to alternate using the left and right pair rather than toggling them together all at once, but the design did work.

The limit only applies to the vehicle currently being controlled. All other vehicles other than the current one are operating on a more limited physics model that doesn't try to calculate all those things that tend to go wrong in the calculations when time is sped up. So to speed up the time on your low-altitude craft, go switch to another vehicle that isn't low altitude, and time warp from there, then switch back to your low-altitude craft. The things that do not get calculated on secondary vehicles other than the current vehicle include: - Rotational velocity (the vehicles stay frozen in their current orientation and all rotational velocity is forgotten and zeroed out, which also has the side effect of stopping wobbling, if you're looking for a cheaty way to do that). - Atmospheric drag (This is why debris can orbit Kerbin on low orbits like 30Km without degrading and falling in. That's a bit annoying because it means to de-orbit debris you have to get it to hit the surface, not just hit atmosphere.) - Component stresses and impacts (i.e. the ships won't break apart from wobble, or collide with other craft - they just pass through each other). Because all these things are turned off when calculating the vehicle as a "secondary" object and not the primary one, the reasons for disallowing fast time warp at low altitude are gone when the ship isn't the primary one you're looking at right now.

No screenshot, but: I attached a ring of solid fuel boosters, and radial decouplers for them. I didn't carefully watch the staging list it automatically generated for it. On the launch pad I hit the spacebar for "go" and the solid fuel boosters turned on... and decoupled the moment they did so. I sat there on the launch pad not moving and watching the boosters fly up up and way.

I voted "something else" because you didn't include "more science parts" in the list. I want the probes I launch to actually *do* something. I'm looking forward to the idea of a fog of war, where you have to launch probes to find out data about the far planets.

Mun Roller and Come Backer One Mun lander with a Shrimec(*) and a platform to take off again. All parts stock, no mods: (*) A term from Robot Wars TV Show meaning self-righting mechanism used when you're knocked upside down. No, I have no idea why there's a letter "H" in the abbreviation. I didn't invent the term. In Transit to Mun: Making de-orbit burn for landing: Landed: Disconnected from lander platform and starting to drive: Self Righting mechanism (made of landing legs upside down on the roof) pushing lander back onto its wheels again after a driving mishap: Driving rover back onto lander platform after an excursion. There is a docking clamp at the front of the rover that will connect to the clamp on the lander when it drives up against it: Clamped to lander for re-flying: And take off again, ready to be taken elsewhere on the Mun (or if I had better skill at landing and hadn't wasted almost all my fuel trying trying to abort crashing trajectories over and over, to be taken back to orbit around Kerbin again and dock with a space station.) :

So am I supposed to connect it like this, essentially? Do I understand it right? So, by the way, what on earth is the difference between the meaning of "undock" and "decouple", then? They sound like they mean the same exact thing to me.