Dunbaratu

Let's not forget that there *already* exists a mode to be used by those who don't want to earn points to unlock things over time. It's called "sandbox mode" and the plan is to keep it in existence in the final game. It's not going away. What I don't understand is people who don't want to have to earn points that are called "money' but at the same time seem to still want to have to earn points that are called "science" Either you want to play the level grindy kind of game where you start off with only a few things available you can do and are rewarded for stuff you do by getting access to stuff not previously usable, or... you don't like that and prefer sandbox instead. I don't see what the difference is in gameplay that makes having to earn money points and use them to buy parts somehow a totally different sort of thing from having to earn science points and use them to advance.

But what you're defending is the scenario where even BEFORE SpaceX goes to the drawing board, the dimensions were already set by the magical gods of rocketry - even before somebody made the first rocket the dimensions of its parts were pre-set. It's a bit like inventing the first electric generator and finding out that the specifications for its voltage, oscillation rate, and amps have already been standardized before there even was such a thing as an electric company.

I'm hitting the same problem right now. I'm trying to edit a narration audio track on top of the video and the cruddy freebie Windows Movie Maker keeps insisting on knocking down the input video quality from 1280x800 to 640x480 regardless of what settings I use.

In order for the drag calculations to work they have to only apply a drag force when you have a velocity, and they apply it in the opposite of the velocity direction. If you are standing still there isn't drag. So what velocity are they using to calculate it? It's got to be something. So it's either orbital velocity or it's surface velocity. And the behavior is not consistent with it being orbital velocity. If it was based on orbital velocity it wouldn't work because standing still on the ground would give you a velocity of 174 m/s east in the calculation, and thus apply a drag force westward on you because it would THINK you're moving through the air. The fact that when landing on parachutes you end up matching speeds with the ground *is* the proof that the drag calculations are based on surface velocity.

Fail. You didn't perform the test. The speed is not the same. Also, fail on not understanding the difference between acceleration and velocity. If I walk east at 3 mph and you walk west at 2mph our relative velocity difference is 5 mph (the difference between 3 and -2). Even if we are both walking at constant speed and neither of us is accelerating. On the other hand if we're both walking east and I'm going 3 mph and you're going 2, then our relative speed difference is 1 mph. Even if we are both walking at constant speed and neither of us is accelerating.

(In response to the claim that the air drag is calculated using your surface velocity not your orbital velocity:) I've made retrograde orbit landings on Kerbin before using only parachutes. If it wasn't correctly simulated, that wouldn't have worked. If it used orbital velocity to calculate it, then sitting on the launchpad prior to launch you'd already be above terminal velocity, in a gale force wind going 174 m/s sideways while sitting at the launchpad before you do anything.

This has made me think that having a planet or moon with big patches of no-friction smooth surfaces could be a fun addition to the Kerbin system, especially for doing EVA's (you'd have to ice-skate using your jetpack). It would be the one and only place where 700Nitro would be correct about being able to land safely while ignoring surface velocity.

Newton says you aren't using vocabulary correctly by pretending the word "gravity" and the words "gravitational constant" are synonyms.

Only if your definition of "land" doesn't include having the craft survive the landing. You're still ignoring that hill coming at you sideways.

Yes but it scales with SURFACE velocity, not ORBITAL, which does end up doing what I said it does. If you're falling straight down according to the orbital mode of the navball, then you've got a sideways component of 174 m/s according to the surface mode of the navball, so the drag calculation will drag you as if you are going 174 m/s sideways because it's calculating your velocity in surface mode and using that.

Gravity isn't constant. It's stronger the lower your altitude. Not that this error in what you're saying has anything to do with the enormous foot you insist on stuffing into your mouth with this bogus argument, but it does highlight the fact that you should calm down and take a LOOK at what you're saying and think about it harder. Your claim was not merely that you fall at the same rate either way, but that this means there's no need to match velocity with the ground in order to land. That is enormously false, as "landing" is not "crashing". And "crashing" is exactly what you'll do if you try to land while the ground is whizzing past horizontally. You keep repeating the same thing without responding to what was said. Please explain why it's perfectly safe for a hill to hit you at 389 miles per hour sideways, or for a motorcycle rider to fall off while the ground is whizzing past at 100 miles per hour just because it's a short fall.

I think the problem is that 7000Nitro is forgetting that atmosphere moves with the body, and therefore it's pushing you sideways. With atmosphere present, you end up eventually being pushed sideways until you asymptotically approach matching speeds with the ground anyway even when you don't try to, and 7000Nitro was not paying attention to the fact that this is happening, instead thinking "I'm still falling straight down in orbital terms" when that's not really true. Thus my suggestion to try it somewhere with good rotation and not atmosphere. (Kerbin has atmo, and the Mun only rotates once a month, so if that's all the experience he has with the game he won't realize he's wrong) That experience will correct the misconception pretty quickly.

Bull****. It's because Kerbin has an atmosphere and air drag is doing the work of matching speeds with the ground for you. Try that trick on a body that spins fast (not the Mun) and doesn't have an atmosphere. Kill your orbital velocity until the navball says (in orbit mode, not surface mode) that you are falling absolutely vertically , right toward the ground. As you approach the ground, notice how fast it's moving sideways. Try to land without killing that sideways motion.

