cpast

I find money a bigger issue in 0.90 than science: I can unlock much of the tree with Mun/Minmus missions and contracts, but need 3.1 million to get the R&D facility fully unlocked.

Honestly, it looks more like a change in how the data was compiled than anything else. Going from smooth to oscillating like that is very unlikely to be an actual change in how many play the game; i'ts more likely that they changed how they measure it. Edit: And I'm right. If you hover over the graph, it shows that there are many fewer data points kept before November 10 - before that, it seems to only have one point per month, while after there's one per day. The oscillation is the weekend (many more people play on Saturday and Sunday), which is not seen when you average data over a longer period.

Arbitrary human behavior is actually quite hard to change. Just because it's not fun to talk about the issues that have to be resolved, and you have to deal with something that's not just the laws of physics, doesn't mean it's something you can easily work around or that it's not going to kill your project just as much as if there were a physics issue to solve (and it's actually going to be *harder* to resolve than just about anything that's ultimately an engineering problem). Launch sites are also not cheap to build and maintain; there's a reason SpaceX uses USAF bases for launches. Expensive infrastructure is one of those things that tends to not be outsourced unless absolutely necessary; you don't want to build up lots of infrastructure only to lose it to political developments in the country it's located in.

If Vector3 doesn't work right on win64, then Unity 4 does *not* support perfect 64-bit. You also can't avoid using Vector3 in Unity; Unity has no such thing as a Vector3d. Unity has Vector3, which is part of the underlying language spec; while the .NET libraries do have a Vector3D (note capital "D"), that's just for WPF stuff, and KSP's Vector3d is Squad's own creation. Any call to Unity functions must use Vector3.

Hm, interesting. That may be the cause of some of the issues. However, couldn't Unity just use .NET for 64-bit Windows? The point of Mono is basically to port .NET to other operating systems; the fact that it's on Windows at all is curious enough to merit an entry in the Mono FAQ (because you can get actual .NET, not just a reimplementation).

I'm pretty sure mod users are in the minority, though. I have yet to see a credible claim that over 50% of people use mods (50% of forumers is not enough to conclude that, because that's a small part of the number of KSP players and an unrepresentative part). If you have a credible source for the claim, I'd like to see it. Otherwise, people on the forum should stop acting like the generic assumption is that someone uses mods.

Modding is definitely a separate game. For GTA, I actually only care about it for modding reasons at this point - the only times I played it in the last couple years was to test mods.

I stopped playing a few months ago (back in September), and have just come back. If you take a break and come back, the game definitely gets refreshed. If you don't come back, oh well.

You can't destroy energy in a closed system. When someone talks about expending energy, they're not talking about a closed system. A system loses energy when it does work on its surrounding environment. The energy goes to the surrounding environment; when work is done on an open system, the system gains energy. Energy lost or gained = work done by or done on the system. From any non-pedantic standpoint, energy = work; energy represents the ability to do work on something, and a system loses energy when it does work on its environment (i.e. exerts a force over a distance). It's not at all wrong to talk about something gaining or losing energy, because not everything is a closed system. Is the confusion you have related to that?

Just fixed it. An anonymous user changed it from "success" to "failure" a week or so ago.

Energy obtained by doing this does not come from the magnetic field; it manifests itself in the fact that moving a magnetic field-producing object through a conductor, or moving a conductor through a magnetic field, takes energy. If you're doing this by hand, you have to do work to move a magnet through a coil of wires. The more energy being bled off by the circuit, the harder it is to move the magnet through a coil. Many railroad locomotives have a brake that literally consists of connecting the traction motor to a grid of resistors, because driving a high-resistance circuit with a generator slows down that generator (in this case, kinetic energy becomes electrical energy becomes heat in the resistor).

Correct. No work is being done holding something in place. Therefore, no energy is expended. Your confusion seems to be with the common definition of "energy" (and "work"), according to which it takes energy to continually apply a force. This is not the case; you do no work on an object unless you apply a force in a direction over a distance in that same direction. When the track goes up, work is being done on the object; however, I'd expect the energy there to come from the kinetic energy of the object (i.e. separation from track changes -> induced current strength changes and object slows -> unbalanced force -> acceleration upwards, less forward speed). However, if you think energy is needed for a force to hold something in place against gravity, you misunderstand the concepts of work and energy.

What are you talking about?

Ah well. Thanks for looking into it; if only KSP let you just specify a static image Also, one change I ModuleManagered into my 0.90 was to add SAS to the flight control computer - now that it's not free, it seemed logical to add as a perk of having the computer instead of a docking port (in addition to the autonomous control it allows). It works out pretty well in my game; it might make sense to think about having it built in.

For the next compatibility release, any chance you could update the thumbnails on the two extendable solar panels from Phase II? Particularly for the big one, it shows as almost blank on the VAB menu, instead of clearly showing what the panel looks like.

