t_v

I’m not sure about the first statement. I don’t think that colonies should be as minimized as humanly possible, hence this part, I was just bringing up colonies as an example that wasn’t the KSC buildings. And I feel the same way about program management as I do colonies - namely, that I think it could be beneficial if well executed. We are on the same page that large amounts of time on these side tasks is detrimental (trying to transfer fuel anywhere is the epitome of that), and that scrolling through menus is not exactly the engaging diversion that we are hoping for. We are also on the same page that these things need to tie into the rest of the game in some way - both to incentivize players to do them and to make them more meaningful. Science progression is already tied into the main game so one example of how the side-gameplay of implementing new technology could be made engaging without becoming time consuming is to have an expanded Kerbilopedia (which has a KSC building dedicated to it) detailing the results of your experiments and once you make certain discoveries, new parts are unlocked. I’m personally in favor of a multi-resource science system instead of a discovery based one, but you can see how side-gameplay can be well designed and integrated into the game while not involving building or flying. In the end, I don’t care whether you can spend fifty seconds to five minutes in the Program Timeline building (missions influence colony happiness, for example) or in the Colony Management Module putting more kerbals in greenhouse jobs (and then leaving it be), or both, I just want there to be some action that is not done automatically that isn’t the same gameplay that dominates the game.

I'm planning on completing a fully self-reliant Grand Tour before KSP 2 is out, but the longer any mission goes on, the more likely the Kraken is to smite it and I haven't managed to build any attempts that can defend against it. Maybe I'll only be able to do it once KSP 2 comes out.

We have only seen designed planets so far, which really means that the overall landscape and aesthetic of the planet are designed and then procedural generation is used to fill in the details that the artists have specified. I think there is a commitment to having a few designed planets instead of a lot of procedural ones, but I don't remember if/where that was said explicitly.

Specifically here for these proposed mechanics I agree with you, but I disagree generally. While having a solid core gameplay loop is important for a game, its side features, mini games, details, and other “distractions” are what oftentimes give games their character and make them interesting for long periods of time. There’s a reason why many combat or shooter games have puzzle segments or diversions that are don’t need to be there for good progression: they give a break from the main gameplay, introducing variety into the player’s experience and making the core gameplay loop more enjoyable as a result. In KSP, these exist to an extent, and in varying quality. There are two main loops you do in KSP: building a craft and flying it. Building is majority placing, rotating and transforming parts, using PAWs and other lists to set up those parts properly, and making sure that a variety of constraints are met. Flying, depending on the mission, will be predominantly conducted in the map view making sure that the course set is correctly and then executing it correctly, or in the flight mode, keeping a rover upright, a plane in the air, or a rocket pointing retrograde. There is lots of clicking around in PAWs for larger missions. These two styles can keep players like me sustained for a while, but the added breaks really keep me from burning out due to gameplay alone. Kerbal EVAs are a cool little moment to relax during a challenging trip (if I don’t have reassembly to do) and reflect on the experience. It also breaks missions into chunks instead of a marathon maneuver node fiddling session. Satellite mapping, both Stock and Scansat, is a nice break where I can sit back and watch data appear, and occasionally mark anomalies with waypoints. After a mission is done, I don’t just go immediately back to building, either: there are science points to distribute, policies, building upgrades, and craft costs to choose from, and asteroids to mark for capture. These little distractions are actually the perfect remedy from burning out on an otherwise pretty focused game, and as long as they are short, they complement rather than detract from the main gameplay. The key point here is that you don’t want to oversaturate the game with these; checking up on a colony every once in a while can be fine, but when you have 30 of them it starts seriously cutting into your time, which is why colonies shouldn’t require maintenance on the player’s part. However, just because these systems shouldn’t take up your time doesn’t mean they shouldn’t be there at all - without them, the only way to avoid burnout is to just not play, while developing a negative experience around the game.

