t_v

I think the suggestion is for it to become a normal part of the UI instead of a strange workaround.

We have a growing list of suggestions for achievements, a lot of which are really good! If you want to propose some, I’d recommend putting them in this thread, and don’t forget to give them a name!

I like you example, except for the fact that it doesn’t point out the problem. And also this: Player C must have hacked those coins into the server, because remember, this isn’t an MMO situation. The reason Animal Crossing has a black market is because once someone has an item or other store of value, they can transfer it to anyone else, thus making a sizable market. If you can only trade within your server, as is the case with non-MMOs, then no one has a zillion Kerbucks because the total value of all of the players on the server hasn’t even reached a billion. The second issue is that this doesn’t really highlight the problem. Replace Kerbucks with Hydrogen, or Metal, and you have the same problem. Just because a resource isn’t central or convertible doesn’t mean it can’t be used for trade; take Minecraft diamonds for example, people want them even though you can’t convert them easily; emeralds would be a better currency but both of those resources can be used for the exploitation you mentioned. The issue with a central currency isn’t that you can exploit people in a big market, it is that it is easy. Paying people in Hydrogen can be effective, but eventually they’ll need to have metal for colonies and suddenly your rates get complicated and no one wants to deal with that. However, if you offer them something that they can turn into whatever they want, then it always has the maximum value, since whatever they need you can provide with one simple transaction.

Right, take two. The post I was quoting is a while back, but it talks about spatial consistency, and this recent one does as well. Yes, that is the key advantage of the leapfrog model - spatial consistency and perfectly predictable behavior, even when people are making unpredictable maneuvers. Visually, when someone changes something, that change doesn’t show up for you because it would be inconsistent with your reality (a ship that was orbiting Kerbin 5 minutes ago shouldn’t be at Duna, right?) and so it is hidden away from you, until you warp forwards and you enter a shared reality, without any inconsistent jumps. Everybody sees things at different positions, but those positions match up exactly occasionally, when someone catches up to someone else. Vessels do pop in and out of existence in reality, but you don't see that, you see the ship go gray until you warp and see the ship pop back into existence, but in the exact same spot as you were expecting it to be at that time, so there are no spatial jumps. I still think that the problems are much more minimal than previously observed, at least on the orbital mechanics side, but the extent to which these things mess up has probably been evaluated in play testing. The point is that these problems exist, and can't really be resolved under this system. Resource problems are a whole new can of worms. You can take the Local Bubble approach and stop people from transferring resources when it would cause a problem, or you can once again have the issues of future ships with more resources interacting with earlier ships. However, I had a few questions about the leapfrog model which I think point out a few points of inconsistency. Here are a few hypotheticals; how would you deal with these? These problems are exacerbated with larger time differences, but they still exist with small time differences. Player A has a station in LKO in year 100, that has been around for a while and people have had the chance to see it. Currently, the last interaction was in year 100. Where does player B, who is in year 101, see that station? Do they see it, or does it disappear once player B warps past the point where Player A is? Second, Player A then uses a tug to move that station into GKO. For a few minutes, that station is not able to be interacted with, but ignoring that, where does Player B see the station, from their vantage point in the future? Does it jump to the GKO orbit, adjusted for the time difference? Or was it hidden all along, so there's no harm? To be clear, hiding the station poses a problem, which is that the player that is the farthest ahead in time is effectively alone and the only way to leave that state is to wait for other players to warp ahead. Third, Player B has resource routes feeding their colony that pass through Player A's base. None have triggered since year 100, but now the station is in a different spot. When the next window happens, does the route just break? Or if it doesn't, what does Player B see? Fourth, Player A is sending the tug over to the station. The same route system is set up but is more frequent, so the last supply mission passing through was after Player A's time. Player A cannot access their station due to interaction rules so there is no risk of it changing orbit, but now they cannot dock their tug. How would this be resolved, simply making Player A warp to Player B's time? This becomes a big problem when players set up supply routes between colonies, as entire sections of critical infrastructure could get blocked off when someone goes into the future. Lastly, assuming that Player B in the future can see the new position of player A's station (as it is in the future), what happens when player A launches a new supply run feeding the station from the Mun? At the start, player A's trajectory is suborbital, so from player B's perspective it has already crashed into the ground and disappeared. But once in LMO, player A leaves the mission for a moment to deal with an aerobrake somewhere else. Does player B see the new craft in its orbit? What are the rules for how long something needs to be present for it to project into the future?

