t_v

Wow, I wish I had seen this image sooner. That’s three wishes of mine fulfilled in one picture. One, really nice IVAs with light-up displays/monitors, two, what appears to be a 3 seat 2.5m-ish plane/rover pod, and three, IVA isn’t permanently stuck with all the lights on!

Okay, I think I see. Essentially, the cost difference between the composer making the track electronically and making it with live music is small enough that it would be easily covered by game sales. Did I get that right? If I did, then the problem is that it isn’t about the total game sales to cover it, but instead about additional game sales generated by the live music. I for one don’t think you could even make a difference of 0.1% in game sales by having live music, which you would need to cover the costs, and those are optimistic costs. It comes down to a few factors. First, the player base isn’t going to change on the music alone. You and I, and nearly every other person who buys KSP 2, won’t make their decision based on whether the music sounds live. The gameplay takes top priority, and then the visuals come second, and then the rest of the experience is a nice-to-have. Second, KSP isn’t one of those games that really benefits from live music. Titles like Elden Ring and Silk Song are trying to show off their polish and massive effort in all areas of the game, and if the music can be made more polished, it will be, especially since the authenticity of the music lends a lot to the experience. KSP, most indie games, and a lot of sci-fi big budget games use electronic music because it doesn’t really clash with the game in the same way as with hand-crafted fantasy worlds. It would be great to have a 2001: Space Odyssey level orchestral feel to the space exploration, but I think not enough people care enough for it to happen.

Throttling the Orion drive should decrease the frequency of explosions, but result in a bumpy ride.

Just an FYI to clear confusion, Parallax does not have collision on by default. You can enable that option if you want, but it is an experimental optional feature.

If only they had shown us footage of a craft being assembled in the hangar... If only they had a dedicated series where they announced info about the game... If only it was easily accessible, on a forum perhaps? I think the issue is that when you see something, you comment on the things that aren't there. You ask "why aren't they showing us X?" as if the reason couldn't possibly be that they don't need to. What the phrase "Why aren't they showing us this?" sounds like is that you are implying that there is a major problem underneath it, and people are saying that we can't jump to conclusions based on a lack of evidence. There could definitely be a major problem, but there could also definitely be no problem at all, and people "saying everything is fine" is just because so far, lots of people have been jumping to negative conclusions, and you'll notice that when people jump to conclusions that the game is doing exceedingly well (usually with lots of demanding features impossibly optimized) the same people that counteract negative conclusions counteract those ones. This isn't a discussion between negative and positive people, it is a discussion between jumping to conclusions and recognizing that we don't know enough to make them. Edit: And lastly, if you want to comment "Why aren't they showing us X?" Then please bring up things that have actually not been shown. I've seen people bring up that they haven't shown us atmospheric or space flight, when they could just as easily bring up staging or something that has actually never been shown in-game.

Jool’s altitude of death isn’t due to pressure, it is the Kraken defending its home. If you get past the death sphere and land, you will inevitably be attacked by the kraken. If the KSP 2 devs have slain the kraken though…

I agree with everything you said in your post, and on the topic of the problem of players not being on the same page, I also agree but I think that it is a problem that can't be fully solved as long as people have the ability to time warp independently. The result that I'm realistically hopeful for is something like Minecraft, where players at higher advancement levels can give less advanced players resources and support to help them catch up.

That’s a good concern that players probably have to exactly match the positions of at least the relevant bodies, which would entail at least a degree of long time warping. Even if you mitigated it by only considering the position of the destination planet important, that is still up to 1 revolution that you have to warp, and while it is better than dozens or hundreds of years, by the time Eeloo makes its way to the correct position, your interplanetary missions will have reached their destinations. Maybe I’m underestimating the amount of times when a repeated mission will feature interplanetary intercepts. I think that when it happens, it’ll be a one-and-done event, but I guess that if someone sets up a “space train,” it would see a lot of docking across SOIs. Thanks for raising that question, because previously I had though of a very complex space warping system by which incorrect trajectories would be warped to cover discrepancies, but now I see that the warping would be not just complex, but impossibly so. I still like this system for its interactivity and stability for simple systems, and for its minimizing of time warping to synchronize, but to allow players complete freedom on where to interact, it would need to add a fair amount of time warps to fix interplanetary problems. Oh well, hopefully we find out soon so that I can be disillusioned of the possibility of this in KSP 2.

