STFU :-P ----- Original Message ----- From: "Dynerman David M" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, April 15, 2002 6:53 PM Subject: RE: [hlcoders] 64 players servers are no problem... :-)
Yeah, imagine that __WIN__sock is in WINdows, not Unix (Unix Sockets) :) david -----Original Message----- From: Oskar 'Zoot' Lindgren [mailto:[EMAIL PROTECTED]] Sent: Monday, April 15, 2002 10:50 AM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] 64 players servers are no problem... :-) hmm.. didnīt know it wasnīt named the same thing... ----- Original Message ----- From: "Dynerman David M" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, April 15, 2002 6:33 PM Subject: RE: [hlcoders] 64 players servers are no problem... :-) Not at all. The dll lets you load arbitrary 3rd party code, generating your own winsock communication code (and unlike zoot said, winsock does not run under *ix, Berkeley Sockets are used, which Winsock is derived from - similar, not exact) The thing is, this isn't really revolutionary. It'd be a lot of code to implement. It's almost like saying "Hey we can make 64 player games by writing our own game" Of course you can. david -----Original Message----- From: Tim Holt [mailto:[EMAIL PROTECTED]] Sent: Monday, April 15, 2002 10:26 AM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] 64 players servers are no problem... :-) -- [ Picked text/plain from multipart/alternative ] This sounds a lot like my april fools joke post about "client servers" talking to each other offering the potential of 32x32 (1024) player games.... botman wrote: >>The only network controll you have to bulid is the one between the server, >>but the part about loseing voice is true if the servers are deadicated. So >>if a monster or a player moves this happens: >> >>entity id and now pos -> the "client" server -> the "client" serverīs >>players >> >>and if the "client" serverīs players move: >> >>the "client" serverīs players pos -> the "real" server -> the real server >>clients >> > >I think I misunderstood what your original message proposed. > >I believe what you are suggesting is to create a network layer between 2 >servers (each of which has 32 players). When a player joins one of the >servers, a network message is sent to the other server to create a virtual >player on the other server. Player movements and button presses are mirrored >from the server the player is actually connected to over to the server running >the virtual version of this player. Thus you have the appearance of 64 players >on a single server (when in reality only half of them are real players and half >of them are, in effect, monsters). > >This should work fine as long as you don't want client prediction (since that >is handled within the engine and not by the MOD DLL code). Also you would >probably need both servers physically located on the same LAN since any network >lag between these servers would be added to the actual network latency between >the server and the client (i.e. the client on server A would move and it's >origin would be updated 100 ms or so later on server B, but the player (on >server A) isn't really located at that position anymore since during that 100 >ms they have moved to a new position). > >It might be interesting to see to what an absurd level this could be taken by >networking 8 or 10 servers together (each creating virtual copies of players on >the others). You'd be limited by the number of entities a server can support >(I seem to remember this being 350 but that might be a limit of something >else). So with 10 servers you could conceivably run 320 "players" in a single >server? Now all you have to do is start creating the network specification for >the communication layer between these servers and try it out. > >Jeffrey "botman" Broome > >_______________________________________________ >To unsubscribe, edit your list preferences, or view the list archives, please visit: >http://list.valvesoftware.com/mailman/listinfo/hlcoders > -- I think...I think it's in my basement. Let me go upstairs and check. -M.C. Escher -- _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders