Jump to content

Vl3d

Members
  • Posts

    2,540
  • Joined

  • Last visited

Everything posted by Vl3d

  1. Just imagine living in a world where every building to ever exist would have overlapping ghosted projections. Could you land on the projections, walk through them? Could you see them from orbit? How could you decide from orbit where to land to build your colony? How would you distinguish between real and ghost from a distance? Which tech-level buildings would you see? If the actions of a player from the past impact a player from the future, and also the actions of a player from the future impact a player from the past - why on earth don't you just play real-time!? Why the obsession with time travel?
  2. There will probably be a modded planet-pack integration system right inside the sky-box, with curation by the devs and a user voting interface. So.. unlimited modded star systems right in the stock game. New stock star systems.. probably 3-4.
  3. Quicksaves in multiplayer? No, you just get one chance, prepare your abort sequences. This discussion has made me hate time travel with flaming passion. :))
  4. No you would not. You only shift when reaching a journey destination and syncing, not during the execution of maneuver nodes. Only on-rails craft that are defined as targets have bubbles and only when in orbit, outside of planet-side visual range. On the ground, in the atmosphere and in very low orbit we would all play real-time.
  5. I agree. I think our ideas have a lot in common, except that I am more strict with the real-time gameplay close to the planet so we don't have causality issues with overlapping colonies and we don't see each other warping. I would just hate seeing people with the same engine as me zoom past. It feels like cheating, breaks mini-games.
  6. Why warp at different speeds? Just let the server warp you all at the same speed. What if the first player changes the orbit of the station or crashes it before the second player arrives? lulz
  7. Maybe a cutscene of arrival or a temporary zoom-in to the planet in map view. That's up to the art department. Certainly you could zoom out to see the whole map after syncing.
  8. It's not me, but the video seems to follow the rules. Most important thing is that he set his destination, started the journey, time-warped to the Mun. Then he came out of time-warp. At that point he would sync to the Mun local real-time bubble. For return to Kerbin similar process.
  9. If you sync to the Minmus real-time bubble, you can zoom out and see the solar system as defined by the server specifically for Minmus. No, they are not where they were when you entered the SOI, because (let's say) you've been spinning in orbit until you synced.
  10. Mun is a destination with its own multiplayer real-time bubble. Time-warping to it would be allowed.
  11. If you go into details, you don't actually move time, the server changes the solar system configuration depending on where your are. Players are real-time or outside of time (and multiplayer - well actually for co-op your teammates on the same craft with you share your out-of-time bubble). The configurations of the solar system differ for each celestial body. They are virtual, specific to you, when you plan your journey. But let's just say yes to your statement. It's a hybrid system, it also has its own bubble. You can travel to it both directly in real-time AND by warping in orbit. It has its own multiplayer bubble. It's on rails in the planet bubble. When you leave for another destination you plan a journey starting from the shipyard using its map view configuration. If you wish to re-enter the Kerbin bubble, you depart the shipyard and resync with Kerbin. Yes, I admit you might need to limit map-view somehow so you don't see the positional jump. That's solvable.
  12. I don't know what you're talking about. I'm advocating for the extensive usage of time warp outside of the real-time multiplayer bubbles.
  13. No it doesn't, it just has to be predictable in your map view so you can plan your maneuvers and rendezvous. It has to be constant for you while you're on your journey, for that specific craft. In-game calendar can very easily be desynced for each localized bubble. You can easily jump back and forth in solar system configuration. Better yet think about it this way: instead of travelling in time, you travel from one positional configuration to another. But you do not desync players in time on / in proximity of the celestial body. It should be written in stone. The universe is empty. We all should be playing together, with the possibility of any number of players interacting in real time on / in-proximity-of the celestial body. Not just your 2-4 player space agency team. You gain space-races, inter-agency contracts, craft trading, very cool visuals and a lot more.
  14. No it wouldn't. You get to orbit, set your shipyard as target and create the necessary maneuver nodes, time-warp to it (while exiting the Kerbing multiplayer real-time bubble, you arrive at the shipyard and sync to the local station real-time multiplayer bubble. You're too small to be seen by other Kerbin based players, so causality is preserved. When you return you resync to the Kerbing bubble and re-enter multiplayer. Done. I' m really suggesting a hybrid system, but the bubbles configurations are controlled by the server. Why would I ever want to sync with a random player B that supposedly already owns land in the future that clearly overlaps with my landed craft? (yes, player A landed there first in his reality) General rule: stop trying to time travel on the celestial bodies. It's cheating.
  15. That breaks causality. And what about syncing colony placement? Assume player A warps to the future and builds a colony at position X. Player B does not warp, is in the past, and also builds a colony at position X. Then he warps to Player A's time in the future. What happens to the overlapping colonies?
  16. So what? It's a very small price to pay to enter big synced real-time multiplayer. You can just tell yourself you spinned in orbit while waiting for a "multiplayer-transfer-window". :))
  17. I beg of you read what I wrote again. When you arrive at Duna you sync to the local real-time multiplayer bubble and to the solar system configuration set by the server for Duna. The map view configuration was virtual, a relic from the past. All players sync to the server controlled configuration of the destination. All players are in sync at the destination. All regions are desynced in relation to each other.
  18. There is no centralized space and time. It's not like you leave at time K and arrive at time K+3=D. Actually K+3 < D. K and D are totally desynced. K is generally in the past, D is somewhere in the future. When you arrive at Duna and sync to real-time D it's like you spin in Duna orbit while time-warping until the solar system configuration changes from K+3 to D. It's like waiting for a transfer window but reversed. You are forced to do this because the server controls time-warp after you arrive. You go from a virtual single player time configuration (the one in map view you saw and controlled with time warp during the journey) to a real-time multiplayer bubble configuration set by the server. If you worry about resource usage the game can just calculate your remaining stocks ignoring the jump from K+3 to D using an internal timer specific only to you. At time K+3 you have N snacks remaining. At time D, after you sync, you still have N snacks remaining. But what is important: there is no universal time. Time is actually irrelevant. You basically jump to each celestial body's present time when you switch colony or craft. You jump back and forth in time, from one solar system configuration to another - but it's irrelevant because causality is preserved. What matters: the regional solar system configurations are under the exclusive control of the server. Players on / in-proximity-of a certain celestial body are always in sync.
  19. Allowed to time warp: You can time warp after you make orbit and plan a journey with a destination with which you can sync and commit to the journey. You time-warp when on the journey. You can time-warp in deep space. In deep space you are allowed to come out of time-warp to change destination and maneuver nodes. You can time warp when you're not in a multiplayer real-time bubble (non-team-members). Not allowed to time warp: You can't time-warp when playing inside the multiplayer real-time bubble (EXCEPT when leaving on a journey - as stated above - but in that case other players just see you burning and disappearing in the distance). The multiplayer real-time bubble would be on and in-proximity-of the celestial body you're visiting or close to a space station, asteroid, comet. The gist: The server always controls the on-rails configuration and syncs you to it when you arrive in the multiplayer real-time bubble. You don't get to control the position of on-rails objects by using time-warp in the multiplayer real-time bubble. To desync, players leave on a journey. Then they can time-warp. They resync with the destination multiplayer real-time bubble when they arrive and finish the journey.
  20. There has to be a serious marketing campaign at least a few months before launch. I hope the team will someday explain what was the reason for all the delays. "We're launching in 2020, no 2021, no actually 2022." But where's the marketing campaign? Dunno.. it's classified.
  21. [snip] Of course you can. You do it all the time when you time warp to transfer window in orbit. As long as you plan the journey and exit the multiplayer bubble you can do whatever you want in map view. Create and execute your maneuver nodes. You sync to your destination when you arrive. I have not been taking about that. What if you warp from Kerbin to Duna and then just warp back? To sync back to the Kerbing multiplayer bubble you have to be gone from that reality. You cannot meet your recorded self and other players can't see two of you. Besides, can you imagine what it would mean for a server to record and replay each player action for every other players? Technically, your solution is second-come first serve since the player that arrived later (player A) What you said makes no sense. I literally said Player B arrives later, then you wrote that Player A arrives later.
  22. Actually with the OAB they just spawn on-rails. So you could just see them rising at the horizon after they get built. The smaller stuff you only see being built when you're in that specific real-time multiplayer bubble. So, with some basic animations to maintain immersion, from low orbit you can basically do warp journeys to anywhere. All while having the MMO experience in the specific real-time bubbles: on the ground up to low orbit / around space stations / asteroids etc. Very, very exciting!
  23. You don't even ACTUALLY need time-warp. What you're asking for is an interface solution to represent fast-travel in map view while keeping the immersion of realistic orbital maneuvers. That's super easy to do: you get to orbit in the real-time bubble, you select the station as a destination / target, you set-up the encounter in map view. You press GO / burn. You now exit multiplayer and arrive at your destination where you sync to the local real-time multiplayer bubble. Maybe you also have to limit map view a little to only display the local on-rails system to be easier for the player to accept the sync. EZ The only reason I'm advocating for having real-time around the celestial body is because I want to see the huge space stations / motherships being built in low orbit from a distance. And I also don't want to see people in low orbit disappearing suddenly - but that could just be fixed with animations of the burning away + a message that you can't interact with them anymore. As for reappearing in high orbit.. there are solutions. Like always spawning vessels out of other players field of view or at a certain place in orbit where they can't be seen.
  24. What if player B in the past creates a station right where player A has the station in the future and then warps to player A time? If you want to have automation with pre-planned routes, you use waypoint navigation AI like in Starcraft. Players on the same celestial body are always in the same real-time multiplayer bubble. First come, first serve = it's a space race. Player B that arrives later has to adapt to things already built by player A. You know, like in reality. This preserves all causality. I emphasize again that we should stop trying to solve time travel on / in proximity of celestial bodies. It breaks immersion, causality, it desyncs players and it's very close to cheating. As for when on the journey in deep space, warp all you want, you're outside of multiplayer. I would also add that solar system configuration is more important than having a well defined time. And one thing about orbits is that they are somewhat cyclic. So what do you even need time for? Let the server define the celestial bodies positions for you to plan and adapt to. As for resources: resupply loops + internal game timer for each player for remaining resources (which has no real impact on multiplayer) + lower productivity instead of killing kerbals.
  25. Nice. Stored parts auto-combinatorics based on schematics. Manually you can already do it in KSP1 in EVA construction mode.
×
×
  • Create New...