Jump to content

Vl3d

Members
 View Profile  See their activity

  • Posts

    2,540

  • Joined

  • Last visited

 Content Type 

Everything posted by Vl3d

  1. Vl3d
    Procedural Radiators video already showcased procedural trusses. Solid rocket boosters should indeed be segmented and extensible to control burn time. I would like the same for fuel tanks - but most importantly have the ability to group/merge tanks together as a single part. I would also like procedural radiators to not look like solar panels.
  2. Vl3d
    Part factories are abstracted away by the V/O/BAB/SPH part selection filters and inventory. What would be useful would be tooling for craft subassemblies for mass production related resource efficiency. And craft / subassembly / part / resources trade for multiplayer.
  3. Vl3d
    If it's in orbit it would have to position itself exactly right for the incoming ship. It would be incredibly long. If you can make one in reverse, that means you can make a regular one to launch the ship. I'm not against particle accelerators, they are just impractically long if they are liniar or need huge confinement fields if they are curved.
  4. Vl3d
    That is not what I said. There is no central / universal time. The server controls the configuration of each space-time bubble. Causality is preserved. Please read the Q&A. Please do not reinterpret or paraphrase my solution with variation, you can just easily link to it:
  5. Vl3d
    I prefer focusing on the mothership. You can imply the tugs. Yes it is. You can have single player, public server multiplayer and private server multiplayer using the same common game design. You would build on the previous game, because I believe big multiplayer was the vision for the game starting a long time ago. I mentioned this in the Q&A. Time will tell. I will keep my dream alive. We will one day build the KSP universe together.
  6. Vl3d
    30 players is not big multiplayer, I'm taking about at least hundreds of people planet-side and thousands of people playing in the same universe.
  7. Vl3d
    Yes you do, on / in-proximity-of the celestial body. It's my opinion.
  8. Vl3d
    I'm not blaming anyone. I'm saying I understand why we are stuck in limbo talking about this time-warp superpower. I'm trying to explain a paradigm-shift that allows us to have huge multiplayer. Just let the server control the state of the in-game simulation.
  9. Vl3d
    It's somewhat understandable that players with synapses defined by years of playing thousands of hours of KSP1 would be resistant to and suspicious of change. I feel like some people just refuse to let go of the God-like superpower of manually controlling time and solar system configuration in exchange of a cool multiplayer game. And this is why they can't change paradigm. It's normal. This is really the only good solution Ive seen. Because all your transfers depend on where bodies are in relation to each other you need to have a consistent causal timeline and players just leapfrog each other as they advance. This is describing a single-kerbal game, right? Your game would be limited to where your character is physically, right? No managing colonies, no switching vessels, no KSP... All this because you refuse to let the server control the simulation. Why can't you just switch colonies / crafts and go back and forth in server controlled state / configuration, not objective time? I'll always repeat that in orbit time is relative, except for life support. And that can be fixed by setting an individual per-player inner game time which is used to calculate resource usage and stocks. It does not impact multiplayer because other players can't look at your colony/craft remaining resources.
  10. Vl3d
    No they don't. You see their projection starting a burn and leaving the SOI. You just can't interact with them anymore. As for arrival, there's a huge difference between seeing people arrive from outer SOI and seeing them warp around on the planet or in lower orbit. You could just arrive outside the visual range of other players.
  11. Vl3d
    Other players don't see you warping / teleporting / hyper-driving on / in proximity of the celestial body. You don't get to manually travel back in time, you can only cancel a journey and return where you were. You don't break causality. Only the server controls celestial body configuration and local time, you do not. All players are in sync.
  12. Vl3d
    You don't manually start your burn. In KSP2 you would just start your journey. You set a destination and maneuver nodes in advance. Then when you press Start Journey the game would automatically warp you to your maneuver nodes and do the burn for you, outside of the real-time multiplayer bubble.
  13. Vl3d
    Yes but only when on a journey, not in the multiplayer real-time bubble.
  14. Vl3d
    Logically yes, if it's not self sustainable or there's no supply chain. You have to first create a supply chain, like mentioned by @SkyFall2489 But in the system I suggested time / solar system configuration varies for each celestial body. There would objectively be no centralized solar system time that you as a player control. But you could have your own game time that is used to calculate resources usage. There would be multiple parallel present(s) representing each celestial body's real-time bubble current time, each controlled by the server. When you switch craft or colony from one SOI to another you travel back and forth in time as decided by the server. So how do you fix this desync in gameplay? I think easily: the server just hides the local time from the player and show "remaining resources estimated time". The thing is that it doesn't really impact multiplayer. Other players can't see inside your craft or colony to check if kerbals are alive or dead. They just see the buildings / crafts on rails. So you're actually playing single player KSP in an MMO context and you're not breaking causality. Because the server controls time-regions, it can simply calculate resources based on your personal game time. The Kerbals without supplies perished for you. When you arrive you just sync you to the real-time bubble and find them dead. Causality preserved.
  15. Vl3d
    You play real-time on / in-proximity-of the celestial body when not on a inter-SOI journey. When planning and starting a journey you exit the multiplayer real-time bubble and you time-warp. There could also be a hybrid system in which you would be allowed to auto-warp from orbit to other orbiting space stations, similar to travelling to moons, but the server would have to deal with local system configuration desync, maybe by limiting your map view and hiding time or a hard-resync. Most important things would be that other players don't see you teleport, you don't break causality, you don't have cheating-like advantages over other players like pseudo-time travel and you let the server control time, system positional configuration.
  16. Vl3d
    You can start your journey from any point in orbit, because you would automatically warp to the transfer window maneuver node, automatically burn and then warp to the next maneuver node. Then you sync back into the local real-time multiplayer bubble when you arrive at your destination. Where do you waste time?
  17. Vl3d
    I misquoted, in the following answer i am referring to your statement: "having to wait in real time for transfer windows". That's absurd, I never said that. When you begin the journey you start time-warping to the transfer window, at which point you exit the local multiplayer real-time bubble. After starting the journey either: (c) you cannot cancel the journey until the next maneuver node and you can't just turn back OR (d) you cancel and/or turn back and sync again to the current planetary real-time bubble. As I have said a hundred times before: you play real-time on / around the celestial body. When planning and starting a journey you exit multiplayer real-time and you can control time-warp. When you arrive at the destination you sync to the local celestial-body multiplayer real-time bubble. Maybe ask Einstein or Newton. You're just asking for pseudo warp-drives and time travel on / in-proximity-of the celestial body in multiplayer. You can only warp when on-rails. Luna and Dark are KSP1 workarounds because the first game was not architected with multiplayer in mind like KSP2 is.
  18. Vl3d
    Well maybe if someone decoded the hidden binary message.. Something could be hidden in the explosion or the kraken tentacles, just saying.. :))
  19. Vl3d
    It's not in orbit, it's direct intercept. Yeah, very similar. Basically the same idea from a slightly different angle, lol. But thanks for the credit
  20. Vl3d
    It has landing legs, an engine and a fuel tank - but only enough for a landing. Next feature video will most probably be the last one - mainly about multiplayer, maybe references to modding or colonies. So we have to wait for another 6 months for a release date, probably.
  21. Vl3d
    Great project! Did you also include this Purdue Space podcast interview? It's one of the most informative.
  22. Vl3d
  23. Vl3d
    Big enough to see in orbit from the ground.
  24. Vl3d
    Also imagine having inter-agency bidding contracts to trade in-game resources for subassemblies designed by other agency players with some specific size and functionality requirements. Like the contracts in KSP1 basically, but actually useful in multiplayer.
  25. Vl3d
    Physical interactions only between craft of the same agency/team. All other players craft would be just fly-through visual projections, for gameplay and performance reasons. We could have interaction with other players craft (other agencies) docking ports only after requesting permissions to dock. Celestial body resources would be infinite like in KSP1. There's enough room for everyone. Free for all, create asteroids that fragment when under stress. I wrote short story about this. No outside-team physical interactions as stated above + lucrative cleanup contracts.
×
×
  • Create New...