t_v

Glad to see you found the solution! G in KSP is probably Gm, which means you are 10 Billion meters above the body you are near. The Vector engine is indeed pretty powerful, especially combined with the infinite fuel cheat, though the “weaker” engines have their uses too, especially when you don’t have much fuel or are going far. Good luck!

In-game rewards have a pretty similar effect to real life rewards. People get heavily invested in their games and will treat in-game success the same way as real-life success, to varying extents. The idea is that a system that relies on contracts between players cuts out the verbal communication part and only includes the actual work/reward part causes people to be more competitive and less collaborative. No matter what interaction that has to do with resources, one or both people are giving up time and resources, and people benefit from the arrangement. Usually, when I’m collaborating with someone, I have resources, they have time, and we agree to share those resources if they utilize them in a useful way, or vice versa. But despite the interaction being functionally the same, the added element of conversation and the spirit in which the interaction was made really changed the experience.

For fun. People here seem to prefer flying manually, even though we all have the option to download MechJeb and use it for everything. I certainly prefer flying manually. Also, this wouldn’t be core. It would be an optional setting or unlock, and only people who need the assist would use it; very few people who can do the game normally will ever touch the autopilot. I apologize if I made it seem like this would be the central gameplay; if you can point to that spot I’d be happy to correct it. I would rather see more people stick with KSP through the use of an autopilot than leave the game in frustration because they can’t learn orbital mechanics through initial pack of skill. I also just realized this argument is akin to “why would anyone turn off the spike immunity in Celeste?” Because they want the challenge and it is better that way.

Can we not argue over semantics? The meaning is that more people will be able to experience the game. Call that what you want, I’ll call it accessibility personally. The difference is that excluding orbital mechanics is excluding a lot of mechanics that are central to the game. The “wasd” mechanic may be in the PC experience, but in console versions it is replaced by the “joystick” mechanic. Flying a specific way has never been core to KSP, in fact the way that people fly differently is one of the things that makes KSP so special. Take gravity turns for example. Someone spends a bit of time to set up a turn and let’s the rocket do the rest. I love that, it requires clever design, a knowledge of rocketry, and a good decision on when and how to initiate the turn. But this is significantly less manual flying than the heat-capped manual ascents that I like. Does this cut gameplay? No. The orbital mechanics are still there, the design is still there, the same decisions are being made on how the rocket should be moving, but now the only input required is pressing a button that locks the spaceship to prograde, which is essentially a small autopilot function. I’m not sure this is serious, but I’ll take this to demonstrate a key difference that I think you are missing. If there were a button that constructs a full craft for you with any specified amount of dV in one click, I would not want that in the game. It doesn’t teach the players anything and they aren’t making decisions. However, if the auto-builder did things like take a stage and extend it to match a certain dV target, and then ask “do you want 0 fins, 2, 4, 6, or 8 on this stage?” And then lead the player step by step towards building the rocket, going through a checklist with electrical, thermals, control, parachutes, etc. I would be happy including that in the game. The player is making the same decisions on how to design their craft, they are learning how to properly include everything they need, and eventually will be able to remember and implement those systems without needing the auto-builder tool. The point that you have missed is that there are different types of autopilot. Simplifying the flight model isn’t providing autopilot, and Elite Dangerous’s autopilot is a very different autopilot to the one that @shdwlrd is talking about. I subscribed that school of thought for Elite Dangerous And, forcing the conversation into one about full hands-off autopilot (that no one really wants) is just dodging the discussion of actual, educational autopilot. Rendez-vous is not a skill that is determined by how lightly you can tap the RCS buttons, it is a skill that is learned through application of orbital mechanics. An autopilot that walks you through the steps to complete a rendezvous then does the burn for you still puts you in control of the flight and educates you on how orbital mechanics works. A good game autopilot will eventually make itself useless for most players. Also, for the concern that it removes failures - inputting that maneuver node is still a point of failure because you can only be so precise with it. The point is that automatic functions don’t have to remove gameplay. Players can still make the same decisions and learn the same things about spaceflight, but with someone there to help them and remove the skill factor. And later, some players that needs the autopilot will be able to complete missions without it, and the players that really need it will still have it.

What I would love to see this used as is a framework to codify challenges and missions. Having a very open system to set parameters, other restrictions, and rewards would help people use this system for many different purposes. A contract that: only activates after the “t_v’s awesome moon landing contract” is completed requires any pod to land on Minmus and then splash down on Kerbin returns 100000 funds I could see these contracts being given out randomly, with the starting contract of a chain being rated by players to increase or decrease its visibility A contract that: requires a specific payload to be launched requires that payload to be placed into polar orbit around any body, between 450-550 km returns 25000 funds and 10 units of deuterium, and places that payload in the contract giver’s game. A contract that: automatically triggers five smaller contracts which: require a kerbal to land on one of Jool’s moons require that kerbal to not be used in the completion of the other four contracts and require the kerbal to splash down on Kerbin. This returns nothing, but the contract now shows as completed In an ideal world, a basic yet very flexible system for creating contracts and challenges, integrated into the game, allows the player base to generate endless content (as if KSP was missing any), utilize other people to accomplish goals in exchange for resources, and verify challenges effectively. However, this needs to be done as a side mechanic, separate from the flight and design parts of the game; the pause menu should not open up a whole marketplace of contracts and resources flowing in and out of your KSC.