Disclaimer - I know comparatively little about code, so this answer is not fully informed. As I understand it, rendering the ice chunks and potential mist isn't going to be too graphically challenging - chunks can probably look pretty good as a single 2D polygon, and there won't be an overly high graphics impact compared to other things that are in the game. However, deciding where these ice chunks should be is a much more complicated task. Players will be able to create a huge amount of different craft, with parts angled in different ways, occasionally clipping or interacting in weird ways. Generating ice on these craft will be a big challenge - and then running the colliders so the ice doesn't just pass through them will be a lot on the CPU. As an example, say you want ice on any surface that is a fuel tank or connected to a fuel tank and is less vertical than 60 degrees. Nose cones on side tanks, if they are separated by one or more parts, will not have ice even though they should be cold due to them being clipped into the main tanks. Parts that are inside the craft and surfaces that are clipped together will generate ice, even though they shouldn't. This system could work pretty well for most cases, but will fail in a big way on craft that are not designed in anticipated ways. Then, colliders are a problem. If you want fidelity, you need a good number of ice chunks - some of which will probably be inside the craft due to clipping, fairings, or other bays. These are a lot of objects to track the paths of, and with many situations, the colliders will mess up and produce immersion-breaking results. Even with a lot of effort put into resolving these issues, the final effect will probably look janky a bit too often for comfort. For modding, I guess if someone wanted to do something, it isn't impossible to create a system like this, but the effort to polish it to levels that would be good for official KSP 2 content is probably too high.

Why would lightyear be a hardcoded value? There's nothing in the game that explicitly needs lightyears to work, unless you want some sort of ruler function to measure the distance between stars. If you are traveling at 0.1c, then it should take 10 Kerbin years to cross 1 Kerblightyear and 10 real-life years to cross 1 real-life light year. If you replace the Kerbol system with RSS, things work properly because the length of a year changes. And if you are getting into other modded systems, you should expect that it will take different amounts of years to cross different distances.

