Jump to content

Dagger

Members
  • Posts

    132
  • Joined

  • Last visited

Posts posted by Dagger

  1. Thanks Caylis for the suggestion!

    I've been preparing the framework for interpolating positions today but @jrodriguez gave me a new idea. Instead of interpolate the movement of the vessel based on position updates, get input updates and apply the input yaw,roll,throttle,etc to the client vessel, probably we would still need some kind of "security position interpolation" in case something bad happens but I'm investigating both possibilities.

    I'm a bit lost in the KSP and Unity API so it might take some time.

  2. Honestly it still has a lot of stuttering and I'm having problems with the interpolation stuff.

    I understand the theory behind it (http://www.gabrielgambetta.com/fpm3.html and https://www.youtube.com/watch?v=6EwaW2iz4iA) but I don't know how to adapt it to KSP and make vessels interpolate their position between packets.

    As it is right now, the vessels stutter as their position is not updated between packets

  3. 2 hours ago, X52 said:

    If DMP is just updating positions, than that would explain the lag i mentioned.

    Best way of achieving a smooth multiplayer experience is not only updating position, but also speed vectors (and in case of KSP acceleration vectors) and letting the client interpolate until the next update from server arrives.

    This way a single package is bigger, but the game feels smooth between packets.

    UDP is much faster because there is not so much handshaking going on, the down side is packets can get lost. This would be no problem for vessel locations, but for login and other data that has to be reliable TCP is the Protocol of choice. That´s the reason some games use both in combination.

     

    Well the interpolation is what I want to achieve as it what modern FPS implement although my maths are a bit rusty after so many years :) Anyway, I will look into it once I understand how to spawn and update a vessel as I don't know much of the KSP API. Right now vessels that are closer than 20km are updated at 30FPS, the ones that are farther away at 5FPS and the ones that are really far (other planets) at 1FPS

    Regarding UDP, with the modern network hardware is quite reliable and even if you work with old hardware, lidgren is what's called a "reliable UDP" library. Some packets cant be sent in reliable mode (like chat messages etc) and some others in unreliable mode (like vessel position updates, sync time requests,...) all of this is taken into account in my fork. Using both TCP and UDP at the same time is a bad choice as some packets will affect each other (like this paper describes: https://www.isoc.org/INET97/proceedings/F3/F3_1.HTM)

  4. 40 minutes ago, Caylis1397 said:

    @Dagger great work, I've looked at some of your code and wow, when this is done DMP (or what ever you call it) is going to be much more stable and a lot more fun to play. Now I just need to figure out how to get an upgrade like this in Syncrio :)

    It really depends in how your mod is designed. If you need reliable messages and you don't  send messages very often then you can stay on TCP . Otherwise, if you need fast message handling and it doesn't matter if some of them are lost (like 90% of the games) then switch to UDP.

    Here is a good article about it: http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/

  5. Hi Guys, I started to make a fork of DMP in April after asking godarklight for permission and right now I have something "workable".

    The new features are the following:

    A new network library based on UDP (it's called lidgren and it's used by many games). No more heartbeats, ping messages, split messages, disconnection messages and faster sync time and vessel possition updates as TCP is not a very game-friendly protocol (causes a lot of lag).

    New client settings system based on XML serialization (I still have to implement the same for the server settings)

    New compression algorithm (QuickLz)

    New message system based on fastmembers so the serialization is easier to implement and expand as they are just properties and you don't handle streams anymore

    Whole code-refactoring of the client and server. (Client side is based on systems and windows so UI layer is separated from BL layer)

    ---

    The problem with it is that I don't understand how the vessel system and atmoloader works, so maybe if someone can give me some tips on how should I spawn a vessel and how should I update the vessel possition hopefully I can finish it during this month and start testing it in public. Of course every developer is welcome to collaborate and fork it :)

    The url is:

    https://github.com/DaggerES/DarkMultiPlayer

    Note that it's only for 1.13 at the moment. The fork still doesn't have a name so suggestions are welcome

     

×
×
  • Create New...