The problem of things being off because of differences in Ap and Pe will already have to be resolved for supply routes to work at all. I don't think that Kerbin and Duna will ever be in exactly the same position relative to each other even if you looked at a million transfer windows, but the supply routes still need to go from one to the other and land very precisely. The landing site might be on the "front" or "back" of the planet, which will affect the trajectory that supply routes take to get to the surface. What needs to happen is a bit of handwavium to say "look at that trajectory, it is hitting Duna's SOI even though the test supply route mission hit Duna's SOI at Ap and this is at Pe." Similarly, seeing other players' trajectories, you will see them hitting Duna at the Pe and they will see your craft hitting Duna at the Ap. If you dock, then you have the same orbital speed as you enter Duna's SOI, and then it doesn't matter if it is at the Ap or the Pe because you only care about Duna's SOI. Similarly with the Minmus mission, if one person sees Minmus on one side of Kerbin and the other person sees it on the other side, that doesn't matter for internal rendevous with stations orbiting only Minmus. It will change the direction that you enter the SOI, but in LMP that is essentially just launching a week earlier or later. In this system you are still launching a week "earlier" or "later", but you get to see the other person make their transfer in real time and enter Minmus from the "wrong side" and interact with them directly at that point, since once you are orbiting within Minmus SOI, it doesn't matter where Minmus is compared to Kerbin, your rendezvous will still work the same. Alternatively, you can see the trajectory go off into seemingly empty space, and then a "Minmus encounter" shows up, just like in single player transfers. You always have the option to "time warp to transfer window" to get the relevant celestial bodies in the correct positions, but otherwise, you see them leave for Minmus and then show up in its SOI. If you dock with them while they are heading off to this empty space, you might need to change your time to their transfer window to interact, but you still don't need to warp all the way to their exact configuration. Or, and I don't like this one because sufficiently motivated player can exploit this, you could get dragged to Minmus when the other player enters the SOI.

Thanks for asking! here's how it would (or could) work: As you mentioned, the locations of things in space depends on time, so if players are at different times, they will see different locations. One of the biggest things that minimize this problem is that relative positions in space are cyclic, with the cycles being more frequent the less bodies are involved. Take the simplest example: a ship in GKO. On day 2 and day 200, this ship will be in the same position relative to Kerbin, so for all intents and purposes for someone rendezvousing it from Kerbin, it doesn't matter that it is in the past/future. This can be applied to more complex configurations that require more considerations. So, your first example, a ship going from Kerbin to Duna. A Kerbin-Duna transfer looks the same roughly every Kerbin year or so (a bit more), so the principle is that if you want to intercept a craft going from Kerbin to Duna, you don't have to travel to the exact transfer window that the other player was using, you only need to travel to any Kerbin-Duna transfer window (with a "jump to window" button on any inter-SOI ship). If you want to intercept it outside of the transfer window, you can do that too with extra fuel, and it would be akin to launching a few months early or late, but offset by a couple dozen or hundred transfer windows (which don't matter because transfer window 1 and 1,000 both have the same relative positions). This applies to more complex trajectories involving slingshots, it just requires you to warp to a less frequent window. Okay, so what happens to ships while you match up your planetary positions by warping to transfer windows (or not, you can just torch-ship your way there too)? Well, just like with subspace, all your ships time warp. The reason I'm fine with this and not subspace is because time warping 3 months to match a Kerbin Duna window (or just a few days for a Mun mission) is much more manageable than warping decades or centuries just to do the same little mission. Alright, so all your ships warp, they consume resources etc. If you were playing alone in a server, it would look like single player. When it comes to other players and stations, there is a little bit more. I'll expand your example of a few craft by adding that the other player is currently returning from an Eve mission and is going to dock at that same Minmus station. you set up the mission, make your Minmus injection burn, and time warp. All the craft that you have warp, but since you are only warping a few weeks, you don't overshoot in your interplanetary transfers. The Minmus station also warps, as well as any craft any other player has in a stable orbit. The logic behind this is that location-wise, the orbits are very cyclic and it doesn't matter if they are on their 2nd orbit or their 2000th, so the ability to rendezvous is preserved. The only ships that don't warp (that you are seeing in real-time) are the other player's ships that are on inter-SOI trajectories. You can still rendezvous with those without breaking physics because if you try, you essentially launched at the "same time" so you can still warp up to their ship, which is traveling at 1x speed, without cheating orbits. So, you rendezvous and dock with the other player's ship without difficulty, even though they interacted with it 800 years in the future. The other player sees that in real time, and for all intents and purposes, you are playing at the same time, except the transfers that you made are not ruined by an 800 year time warp. (sorry if that was confusing, it is really an intuitive system when you see it. Essentially, you are functionally always synchronized without messing up orbital mechanics or having to warp a lot. If you didn't get that from the paragraph above, I can try to explain it differently.) The last consideration is - now the other player wants to dock with that station that you are currently managing. You don't want to suddenly be thrown into warp when the other player starts to rendezvous, so as you see them come into an orbit of Minmus, you are moving at 1x speed but the other player sees a version of the station warping around Minmus. When they rendezvous with it, they are put at the point in the orbit that you are at, so that you see the same thing passing below. That is the only time when a spatial discrepancy has to be resolved, when two players are actively interacting with the same craft or station. Any other time, it works like subspace bubble except instead of warping to the exact time that the other person is at in order to interact, you can be functionally synchronized (but not actually synchronized) relative to select celestial bodies and craft.

