DStaal

The OS has been 64 bit for a decade. It's just finally dropping support for non-64-bit apps. I have one app that I use on a daily basis that I'm losing to this, and it last updated 3 years ago. (And is based on code originally written *25* years ago - 5 years before OS X came out.) I have a few games I'm losing, but the most recent is Arkham Asylum, which came out a decade ago. Apple doesn't work as hard as Microsoft at backwards compatibility - but they don't drop things without warning typically either. Developers have known about this for years, and users have been warned on app launch for the last year. This is a molehill, not a mountain.

Note that I said 'remove ship from port', not 'remove port from ship'... (And you'll likely be told it's to heavy to move - so don't *move* it.)

Welding - and construction ports - don't have anything to do with KAS. You're likely working with Konstruction ports from the Konstruction mod. This is a known issue that occasionally crops up with those ports, that's based on the way the game works. The mod can't avoid it, just play the numbers. Luckily the fix when it comes up is typically fairly straightforward: Undock, then using KIS remove the ship from the port, then add the port back to the ship. (You can also try adding/removing a part someplace else, but it's not as certain a fix.)

*If* every part independent and has minimal interactions with other parts. The problem with physics for KSP is that isn't true: Every part of every ship is an separate dependent part, which has continual interactions with all the other parts and on the ship. So while each function is a pure function, the inputs of the functions will depend on the outputs of other functions, and the overall order matters. Simple two part example: Engine and fuel tank. If you compute the fuel tank first it has no forces on it, so will stay in place. If you compute the engine first it pushes on the fuel tank, and the fuel tank moves. Then you have to compute the center of mass for the entire ship for orbital mechanics... You can do some parallelization, but at the end of the frame everything has to be synced back up again on a per-ship basis at minimum. Likely a ground-up redesign over KSP1 can help that quite a bit, but I still expect physics threads to be a bottleneck.

There's wheels as part of the pack, specifically for that type of docking. Note that docking on the ground is difficult if the ground isn't exactly level, as it's harder to line the docking ports up exactly. I've landed them fine with the Meerkats - you just need to make sure you've got the base balanced with the center of thrust under the center of mass. (And that you don't *move* the center of mass as your fuel tanks empty...) TCA can help, though a couple of Twitch or Spider engines can be useful with TCA or it won't have full control.

Does KSP do density profiles? I would figure it just models an ideal sphere.

Then the planet would collapse into the black hole. And see my post above for the artificial planet - to make one significantly different from a real planet would require materials that don't exist.

There is a range - you get a planet with high Osmium content, it'll be denser than one with more silicon, for instance. But it'll still be within an order of magnitude or so. And hollowing out a planet would lower it's gravity, while requiring stronger materials than we know of. KSP's appeal is generally it's realism. Modifying it's physics in unrealistic ways would reduce that appeal - you can try most of these situations (at least the world sizes and the gravity) in Kopernicus. Try them out, see how they behave. Feel free to post them as mods - but note that I've seen criticism of planet packs for even being slightly to dense, and I would expect very extreme packs wouldn't garner much of an audience.

As a Mac user without a PC - I feel your pain. (There's a whole thread on that the console port will be late: I keep wanting to go 'at least you know it'll come out'.)

Which is part of why you don't notice the size of the planet - the physics where it matters aren't being applied in that game. Given that the physics where it applies is the *base* of KSP, that's a very different game. I'll bet there's no curvature at all - it's just a flat plane that wraps it's edges. There doesn't need to be curvature because you never interact with it as a sphere - you either fly/walk around the surface, or you are in space and it's a point that you aren't allowed to get within a certain distance of. They specifically mention in one of their interviews that you can have an Apollo 11 moment.

They have said they'll be improving the terrain, and providing things like colliable scatters, so that is planned.

How often in that game do you have to calculate how much fuel you need to reach orbit? Or to change orbits?

steuben covered that. Even limiting it to just 1km down - about half of the physics bubble - and you still get Petabytes of data per world. Now, I'm sure some compression could be possible - but you'll still have huge amounts of data to store. 100% of the players in KSP notice the size of the planet they are launching from, orbiting, or trying to land on. You may not notice that you notice, but it affects everything you do.

Hence my thought of the drag-and-drop and exposing a LUA API. The drag-and-drop for the people who aren't programmers, LUA for those who are and want that. Of course this is all another system which would be added to the game, requiring a new interface, etc. I think this would be worth it, but that's one player's opinion - but that does lead to: This would then add *another* system, interface, etc. on top of the scripted actions. It might be best to put all this in a DLC, some time after launch.

On the console issue, it's also worth noting that both Sony and Microsoft have said they'll have next-generation consoles coming out next year. KSP could conceivably be being produced as a release-day game for one or both - which would mean they need to wait for the release of the console before they can release.

You forgot an important step: How KSP is going to figure out what the craft is doing. After all, it could have a random collection of parts, producing and consuming a random selection of (possibly mod-created) resources... Programming what actions the ship is taking isn't enough to simulate that, you need a good guess on what each different module in the ship is doing, and how it adds up at each step of time. Which would mean you need to simulate it. There are games which do this kind of thing, but you'll notice that they give you a selection of units that you can order around - each is then clearly defined, and the game project it better.

No problem. Note that the SSPEX patch for MKS reduces the mass of the parts by the amount of the MK's that you have to add...

What mod are the parts a part of? MKS doesn't add MaterialKits to other parts, but they may have compatibility patches. As for what sense it makes: Fasteners to secure it to deployed/inflated condition, furniture, walls, etc. The idea is that an inflatable/deployable module arrives like an empty house - and then the MaterialKits are your furnishings and belongings you put in as you move in.

I wouldn't want to be my main mode of play either - but I could see it as interesting a few times. That would be one of the science-fantasy games I mentioned; Warp drives in particular. It would be interesting to see how well an interstellar war (note that I'm not all than interested in interplanetary for this...) would play out with realistic timescales for travel - and detection ranging out to being able to see them coming.