System requirements will probably be posted much closer to the Early Access launch from what I can guess. The main focus seems to be getting good performance and stable code for a portion of the game, so requirements will rapidly change until shortly before launch.

Thanks, I don’t play either game, so I was just getting information from secondary sources. Even this corrected information won’t happen to KSP because you can still play KSP 1 separate from KSP 2.

This is why it won’t happen, most probably.

What happened with overwatch is that the original game got shut down. Servers are gone, player data is gone, I’m not even sure if you can download the original game anymore. This would be a concern if it happened to KSP 1 because you would lose access to the game, including any DLC that you purchased

Releasing the new part list, maybe even to a new wiki. This would indeed be helpful for people who want to calculate dV ahead of time, but probably not for le since I need to see the parts in game to decide how I’m going to use them.

For your concerns about splitting threads, we are many threads into the science discussion. I would have linked them in the “science progress” thread to save space and time, but then I realized there was some original stuff with the discussion of real science experiments. I really hope it doesn’t turn into yet another thread discussing the tech tree or science points. And this is in the first 1/5 of the total amount of threads (over 50 pages, wow!) so I don’t know how many more there are beyond that. I do remember seeing a few…

Both of those currently exist as mods, and they should not be added to the base game. KSP makes for a poor warfare game unless you basically go for a reskin of CoDE, which means its implementation as a war game is very likely just going to flop. To be clear: I have nothing against people going for the experiences they want, sub-par or not. But when official content is released, it should fit the core vision of the game. This means no warfare, and no going for the most realism possible.

What a strange conceptual structure. Somehow though, I don't see any bottlenecks, even with large groups of people. I know relatively nothing about architecture or building design though (which I guess will be a limit on the size of my colonies).

The theory is that the minimum spec required to run a demanding game like Cyberpunk should be enough to run pretty much any game that is less demanding, like KSP 2. So going for that level of hardware would ensure a decent experience over the next few years.

I think it is the opposite. If KSP 2 mods work anything like KSP 1 mods, then every time you add or remove mods, you need to re-load everything. This is because mods can take priority over other mods in complex ways, and all the part modules will have to be re-constructed to avoid unintended behavior. In the other hand, toggling mods from a launcher or before starting up the game would work much more easily, and databases of mods that you can download from can also be implemented nicely.

I think that the performance depends on how multiplayer is implemented. I detailed this in another thread but for one example, doing the calculations on the client versus the server makes a huge impact on performance, and you might want to do calculations on the server when there are lots of background missions or someone is trying to use a modified client. And no matter how performant the system is, people will try to push it. At that point, you either own a server or rent one, and renting one from the first party has a few benefits like keeping the game funded for longer. Not as many people will rent servers if they don’t reach meaningful limits on their machine and network, but having that service would still benefit some people and the devs.

I agree with this, and I don’t think there is a single best way to do anything; it always depends on the context. However, the question is: what should the default experience for KSP 2 be, and what additional options should be coded? We don’t have to agree on that; that is what the discussion is for. But one form of LS with death is going to end up very different from another form of LS with death. Instead of just saying that death or hibernation is better, consider why it is better gameplay in context with the LS system that you are envisioning. Or if you truly think that death is better than hibernation under all contexts, then why?

Then ‘death’ for kerbals can be defined as a temporary state, as long as the body is left in relatively good conditions (such as in a closed capsule). Semantics aside, the decision for permanent death or hibernation should be made on which one benefits the game more. I think that we are not even clear on whether life support is good gameplay to begin with (because we haven’t agreed on how it should be implemented) But between being punished by losing time and investment, and being punished by having more gameplay and the chance to continue an important mission, I know which one I’d prefer.

I think it depends on how the multiplayer connections are done. On one theoretical end, the server can load the client up with just the amount of craft that it can handle and then let all the physics processing happen on the client end, with intermittent updates to allow new developments to be seen. With this somewhat lower quality system, the server could maintain quite a few players (probably tens of thousands in one server) as bandwidth and compute power are minimized. However, the more fidelity you want, the more taxing each player is to the server. If you want players to not be able to cheat themselves anywhere, duplicate crafts, and generally break the game, you need the server to be running its own instance of KSP 2 to determine what is reasonable and what is hacking. With a few thousand players burning, transferring resources, and doing things, this becomes much more taxing for a single server. Then, the amount of bandwidth will get limited when the server tries to show a hundred players that a vessel has started burning, and consistently updates and synchronizes all of the connected clients. Finally, if the time warp system (yes, we are all tired of hearing about it) allows people to see the past, does the server have to store all of the events that have happened? This could quickly reach a rather large file size, even with some smart logic and optimization. So it really comes down to implementation. I think that the practical limits of a dedicated server running KSP 2 will reach a few hundred players with reasonable fidelity, but I hope to be surprised.