The thing is that you are still transmitting cause and effect backwards through time, and restricting interaction to give the impression of fewer paradoxes isn’t the best solution. Instead of blocking off that station or docking port, just show the other player’s ship docked to that port, and then hand wave the fact that that ship is from the future just like you can handwave the fact that one player has a far future colony network next to another’s starting bases. I can explain how complex infrastructure can work well, and work with time warp , under this system if you don’t want to read through previous posts, but right now I’ll just say that it isn’t a disaster. I think the problem is that we have different play styles and ideas of playing together. I oftentimes have multiple missions goi g at the same time, and I think that a large percentage of the player base does the same, and there is never a time when I can just warp 800 years without several missions overshooting their targets by 799 years. This means I will essentially never synchronize with people, and to me, that doesn’t sound like playing together. I’d rather have to wait for people to take their turns (and participate in community events because we’re all at the same time) than have my own time warp and never interact with anything else. You might as well have everything be ghost ships that you can see but not interact with, like Vl3d was talking about.

The thing is that is the same paradox, skinned differently. Someone in the future is interfering with actions in the past, and the solution can just be what @JoeSchmuckatelli was talking about (which is the solution I am proposing) which is to just accept the difference in time and allow players to interact, hand waving away the temporal weirdness. I agree, but a lot of people just put a lot of posts talking about LMP, and I wanted to mention that the problems people had with it were solved by just letting people interact. I hope this doesn’t become another huge discussion, but I don’t want people to think that LMP doesn’t have functional paradoxes or is the only solution that works well.

The thing about “asynchronous” is that a lot of people are seeing LMP and DMP as being equivalent to “asynchronous time warp” when there’s other ways to implement it. Since we’re jumping back into this (wheeee), I’ll talk about my system which does increase interaction and does fit under “asynchronous time warp” as defined here: The idea is that you can time warp however you want, but you also see other peoples’ real-time movements and activities. Bej also said that the risk of paradoxes is overblown, and I agree. Even if there is a temporal paradox, players will probably not notice it if it is small, and LMP can’t fix it if it is big. Here’s a commonly brought up paradox: one player has progressed very far in the game and is further along in time, and the other player has not, and is less far along. The two players interact, and suddenly technology from the “future” makes its way to the “past”. Or, the advanced player has a base and the less advanced one goes around it, and suddenly they see a base that doesn’t exist yet. Well, LMP has ways to solve this… or does it? You can disallow interaction across time and you can have a “keep out” zone where future structures are, and then players can do their temporal mental gymnastics much more easily. But if the two players ever want to actually interact, then the less advanced player has to warp to the more advanced player. In-game “1000 year hiatus” aside, what functionally just happened is that the less advanced player, who has not actually advanced through the timewarp, has just come into contact with the player in the future. All of that non-interaction just to have an in-universe explanation for why two space programs that were founded at the same time and are thousands of years apart in their development suddenly interacted in the “present.” That seems like a paradox to me, even though it is (weakly) explained in-game. Since we are also on a trend of using Minecraft for analogies, when you walk over to someone’s base in the LMP system, you wouldn’t see or interact with them, you would see a recording of their actions at the time that you are at (as in, if you played less hours than them, you would see them some number of hours ago) and instead of seeing the world populate with cool creations, you would see it populate with chunks that you can’t interact with because another player did something there in the future. In order to have interaction, you press a button to populate the world, but why would you want to have that system when you could just see the other players and their creations by default instead? I’m just saying, if LMP doesn’t actually solve the problem of people in the past and the future interacting, why would you have all those extra steps to have an in-game justification and the semblance if a paradox-free experience?

