DStaal

Are we talking about automation, or about supply networks? Automation is one way to set up supply networks, but it's not the only way, and it's not the only thing automation can be used for. They are really separate discussions.

I think it's worth looking at the three mods that can do this (or limited cases of it, at least) in KSP right now: MKS, Pathfinder, and Routine Mission Manager. MKS and Pathfinder both have a system where if you have the right setup on both ends you can set up transfers. The transfers have a cost in terms of fuel and resources, which is calculated pessimistically based on what you're transferring, and the relative locations of the craft you're transferring between. (So it's almost always cheaper to run your own mission.) There is also a max size of a transfer. This is completely abstract, with simple scalable resources. No Kerbals are directly involved (Pathfinder explicitly models a railgun system), and resources are removed at the start of the transfer, otherwise it fails. Routine Mission Manager is more complex - you have to fly the mission first, and then it replicates it. So you design the ship, the payload, etc, and you get the same result. If you want a different result, you have to fly that mission yourself first. I believe it can move Kerbals, but you'd have to assign them to the ship as you start the mission. Now, neither of these is a full solution for a resupply, as none of them have an option for 'do this every X days'. (Though both Pathfinder and MKS can automatically move resources around between landed bases.) For all three however it wouldn't be that hard to add: you just have to have the mission fail if the resources at the start time aren't in place. I could see any one of these systems being used to create full supply networks.

KSP is still CPU-bound, though it's gotten better - there's now *some* threading. I'd say for that, you want RAM and CPU.

So far all we know is that it was delayed until the next *Fiscal* year. Which means it could be as early as April 2020. Best to wait and see.

I just want to say thanks for the roadmap - it's well more than we should expect or need. (And I fail to see what's ugly about *any* of your released parts, but if you don't like the look, who else matters?)

There's basically two ways large bodies could collide: In a one-time mega-event, or something gradual as the two bodies spiral together. The mega-event (if it's not just a large asteroid) would be something that you'd really need to be able to plan a campaign around. Could be a good DLC at some point, but otherwise if it's in your home system it'll just get in the way of most players, and if it's not in the home system most players will miss it entirely. As for something gradual - That's Rask and Rusk.

Orion drives went working scale mockups before being abandoned for political reasons. There's no real untested technology there, just undeveloped technology. Fusion drives would have untested technology, but barring something extremely surprising, there's no *unknowns* to the drives - We've made working fusion reactors as research experiments, they just take more power as input than they give as output. Yes there's some hard technology development before they're useful, but the steps are all known. The Alcubierre drive and the rest of the 'realistic' warp drives rely on quirks in the physics equations of our current theories. Those quirks haven't been shown to correspond to anything in the real world yet, and quite possibly are only there in the math, not in reality. We'd have to prove that the math actually applies to real life before even starting to think about building them - and we don't know how to do that yet.

Not once they're compressed. They are heavier, have a different docking strength, and fit a different profile - but none of those matter once compressed.

I expect some form of partial autopilot will likely be included, as it would help one of the stated goals of making the game more accessible to newcomers. How extensive and what modes of the game it would be in are of course open questions - it could just be in some limited tutorial mode. If I were designing it I'd have the ability to execute the next node, and maybe a helper for gravity turns. Those two would touch most of the 'frustrating to learn to pilot' issues, and leave plenty of skill for people to learn about transfer planning, etc. As for tweakscale/procedural parts: I think having some limited form of part scaling - that can apply to specific parts only, within limitations that would depend on the part - would likely reduce the overall load on the developers. (Though it would move the load from the modeling team to the programming team.) I also think something like it built-in would be something that could enhance modding for the game. Personally, I'd limit it to structural parts and tanks, at least in stock. This would mean fewer parts in stock, and fewer total parts in many ships, easing some of the physics issues.

There's a reason I said 'antenna' - this isn't on a per-ship basis, it's on a per-antenna basis. If you want a Duna network, what you need is to set up a relay satellite with one antenna that's on the Duna network, and one that's on your Kerbin network. (Or on your 'interplanetary backbone', if that's the way you're setting it up.) Then all communication will relay through that satellite.

