Bartybum

The player's already not looking for gameplay to be balanced, they're looking for it to be easier. You can still ignore aero heating while having overheating engines and functional radiators, since the two aren't solely dependent on aero heating. By all means, but that's not guaranteed to convince the player to keep them. They may be totally incompatible with what the player wants to do, like drop a large cosmetic mech out of orbit and land at the KSC in sandbox. And yet the player may go nah screw that, I'm here for cool stuff not realism.

But even then, that's just one contract out of a range of available ones. All it takes is to not make that one pop up if G-limits are disabled. Thermal effects are very likely gonna rely on velocity and air density. All the game needs to do is just ignore thermal effects. It's going to impact the game by making it easier, which is exactly what the person who's disabling it wants. I dislike the notion that it's "throwing in the towel". By all means, I'll welcome an attempt, but the way I see it, the only thing that's fun about it is the cool flames. Keeping the flames and disabling the heating is already a thing in KSP. It's wise to cover your ass in case the players you're trying to persuade with fun mechanics aren't persuaded. A hard game is still a hard game, even if it's well made. Some people are gonna want the game, but aren't yet ready to tackle the learning curve in one go.

I do wow that's niche. Thank you!

I'm having this same issue. It's making AFK rover voyages impossible. I'd like to be able to stop at every waypoint and quicksave, but as soon as i pass below 3m/s, the rover starts spazzing out. The stability assist should reduce to 0 below a configurable speed.

@KSK but how would making comm range, aero heating, plasma blackout, G-limits, etc. optional more difficult for balancing? Whenever they're disabled they're disabled because the player wants an easier game to begin with. Bar life support, I honestly can't think of any features that players would want to be optional that would impact balancing in any meaningful way.

Bar microtransactions and unreasonably excrements DLC, I can't really think of any blocker features to be honest. I'd only opt out if the game wasn't filled up with good stuff.

Okay I must have been dreaming. I swear I've seen you say the game is meant to be played casually, but I guess not D: Carry on

That’s kinda subjective though. As is your idea from earlier in this thread that the game’s meant to be played casually.

Except they will... [snip]

Assuming you're talking about all the near/mid-future engine types we're gonna get, they've very obviously been added to address the time issues with launching otherwise multi-decade missions while trying to develop a space agency back at home. It's a very different situation than multiplayer. I agree with OP, MP is likely gonna be small local servers. MMO just wouldn't work for KSP.

What if I don't wanna have to deal with G-limits, plasma blackout, atmospheric heating or comm networks? What if I just wanna have some fun in my own way i.e. sit back and create something ridiculous? To be honest, it sounds to me like you're trying to dictate how others should be playing the game.

Mmm, no it defs doesn't, does it? I suppose multiplayer could be based off the assumption that both players work cooperatively (i.e. you wouldn't play KSP with someone you don't like), and then it leaves it up to the players to decide whose version of the station will persist. This way, if B destroyed the station, and then synced with A, the game could prompt both to decide whose instance is correct. The same would apply here. Both users must work together to decide whose station instance to keep. That being said, this whole scenario seems like one based of a neutral/hostile relationship between players. It can be avoided if they just coordinate. Perhaps again, the tech that's unlocked will be determined by whose instance is considered correct. That way if you used a ship to fulfill a contract/unlock tech and that ship gets wiped, then so would the tech/money. Tbh I hadn't thought much about money and stuff though - I've mainly been focused on sandbox gameplay. For a co-op career, I do think forced timewarp would be quite cool, but I wouldn't wanna play that with more than 3-4 players (which is plenty), because of transfer windows. I do, people can learn things pretty quickly. To interact with a player, you'd simply have to be synced to them. In any case, I would also see the option of locking timewarp to prevent desync being implemented when players wanna interact, or even globally so that there's no desync at all.

My apologies if that came off as not chill, not my intent. That being said, I do find your attitude towards the gameplay style I described earlier to sound a bit like gatekeeping. Personally I don't think it's absurd to play how I'd like to play. After all, it's the same general play style as in any other multiplayer sandbox game. People go off and do their own things free of restrictions, but can interact together if they wish. I answered that: I have preferences on what I'd like to do, and I don't want to have to be constantly waiting to do them. Do I have to keep sending missions out? I don't want to have to wait months in real life to finish them because others keep having more urgent missions to do. At some point I'd like to finish my missions. If B docks to the station on day 1, then the paradox only occurs when B tries to sync with A after B has docked. One solution could be to prompt B that to sync forwards with A would require B's station to be replaced by A's, effectively undoing B's work. Admittedly, this would require some measure of player coordination to avoid losing ships due to the game trying to avoid paradoxes. I imagine the scenario to look like this: A and B each launch a ship into orbit (assuming the station has more than one docking port) Both craft are at time T=0 A timewarps forward 5 days A is at T=5, B is at T=0 A informs B that they will be docking to the station; B cooperates and agrees to wait until A's save is ready to be synced with (only logical; you want to make sure you set out at the correct time) A docks (assume it takes one day to dock) A is at T=6, B is at T=0 (but can be anywhere between the two) B syncs with A, and then A goes and does something else. The station in B's save now has A's ship docked to it A is at T=6, B is at T=6 B docks A is at T=6+x (x is whatever arbitrary time has passed while A has been doing other stuff), B is at T=7 (assuming it also takes B one day to dock) If B warps ahead of A, then A can sync to B to update the station and A's save. Otherwise, A is prompted by B to update A's version of the station (sort of a reverse sync) to reflect what the new station should be (with both ships attached), as well as where it should be. Both players' saves now have the station with both ships docked, both in the correct position in each player's respective timeline If that's programmable, then personally I don't think it'd be too difficult to get the hang of, especially if taught properly in a tutorial with examples. I think it follows a fairly logical train of thought. The timewarp queue is the priority list that I was talking about earlier, the one that would evolve out of transfer windows: At max I'd imagine no more than six to eight players.

