Announcement

Collapse
No announcement yet.

proquake (or qrack): multiple network interfaces + qrp

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    remember though, DarkPlaces isn't designed to specifically stroke the Quake1 game. It just happens to support it

    I did and RE: in PM
    Want to get into playing Quake again? Click here for the Multiplayer-Startup kit! laissez bon temps rouler!

    Comment


    • #17
      I think there is a difference in the rate at which Qrack and DP refresh pings to the scoreboard , and/or there is some type of averaging of pings going on.


      Qrack could be reporting pings faster and more often. I could detect no difference in pings at Rage using DP vs Qrack.
      Want to get into playing Quake again? Click here for the Multiplayer-Startup kit! laissez bon temps rouler!

      Comment


      • #18
        Originally posted by R00k View Post
        I was under the assumption that if the "-ip" wasn't specified it fell back to INADDR_ANY
        It does until this chain happens: _Datagram_SearchForHosts -> dfunc.Broadcast=WINS_Broadcast -> WINS_GetLocalAddress

        as a test, start fte, set sv_listen_nq 1; dedicated 1; map start
        in qrack/proquake/etc, do connect localhost:27500
        if that fails when connect $NAMEOFMACHINE:27500 or whatever works, you have this bug. If you prefer, you can test with DP instead, of course... I think its 'sv_protocol quake' to get it vanilla-compatible.
        try it.
        Some Game Thing

        Comment


        • #19
          INADDR_ANY done.

          I guess thats a wild card for anything that is bound to this socket...?
          www.quakeone.com/qrack | www.quakeone.com/cax| http://en.twitch.tv/sputnikutah

          Comment


          • #20
            if you bind to INADDR_ANY, you get packets destined for any interface that the local machine owns, yeah (any interface/alias, rather than any ip). it'll guess some local ip when sending packets based on the interface the packet is sent over, so you might not know the ip the other side will see, but you won't know that if you're NATed either, so no loss.

            like I say, you don't always know the source ip in your outgoing packets. routing tables will mess this up even if you did try to guess. This doesn't affect clients, as the ips will always be the same for any remote endpoint. NQ servers listen on one socket, and host the game for each client on a separate socket. The server needs to report its local ip properly in order for the client to accept packets as from the server. The ip that is reported for the client to connect to instead is unaffected by this change, but the sender's ip is. The server's source IP may appear differently, but in cases where it is, both IPs are able to send to that client. If you're really paranoid you could explicitly bind the connected socket to the same ip that was reported to the client, but mneh, that's not gonna happen.
            Some Game Thing

            Comment

            Working...
            X