Don't go the TF2 route
MrMakaveli
Join Date: 2004-05-06 Member: 28509Members
Join Date: 2004-05-06 Member: 28509Members
Comments
But seriously, I agree, l4d hit reg was extremely frustrating at the 33tic cap and even with 66tic modded servers. Shooting a hunter in that game is similar to shooting a fast skulk, except hits were very inconsistent because of the tickrate.
I think the idea is to create a more uniform server experience across different servers.
You don't even know what you are saying.
Lets take the recent CS:S update for example. The game was coded(network code and interp stuff) for 33 tik, which was just recently bumped up to 66 tik.
This also brought better net interpolation for better hitbox registry.
A higher tik # does not mean better gameplay. Only what the game is coded for.
If you are playing on a 100 tik CS:S server right now, you will do worse than a 66 tik server due to inconsistencies in the player to server - server to player connection and data transferring.
Yeah.
*****
If you want better clarification on this, go research it out before you post. My statements are way too simplified and dumbed down with non-technical words to really explain why this is a bad thing(or how/ that it matters).
Networking is a bit more complicated than just making sure the tickrate is set to fifty million.
But then we'll miss a golden opportunity to be the worlds most successful hat simulator... IN SPACE!!
Other than that the Spark Engine was written from the ground up. <b>They got this.</b>
Less stress on the server.
Simple analogy:
Ticks = Updated per second
So if you want the server to send you updated about player positions, phys objects etc. 100 times per seconds. The server also needs to calculate 100 updated per second.
So you can run 3 33tick servers on the same machine as a single 100tick server.
Lets take the recent CS:S update for example. The game was coded(network code and interp stuff) for 33 tik, which was just recently bumped up to 66 tik.
This also brought better net interpolation for better hitbox registry.
A higher tik # does not mean better gameplay. Only what the game is coded for.
If you are playing on a 100 tik CS:S server right now, you will do worse than a 66 tik server due to inconsistencies in the player to server - server to player connection and data transferring.
Yeah.
*****
If you want better clarification on this, go research it out before you post. My statements are way too simplified and dumbed down with non-technical words to really explain why this is a bad thing(or how/ that it matters).<!--QuoteEnd--></div><!--QuoteEEnd-->
You really have no idea what you're talking about. You can't even abbreviate tickrate right. 100 tic was available in CS:S years ago. It's harder to notice a difference in that game anyway since the players move relatively slowly so there is little need for things to be updates at a high rate. As long as the game is properly coded to handle different tickrates, including automatic adjustment of client rate settings, higher tickrates are better as long as the server and clients' connections and computers can handle it. CS:S before the orange box engine update (I don't know how it is now) obviously wasn't coded very well to accommodate different tickrates because weapon firing speeds and air acceleration were proportional to the server's tickrate. You seem to be talking about everything at default settings, sure an increased server tickrate won't help much if every client is running default rates in CS:S. Please, hit me with the technical speak because you seems to be making stuff up or are misinformed, like half of your posts.
I don't even know why I waste my time with someone that skips a line just to write "Yeah," as if you weren't even confident in your argument.
Tick rate is nothing more than server FPS. So a 100 tick server calculates 100 snapshots of the games current state per second.
Clients have 2 basic ways to interact with this: Updaterate and Commandrate.
Updaterate determines how often the client asks the server to send him data about one of those snapshots.
-> updaterate 100 on a 33 tick server means you still get only 33 updates per second, cause the server cannot provide more data. However because your client interpolation is based on the updaterate variable you interpolate incorrectly.
Commandrate determines how often the client informs the server about the clients state.
-> commandrate 100 on a 33 tick server has a positive effect, cause although the server only calculates 33 snapshots he will do so with a little bit more recent client data. (Effect is minuscule and the additional bandwith usage is not really worth the improvement.)
Hence most server cap their clients command and updaterate at the tick rate.
If your rates are higher than the servers rate client interpolation will be calculated incorrectly.
If your rates are lower than the servers rate either the server has to interpolate more and send those guessed snapshots to the other clients, or the server just forwards data and all other clients have to interpolate more.
Hence if you use a commandrate of 1 and interpolation was of you would seem to be teleporting for all other players.
However back in the days when bandwith was precious it often made sense for low bandwith users to reduce their update and commandrate.
Nowadays you should just set it to the servers tick rate and presto. Everything is good.
Interpolation means that because if have a client side fps of 100 and the server only sends you 33 updates a seconds. You have to guess for 67 frames per second where all objects are actually. This causes the shot around a corner moments, which gets worse the faster the objets whos position you have to guess gets. Leaping skulks in ns that only used a commandrate of 15 were a prime example.
I don't even know why I waste my time with someone that skips a line just to write "Yeah," as if you weren't even confident in your argument.<!--QuoteEnd--></div><!--QuoteEEnd-->
You just stated what was the problem in CS:S, why you arguing what I said? You figured out exactly what I said. CS:S was never designed for a higher tik(100), and still isn't. This is the way the Source engine is handled.
BTW, I never mentioned CS(the older game on HL). I'm sure 100 tik didn't really help there either.
And no, I'm not about to go copy+paste off somewhere all the technical details. You can go find it yourself(since it is a well documented and debated thing). Don't need to make 3+ page posts honestly.
Also... YEAH!!! ;D (heated much?)
Tick rate is nothing more than server FPS. So a 100 tick server calculates 100 snapshots of the games current state per second.
Clients have 2 basic ways to interact with this: Updaterate and Commandrate.
Updaterate determines how often the client asks the server to send him data about one of those snapshots.
-> updaterate 100 on a 33 tick server means you still get only 33 updates per second, cause the server cannot provide more data. However because your client interpolation is based on the updaterate variable you interpolate incorrectly.
Commandrate determines how often the client informs the server about the clients state.
-> commandrate 100 on a 33 tick server has a positive effect, cause although the server only calculates 33 snapshots he will do so with a little bit more recent client data. (Effect is minuscule and the additional bandwith usage is not really worth the improvement.)
Hence most server cap their clients command and updaterate at the tick rate.
If your rates are higher than the servers rate client interpolation will be calculated incorrectly.
If your rates are lower than the servers rate either the server has to interpolate more and send those guessed snapshots to the other clients, or the server just forwards data and all other clients have to interpolate more.
Hence if you use a commandrate of 1 and interpolation was of you would seem to be teleporting for all other players.
However back in the days when bandwith was precious it often made sense for low bandwith users to reduce their update and commandrate.
Nowadays you should just set it to the servers tick rate and presto. Everything is good.
Interpolation means that because if have a client side fps of 100 and the server only sends you 33 updates a seconds. You have to guess for 67 frames per second where all objects are actually. This causes the shot around a corner moments, which gets worse the faster the objets whos position you have to guess gets.<b> Leaping skulks in ns that only used a commandrate of 15 were a prime example.</b><!--QuoteEnd--></div><!--QuoteEEnd-->
Which in my clan matches, Embarko would always call the Fades and Skulks as being "bugged". LOLZ!!! would ensue.
And ya, I hope once the game is realeased, they also release the information on how the netcode works in NS2.
BTW, I never mentioned CS(the older game on HL). I'm sure 100 tik didn't really help there either.
And no, I'm not about to go copy+paste off somewhere all the technical details. You can go find it yourself(since it is a well documented and debated thing). Don't need to make 3+ page posts honestly.
Also... YEAH!!! ;D (heated much?)<!--QuoteEnd--></div><!--QuoteEEnd-->
exactly, the problem with CS:S is specific to that game; so why are you arguing against high tickrates (or server fps for a more universal term as tankefugl pointed out) for NS2 using logic that doesn't apply to it?
I think it would apply in most cases. An engine won't spend all of its CPU cycles updating the word, especially if not much has changed, so I think most engines use timer-based events (less likely on-demand) to trigger updates (while I/O might be handled in another thread). The frequency of these updates can be referred to as the "tick rate" in the context of just about any engine that uses this scheme.
And Jimy, playing with a higher ticrate is always better for the clients as the game world becomes more accurate.
And Jimy, playing with a higher ticrate is always better for the clients as the game world becomes more accurate.<!--QuoteEnd--></div><!--QuoteEEnd-->
Let me clearify.
I am not disputing that the frequency of processing is relevant to the accuracy. However, using Source's metrics for the update frequency for another engine, as well as the arbitary limits 33, 66 and 100, is a bit far fetched. While the general principle of periodic updates are the same, how frames are interpolated (or extrapolated) is as far as I know not known.
An update-per-second number for one engine does not have to give the same accuracy as the same update-per-second number for another engine. Arguing around Source's specific limits might be misleading.
think about it!
Even then most of us bought the SE for alpha and see the black armor as something extra that doesn't really matter.
Tickrate or updaterate or frames-per-second is the rate at which the server updates the world state (like positions of players, where projectiles are, etc.) Every time this update is calculated, the changes are packed into a network packet and sent to the other players. The player's game calculates so-called interpolations of these changes locally (as explained this is needed because you will probably run at a higher FPS than the server).
To say that this is a source-only concept is completely wrong: every FPS (and most other games) has a certain tickrate at which they calculate and send updates. The difference is in how the engine deals with these different tickrates and how well it is capable of performing the interpolations required. Generally speaking it is true that a higher tickrate is better for the gameplay experience: more updates are calculated and so you have more accurate information about where everybody is and what they are doing. However, as explained before me in this thread, the engine should be able to handle this high tickrate (the commandrate vs servertickrate example for instance). If these settings are not optimal, bad things will happen. This is why valve chose for fixed tickrates and other default parameters because they found that those values worked best in every aspect (gameplay, server load, network traffic, ...).
So to sum up: yes, higher tickrates are in concept better for gameplay. But no, this will not be the case in any engine or implementation. And it is my opinion that a tickrate of 66 is enough for an FPS. It's just what you are used to. Even if you play on a 33 tickrate all the time, you'll get used to the feel of it and subconsciously adjust your playstyle to it. Suddenly switching to 100 tickrate is not miraculously going to improve your performance.
Seriously, TF2 has become something stupid. It was silly before which was fun, but now things are getting stupid. Items, hats...it's becoming FPS-WoW.
Don't go that route UW. don't or you will lose loyal players, and gain stupid children distracted by shiny objects.