A rider sitting atop a motorcycle is typically less that 1 meter up above the ground. If the motorcycle is stationary and the rider falls off, in the time it takes to fall from that height, the vertical component of velocity is still quite small and only results in a minor owie. In the alternate universe you're talking about, 700NitroXpress, a person going 100 miles per hour on a motorcycle who falls off the motorcycle should be just fine, because its no worse than falling off it when it was at rest. Friction with the moving ground MATTERS.

No, sideways relative velocity with the ground matters a heck of a lot. On Kerbin, for example, at sea level the ground is moving at 174 m/s from west to east. It's moving slightly faster at higher altitudes. When a hill hits you at 389 miles per hour, the fact that it attacked you from the SIDE instead of you attacking it from above will be of little consequence. The hill will still win. The only reason you're not noticing it much on the Mun is because the Mun is tide-locked and so it rotates very slowly compared to most of the bodies in the system. Your claim that you don't need to kill the relative difference between your horizontal velocity and the ground's horizontal velocity to get a safe landing would only be true of the ground was a perfectly smooth sphere, and it was frictionless.

As an aside, I really dislike the terminology that everyone uses about KSP where they refer to a vessel that's following along the time-parameter equation for an ellipse (i.e on-rails) as as having "no physics" being calculated. It doesn't have NO physics. it just isn't using UNITY's physics, and it has significantly LESS aspects of physics being taken into account. But it doesn't have "no" physics at all being taken into account. As long as that time-parameter ellipse formula that the on-rails movement is following was calculated based on the fact that position is the second integral of acceleration, and that the acceleration follows the inverse square law of gravitation, then the ellipse itself should still be referred to as at least SOME crude form of following physics. This is also why I don't buy the argument that going on rails requires killing all rotation. If you can calculate the linear position using a time parameter equation based on initial position and initial velocity when the object went on rails, then surely you can also calculate the angular position using a time parameter equation based on initial orientation and initial rotational velocity when the object went on rails. In fact the rotational position should be a simpler calculation than the linear position because the rotational velocity is staying constant. It's just angle at time T = initial angle + T*(rotational velocity). Now granted, if you wanted to calculate tidal effects on rotation it gets more complex, but at least constant rotation is still a huge step up from no rotation, in terms of realism.

A part of the code looked like this: Has the bug fix for the problem where you couldn't lock variables that contain capital letters been released on Spaceport yet? Kevin said on github it was fixed but I don't remember there being a Spaceport update since then.

It doesn't sound like multiplayer or acheivements. It sounds more like having a "voyeur mode". A place where you can upload your save game directory and have other people spy on it.

I think it's really important the the following two suggestions be treated as the utterly distinct suggestions they are, and be dealt with separately: 1 - A new star system that is reachable from Kerbin. 2 - A new star system that can be played as a campaign you start from scratch elsewhere. They are not even close to being the same suggestion and yet #2 is often rejected for the FTL reason that is only applicable to #1. I would hate to see #1 as well, but would love to see #2.

If you complain for gameplay story reasons that makes sense, because of how the Kerbal science is portrayed as "finding stuff by the side of the road" - seeming to imply that a lot of their rocket parts were not of their own deliberate careful design. But if you complain for realism reasons that doesn't make sense at all. Take the diameter of a fuel tank part, for example. Presumably the timeline doesn't go in this order: step 1 - A company designs a rocket fuel tank. step 2 - Then they wait around for a space agency to exist so they'll have a customer that will buy it. It's not like NASA was sitting around going "Wow, there sure are a lot of different rocket parts available on the market to buy, Maybe we should, you know, try putting them together." Granted, this is exactly how it's portrayed in KSP, and that is part of what makes it a bit cartoony and funny. So if you say that picking the size of your parts shouldn't be allowed because it's contrary to the Kerbal story presented, then I'd totally agree with you. But when you say it's because they're unrealistic, I'm not buying that. Realistically, the rocket parts wouldn't exist until after the rocket design that uses them existed. So the parts would be built to match the spec, not the other way around.

I don't think the OP was about what SQUAD has already said they won't do. It was about what forum participants want to not be in the game.

It's an impressive feat but I can't read any of the text in the terminal in the video. The game was running at high-res, but the video was being captured at low-res, which makes all the writing small and blurred out.

Actually, since a and a2 are in denominators of fractions it would have to be the other way around. "A" would have to be bigger than "A2" in order for (1/A) to be smaller than (1/A2).

I can't see any "switch to 0." anywhere in the code you posted - neither commented nor uncommented. Is what you posted what you're really running? At any rate the problem probably is, as previously noted, the ".txt", which is always implied and not stated explicitly. Saying "run prog.txt ." Gets interpreted as two separate statements. "run prog." followed by "txt.". And the syntax error is on not understanding what the command "txt." means.

Is the value of this: vom^2 + (mu * (1/a - 1/a2) ) coming out as a negative number? Taking the square root of a negative number would result in NaN, as floats and doubles can't do complex numbers. All the variables you're using are positive so the only chance for that expression to end up negative is if 1/a is smaller than 1/a2.