DStaal

As an IT admin, I'm well aware.

There are lots of tricky things you can do to help the math, however at the end of the day full N-Body is O(n^n) and recursive and patched conics can *most* of it in O(n). If the developers wanted to spend the time and effort, they could probably get reasonable speed out of N-Body, for a reasonable amount of ships, by working hard and taking a lot of shortcuts... Or they could use patched conics and spend that time and effort on other things.

Actually, no - it's the opposite. When you're close to a large gravity source the prediction is generally fairly close to a 2-body system. When you're well away from any other large masses is when minor variations start to make more of an effect.

If we're thinking about tankage, one thought would be to have basically a fractal series of tanks - Empty the small ones first, then flow from big to small as you empty enough that you can transfer the fuel to another set of fully-pressurized tanks. Done right you should be able to minimize the amount of pressurization filler you need. (And you may be able to recycle it as well.) Also note in the 'it takes super high pressures to create and store' - what makes metallic hydrogen interesting is that it should theoretically be meta-stable, so you need super high pressures to *create* it, but maybe just reasonable pressures to *store* it. (From what I understand, this is unsupported theory at this point - *if* the theory turns out true, then metallic hydrogen is useful as a rocket fuel. If it isn't, then it's just not going to be worth the bother.)

No clue. It will depend on the system requirements of KSP2 (which are likely going to be different from KSP1) and your PC.

Unknown at this point. It's possible. (If you're looking for one for KSP1, I recommend the mod GravityTurn.)

Position 3: Games are games - realism is only useful insomuch as they mimic real life. Looking 'realistic' by one definition or another doesn't necessarily help a game, and should be considered in terms of what the game is trying to accomplish. --- Yes, KSP is a space program manager simulation. About little green men, who's heads are as big as the rest of their bodies. Full realism isn't the goal of the flavor of the game - it's semi-realistic from the start.

No, I'm suggesting that 'realism' isn't the goal - that 'useful' and maybe 'pleasant to look at' is. Realistic is better in some cases, and worse in others - use it when it's relevant, and when it helps the game. Realism helps things like Call of Duty, as it's trying to put you into the place of a soldier. It hurts things like Cuphead, as that's operating more on cartoon logic. But it's not an either-or, it's a spectrum, and each feature has advantages and disadvantages. Just saying 'it's realistic!' doesn't say anything about whether it's *good* for any specific purpose - even Call of Duty has a HUD to help you with elements that are part of the game. Think about what your trying to convey, and how the tools you have could do that for you - if realism helps, fine. If it gets in the way, remove it. And if you can't imagine a Sun without lens flares and a glare - I suggest you go outside and look up.

There are quite a few games that have taken that art direction, even new games. KSP needs a more fine-grained interface than the sprite-based style of NES, but that doesn't necessarily mean it needs to be fully realistic - or to carry over the flaws of real-world optics.

Why? Why represent real-world optics? The point is to show the action to the player - if real-world optics help, fine. But if they get in the way, they should be removed. It's not a camera, it's not our eyes, it's a viewport into a world - and we define the viewport however is convenient and useful for us. Don't replicate reality - of either a camera or an eye - decide what helps the gameplay and put that in, and decide what hurts the gameplay and remove that.

Here's the thread someone already made on the topic:

Or it could also mean a cluster of small engines that all output into the same plume. 'Compound' just means 'made up of separate parts' - it doesn't say anything about how those parts relate to each other.

https://en.wikipedia.org/wiki/MOOSE http://www.astronautix.com/m/moose.html

IGN's breakdown of the trailer provides a couple more details. First off, this is confirmed to be a metallic hydrogen variant: Secondly, this is referred to as a 'compound drive': Though I wouldn't know what they mean by 'compound drive'. Do they just mean similar to that compound areoplug in construction, where it's basically a cluster of smaller drives of some sort? Or is there something else going on?

Obviously you want to deploy and board *before* you re-enter if possible...

