Re: [hlds] rate toggle
I understand it just fine, I'm not the one stating something and then pointing to a document that doesn't come close to stating the same thing as proof... On 7/24/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I think you clearly misunderstand the document I refer to -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] rate toggle
-- [ Picked text/plain from multipart/alternative ] Some how I doubt you have even bother to read it On 7/25/05, Clayton Macleod [EMAIL PROTECTED] wrote: I understand it just fine, I'm not the one stating something and then pointing to a document that doesn't come close to stating the same thing as proof... On 7/24/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I think you clearly misunderstand the document I refer to -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] rate toggle
doubt all you like, the document clearly spells out what cl_interp is/does. It's got to do with you and your view of the server's data. Your view of the server data has nothing to do with my view of the server data. You can alter *your* 'delay' all you like, it doesn't affect me, as I have my own setting, and my own communication with the server. It's the same thing as saying that because you have a 500ms ping that I also have an effective 500ms ping, even though I actually have a 25ms ping. Your ping is your business, not mine, and it doesn't change anything with my communication with the server. It only affects you. On 7/24/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Some how I doubt you have even bother to read it -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] rate toggle
-- [ Picked text/plain from multipart/alternative ] Look, it is quite clear that you haven't even bothered to look at the dicument let alone read the section I specifically quoted What part of *command execution* don't understand? On 7/25/05, Clayton Macleod [EMAIL PROTECTED] wrote: doubt all you like, the document clearly spells out what cl_interp is/does. It's got to do with you and your view of the server's data. Your view of the server data has nothing to do with my view of the server data. You can alter *your* 'delay' all you like, it doesn't affect me, as I have my own setting, and my own communication with the server. It's the same thing as saying that because you have a 500ms ping that I also have an effective 500ms ping, even though I actually have a 25ms ping. Your ping is your business, not mine, and it doesn't change anything with my communication with the server. It only affects you. On 7/24/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Some how I doubt you have even bother to read it -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] rate toggle
Can two take this pissing contest somewhere else please, it got old about 6 posts ago. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] Setting Up HTTP Server
Okay funny I managed to get it working.. and it is fast... However I noticed
out of the Server.cfg trying to use sv_downloadurl
http://{Websit}/my_cstrike;
never worked...
When I went into the console after reading all night long I ran across where
someone entered into the console to check their return.
I did the same and nothing came back.. so I attempted to execute the cvar
manually with the correct address and it started working. Strange as it may
seem. I have cycled the server up and down all night long.
Thoughts on SRCDS - Win X64 Server? Is this a bug?
Thanks for those that responded, earlier..
- Original Message -
From: Hackmett [EMAIL PROTECTED]
To: hlds@list.valvesoftware.com
Sent: Sunday, July 24, 2005 1:15 PM
Subject: Re: [hlds] Setting Up HTTP Server
Hi,
that has imo nothing to do with your problem.
Directory index means that you try to enter the domain and have no
index.htm or so in this directory and the apache creates a file-list
You can test this by enabling the Idexes Option for this directory:
in httpd.conf:
Directory /home/virtual/site96/fst/var/www/html/my_cstrike/maps/
Options Indexes
/Directory
But this should not be needed.
If there is no request to the webserver at all your problem seams to be in
the SourceDS config.
this is the latest message I am seeing in the Error logs for HTTP
Server???
[client 69.226.117.201] Directory index forbidden by rule:
/home/virtual/site96/fst/var/www/html/my_cstrike/maps/
- Original Message -
From: Hackmett [EMAIL PROTECTED]
To: hlds@list.valvesoftware.com
Sent: Sunday, July 24, 2005 11:32 AM
Subject: Re: [hlds] Setting Up HTTP Server
Hi,
check the apache access-log if there is any request for the files at
all.
btw:
Downloading missing files from the gameserver also didn't work on my
servers when http download was configured.
it's MIME required on a Windows based Web Server???
My host is based on UNIX / Lynx based... What I find strange in this is
the
objects can be seen via web browser and downloaded. But from the game
it
does not pull.
Quick thought, does the client remember past downloads? As I was
testing
this, I took a custom map in my client and renamed it to something
else.
When I attempted to down load, it failed immediately. When I removed
the
res
and any additional objects, then it trickled but still failed on the
BSP.
If this is any help. The trickle was from the game server for all other
objects the bsp was attempted from the web server. Now what I found
additionally intresting is if the object is not found on the HTTP
server
than the download should revert back to the game server to retrieve the
object.
- Original Message -
From: Chris K [EMAIL PROTECTED]
To: hlds@list.valvesoftware.com
Sent: Sunday, July 24, 2005 10:26 AM
Subject: Re: [hlds] Setting Up HTTP Server
I created a MIME type on mine for .bz2 files and also compress most
map files. Would this help?
On 7/24/05, Jim [EMAIL PROTECTED] wrote:
I do have the folder set to 755 and just attempted another test. I
put
a
single map BSP. on the web server. The .res file was on the game
server,
All
the resources trickled from the Game Server the .BSP map also had a
.BZ2
there as well.
If I use a web browser I can see the file and download it via the web
browser. But going from steam's sv_downloadurl it failed again.
Other suggestions?
___
--
greetz
[Team America] Hackmett
Freedom is not free
www.tawp.de
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
--
greetz
[Team America] Hackmett
Freedom is not free
www.tawp.de
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] rate toggle
I've read and understood it. You, obviously, have done one of those. Your client is not my client. Read that last sentence about 100 times. On 7/24/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Look, it is quite clear that you haven't even bothered to look at the dicument let alone read the section I specifically quoted What part of *command execution* don't understand? -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] rate toggle
once again you fail to understand what's going on. I'm not disputing what you're saying about client view interpolation. I'm trying to point out to you that this only affects communication between *you* and the server. The communication between *me* and the server isn't affected by *you* one iota. That's the point here, Elvis. Why are you so mad, cuz you're wrong? heh. Calm down. Kids these days. On 7/25/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Clayton you are once again being your usual arguing for the sake of it fucktard self You said quite specifically: I thought cl_interp only affects that client's view, and not anything to do with actual network communication, no? Once again for the dummy: http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Lag_Compensation The lag compensation system keeps a history of all recent player positions for a time span of about one second (can be changed with sv_maxunlag). If a user command is executed, the server estimates at what time the command was created. This command execution time is calculated as followed: *Command Execution Time* = Current Server Time - Client Latency - *Client View Interpolation* Then the server moves all other players back to where they were at the command execution time. The user command is executed and the hit is detected correctly. After the user command has been processed, the players are moved back to their original position. On a listen server you can enable sv_showimpacts 1 to see the different server and client hitboxes: Since the server is the final arbiter of what happen excluding Cheats or Client Side exploits, it is quite clear from that explanation, the server takes into consideration the clients interpolation. This means each and every clients interpolation settings has an effect on when the server decides an action takes place and is a core component of the of the Source netcode. Clayton do I need to make the words *Client View Interpolation* larger, more bold or a different colour before you will pay attention to them and accept the fact it is a key component to Client Server communications for Source, or do you want to continue to deny its existence? You made a statement, the statement was incorrect. I politely at the time corrected it, but rather that accept your mistake you persist on arguing the point regardless. You cannot even bring yourself to quote from the source material I am using to back up your incorrect point of view, because you know you are wrong! Usually Clayton your arguments on this list are you taking some sort of grey area position where there is some 5% wriggle room for you to give yourself an excuse to have an argument, in this case there is no wriggle room for you, you are incorrect, and everybody on this list can see the proof for themselves and judge accordingly. This is not the first time you have tried to pull this shit, but I here to make sure people are well aware of who you are and what you attempt to do, each and almost everytime you reply to this list. For the record, I am not here for a pissing contest, I'm just sick and tired of this Clayton dickhead polluting threads on this list with misleading, or flatout incorrect information for whatever perverted reason he has for doing such things. On 7/25/05, Clayton Macleod [EMAIL PROTECTED] wrote: I've read and understood it. You, obviously, have done one of those. Your client is not my client. Read that last sentence about 100 times. On 7/24/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Look, it is quite clear that you haven't even bothered to look at the dicument let alone read the section I specifically quoted What part of *command execution* don't understand? -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] rate toggle
You both have each others email addresses, why not leave the rest of us out of this one? On 7/25/05, Clayton Macleod [EMAIL PROTECTED] wrote: once again you fail to understand what's going on. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] rate toggle
[rant] My god, two days after a message - how pathetic. Yes, client interpolation DOES have to do with netcode, and here is the REASON that neither of you seem to have the decency to produce for each other. [/rant] Interpolation does several things which effect netcode, these will be summarised here: - Sets the data drop time for incoming packets. - derived - Sets the data collision resolution time. - derived - Sets time to extrapolation on the client. -derived - Sets minimum time to client view regulation. -derived - Sets delay on gameworld data rendering. - Generates intermediary data using _known_ data, _if_available_. What it does not do: - change packetrates - alter the rate of incoming data from other clients - generate new data for clients with low packetrates When you see another client lagging, most peoples reaction seems to be a kick. If you turn up your cl_interp value, your client will have more time to wait until the next update arrives for the laggy player. At 30 packets per second you would get away (on an ideal network) with cl_interp 0.033. If a client is only capable of sending 10 packets per second however you will need cl_interp 0.1, again on an ideal network. Data rates can also be important, particularly on slow speed connections - latency for packets is one thing, but they take time to transmit as well, and the larger they are... Remember your time frames too. Client A with 100ms of latency plays game data on defaults, 100ms of interpolation and a packetrate of 20 packets per second. Client B has 'optimised' and is running with a client packetrate of 60 packets per second and 40ms of interpolation with a latency of 30ms. Client A attacks B and the packet arrives at the server 100ms later (neglecting to take into account the potential 50ms wait until the next packet is due for sending). The server rolls back 200ms and generates data. The server is trying to send 60 packets per second, the next packet will be sent within 16ms. Client B receives the update at 230ms to 296ms. Clearly this is well outside of client B's interpolation time, and is not a 'problem' with the 'netcode' settings but will give that appearance on the client. I have come to the conclusion that SRCDS is not affected with it's latency compensation by false pings generated through improper rate settings. I am not sure about HLDS. I have not built any system to test this however, but am merely aware that the scoreboard ping is not what is examined by high ping kicker tools. No, interpolation does not directly change the netcode, it is calculated on the server to regulate client view to server view - and in this regard it is significant in netcode also as it is responsible for the variables of the system stated above. There is no reason to deny it's significance in this discussion as proper cl_interp values can be used to compensate all clients for poor network performance - this is entirely what it was designed for. If client variables are mis-adjusted (VERY VERY COMMON) then you cannot make judgements about the functionality of the systems which they effect. Sorry if I missed anything, but hopefully this will get the discussion back on to something that matters, and exists. On 7/25/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] [snip-unnecessary-crap] http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Lag_Compensation The lag compensation system keeps a history of all recent player positions for a time span of about one second (can be changed with sv_maxunlag). If a user command is executed, the server estimates at what time the command was created. This command execution time is calculated as followed: *Command Execution Time* = Current Server Time - Client Latency - *Client View Interpolation* Then the server moves all other players back to where they were at the command execution time. The user command is executed and the hit is detected correctly. After the user command has been processed, the players are moved back to their original position. On a listen server you can enable sv_showimpacts 1 to see the different server and client hitboxes: Since the server is the final arbiter of what happen excluding Cheats or Client Side exploits, it is quite clear from that explanation, the server takes into consideration the clients interpolation. This means each and every clients interpolation settings has an effect on when the server decides an action takes place and is a core component of the of the Source netcode. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] rate toggle
-- [ Picked text/plain from multipart/alternative ] Hey I agree with you James. My stupidity allowed me to get sucked in to Claytons baiting tactics. On 7/25/05, James Tucker [EMAIL PROTECTED] wrote: [rant] My god, two days after a message - how pathetic. Yes, client interpolation DOES have to do with netcode, and here is the REASON that neither of you seem to have the decency to produce for each other. [/rant] Interpolation does several things which effect netcode, these will be summarised here: - Sets the data drop time for incoming packets. - derived - Sets the data collision resolution time. - derived - Sets time to extrapolation on the client. -derived - Sets minimum time to client view regulation. -derived - Sets delay on gameworld data rendering. - Generates intermediary data using _known_ data, _if_available_. What it does not do: - change packetrates - alter the rate of incoming data from other clients - generate new data for clients with low packetrates When you see another client lagging, most peoples reaction seems to be a kick. If you turn up your cl_interp value, your client will have more time to wait until the next update arrives for the laggy player. At 30 packets per second you would get away (on an ideal network) with cl_interp 0.033. If a client is only capable of sending 10 packets per second however you will need cl_interp 0.1, again on an ideal network. Data rates can also be important, particularly on slow speed connections - latency for packets is one thing, but they take time to transmit as well, and the larger they are... Remember your time frames too. Client A with 100ms of latency plays game data on defaults, 100ms of interpolation and a packetrate of 20 packets per second. Client B has 'optimised' and is running with a client packetrate of 60 packets per second and 40ms of interpolation with a latency of 30ms. Client A attacks B and the packet arrives at the server 100ms later (neglecting to take into account the potential 50ms wait until the next packet is due for sending). The server rolls back 200ms and generates data. The server is trying to send 60 packets per second, the next packet will be sent within 16ms. Client B receives the update at 230ms to 296ms. Clearly this is well outside of client B's interpolation time, and is not a 'problem' with the 'netcode' settings but will give that appearance on the client. I have come to the conclusion that SRCDS is not affected with it's latency compensation by false pings generated through improper rate settings. I am not sure about HLDS. I have not built any system to test this however, but am merely aware that the scoreboard ping is not what is examined by high ping kicker tools. No, interpolation does not directly change the netcode, it is calculated on the server to regulate client view to server view - and in this regard it is significant in netcode also as it is responsible for the variables of the system stated above. There is no reason to deny it's significance in this discussion as proper cl_interp values can be used to compensate all clients for poor network performance - this is entirely what it was designed for. If client variables are mis-adjusted (VERY VERY COMMON) then you cannot make judgements about the functionality of the systems which they effect. Sorry if I missed anything, but hopefully this will get the discussion back on to something that matters, and exists. On 7/25/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] [snip-unnecessary-crap] http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Lag_Compensation The lag compensation system keeps a history of all recent player positions for a time span of about one second (can be changed with sv_maxunlag). If a user command is executed, the server estimates at what time the command was created. This command execution time is calculated as followed: *Command Execution Time* = Current Server Time - Client Latency - *Client View Interpolation* Then the server moves all other players back to where they were at the command execution time. The user command is executed and the hit is detected correctly. After the user command has been processed, the players are moved back to their original position. On a listen server you can enable sv_showimpacts 1 to see the different server and client hitboxes: Since the server is the final arbiter of what happen excluding Cheats or Client Side exploits, it is quite clear from that explanation, the server takes into consideration the clients interpolation. This means each and every clients interpolation settings has an effect on when the server decides an action takes place and is a core component of the of the Source netcode. ___ To unsubscribe, edit your list preferences, or view the list
Re: [hlds] 66 tick
I use net_channels repeatedly whilst changing my netcode settings. Your client netcode settings if they are to be optimised need to consider: -client side FPS -server side FPS (roughly) -server tickrate -network bandwidth -network switching rate (unlikely to be exceeded) Most of the above are simply cap's which you dont want to exceed. If you change your netcode settings and see excessive choke, you have gone over your cap for one of the above. The server can only process packets as fast as it's framerate. Similarly, the server only requires packets at the tickrate to achieve optimality - some consider a few spare to be reasonable also, although I do not share this view as cl_cmdbackup exists. You cannot generate packets faster than your client framerate - setting your cmdrate higher than your framerate can cause excessive choke. Your connection will have a limit to the number of packets it can send and recieve per second, and this will of course vary with packet size also. In general you should not exceed this, and on a boadband connection you will not exceed it on a 66 tickrate server (assuming your ISP are not complete morons). Now the easiest way to optimise your netcode is with trickle settings and essentially educated emperical testing. You should have an idea of the range of your settings: - No need to exceed 66 packets per second so cmdrate and updaterate = 66. - No need to exceed framerate so cmdrate and updaterate = average client FPS I would recommend setting: cl_cmdrate 66 cl_updaterate 66 set rate correctly as is documented many other places - maximum connection capability in Bytes per second. Check net_channels, you should see 66 packets per second on the inbound channel unless you are not on a true 66 tick (I have seen some scum running falsely advertised tickrates, a GSP no less) or unless your client is severely overloaded for bandwidth or processing. You will probably not see 66 packets per second on the outbound channel. What you will see is choke registering on the outbound channel - on any channel that has choke, lower your update and cmdrates until that choke is minimised. Not all clients can achieve 0.0 choke in all scenarios. On 7/24/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] with new hlds update what should serverside and client side rates be ? and with 66 tick i should see more than 33 on in and out on net_graph? -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] rate toggle
I am interested to hear opinions over the viability of client rate regulation at the server side by means of server regulated client view extrapolation. Would this be a better solution?, or does it simply produce too much regulation on the low rate client? On 7/25/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Hey I agree with you James. My stupidity allowed me to get sucked in to Claytons baiting tactics. On 7/25/05, James Tucker [EMAIL PROTECTED] wrote: [rant] My god, two days after a message - how pathetic. Yes, client interpolation DOES have to do with netcode, and here is the REASON that neither of you seem to have the decency to produce for each other. [/rant] Interpolation does several things which effect netcode, these will be summarised here: - Sets the data drop time for incoming packets. - derived - Sets the data collision resolution time. - derived - Sets time to extrapolation on the client. -derived - Sets minimum time to client view regulation. -derived - Sets delay on gameworld data rendering. - Generates intermediary data using _known_ data, _if_available_. What it does not do: - change packetrates - alter the rate of incoming data from other clients - generate new data for clients with low packetrates When you see another client lagging, most peoples reaction seems to be a kick. If you turn up your cl_interp value, your client will have more time to wait until the next update arrives for the laggy player. At 30 packets per second you would get away (on an ideal network) with cl_interp 0.033. If a client is only capable of sending 10 packets per second however you will need cl_interp 0.1, again on an ideal network. Data rates can also be important, particularly on slow speed connections - latency for packets is one thing, but they take time to transmit as well, and the larger they are... Remember your time frames too. Client A with 100ms of latency plays game data on defaults, 100ms of interpolation and a packetrate of 20 packets per second. Client B has 'optimised' and is running with a client packetrate of 60 packets per second and 40ms of interpolation with a latency of 30ms. Client A attacks B and the packet arrives at the server 100ms later (neglecting to take into account the potential 50ms wait until the next packet is due for sending). The server rolls back 200ms and generates data. The server is trying to send 60 packets per second, the next packet will be sent within 16ms. Client B receives the update at 230ms to 296ms. Clearly this is well outside of client B's interpolation time, and is not a 'problem' with the 'netcode' settings but will give that appearance on the client. I have come to the conclusion that SRCDS is not affected with it's latency compensation by false pings generated through improper rate settings. I am not sure about HLDS. I have not built any system to test this however, but am merely aware that the scoreboard ping is not what is examined by high ping kicker tools. No, interpolation does not directly change the netcode, it is calculated on the server to regulate client view to server view - and in this regard it is significant in netcode also as it is responsible for the variables of the system stated above. There is no reason to deny it's significance in this discussion as proper cl_interp values can be used to compensate all clients for poor network performance - this is entirely what it was designed for. If client variables are mis-adjusted (VERY VERY COMMON) then you cannot make judgements about the functionality of the systems which they effect. Sorry if I missed anything, but hopefully this will get the discussion back on to something that matters, and exists. On 7/25/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] [snip-unnecessary-crap] http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Lag_Compensation The lag compensation system keeps a history of all recent player positions for a time span of about one second (can be changed with sv_maxunlag). If a user command is executed, the server estimates at what time the command was created. This command execution time is calculated as followed: *Command Execution Time* = Current Server Time - Client Latency - *Client View Interpolation* Then the server moves all other players back to where they were at the command execution time. The user command is executed and the hit is detected correctly. After the user command has been processed, the players are moved back to their original position. On a listen server you can enable sv_showimpacts 1 to see the different server and client hitboxes: Since the server is the final arbiter of what happen excluding Cheats or Client Side
Re: [hlds] rate toggle
-- [ Picked text/plain from multipart/alternative ] But I cannot see what the technical problem (other than maybe it might be computationally intensive for the server) would be to automate the clients various rate settings, to best suit the clients connection and the servers settings. On 7/25/05, James Tucker [EMAIL PROTECTED] wrote: I am interested to hear opinions over the viability of client rate regulation at the server side by means of server regulated client view extrapolation. Would this be a better solution?, or does it simply produce too much regulation on the low rate client? On 7/25/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Hey I agree with you James. My stupidity allowed me to get sucked in to Claytons baiting tactics. On 7/25/05, James Tucker [EMAIL PROTECTED] wrote: [rant] My god, two days after a message - how pathetic. Yes, client interpolation DOES have to do with netcode, and here is the REASON that neither of you seem to have the decency to produce for each other. [/rant] Interpolation does several things which effect netcode, these will be summarised here: - Sets the data drop time for incoming packets. - derived - Sets the data collision resolution time. - derived - Sets time to extrapolation on the client. -derived - Sets minimum time to client view regulation. -derived - Sets delay on gameworld data rendering. - Generates intermediary data using _known_ data, _if_available_. What it does not do: - change packetrates - alter the rate of incoming data from other clients - generate new data for clients with low packetrates When you see another client lagging, most peoples reaction seems to be a kick. If you turn up your cl_interp value, your client will have more time to wait until the next update arrives for the laggy player. At 30 packets per second you would get away (on an ideal network) with cl_interp 0.033. If a client is only capable of sending 10 packets per second however you will need cl_interp 0.1, again on an ideal network. Data rates can also be important, particularly on slow speed connections - latency for packets is one thing, but they take time to transmit as well, and the larger they are... Remember your time frames too. Client A with 100ms of latency plays game data on defaults, 100ms of interpolation and a packetrate of 20 packets per second. Client B has 'optimised' and is running with a client packetrate of 60 packets per second and 40ms of interpolation with a latency of 30ms. Client A attacks B and the packet arrives at the server 100ms later (neglecting to take into account the potential 50ms wait until the next packet is due for sending). The server rolls back 200ms and generates data. The server is trying to send 60 packets per second, the next packet will be sent within 16ms. Client B receives the update at 230ms to 296ms. Clearly this is well outside of client B's interpolation time, and is not a 'problem' with the 'netcode' settings but will give that appearance on the client. I have come to the conclusion that SRCDS is not affected with it's latency compensation by false pings generated through improper rate settings. I am not sure about HLDS. I have not built any system to test this however, but am merely aware that the scoreboard ping is not what is examined by high ping kicker tools. No, interpolation does not directly change the netcode, it is calculated on the server to regulate client view to server view - and in this regard it is significant in netcode also as it is responsible for the variables of the system stated above. There is no reason to deny it's significance in this discussion as proper cl_interp values can be used to compensate all clients for poor network performance - this is entirely what it was designed for. If client variables are mis-adjusted (VERY VERY COMMON) then you cannot make judgements about the functionality of the systems which they effect. Sorry if I missed anything, but hopefully this will get the discussion back on to something that matters, and exists. On 7/25/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] [snip-unnecessary-crap] http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Lag_Compensation The lag compensation system keeps a history of all recent player positions for a time span of about one second (can be changed with sv_maxunlag). If a user command is executed, the server estimates at what time the command was created. This command execution time is calculated as followed: *Command Execution Time* = Current Server Time - Client Latency - *Client View Interpolation* Then the server moves all other players back to
[hlds] Tickrates....
O.K so I have -tickrate 99 at the end of my target line right? That means i should get a tickrate of 99. So in comes a guy into my server and says that my server isnt 100 tickrate. I'm like yes it is and hes like no its not He then proved it by using net_graph 3 and saying that the In part wasnt 100 on the right hand side. It was 20. He then went to his server and dragged me along and showed me that there it was 100 instead of 20. So what gives? I had the -tickrate switch set to 99... ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] Tickrates....
sv_maxupdaterate 20 On 7/25/05, Rafael Lopez [EMAIL PROTECTED] wrote: O.K so I have -tickrate 99 at the end of my target line right? That means i should get a tickrate of 99. So in comes a guy into my server and says that my server isnt 100 tickrate. I'm like yes it is and hes like no its not He then proved it by using net_graph 3 and saying that the In part wasnt 100 on the right hand side. It was 20. He then went to his server and dragged me along and showed me that there it was 100 instead of 20. So what gives? I had the -tickrate switch set to 99... ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
[hlds] SPAM - Valve!?!
Valve List Mods, Ya know I've thought about this for a good long while now and I have to agree with just about everyone else on this list, when they say we want Mr Anti-Spam Spammer ([EMAIL PROTECTED]) removed from the list... I, of course, already have rules setup to auto-junk this crap... However, what if EVERYONE on this list started using that type of anti-spam? Imagine the kind of backwards spam that would create. Allowing him to stay on the list does nothing but encourage that, and really pisses off the rest of us. Perhaps I should setup an account with this stupid company myself, maybe if we all start doing it the mods will get off their butts and take some action. Frankly I don't send HIM email, I don't want him to send ME any. I send email to VALVE and get spammed by another party, that makes it Valve's problem/fault. It's an EASY fix (this I know for a fact) and I don't understand the reasons behind the inaction. Perhaps someone from Valve (Read: if you are NOT from Valve, don't guess an answer) can explain why they let this continue? I've worked in a couple abuse@ departments (fighting spam, specifically) and like I said, I know how easy this is to fix. So I guess that, really, is what's pissing me off the most. The fact that is a simple fix and yet, despite all the complaints, the list mod(s) have done nothing? Confused Annoyed, -The Joint Chief AKA Stoned Smurf ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
RE: [hlds] SPAM - Valve!?!
Let's all make email accounts with this type of anti-spam and sign it up for the mailing list. That'll will fix it. Actually it would be a fairly decent way for a lamer to screw up the list, and they already know valve won't lift a finger. Good game, Valve. - voogru. -Original Message- From: stalker333 [mailto:[EMAIL PROTECTED] Sent: Monday, July 25, 2005 2:31 PM To: hlds@list.valvesoftware.com Subject: [hlds] SPAM - Valve!?! Valve List Mods, Ya know I've thought about this for a good long while now and I have to agree with just about everyone else on this list, when they say we want Mr Anti-Spam Spammer ([EMAIL PROTECTED]) removed from the list... I, of course, already have rules setup to auto-junk this crap... However, what if EVERYONE on this list started using that type of anti-spam? Imagine the kind of backwards spam that would create. Allowing him to stay on the list does nothing but encourage that, and really pisses off the rest of us. Perhaps I should setup an account with this stupid company myself, maybe if we all start doing it the mods will get off their butts and take some action. Frankly I don't send HIM email, I don't want him to send ME any. I send email to VALVE and get spammed by another party, that makes it Valve's problem/fault. It's an EASY fix (this I know for a fact) and I don't understand the reasons behind the inaction. Perhaps someone from Valve (Read: if you are NOT from Valve, don't guess an answer) can explain why they let this continue? I've worked in a couple abuse@ departments (fighting spam, specifically) and like I said, I know how easy this is to fix. So I guess that, really, is what's pissing me off the most. The fact that is a simple fix and yet, despite all the complaints, the list mod(s) have done nothing? Confused Annoyed, -The Joint Chief AKA Stoned Smurf ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] SPAM - Valve!?!
-- [ Picked text/plain from multipart/alternative ] What brought this on? I haven't seen this guy for a while, or maybe my mail is deleting it automatically now. In any case I'm not seeing him anymore. On 7/26/05, Spencer 'voogru' MacDonald [EMAIL PROTECTED] wrote: Let's all make email accounts with this type of anti-spam and sign it up for the mailing list. That'll will fix it. Actually it would be a fairly decent way for a lamer to screw up the list, and they already know valve won't lift a finger. Good game, Valve. - voogru. -Original Message- From: stalker333 [mailto:[EMAIL PROTECTED] Sent: Monday, July 25, 2005 2:31 PM To: hlds@list.valvesoftware.com Subject: [hlds] SPAM - Valve!?! Valve List Mods, Ya know I've thought about this for a good long while now and I have to agree with just about everyone else on this list, when they say we want Mr Anti-Spam Spammer ([EMAIL PROTECTED]) removed from the list... I, of course, already have rules setup to auto-junk this crap... However, what if EVERYONE on this list started using that type of anti-spam? Imagine the kind of backwards spam that would create. Allowing him to stay on the list does nothing but encourage that, and really pisses off the rest of us. Perhaps I should setup an account with this stupid company myself, maybe if we all start doing it the mods will get off their butts and take some action. Frankly I don't send HIM email, I don't want him to send ME any. I send email to VALVE and get spammed by another party, that makes it Valve's problem/fault. It's an EASY fix (this I know for a fact) and I don't understand the reasons behind the inaction. Perhaps someone from Valve (Read: if you are NOT from Valve, don't guess an answer) can explain why they let this continue? I've worked in a couple abuse@ departments (fighting spam, specifically) and like I said, I know how easy this is to fix. So I guess that, really, is what's pissing me off the most. The fact that is a simple fix and yet, despite all the complaints, the list mod(s) have done nothing? Confused Annoyed, -The Joint Chief AKA Stoned Smurf ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
RE: [hlds] SPAM - Valve!?!
Speak of the devil I just got the stupid antispam thing now. -Original Message- From: Whisper [mailto:[EMAIL PROTECTED] Sent: Monday, July 25, 2005 11:55 PM To: hlds@list.valvesoftware.com Subject: Re: [hlds] SPAM - Valve!?! -- [ Picked text/plain from multipart/alternative ] What brought this on? I haven't seen this guy for a while, or maybe my mail is deleting it automatically now. In any case I'm not seeing him anymore. On 7/26/05, Spencer 'voogru' MacDonald [EMAIL PROTECTED] wrote: Let's all make email accounts with this type of anti-spam and sign it up for the mailing list. That'll will fix it. Actually it would be a fairly decent way for a lamer to screw up the list, and they already know valve won't lift a finger. Good game, Valve. - voogru. -Original Message- From: stalker333 [mailto:[EMAIL PROTECTED] Sent: Monday, July 25, 2005 2:31 PM To: hlds@list.valvesoftware.com Subject: [hlds] SPAM - Valve!?! Valve List Mods, Ya know I've thought about this for a good long while now and I have to agree with just about everyone else on this list, when they say we want Mr Anti-Spam Spammer ([EMAIL PROTECTED]) removed from the list... I, of course, already have rules setup to auto-junk this crap... However, what if EVERYONE on this list started using that type of anti-spam? Imagine the kind of backwards spam that would create. Allowing him to stay on the list does nothing but encourage that, and really pisses off the rest of us. Perhaps I should setup an account with this stupid company myself, maybe if we all start doing it the mods will get off their butts and take some action. Frankly I don't send HIM email, I don't want him to send ME any. I send email to VALVE and get spammed by another party, that makes it Valve's problem/fault. It's an EASY fix (this I know for a fact) and I don't understand the reasons behind the inaction. Perhaps someone from Valve (Read: if you are NOT from Valve, don't guess an answer) can explain why they let this continue? I've worked in a couple abuse@ departments (fighting spam, specifically) and like I said, I know how easy this is to fix. So I guess that, really, is what's pissing me off the most. The fact that is a simple fix and yet, despite all the complaints, the list mod(s) have done nothing? Confused Annoyed, -The Joint Chief AKA Stoned Smurf ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] SPAM - Valve!?!
-- [ Picked text/plain from multipart/alternative ] My filter must be working then :) On 7/26/05, Spencer 'voogru' MacDonald [EMAIL PROTECTED] wrote: Speak of the devil I just got the stupid antispam thing now. -Original Message- From: Whisper [mailto:[EMAIL PROTECTED] Sent: Monday, July 25, 2005 11:55 PM To: hlds@list.valvesoftware.com Subject: Re: [hlds] SPAM - Valve!?! -- [ Picked text/plain from multipart/alternative ] What brought this on? I haven't seen this guy for a while, or maybe my mail is deleting it automatically now. In any case I'm not seeing him anymore. On 7/26/05, Spencer 'voogru' MacDonald [EMAIL PROTECTED] wrote: Let's all make email accounts with this type of anti-spam and sign it up for the mailing list. That'll will fix it. Actually it would be a fairly decent way for a lamer to screw up the list, and they already know valve won't lift a finger. Good game, Valve. - voogru. -Original Message- From: stalker333 [mailto:[EMAIL PROTECTED] Sent: Monday, July 25, 2005 2:31 PM To: hlds@list.valvesoftware.com Subject: [hlds] SPAM - Valve!?! Valve List Mods, Ya know I've thought about this for a good long while now and I have to agree with just about everyone else on this list, when they say we want Mr Anti-Spam Spammer ([EMAIL PROTECTED]) removed from the list... I, of course, already have rules setup to auto-junk this crap... However, what if EVERYONE on this list started using that type of anti-spam? Imagine the kind of backwards spam that would create. Allowing him to stay on the list does nothing but encourage that, and really pisses off the rest of us. Perhaps I should setup an account with this stupid company myself, maybe if we all start doing it the mods will get off their butts and take some action. Frankly I don't send HIM email, I don't want him to send ME any. I send email to VALVE and get spammed by another party, that makes it Valve's problem/fault. It's an EASY fix (this I know for a fact) and I don't understand the reasons behind the inaction. Perhaps someone from Valve (Read: if you are NOT from Valve, don't guess an answer) can explain why they let this continue? I've worked in a couple abuse@ departments (fighting spam, specifically) and like I said, I know how easy this is to fix. So I guess that, really, is what's pissing me off the most. The fact that is a simple fix and yet, despite all the complaints, the list mod(s) have done nothing? Confused Annoyed, -The Joint Chief AKA Stoned Smurf ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