I can see that point of view - my main thought is that while I know of a lot of thought-experiments about interstellar war exist, and there are games about it, the games typically assume some science-fantasy tech, and the thought experiments have nothing to base themselves on. Multiplayer KSP would sit in an interesting place to actually be able to test some of those thought experiments.

If it's core design choices that need to be fixed, that may mean rewriting most of the program. If that's the case - *admitting* that helps. And if you're making core design changes in game, things like savefiles, mods, etc will likely be affected. Best to put out a new version so people can specify which they're referring to.

I could see an interstellar war simulated in KSP as being fairly interesting, actually. Not always what I'd want, but I could see it being both fun and educational. But that's a bit different than just lolsplosions - you'd have to start in places far enough apart for both sides to be able to sustain significant infrastructure before they reach each other.

What I'd like to see for programming is something like an extension of the Breaking Ground robotics interface, or the initial Lego programming interface: You have a bunch of pre-written actions: 'Perform Maneuver Node', 'Orient to retrograde', 'Activate Action Group', etc., and then a graph where you can drag-and-drop them into order, with delays, etc. And then have a Lua API for those who want something more.

I while back I posted dragging some experiments into place. They've completed their run, so I sent up a ship to return them to Kerbin, and had one of the engineers working on setting up a long-term base nearby carry them over: The ship design was the result of many tests, and was barely stable enough in reentry - in fact it started tumbling as it hit the lower atmosphere at ~Mach 3.5, but that was slow enough everything survived. (Tumble really started when I lost probe-control to the plasma sheath - which also meant I lost the spin-stabilization. Plan had been to leave it on SAS and have RCS help, but I missed the atmosphere on the return trajectory, and therefore had to do a powered deorbit.) Brought in around 500 science, but I was hoping for an unlock of some of the saucer parts...

I don't believe I've seen anything saying you don't need to have the craft in focus during the burn. I believe they have said that you could timewarp during a burn using some new timewarp mechanics, but nothing that would require an autopilot.