Why is it up to you how others play multiplayer? Both play styles are equally valid. One person does a mission here, one does a mission elsewhere. Space agencies can have multiple missions at once. I’m on a multiplayer server because I wanna build stuff that others can then later interact with. And likewise, I wanna interact with their stuff. It’s absolutely relevant, because if my connection drops at the wrong moment I’ve lost my position in the queue and have to go do something else until my next transfer window/whatever, which could take god knows how much time if I have to wait for other players because they’re doing stuff in that window. That’s not fun.

Because I don’t want to wait days or even weeks in the real world before I have a chance to continue what I was doing. What if I don’t have time to play KSP every day? What happens if my connection drops out when it’s my turn? Does the whole server pause, or do I suddenly have to wait another few weeks in real life before I have another chance to do my thing? If I have to wait months in real life to do even basic interplanetary stuff (not even mentioning interstellar voyages) then what’s the point?

Problamo is that in Minecraft it doesn't matter what the time of day is. You can do almost anything at any time in that game. That's why people can coordinate time changes so easily in Minecraft. KSP doesn't have that same luxury, because you have to deal with live physics, transfer windows, waiting for maneuver nodes, rover voyages and more. Forced timewarp (voting is still forced on those who don't want it) severely bogs down progression in the game. Picture this textbook problem: A wants to drive a rover from point A to point B which is an hour away. B wants to do a mission to Duna, but his transfer window's in a week. C is already en-route to a Munar orbit, arriving in two days. Alright, in that case we let C go first, because their mission won't take long, and they're coming up first. Then comes B, because theirs won't take too long either. Last but not least comes A, whose mission will take an hour. Assuming nothing went wrong, A only had to wait about 10-15 minutes to do their task. Now B and C both have to wait an hour before they can do anything, and after that, one of them will have to wait for the other too. Suddenly we have to prioritise who can do what and when, and the whole game slows to a 1x crawl. The waiting is only compounded by however many failed attempts and reloads have to happen. Furthermore, once you have even primitive life support systems in the game, you need to plan way ahead and pack loads of food, otherwise your Kerbals could be waiting in orbit for years before they can do anything. While it may still be tolerable on a server with only three players, once you start adding more and more, the list of prioritised tasks grows and grows, as does the waiting time. I don't wanna have to wait for hours on end for the other players to finish what they were doing, because that's not fun for me in any way. They don't wanna have to wait for me, because that's no fun for them either.

Minecraft is not KSP. You don't have people doing stuff that heavily relies on time progression. Then just hit the sync button? And don't play with people who refuse to hit the sync button? It's as easy as not playing with griefers.

Fair point. I would love for automation; it'd help with the whole running a space agency shtick.

Forced timewarp is flat out stupid. It severely limits gameplay. If there's any way to kill space-based multiplayer it's forced timewarp.

What extra system would be required for me to restock my space station with supplies? Supply lines can merely be a gameplay strategy to get around the costs of having to constantly send expensive ships from Kerbin.

I'm in favour of an optional approach like atmospheric heating, etc., but by default it should be off for easy difficulty, but on for normal and hard. Like many others, I think the best way to do it is like Snacks!, where you have few resources that are easy to manage, as well as waste recycling capabilities. Throw in some production facilities and we're golden. Life Support is a pillar of manned spaceflight, and the game should be able to reflect that. Resupply missions? Food production? If that's not emergent gameplay then I dunno what is. Just like relay constellations emerged from CommNet, supply lines can emerge from life support. If you make it in the player's interest to set up these lines, particularly in early-midgame when you don't yet have colonies, then the corresponding gameplay will emerge. I'm not really a fan of air management, but I do think we should have to make sure our Kerbals stay fed.

This quite literally just happened to me while wearing the base suit. Landed on Minmus, went to space centre, came back and Bob is dead because his helmet was removed. F

@Yi C literally just scroll up and read all the stuff about time synchronising. That's one way to do it

I don't care much for procedural tanks, because I do like the Lego system we have at the moment, but in the real world engineers can design and build a tank to whatever size they need, so it's not illogical at all.

If procedural fuel tanks are a thing I'd definitely want them to have procedural 3D models for them too. The current procedural tanks mod is extremely ugly