The thing about "alpha and beta quality" is that it is an incredibly vague term, because games that are in alpha, beta, or full release can have vastly different qualities. Where did you see the developers state that their early access would be better than beta? For performance, I agree that it is pretty terrible if you are considering the highest-end machines running it (the expectation that people with those machines have is usually that everything runs buttery smooth), but code can get optimized so extremely so fast that I wouldn't place much trust in those frame rate numbers.

Right, so it is kind of a sleight of hand where time is shifting around relative to different people, similar to my system, the discontinuities are shown but made less jarring. I also don’t think it will impact gameplay that much (transfers, rendezvous, and most other operations work well, and pretty much the same as other systems) but there isn’t a way to make real-time player actions physically consistent in in-game time unless you force the difference between real time and in game time to be accounted for via time warping to synchronize.

Oh, my answer is gone, I just made a post referencing it. Did it get removed or just never sent? I’ll have to re-write it.

Everyone cares about persistent universe multiplayer. Persistent universe means that the universe is not wiped for any reason, and only a server shutting down, crashing, ending, or losing its data can end that. I want to have a persistent universe in my multiplayer, which is why my system allows for and is designed around that. So is Local Bubble, voting, and leapfrog. For the second thought experiment, problems 1 and 3 are the same issues my system has. @Pthigrivi mentioned that the biggest thing Local Bubble has is physical consistency throughout time. I agreed with that (although I had some questions about representing past craft that might be inconsistent), but I’m wondering: how would you manage syncing the solar system configuration when coming out of a Journey, and how would you manage syncing the ship back into the large multiplayer server? Just have it fade in, or something else?

I guess that a centralized, convertible resource is out. Definitely not a dealbreaker, but it does inform me a bit about how the rest of the systems might work. When there is a big imbalance of materials, there won’t be a way to re-balance them by converting them, so this makes me believe that increasing or decreasing resource rates drastically will be very easy to do.

I think I see it at the bottom middle, to the right of the blue highlighted placement mode

What I’ve seen is the same surfaces looking vastly different across clips. What I’m assuming is that for the show and tells and feature videos, the devs film on max (or close to max) settings, which includes dense normal maps for terrain, higher polygon count, materials and reflections, whereas for the Twitter screenshots, we are seeing what the average buyer would see on their slightly higher-than-average laptop and medium settings

Right, I got the scale off by three orders of magnitude! I must have been thinking about something else that dissipates relatively quickly, like carbon or neon burn times. Planetary nebulae still last a relatively short time astronomically speaking, and the question is whether we should include effects that dissipate "quickly" enough to be noticeable in game, and then go away forever. Thanks for correcting me, I would have gone on with figures mixed up, which would not have been good.

Easy to do when you don’t have one. Let’s face it, even a bad or badly managed product is better than no product at all (and I think that this doesn’t even qualify as badly managed for a piece of software - those things can get such huge delays…). KSP would have ended with KSP 1, now we are getting KSP 2. Take your pick, if you would rather live in a reality where the franchise died with the first game then the internet is a large place, and I’m sure you can find someplace to hide from this horrible tragedy.

Yes, what I meant is that the TWR has a constant point of reference while in flight. I’m not sure that if you set it to a low mass body and launch it, it will display that way. I’m pretty sure I’ve done that and it still reverted to Kerbin gravity.

When the game shows you TWR, it is always relative to Kerbin g’s, so it won’t decrease on low mass bodies. I’ll admit, sometimes it helps to know what 0.35 TWR means on Minmus, so I’d like to see a total acceleration ability (in m/s^2) divided by the gravity you are experiencing. In orbit though, the effective gravity should just read zero.