The main thing it does is *restrict* which ships/antennas can talk to each other. If you put 3 satellites into one network, they can only talk to each other - nothing else. The network is centered whereever you've centered it - they do *not* get combined or anything, it's just that they will no longer talk to any other antenna besides those in the same network. That may mean they can't be controlled, if none of them also has connection back to Kerbin.

The data won't change until you process the experiment results. Finding them is the tricky part.

I think it partly depends on where you find fun in the game. Is it in piloting ships? Designing ships? (Or planes? Or monstrosities?) Or is it in planning out a space program? None of those is the 'right' answer - but they each have different needs. MechJeb is useful for some of them, nearly essential for others, and likely harmful for others. MechJeb may replace your flying, teach you to fly, or get in the way of your flying, depending on your use. If they're doing some better tutorials, I think some form of graduated MechJeb where there's some hand-holding on flying that can be disabled as you get better is probably a good idea.

I think Restock did decently there - the point of the mod is to replace assets, so 'extend' is out. It only conflicts if you're using stock assets in other parts, and they have an easy-to-use solution for that built in at initial release. Given the goal of the mod (to replace stock assets with their own looks), I don't see how they could have done much better. They obviously worked at compatibility with other mods, within the given goal of their mod.

Because I haven't said it recently: These parts are gorgeous. And the new textures are amazing.

Sure - but I'd still have to pick out the music. Getting good music for it is really the hard part. Relevant video I watched recently:

If they really wanted to go all-in on it, they could even have different themes for different planets... I like KSP's music, but I'll admit it's not really up to a professional game studio's level.

Do *not* paste it into a message here. Upload the file to a file service like Google Docs and then paste a link here.

Solar sails within a system aren't likely to actually be all that interesting or useful - for the amount of dV needed, you can easily carry the fuel for a higher TWR. It's only really interesting for interstellar (and boosted) - sure the acceleration isn't much, but you can keep it up quite a while. There is a mod that puts solar sails in KSP1 - I've played around with it, but the hard part is planning the trajectory. Timewarp under thrust is fine, but you aren't flying Hohmann transfers or anything similar anymore.

Part of it is historical reasons - CRP was started at one point by one group who saw the need, ClickThroughBlocker was started by someone else who saw that need, etc. Who's interested in what problem depends on personal interests and what you need. People interested in resource definitions and distribution may not be interested in UI coding, and vice-versa. Also note that there are a couple of groups who've started their own resource packs since CRP was invented. Some haven't gained much traction, some have. And sometimes you'll have a special case that needs something different. And maybe you don't need all of them in every case, or the case you have isn't covered by the mods available. (One of the reasons for all the different part switchers is that the functionality of them doesn't completely overlap - they all do slightly different things, sometimes incompatible things.) I'm hoping Star Theory is taking a good look at what's out there, and seeing which dependency tools are getting wide use, and building their own versions of them into the base game. Module Manager, ClickThroughBlocker, and a part switcher are obvious things that likely should be included as core in KSP2, allowing easy use by any and every modder. Something like CRP they may want to define a few more resources in stock, and give them better definitions, but the real need is for modders to work together. Others are in widespread use - but aren't everywhere. Regardless, starting now on any of it for modders is jumping the gun. We don't know what'll be in the game, or what will be possible to change. I could see Star Theory having built-in resource definitions of every major rocket fuel, as well as having a mining system with resources for that. If that's there, there may be no need for a CRP - even if the game itself doesn't use all the resources. Or they could add one or two resources, and we'll need to organize something. Who knows? It's to early to guess, and to early to start. Anything people do now would just be in theory until we can see what is actually needed and possible.

Robotics was something Squad developed after Star Theory started working on KSP2, so it wasn't something on their radar.

This... Will be *so* useful.

You just don't have the right peripherals. https://en.wikipedia.org/wiki/ISmell

I honestly think this would be a good role for a Bussard Ramjet - Make the ship an open system with input being interstellar gas. Siphon off heavier elements as it passes through, and use that to replace what is lost. You'd still need a 99+% recycle system, but it no longer needs to be 100% and you can also siphon some power off the ramjet fusion. There are complaints about Bussard Ramjets - but they mostly are that it's slower than other methods of traveling between the stars. Take out the destination, and those complaints are no longer relevant.

PR created. https://github.com/ihsoft/KIS/pull/356