Non rotating solar panels would be cool for keeping your craft looking nice, but I don’t think any significant portion of the power a panel generates is used for rotation. And when a panel isn’t properly rotated towards a light source, it generates a lot less power.

The thing is, you absolutely can. SoL delay is a great tool to teach players how difficult interstellar organization (technically travel is unaffected) is, but it isn’t the only tool to do that, and it isn’t necessary. The actual difficulty of accelerating a craft to escape a star system towards another, intercepting it and slowing down is plenty enough. and KSP 2 is disregarding very real issues with orbital mechanics by excluding n-body instability, and is disregarding very real issues with life support by excluding Van Allen belts, and is disregarding very real issues with running a space program by excluding the Kerbal judicial process and public opinion, with all of the political games and misinformation that surround space flight. Your point is? Should all of those be included? They certainly teach the player a lesson about the real issues with space travel, so surely they must be in, right? It isn’t enough to manage funding to show that running an agency is hard, you also need fully fledged politics. It isn’t enough to actually travel interstellar to show that it is hard, you also need communication delays. I completely agree with this. I’m personally going to play with SoL delay whether it is stock or not, because I like the decisions I have to make with it. But unless it is an option (and off by default), I will say that the default experience shouldn’t have SoL delays because for the average player it does very little to show the difficulties of interstellar travel (the difficulty has already been shown), and does a lot to making the experience less seamless and more filled with little annoyances like KSP 1.

I think it is both - there was some code that was creating these effects, but the underlying cause is the problems with numerical stability in the way KSP handles all of its coordinates and other vectors. Whether it is a big or a core issue, I agree that it would be good to fix it.

If you are on MacOS, you don't have access to Parallax, and every other graphics mod runs worse than on Windows. I would recommend putting your KSP install on a VM if you have one, but without Parallax, Scatterer, EVE, and Waterfall run pretty well. On the content side, I would highly recommend Nertea's mods as mentioned above (make sure to install Heat Control if you are using near/far future), and Extraplanetary Launchpads. I really like the style that Angel-125 brings to mods, and things like Blueshift and Sandcastle make FTL and construction feel like much more accessible and like they fit into stock. (lastly, I would install these via CKAN, which uses the Terminal UI for MacOS, it really helps to easily manage your mods and dependencies)

Good thing KSP simulates landing gear then. Well then it isn't an analogy. You’re right, so let’s do away with the landing gear scenario, because in that one, it is actually relevant to aviation. The thing is, communication between colonies isn’t a space flight problem, it is a government one. Your ships won’t experience different gravity just because your colony is self-governing. It is akin to the anti-radiation paint that goes on airplanes: an actual, serious problem, that excluding would misinform people about (I bet 99% of people think airplanes just have regular, durable paint), and most importantly is not really relevant to the subject. I mean, you could make a huge gameplay system on the outer layer of your plane in a flight sim, but it would just add grind. Not because some people deem it that way (nice straw man btw) but because it is (1) mandatory, as you have to deal with it or your plane breaks down and your passengers get cancer much faster, and (2) not really relevant to the main gameplay. I am strongly in support of features like SoL delay, as long as they are not mandatory. I’ll say this every time that some wacky idea gets introduced: as long as you can ignore it and be fine, there is no harm in implementing it (which isn’t saying that it should be implemented). SoL delays, if they are put into the core experience, are not ignorable. They create a choice between putting in more work and “cheating” by time warping, and they will harm a lot of players’ experiences. Yes it is “misinformation,” test it is unrealistic, but at the end of the day, I want to fly my probes without worrying about my RTGs decaying and whether I should fly yet another mission to unlock that crucial reactor technology yet again.