I thought that when recording in big orchestras, people tended to record most or all of the instruments together in order to have the orchestra playing together, as there are minor variations in everyone's playing unless they are well synchronized. But if you have something that shows otherwise, I'd love to see it. I was a bit concerned that what I had was wrong, so I went to search it up and the algorithm didn't produce any results for or against what I thought was the case.

I was going to mention the possibility of some adaptive music when I saw the "Trumpet 3" track (because recording instruments separately indicates that you want to edit them, potentially in-game), but this is pretty promising evidence! I don't know about a track for every planet, but I'm still hoping for more chimes to come in on cold planets.

I hope that Intercept does not make provisions or designs gameplay with PvP in mind - space exploration is a challenge enough, without adding in warfare. (just to clarify, I have nothing against warfare in space games, or warfare in KSP - as long as it isn't in my KSP experience, and isn't encouraged as part of Stock)

Yeah, the thing with multiplayer space combat is that it will almost exclusively be strategy and ambush. In real life, crafts that are close together in space (and velocity) have a lot of time to react, and usually can plan things out ahead of a confrontation and in the hours following it. However, in a game with time warp, the amount of time it takes to plan a trajectory is a significant percentage of the time it takes to intercept or evade someone. On top of that, you can't just hit someone who has already warped away because that would feel terrible. So in a KSP 2 combat mod, there will likely be a condition that ties players' clocks together if they are actively in combat.

I agree that stars take a lot less effort than planets to make, once you have a good framework for defining them. I personally am hoping to see a wide variety of stars and associated objects in the game - wouldn't it be fun to fly through a planetary nebula? (Although those only last for a few decades usually, and I don't know how I feel about one-time events). Having low mass stars scattered around between the big systems would also be fun, as you could slingshot off of them by passing really, really close and maybe gaining or losing a lot of speed relative to your target. One thing I think shouldn't happen is mass produced stars, though. There are enough types of astronomical objects to fill up more than a globular cluster with each star being created in a different manner than the others[citation needed] so having each type of star represented once or a few times is way more than enough, no need to go full random. Take five red dwarfs, four small protostars, four "low mass" white dwarfs, six brown dwarfs, and you have 19 low mass objects already. Even black holes, have a big one and two "low mass" ones wandering the area, and you have just doubled the number of systems with planets. Overall, I think you can get into the hundreds of stars without using a random generator by sprinkling them around, representing the common ones more and the rare ones only once (or twice, so people can stumble onto them). At that point, you might want to consider generating planets around those stars, so that players can see them rising over a horizon instead of only looking at them from space. But, the real question is, what does this add? A cool effect in the map view where you can see your space program among a big field of stars, a handful of really cool views and a bunch of other good ones, but beyond that? We can't go beyond light speed, so these stars don't incentivize you to develop faster ships; going 1000 ly at .8c is about as difficult as going there at .4c. You can get really good at deviating your trajectory by passing by stars, but then ultimately, there is nothing to gain by going there. Any resources you get out there will either be token items or already in the planetary systems, and if there is nowhere to land, you probably won't be able to construct anything. Maybe there are things like Bussard scoops, but even with that, you end up with a program full of space stations and a few surface bases on suspiciously close systems. The game wouldn't benefit that much by adding stars, and it would take a lot of work to add a good variety of them to even get that benefit.

It is probably best explained by someone else, but as a summary, it is similar to how DMP and LMP work. All the players can be in their separate times and the game plays perfectly consistently, similar to single player, but you can also interact with other players' ships. In order to mitigate wackiness though, you can only interact with ships that haven't been interacted with in the future. Planetary positions are consistent between players who are at the same time, and when you want to catch up to other people, you just warp forwards until you are at the same time as them.