If you want to look at the suggestions, the sub-forum is accessible from the main page under the KSP 2 section. I’ll link it here too: https://forum.kerbalspaceprogram.com/index.php?/forum/112-ksp-2-suggestions-development-discussion/ If you want to suggest some things, you can start your own thread in that sub-forum. Alternatively, there are a few threads for small suggestions that don’t merit full threads. I’ll link one here: I hope this helps, and welcome to the forums!

I am guilty of this. But on the topic of who hosts the servers, I hope that it is a dual solution: independent parties can run the server software on their computers, but Intercept also does first-party hosting as a subscription service. Server hosting is a good way to make a bit of money, and the benefit of a first party service is that for the user, they get good integration and ease of use, and a standardized stable connected host machine. The developers should develop their multiplayer software to work well on many devices, but there will always be specific configurations that run that specific software better than others. Most independent parties will not invest in machines just to run KSP 2 servers, and so the way to get high-performance stable servers are to pay for hosting. Intercept can provide that with the additional benefit of good integration, and making money this way will keep the game afloat for longer. I personally will use old machines to run servers whenever I can, but for a large portion of the target audience, this would be a good option to use, and this would generate a fair amount of revenue. What do you think?

Thank you for the clarification and I apologize for the misunderstanding. Visualizing staging can still be a very difficult thing to get right with the extreme freedom that KSP gives players, but I think that it is much less difficult than a full trip visualizer. As for maneuver planning, I think that a tool tool that plans your maneuvers at the start would be feasible, but not worthwhile because I don’t think anybody can make their launches consistent enough for the maneuvers to work. However, planning out a high-dV burn in the editor might be helpful so you know that your ship can actually do the mission before you are in orbit and realize you are 10 km/s short.

Many people have said this before: there is no bar. At least, not one set by these mods. KSP 2 can look worse than this and still be a good game, just like KSP 2 can look worse than MSFS and still be a good game. The quality of these mods does not put any pressure on KSP 2 because reasonably, KSP 2 should be judged on its own merits rather than expected to keep up with products specifically tailored towards a specific aspect.

I agree; I think it speaks volumes to the potential of FAR's system that it is pretty fun and intuitive despite its UI shortcomings. I have not had the best experience porting my plane designs over to FAR because the aesthetic I am going for simply does not work well aerodynamically, but @Dinlink has shown me that creative designs are still possible with some extra considerations. What I would like though is a FAR like aerodynamic model, that includes the benefits of having sleeker planes go realistically faster and the voxel model making the interiors of cargo bays possible, but tones down the realism so that people like me and people who are even worse at designing planes than me (which there are a very small number of) can learn these realistic aerodynamic effects without hitting such a steep learning wall. I think this requires changes beyond just UI, I think this requires the effects to become easier for new players.

Okay, let me restate: this is a relatively simple mission for me. It is just one step up from an Apollo-style mission (2 detachables instead of one) and is honestly much less in-depth than a mission I would normally use for a single-launch Eve colonization. I dislike that you think I am making false embellishments when I was just trying to point out some technical difficulties with this kind of system to the best of my knowledge. Okay, there’s one fix. Have the starting image be the same orientation as the rocket in the VAB. When does it flip? Because if you have a mission that makes a burn in the upside-down direction (e.g. you have an ion engine on the front of the ship), you would want to flip that again. So do you calculate thrust direction for each stage and orient the craft based on that. What about maneuvers using RCS engines then? This problem is already pretty complex, and needs to be solved for a visualizer to work. As I said before, the plane is attached via a docking port, so that it can re-dock to the station. There’s nothing in the staging that suggests if or when the plane detaches from the mothership. So the assumption is that it stays attached and the two land together. The alternative is that another mission with a drone that is meant to stay attached and parachute a base down decouples and suddenly a surface base is left in orbit. If you just want stages of the rocket separating and you don’t care about where those stages separate, that could solve a lot of these problems. You wouldn’t be showing burn information, location at each of those separations, or any other information that would be useful for a mission planner, but it might be reasonably achievable, still with a lot of issues. You are getting the wrong vibe. I would really, really like for this to be in the game. It would make for such a special experience to see your own rocket represented in the same professional style as rockets that have millions of real-life bills invested in them. If this could possibly work, I would strongly advocate for it. But just like planetary collisions, there is no way that you can program a tool to take all the possibilities and represent them well in the scope of KSP 2. The sheer amount of craft that people can design means that any system you create, no matter how well developed, will break when someone tries creating something new like a stack separator loop. I think that Pthigrivi’s idea of mission planning is much more feasible- we already have good delta-v readouts on ships, at least for 99% of cases, and doing things like pork chop plots is a problem that has been solved. Full-trip visualizers are not going to happen, only numerical trip planning and maybe some partial, restricted visualizers.