Due to the patched conics system, the map would be littered with tiny SOI that your trajectory would run over; you would constantly be slowing down the simulation to allow crafts in the background to interact with these SOI instead of phasing through them at high timewarp. Making the asteroids movable would be a large technical hurdle and would cause more problems than it is worth. Those are only a few problems with hundreds of asteroids in that size range.

It definitely could add a new gameplay loop, and having those decisions to make about how to progress across multiple colonies is the reason I personally want SoL delay in my personal KSP 2 experience. But for the average player, I think it would add too much grind. Sure, you can transmit this tech in four years, but why would you do that if you can unlock it again in two? So you fly a science mission, just to unlock a tech that you have already unlocked several times, which doesn’t feel like you are making meaningful progress. Instead, without delay, you can transfer the tech between colonies provided that you have powerful enough comms, and then the next science mission can be focused on discovering a new technology or building towards one, instead of repeatedly unlocking each essential technology.

I really do want to see vast asteroids, although Brittanica tells me that there are about 250 known asteroids larger than 100 km in our solar system (10 km in KSP) and adding 250 Gilly-like bodies with their own gravity might pose an issue. I just want to see an end-game space station dock to an asteroid that is a hundred times bigger than it.

I would like to say that the last two responses really encapsulated what I was hoping to say; that for many, KSP isn't about managing a disjointed space empire, it is about building and flying rockets to have a good experience and work towards cohesive goals. I personally think that SoL communications is a feature that I would like to see in the game - but as a mod, just like I see power suits as a fun mod mechanic in Minecraft, for example. It just doesn't mesh well with the rest of the game for me.

The problem is that this ignores the problem of gameplay. Players of the game (not all of them, and not me) will not want to deal with the issues posed by speed-of-light delay in the game. The question is: Is SoL delay such an integral part to the KSP 2 experience that it needs to happen by default, like the orbital mechanics and engineering challenges of the game? Or is it something more minor that could help reflect real space travel but ultimately can be hand waved, like the dimming of skyboxes in sunlight? I personally think it is the latter. And, if you want scientific explanations for things being the way they are, it is best to forget it. If there are magic photoreceptors that somehow have 30 stops of dynamic range, then why not magic waves that travel infinitely fast? I think that in your opinion, this feature would fit solidly into the core of KSP 2, and correct me if I am wrong. But other people don't see it as a necessity, and the hinderances it poses to gameplay could outweigh the benefits of "realism." (remember, nothing about the way the KSP universe or the Kerbal civilization works makes sense unless you consider that a player is playing a game)

The alternative, which I like better, is to not have speed of light delays in communications. Your point about desynchronized tech trees being an annoyance has changed my mind about whether it should be in stock, and I’d be happy to see it as an option or mod. I think that trying to explain the FTL comms with a technology like quantum entanglement raises more problems than it fixes. The main issue is that as far as we can tell, the “synchronization” of the two particles doesn’t happen immediately - there is a good chance that the two only match once information has the ability to reach from one to the other, which probably happens at the speed of light. Instead of messing with quantum, which has to be hand-waved in multiple ways to get it to work (the main problem is that you can’t actually tell whether communication has even happened when using these particles), why not hand-wave light and say that it travels infinitely fast? Sure it breaks things, but it is a simpler break than breaking quantum, if you want instant comms.

There was a huge discussion in terms of both the objective and subjective side of this suggestion. I'm linking it below: The gist of it is that stars are very dim compared to the sun or even the light of the sun reflecting off of planets, and very bright compared to objects in the shadow of planets (or in interstellar space, but that was discussed in another thread). Regardless of opinion, if you want realism you shouldn't be able to see stars if anything is reflecting the star that you are orbiting. That being said, I think that lots of people want it both ways, but so far it seems that the developers have not decided to implement it. Worst case scenario, it could be modded in like in KSP 1, which would add maybe a few weeks of wait at most. Overall, I think that it shouldn't matter what the developers decide to do since all players will be accommodated for relatively quickly.