Your example was one of trying to dock while someone else changed the orbit of the target vessel. If no one is changing the orbit or interacting with that vessel, docking works the same way in both systems. If someone does interact with the vessel, as in your example, then in the leapfrog model the craft becomes inaccessible and in the cyclic model (people have been using Local Bubble to mean several things) you would see the effects of that interaction. That is correct. If someone is in a 100km circular orbit, when you warp they warp (seen from your perspective). However, this creates a spatial desynchronization because they don't see their craft warping. So, when you dock, that spatial difference must be resolved by warping to the point in the orbit that the owner of the craft sees. You are seeing projections of people's crafts, but they are more recent, as they reflect the real orbit or trajectory that the craft is in, just on a different point along the orbit. Effectively, instead of having two greyed-out craft (one for the craft at your time and one for the craft at their time) you see one craft that you can interact with that represents where they are in the "present," give or take one orbit. The reason I think you need two ghosts in the leapfrog model is because you don't want to have players placing their ships in the exact orbit of yours and griefing you from the past.

The issue is that paradoxes are not really avoidable, as far as we have seen. In your solution, when players re-sync, they are either traveling forwards or backwards through time to do so, until they reach a certain point on the cycle. This means that either ships from the past are interacting with the future in the present, or a ship from the future just went backwards through time and is now changing events in the past. Textbook paradoxes, although it doesn’t matter because from the player perspective, IRL causality is preserved (as it kind of has to be). Even the leapfrog model has its paradoxes: Right, but in the leapfrog model, the target does pop out of existence. You are trying to rendezvous, and then you suddenly see the other ship has been greyed out and you can no longer dock. The alternative that I was proposing is that you see how the orbit is changing, or if they exit the SOI, you see that the ship is no longer there. Docking in the first case is impossible when another player is interfering, because you can’t interact or know where to go to find that ship again, whereas under the second solution it is made much harder, but you have the information to know where that ship’s new location is if you still want to dock with it. In either scenario, another player doing things with the ship you are rendezvousing will make things a lot harder; leapfrog doesn’t fix that, unfortunately.

The design decision that people (including me) are expecting is that ISRU resources will not always be available everywhere. If you are mining on Minmus, you probably won’t get access to metals since it is a ceramic moon. And, once you need Uranium for nuclear engines, it would be nice to be able to source directly from Kerbin instead of shipping it from Dres. And, although unlock-able resource pools would work (so once you unlock a technology that requires Uranium, you get a regenerating pool of it at Kerbin), I would rather exchange resources that I mined elsewhere to convert it to Uranium, instead of just waiting for the number to go up.

A few things, since I haven’t actually stated my position on currency. First, if resources being converted to real money is a concern with a central resource, then it is also a concern without one. Instead of one rate for the central resource, there would be multiple rates, but the problem would still persist. Second, barter interactions still happen with a central resource; the reason there are more complex interactions today is because we have systems set up to enable seriously complex compound exchanges with conditions, schedules, automation, and more. Saying “I’ll give you 10 Uranium for completing this task is similar to “I’ll give you 10,000 credits if you complete this task” and the difference really arises through the spirit and systems around the interaction. And for my thoughts on a central resource itself, I see its utility. The idea is a resource that can be converted to every other resource, or almost every other resource. Some resources like Hydrogen could become a de-facto currency because depending on systems you could convert them into three or four types of fuel, plus life support ingredients. However, we are really talking about something that can be converted to almost everything. The use I see for this is resource balancing. Hopping to a nearby spot where you have the necessary resources would be nice, but sometimes you need to seriously shift the concentration of resources at a base to keep it functioning. Instead of spending a an hour in the BAE placing mining modules in the secondary deposit (we are talking serious shifts), the player can fly big missions to Kerbin to exchange the resource they currently have in excess with the resource that they are lacking. This can reduce the hassle of managing resource rates and encourage players to keep all their colonies as connected as possible so that the balancing effect of the most advanced colonies can spread as far as possible. Lastly, transfer of this convertible resource would make things easy between players, and if it is something digital like currency, then it can be transferred electronically. In essence, I don’t see a problem with a highly convertible resource that isn’t present without one, as long as the rest of the systems are handled the same, and it has uses.