It's more like not being able to fly, and worrying about the autopilot, so you don't have to fly long distances yourself. Yeah, timewarp isn't like trying to get an airplane to fly. This isn't to say that timewarp may ultimately prove to be "the" deal breaker to multiplayer, but that result isn't likely to be the case, and if it is, it will be because of UI issues, not technical ones.
#Openttd transfer how to#
If you can synchronize the data, then you're just deciding how to decide on the level of timewarp, which is a UI problem, not likely to be less manageable than the synchronization issues. If you can't synchronize ship positions/velocities well enough to allow for the level of interaction you want, then timewarp is moot. In my opinion, there's enough challenge accurately synchronizing data between multiple players that the level of timewarp becomes just one more piece of data that needs to be synchronized. You're basically saying that timewarp is the single most important part of multiplayer, everything else is just aesthetics, and that if you can manage that, everything else will be easier. If it's so easy, why not simply write out the plan? " It's going to be easy to solve" is usually not the right plan.
#Openttd transfer software#
Proper software development is about having a plan on how to develop the software, and while you don't expect to have all implementation details solved at initial design, you should have an idea on how to tackle some of the major issues you're going to encounter. And saying "it's easy to resolve" doesn't make it easy to resolve, just like saying "learning to speak a foreign language at native level is easy" doesn't make doing so easy either. The reason people keep bringing it up is because it is a major dealbreaker if you can't resolve it. Before you find out that half of the stuff you did can be thrown out as you have to redesign your craft ("wings? who knew?"). Getting the plane to fly is one of the easiest things to resove, really!"īut, before you spend endless hours on putting chairs and an entertainment system inside the cabin, and paint the entire plane, and set up a schedule for your fleet, you do want to have that tiny issue of "does it actually fly" resolved. This is a bit akin to design an airplane. It is one of the easiest things to resolve, really! Stargates are either a request that might be added to stock KSP, or a way to avoid timewarp, so argument not processed. Physics calculations will not be done, and a GPU loves to eat thousands of triangles, just for breakfast. You load the craft as a whole, and move it. It is one of the easiest things to resolve, really ! You might not read it, but we need to stop discussing about that until we have a powerful and reliable multiplayer mod.ġk part ships will not lag if it is just a bunch of parts on positions that get displaced and orientated by a "global" position. Stargates could be located just inside each planets SoI, destination chosed before transition. You don't want to lodge a rocket towards empty space while playing with your friend(s). In MP, you want to build together, explore a system/planet/moon together. Put in stargates! You want to travel between planets and use timewarp? Play singleplayer. So the transition between planets is just dead time. But people need to build big because they want to go to a planet far, far away. Now, if someone built a 1k part ship and it met yours, it would lag. MP would be more of a coop with friend(s). Now, MP for me would not be some sort of a global server etc. Only got to page 9.īecause they are going to a planet far, far away. No idea if this "idea" has been discussed. With this method we will see exactly the same problems as cloud gaming and they are why I absolutely hate cloud gaming. Otherwise a MP will not be playable at all. The others needs to adapt to you, not you to them.
Well, what if you have a very low bandwidth and/or big latency? You ill not be able to control your ship. Wait, isn't this is method number 2 but this is using dedicated server instead of listen server?
No one computes the ship, instead the server computes all the stuff and the client acts only like a "dumb terminal" for inputting commands and showing each other ship position. Player A sends a thruster on command -> It go to a server, computes, and it moves Player A ship -> It send a video/positional data to Player BĪnd vice versa is true. Player A sends a thruster on command -> Player A computes the movement, and the ship moves -> Player A sends a positional data to ship in Player B computer (author KSP multiplayer)ģ. Player A sends a thruster on command -> Player A computes the movement, and the ship moves -> Player A sends a command to ship in Player B computer, it computes its command, and the ships move (OpenTTD)Ģ. Alright I'm not a programmer but it seems that I notice several multiplayer system:ġ.
0 kommentar(er)