Er...yes? Yes, I'm pretty sure we have the ability to create fire in space. Unless you mean igniting engines in space? (I can't think of any KSP uses of "fire" per se, just reentry effects and engines.) In which case also yes.

You'd basically have to almost totally rewrite your code, unless you had specifically planned your project to make it easy to change engines (even then, there'd be a fair amount of rewriting). It has nothing to do with the programming language; it's that KSP uses Unity for core parts of the game, and everything interfacing with Unity would have to be rewritten. Even parts that don't directly call Unity functions have design logic driven by Unity's behavior. If you want to make it easy to swap engines, you could make your own intermediate layer to sit on top of the engine and only talk to the intermediate layer, so changing engines only makes you change the intermediate layer (though how you do things at a higher level might have to change for performance reasons, because something efficient in Unity might be slow in Unreal or vice versa). Unity itself abstracts away a lot of OS-specific stuff, as does .NET/Mono, which is part of the reason why it's easy to make one game for Mac, Windows, and Linux; however, to make it easy to change engines, you'd have to add a second layer of your own, which I doubt Squad has done.

The shuttle had more manned missions than any other spacecraft, achieving more manned flights than Soyuz in 20 fewer years of operation, and took more people to space than every other spacecraft combined. In addition, a crew capacity of 7 meant it could take more people who didn't have to be fully qualified to operate it -- you generally want at least 2 people who are perfectly capable of flying the thing, and having 7 total means you have 5 flexible seats instead of the 1 you get on a 3-seater. - - - Updated - - - I think more of the reputation has to do with the fact that the missions it excelled at turned out to not be as critical as believed. Claims that it "trapped us in LEO" are ridiculous -- budget is responsible for the lack of manned missions outside LEO since Apollo (as it turns out, no one was both willing and able to pay for such a mission). It was capable of on-orbit repair, but it turned out to be cheaper to junk a satellite and launch a new one. It could be turned around in a couple of months, which is seriously impressive (it's only in comparison to the original projected launch numbers that the launch rate is low). And even to the degree it turned out that reusability wasn't necessarily cheaper, there was no way to know that before building a reusable rocket. Part of the point of a space program is to try things no one has tried before, and STS was an experiment (which turned out to work OK, and work really, really well as a way to deliver people to orbit).

I sometimes play KSP on the train. While Amtrak has wifi on the NEC, it's really unreliable. Unless Squad intends internet access to be a requirement for the full experience, they should not rely on the internet to teach players how to play. Games should be self-contained as much as possible; it's stupid to have tutorials be the only thing that requires internet.

Implementing a UI element for its own sake, rather than to solve some actual problem, is always a bad thing. What, exactly, should the tooltips be for? What information should be displayed on them?

The issue is that it still takes time to scale from full warp to zero, even if tapping the ',' key. At high warp, that's what takes most of the time. I'm actually not sure *why* it'd be an issue snapping to 0; AFAIK, the way rails warp works is that KSP does no physics at all. In an orbit around one body, there's a closed-form expression for your location at a particular time, so all timewarp does is add some larger amount to the time each increment (this doesn't cause issues because no forces are being simulated and the orbit doesn't change, so floating-point errors have minimal effect). If that's how it's done, I don't see why dt can't go from 1000000 in one step to 1 in the next.

I've used it to get easy launches in my sandbox test save (so launching into space is as simple as sticking one big SRB on there). Otherwise I *try* to avoid it, but if I end up really frustrated at a minor issue that makes the mission not work near the very end, I'll sometimes use it when I'd really rather not redo the whole mission.

With the definition of "simulator" I'm familiar with, then definitely yes -- exhibit A, FSX. It's a simulator, which is sold as a game. @rcp27 That's what I'd call an "industrial" simulator; while it make sense to distinguish by saying that, there are games that are commonly referred to as simulators. There's a fuzzy line. However, the fuzzy side of the line is definitely where the goal is to have fun by means of modeling a real-world thing, which is called a "simulator" by people thinking about games and a "game" by people thinking about simulators.

Your definition of "simulator" conflicts with what the standard definition, which is something designed to simulate reality. Your definition also includes sandboxes, and a sandbox need not be a simulator (Minecraft is a sandbox AFAIK, in fact one of the purer sandboxes out there, but it's not a simulator). When people talk about KSP as a simulator, what they more often mean seems to be how realistic it is (if someone says "it's a game, not a simulator" in response to someone saying planets should be real-world scaled, they aren't saying "it has defined goals and isn't just about doing whatever you want," they're saying "just because it's more realistic doesn't mean KSP should do it, because fun trumps realism [and I find the current system mode fun]").

While I like Lenovo (that's what I use for my own laptop), in my experience their non-ThinkPads leave something to be desired in terms of build quality. They seem to be getting better with their other lines, but there is a difference between the two.