I actually think this might be worth investigating - could you do this as basically a stowable command chair that you have to get into once deployed? Could that help the COL/COM issues?

Ok, so we've moved the issue from having multitudes of engines to having multitudes of ISRUs - or we just have a magic generic ISRU which can convert to anything. Either way, it still sounds like a lot of extra busywork over the current stock system, for not much extra gameplay for most. (Honestly, I often start designing my space career in current stock KSP to limit the number of fuels I have to balance, as I hate having to keep track of how much of each is at each refueling point... I'll often either cut monoprop out and just use LFO RCS or cut out oxidizer and stick to nuclear and monoprop engines, depending on the playthrough.)

I can probably rebind or remap... But why? It's not like I need to throttle down...

Haven't had much time to play recently, so just got the next section of my modular interplanetary ship up - a science experiment pod: I'm debating whether I should replace it already - I meant to put in some scansat scanners so I can scan for landing sites quickly, but I forgot to put in the altitude scanners. Maybe just send something up and attach it via KIS? (It also could use RCS, to make it easier to reconfigure the modular ship. I'm thinking on what the best way to handle that overall is - my normal solution is a docking adaptor/tug, but that's for stations and this will eventually be mobile; I don't want to have to ship extra docking tugs around. A tug on one side isn't balanced, and has trouble controlling the module it's trying to dock. I managed it in this case with what became an expendable tug - mid-docking maneuver I ditched the tug, and completed the docking with just the RCS in the command module, after I'd lined up so the remaining maneuver was single-axis. That was complex and very timing-dependent however, and resulted in the tug being sent into a junk orbit.)

Huh. I'll have to double-check if it's the same on Mac (some of the option/control/command keys get switched around a bit). If so, that's a really awkward key for me...

How to throttle down. I can full-throttle, throttle up by increments, and throttle *off*, but I've never worked out how to throttle down by increments - I just throttle off and then throttle up to where I need to be...

Now, now - we all know Jeb never hits the brakes. That was the *accelerator* pedal. (Possibly the 'accelerate in reverse' pedal, admittedly...)

Also worth noting is that, sure, a hand-optimized full stack solution designed just for a particular game is going to be better... *If* you're an expert in coding realistic physics, and lighting, and AI, and progressive loading, and memory management, and every one of the dozen other things the game engine has tools for. Yes, you could in theory write a solution that's better for your specific case - but most likely you'll mess up, vs. the publicly tested solution that has been optimized over time and exposure from dozens of games. The game engine company can afford to hire experts in each of those as they know it'll help their game engine sell, and they'll be able to recoup the costs over many games - where an individual game likely can't hire experts in everything. Realistically, the game is likely to perform better if you're using an established game engine that suits your game. In theory could *could* do better doing it all yourself - but you'd *probably* end up spending more money and doing a worse job.

I still like my idea, which doesn't contradict the above: planetoids/astronomical objects on rails, patched conics below ~3x 'low orbit', N-Body above, ships don't affect each other. This lets you put a space station in most of the common orbits (both high and low) and have it never perturb, and it means the solar system doesn't have to worry about being perturbed over time. It allows the Larange points, the 'interplanetary transport network', and some of the gravity assists. It would also mean the math was available and you could do special cases like Rask/Rusk - where you could pull in the patched conics limit to very low orbit. (And you could keep the planets themselves on a patched-conics system with a fake baricenter that doesn't have an SOI.) Biggest problem is that the SOI system is likely also a precision system: Ship locations are relative to the nearest body, so you limit floating point error effects. This suggestion would abort that above it's patched-conics limit - though you might still be able to use the SOI system for positioning, or you might just allow solar/universal SOI and take any floating point effects.

As a long-time Dvorak user, I can see it being useful to me as well. Many of the keyboard controls (in this and a lot of other games) are laid out in a 'useful' but not necessarily mnemonic formation. Change the layout, and they can be hard to learn - just looking at that implies a few things to me about the control scheme for KSP that I've never learnt because what keys do aren't linked to what the keys are other than by their placement.