If you had a ruler that appeared on the screen and displayed the numbers so that people could see how comparatively small the Kerbol system is, then yeah. As it is, zooming out would give you the visual of 40 ly rather than 4, because there's no reference to stop people from assuming that the Kerbol system is 'standard size,' resulting in a gross overestimate of what a lightyear actually is compared to our solar system. If you really want a visual reference of how big a light year is, you are better off using the scaling system that the rest of the game uses so that things have proper proportions. I don't want light years to be 1/10th the size, or 1/4th the size, or even the size that they are in real life. I just want the size of light year that makes the most sense for gameplay. The point I was trying to make above is that no matter what distance you use to represent a light year, there are going to be problems with it. If you want a visually accurate depiction of the scale of a light year, you should keep its proportion to the rest of the game the same i.e. 1/10th. But that also creates a cascade of things to reconcile in the units and constants (the time it takes wouldn't actually change much, as "shorter" trips under full baristochrone trajectories take similar amounts of time). Most importantly, the actual value for a light year measured in meters is going to be wrong, which is bad for anyone who looks it up on the wiki and is woefully misled by distances that are an order of magnitude off. This applies to any value that you assign a light year. If it isn't 1 ly, that means it isn't numerically accurate and people will probably want some sort of reason for that within the lore of the game. The 1/4th ly measurement probably works well for this, but then again, it isn't accurate and will throw people off when trying to convert from lightyears to meters. 1 ly is the only numerically accurate answer but it misrepresents the size of a light year by being too large for the rest of the game. So you have to decide what criteria you want to fill when scaling light years. And I choose the gameplay of it. Longer distances do result in longer transits, but not in the same way as you might think. The interesting thing about a baristochrone trajectory is that the time to cross any distance increases with the square root of that distance, ignoring relativity and other effects. So crossing a distance in real light years is only 3 times as long as doing the same in deci light years. Between 30 and 100 years, the gameplay implications are pretty similar. However, the real consideration here is delta-V. If you want to take advantage of the square-root law, you have to be in a full baristochrone trajectory - no coasting phase. With smaller light years this is much easier as you have to burn for less time along the journey, while there is more challenge in getting enough dV to make a "quick" journey in large light years. Somewhere from 0 ly to ∞ ly is the right amount of challenge for KSP 2, and that is where I'd like light years to be scaled at. The educational purpose is never going to be fulfilled because they will always be off either visually or numerically, so in the end, the gameplay challenge is what matters.

In earlier KSP 2 images, when hovering over a part in the VAB, the information includes the cost of the part as well as the quantity of that part you have. In the most recent dev diary I haven't seen that, but there is a good chance it is going to be in the additional information that you can access by pressing shift, either on release or once the "Exploration" update releases. What I speculate this to mean is that instead of scrapping craft, you can get the parts back and re-use them for future missions. This is probably most useful on colonies so that you don't have to produce more parts, but I hope that you can still keep craft "intact" at the KSC. Since this system is sort of like a suggestion, here is what I'd like to see in order of increasing fancifulness (and probably complexity to implement). When loading craft into the VAB, I'm sure there will be some sort of organizational system. A separate tab for craft that are "stored" in the colony would be nice, especially seeing as they can be "built" out of the same parts they came in with, meaning no new parts need to be built When loading a craft that has previously entered the colony, having an overlay to show which parts are missing (from other rockets taking them), something like the parts being greyed-out and transparent. This could also work for any craft in conjunction with the next suggestion, to show which parts are available and which ones need to be built. Being able to select whether you want to build a part or use an existing one would be great. If you are putting together a new interstellar craft, you might want to "borrow" the Daedalus engine but make new truss segments so that interplanetary transport ships can use the old ones right away. Lots of applications could come of this. Having to store the parts in dedicated modules would be nice, making bases look varied and potentially tying in with whatever logistics challenges are present with colonies. What would be especially nice is if you could see the craft rendered in these hangars, and even remove the parts from the craft as they are used for other missions. Lastly, there was a realism mod that made it so that tooling a specific part or putting together a stage for the first time was very expensive but was then more efficient for future launches. Having a cost to reassembling craft would encourage interesting choices, like a moon rover that re-uses a deep space probe body because removing only the solar panels is a lot cheaper than separating and reattaching all of the batteries. Or again with the repurposed interstellar ship, re-using the entire truss structure, habitation and all, because a more efficient cargo configuration isn't worth the cost of disassembling everything. I'm not sure I want this to be Stock as most people would find it overly restrictive, but it would be a good extension to that mod.

Is this to stop from losing progress during a game crash? I don’t know enough about performance to say whether this system would worsen the problem it is trying to solve, but it might be good to not save during a crash, in order to avoid potentially carrying the issue over upon re-launch (if the crash is based on something that gets put into the save file, like craft positions or states)

The helipad is likely a leftover from KSP 1 where the administration building had a helipad, I think way before robotic parts were even in the game. The two probably don't correlate, although helicopter parts would be able to use the helipad quite well as in KSP 1.

I think in the Q&A section or the following pages of the early access announce thread, it was mentioned that save compatibility was an important objective throughout Early Access (at least, forwards compatibility), but no guarantees were made that it would work out fully.

There's some pretty nice dense foliage in the KSC too - I hope that scatter density is something that is adjustable for performance

Allegedly Since new news comes every month, people were wondering what would come this month, and @Ghostii_Space mentioned that We have gotten a dev diary, so the idea is that a trailer could also be on the way, because the December holiday is generally a good time for marketing

haha, yes But in all seriousness, massive quantities of Methane can probably be found all over Kerbin as it is essentially a giant grassland, a large part of which could be marshes or peat bogs which have a lot of methane-producing bacteria. I don't think the Kerbals would need to use animal farts to obtain their methane.

I just realized, I assumed I would be overriding game files like textures and music manually or, more likely, through a mod, but if there is time to create an in-game interface for uploading asset packs that override stock ones, I would greatly appreciate it.

In the PC gamer interview when taking about the roadmap, Nate says that the first step of the roadmap, the “Science” step, introduces the mechanics that make up science mode, which is separate from sandbox and Adventure mode, which comes at the end of the roadmap

I pretty much see this being the case. The reason is, we know that before colonies can build their own modules to do manufacturing and processing, you need to bring the modules in. This means there must be a transportable module that coordinates repeated missions, one that can manufacture new parts that can’t be transported, and one that can do ISRU. Without these modules being transported, it would be impossible to start growing a colony, so I think that you will see those parts in the game

Right, I think I see the misunderstanding. First, colonies can be in space, not just on the ground. That has been confirmed pretty much since the announce trailer, with all of the orbital colony stuff we have seen. Second, I’m pretty sure that anywhere you could set up a ground-based colony, you could do a space-based one instead. With a big enough ship, I hope you can put down enough fully completed modules to kick-start a new orbital hub, just like you can fully deliver a space station to a destination. You can then collect resources like with any other colony, from asteroids or nearby celestial bodies. Third, I’m not going to judge your play style, but there is functionally nothing different between surface and orbital colonies. Colony is here, resources are there, you decide how to get them. Instead of rendezvousing you are driving in, and instead of undocking you are taking off. If that doesn’t appeal to you and you would rather only deal with the orbiting part is space travel, then that is totally fine. I sincerely hope that the game is reasonably completable without needing to put a single colony module on the ground (or in orbit for that matter) because that would mean the variety of playstyles available would increase significantly. Also, with an interstellar ship, you should be able to reach any destination from anywhere else, so if all resources are really available and free from Kerbin (which I doubt), you can always plant flags on every celestial body without a single colony outside of Kerbin SOI. Problem solved!

Wait, I was just reading through the thread, and this stuck out. What are colonies, if not space-based infrastructure? Oh. So let me see if I understand the distinction: you see colonies as boring planetary infrastructure, while space-based infrastructure is cool? Correct me because I’m sure that was a gross oversimplification, but I hope this can get perspectives across: Colonies are pieces of infrastructure that are hub points for missions and allow the creation of new ships. Details of the implementation aside, a space station and an orbiting colony only differ in the size of the parts they use. If you had fun putting the space station together in orbit, well the colony is the same thing. This is, for example, a pretty good description of a colony. To build this interstellar ship, you said you need something to manufacture parts, presumably on a space station of some sort, and some ships that transport materials to the station for processing on some sort of repeated route. That station is a colony, and by investing your resources in the asteroid miners and parts manufacturing facilities, you are getting yourself the capability to build that interstellar ship. What you want and the colony system seem to be the same thing, just one of them has a defined name. Ground based colonies are just like orbital colonies or surface bases, but on the ground. Seeing as you are willing to launch from Kerbin to get everywhere, this shouldn’t be any different to what you are expecting.

I would like to start by pointing out that KSP 2 is not a voxel-based game, it’s terrain is stored as a 2D texture. @K^2 outlined how having multiple heightmaps could produce large-scale underground terrain, but these are more limited than voxel terrain maps. I probably shouldn’t have to explain how transitioning the entire planetary terrain system to voxels would add several years of dedicated development, so I’ll just say that the easiest option is likely to involve a lot of work to make procedural terrain create workable cave walls. With technical concerns aside, I’d love for oceans (sub-surface or not) to have parts that interact with them. Especially on lifeless worlds, however much interesting stuff there is to find on the surface, there is just as much to find in the oceans. Adding more environments diversifies mission profiles, and oceans can bring about new craft architectures, which just puts more “build and fly” into “build and fly.” My personal preference is to go deep, adding in sonar scanners, air tanks and pressure-capable hulls for ships and submarines, as well as underwater-specific modules like geothermal power (which would be very effective in underground oceans), pressure locks (for transferring kerbals to/from the surface) and underwater-specific “launch pads.” Adding the whole pressure mechanic would probably be too much work for that gameplay as it would have to be set-and-forget, but who knows what directions are taken for updates and DLCs. Overall, I think a “buoyancy update” encompassing anything floating in a fluid would be a good candidate for adding new mechanics down the line.

I am totally fine with you wanting a more in-depth experience through life support, signal delay, etc. but interplanetary missions are very different when going to different planets, and this requires different design principles and not just higher delta-v numbers. I've played with realism mods and I can assure you that the design challenges you face, both in stock and with mods, can be very engaging and vastly different than the ones you have around your homeworld and its moon(s). With your experience, I'd recommend trying it out and seeing how branching outwards adds more depth to the game than more levels of brute force Isp and dV. For example, I did my first (sadly un-recorded) Jool-5 mission a few months ago after going back to Stock, and the mission had a lot of considerations to manage. I could have replicated the dV cost by simply having a mission go between Minmus and the Mun a few dozen times, but landing and returning from Jool's moons requires rockets that are different from those that can land on the moons. I had to consider whether I wanted my mothership to be able to land (which meant balancing fuels for each part of the trip) and how much dV each sub-lander should have. I put together an ISRU system to refuel on Pol and consolidated the Vall and Bop landers, but Tylo and Lathe have completely different requirements to the rest of the moons. One of them is atmospheric and a vacuum-designed craft would not be stable, and the other needs the most dV possible to land and get off of. Designing a lander to be able to get off of both planets (while staying small enough to transport via the mothership) was more challenging than if both planets were just differently sized balls of rock, and presented interesting gameplay. Overall, the mission was a lot more in-depth design-wise than it would have been if all the planets were, as you said, just about the size of the rocket. My point is, having these destinations is one way that the game gets more depth. This works in Stock as well as with challenging mods. If you decide to do an interplanetary mission, you will discover another side to all the mechanics you added via mods. Your life support mods now present an interesting balance between longevity and weight, when you only had to optimize for one or the other before, in bases or ships. Your part failure mods are now much more complex and interesting to manage as the complexity of interplanetary landing missions dwarfs even surface bases on the Moon or Mun. Your radiation, signal delay, and fuel boil-off mods suddenly take on a new dimension as you have to manage distances, times, and circumstances that you never had to consider near your starting planet. I'd recommend even attempting a crewed landing on Mars or whatever planet is easiest to get to with your mods, and you might see how people are satisfied with even the simplified mechanics of Stock, applied to interplanetary and now interstellar challenges.

What usually happens is that the server has a mod list and the computers that connect to it have their own mod list. The server handles all of the effects so even if a client has a gameplay mod that isn’t on the server, it will usually only result in problems on the client side, when the computer asks the server to load a craft with parts that don’t exist or something. If lightweight Lua mods are a thing, then the server can just send over its mods as the client connects and ignore any extra mods that the client has. I think one of the benefits of this approach with Lua is that the mods don’t have to load at startup. They are on a different layer anyways, they don’t interact with the game similarly to C# mods, the game instead encompasses Lua mods and runs them inside itself, which means that you should be able to start and stop them without causing the game itself to fail. I’m also not an expert on this, so if anyone knows better, correct me. As a result of being able to load Lua mods after the game starts, you could have (probably smaller) differences in mods between your save files, and when you join a server there could be a separate mod list that gets downloaded and activated on your computer as you join.

I just looked at the image again after the comment that it was blurry, and I suddenly noticed that there were clouds in the background, which I hadn't before because I'd just seen it as "sky." the edges are a bit soft and the blobs are less defined than a comparable sky in reality, but the shape and distribution looks good enough that I could see this cloud pattern easily existing in real life.

This is why I didn't really want to participate in the racing discussion, as I don't really care for racing against other server members, even in competitive scenarios. Either I am further progressed or the other team is, and the amount of in-game time that took is not what is important to me. It seems that if players try hard enough to game the system, there will be loopholes. Maybe not the one that you pointed out, as you can easily add logic that adds up the elapsed times when overlap is ruled out (as in, several players performing orbital assembly "simultaneously" doesn't count for extra time, but several players completing one transfer with one ship does), but there is sure to be some way to exploit the system for determined individuals. Again, I don't really care for space racing, but I think that most players wouldn't try to exploit the system so harshly against their friends, and in those situations where you truly hate your server mates, moderation tools are there, and of course you can always decide as a group who really won the race.

not exactly, the idea is that you warp forwards, but not all the way to the other player's time, only to a point which is comparable to their time within that specific frame of reference. Instead of projecting forwards, you are projecting backwards and finding a suitable time where the backwards projection lines up exactly with the current state. If you end up warping forwards to the other player's time, then great! It functions just like Leapfrog. But if you dock to something in the past, it doesn't necessarily warp you all the way to the present, just to the earliest point that avoids spatial discrepancies. As for racing, I'm not sure there will even be official racing, but you can measure total in-game time and find the largest difference from start to finish. It doesn't matter if players spent their time in the VAB if the mission still took five months to complete the transfer. Oh, and I saw something I wanted to respond to, but I didn't want to interrupt the racing discussion. @Pthigrivi, you made a point that you don't know whether a ship is at the periapsis or apoapsis of its orbit in the cyclical system. I wanted to say that this is also the case for Leapfrog. You are in the past, so you can't tell whether a ship is at its apoapsis or periapsis, or even what SOI it is orbiting in. However, both models give you some consistent behavior so that you can rendezvous to that ship, and then the main advantage of Leapfrog is that if you can dock, there is no time warp required to synchronize things. Both systems hide the true position of the craft, but one compensates by disallowing interaction in situations where that matters and the other compensates by forcing a short warp in situations where that matters. The idea is that if you are docking to a station orbiting Jool, you care about synchronizing whether it is on the day or night side, whether it is at Apopasis or Periapsis, but not much else. So if the moons are in different positions, specifically for docking to that station, that wouldn't matter. If you wanted to dock to a ship that is transferring to or between moons, instead of warping 6+ years, you would warp a few days or weeks until the exact same transfer window appears. There are innacuracies in the transfer windows that I still need to think about, but that is the concept.