wrote:

wrote:

I must be blind but timenudge, maxpackets and the rest of such settings arent mentioned nohow nowhere in rules. link please to prove the opposite.

ohh, really? why then elitez says different?

It could be taken out of the event rules, in the most of it, there are -

* cl_timenudge: 0

* Rate: 25000

* Snaps between 30 and 125

* cl_maxpackets between 60 and 125

Moreover, such values of timenudge and snaps are forced directly by pbsv on some clanservers. About why, thats a question to server owners and event managers, neither to rank mods, I think. But like you always say me - it is their free will:)

As far as we got that such cvars arent mentioned nohow in the rank, I can try to explain ontopic about the values.

I came to beer and checked settings.

That happens if I set my rate to "1"

It gets almost such bad if I try to set my snaps to "1"

Cl_maxpackets "1" causing even sadly things (take in mind it automaticly goes to "15" not the "30" as you told us in your first post, so at least one sourse is wrong )

After all, that is my normal ping without any losses using values forced by eventmanagers. Taking in mind there are players absolutly having no clue about cvars and people love pissing the rest with their lags, forcing such cvars to playable values are understandable.

First of all, I am sorry that I didn't take myself the time to work out that stuff way ago, being lazybish for too long, but now that there is the discussion

wrote:

After some arguing on elitez server, i got asked by the owner of the server to convince ppl that cl_timenudge does not make ppl lag or make them hard to hit, because as they claims they follow ranking rules, and in ranking its written that cl_timenudge must be 0 since it makes ppl difficult to hit.

Aside timenudge i want to talk about other mandatory settings that are actually sucked out of finger from very common reason "lets blame ppl settings when i do play bad"

As Mentioned, its Event rules, not rank. Rank skipped those forcement for exactly the reason you say.

wrote:

SNAPS - 40-125 - snaps are prohibited to be 40-125, while the servers working at SV_FPS 30 !

True dat, but remember some servers had higher values then 30 in past. We tested all the stuff out and higher values had quite nice accurate gameplay while people hated it.

wrote:

MAXPACKETS - 60-125 -

Quote:

cl_maxpackets30(1.9kb/s), 40(2.3kb/s), 58(3.2kb/s), 111(4.5kb/s), 125(9kb/s)
how it works? 58 cause max 3.2kb/s trafic and if u set it to 59 it will take 4.5kb/s of badwitch
its measured on keiro personal firewall

That measurement is true and done by a nerd. The basic rule is 125/X will result in a fps related maxpackets way, so 42/63/125. Those are 2 different views of how to do the problem. However its also been tested on 42 you get more %lag then on 63 - since any connection can handle 63 its the base for most, but measured you are rite.

wrote:

CL_TIMENUDGE - 0 - why? [...] and if u will set timenudge to -30 yours client will stop applying interpolation and yours targets going to move with unsmooth movement and their on screen position going to be more correct to the position on the server. Since server predict players movement and client predict client movement, the information about players positions are off, especially when players do lag...

Server just does not predict, it calculates if your position is true. Actually server calculates the incoming maxpackets (60-125) down to 30 snaps that you receive. Client renders those snaps to 125fps movement again. Since you recieve 30 snaps, difference between incoming data is 33 msec. Quake3 trys to get max smoothness for players, if it does display only what it has or interpolates ahead already, i don't know. Logically best smooth netcode would be one that interpolates exactly 1 frame behind same time incoming snapshot, since it would display server view most exact without lag. But heh, I am not a coder.

wrote:

cl_timenudge is not responsible for sending any packets and can't make ppl lag, its a client side snaps prediction change!!!

true

False thing in the docu, it drastically changes the way you see them.

wrote:

It's client sided only. All what it does is to inter- or extrapolate the movement of all other players. With negative values you adjust client side prediction.

To state such exact things we should learn coding and find the real thing out.
Because there is a difference between prediction because of lack of data and prediction because of extra set interpolation.

wrote:

e+ is the only mod on the world where timenudge is not allowed {fact} all turnaments in what i have played on clanbase or esl allow for timenudge

Yes but they don't have as good unlagged as E+ has. Unfortunately devs didn't improve further.

wrote:

let me ask at the end a questions, what a idiots have set those limits for this settings? they cant read the e+ readme or a mod forum faq?

Imo here I can help you a bit, took 2-3 min to search
http://www.excessiveplus.net/forums/thread/tdm-league-2009-15
http://www.excessiveplus.net/forums/thread/e-tdm-league-20078
Remember it was introduced because Settings were different on each damnit Server? Mostly it was taken over to just get stable settings everywhere.

wrote:

And excuse me for be harsh on the server but when i see so much bullshit around, then its definitely needs some hot debate, and rethinking of some rules, since they are bad they for sure need a correction.

The rules are the minor problem, the lacking development of the mod is rather a problem. We hadn't a single only bugfix update since 1.02b. And most updates just increased fancyness on cost of fps/bugs.

Its pretty easy, to small snaps value causes 'desync' on your own client. Since Checks for correct status of yourself are made on client and server it can cause the increase of basiclag. Tyrant played accidently with snaps 10 in past and he was laggy.

wrote:

Skull was a ranking mod, but he took his job seriously and caught many cheaters besides just clicking buttons on ranking page, and cheaters are important thing in ranking, you know. Entire ranking is useless if cheaters participate in it.

signed/Decision about swc fait still has to be done since what, 2 months? I can't do the job my life long and I don't since quite some time.

wrote:

If anyone have any proves about that cl_maxpackets 58 or cl_timenudge cause players to jitter lag or whatever please GIVE proves for existence of such things, because according to the quite solid fact that i have summed up in this topic this is only human paranoia about other player that getting unfair advantage because of bad settings.

if you also mean unfair advantage because of optimized settings (recognise, positive timenudge is imo not forbidden) for whatever, here you go (but before you read, be aware that this is all theoretically true, not practically):
-Low Snaps causes people to lag.
-Low Maxpackets causes people to lag.
-Low Rate causes people to lag (anyone has technical explanation about the exact difference to snaps and maxpackets?)
-Snaps affects yourself and others
-maxpackets affect how you are seen for others and causes a 66msec delay for each your actions on server.
-low rate causes Lags when there is to much information to be send, since it limits those. 1on1 works with 5000, 7v7 needs 25k or more. Basically it does not lag how people see you on server, or at least you get way more bad effects cause of it then enemy.

So how does timenudge fill in that? as mentioned, its totally clientside (oh wait, xerp is that too and it caused a split upon some peeps in cpm) and therefor, as fala said does not cause you to be bad hitable or laggy at all.
Leaves the question if the basic function of timenudge is fair or unfair (you know my answer already).
In OSP for example, timenudge was commonly used to decrease effects of netcode and ping. Nudge was 1/3 of your ping if possible. Since everything was behind anyways timenudge gave everyone better gameplay and therefor it was fair. Ofc lowpingers had most of it since it enabled lan like hitscan gameplay. The side effects were irrelevant compared to the upsides.
Now what counts for E+? In E+ we got a total different situation due to unlagged.
Hitscan gameplay is been possible by default. If someone sets negative timenudge to get more lan alike gameplay, he also forces everyone else to indirectly use timenudge and therefor forces every player he faces to use negative timenudge.
Ergo he forces his enemy to set laggy players for time/ping reasons because of timenudge.
This is the passive effect of timenudge, so whats the active?
Basically every Player has his ping as disadvantage, since any Incoming enemy is seen by ur own ping late. with 30 msec you see someone come around a corner, with timenudge -30 you theoretically see him like ping zero. Someone with a ping of 40 or higher still has the disadvantage even on negative timenudge of -30, no matter what he can't remove that limit. Means he will have a major disadvantage in any situation against someone with ping 30 and negative timenudge.
Now lets make that even cooler, what about people with a ping of 20 for example? when they use timenudge -30, their ping goes zero on scoreboard, but does it effectively draw players ahead of their server position? In that case, these players would ALWAYS camp because it reduces their reactions by 10 msec, for a 130 msec professional causes 120msec insane reactions. You might compare it to wh shooting rythm.
How does Unlagged even calculate all that? if it calculates ping in scoreboard setting negative timenudge below ur ping would cause a player to not have unlagged feeling. However he would have to shoot behind a player to hit him (which is easier then to predict ahead). Ultimate advantage
If Unlagged calculates real ping its also Ultimate advantage.
If Unlagged calculates real ping together with timenudge setting, the player still has the Ultimate advantage.

So no matter how you twist it, players with a ping of 30 or less got way more advantage on unlagged by timenudge then any player with highping.

This is one major reason to prohibit timenudge. If you ever played a person with -30 timenudge, you will wonder how odd fast they react upon incoming players.
Which leads to our next small reason, Its easier to say if someone Wallhacks or not if timenudge is enforced to 0, since you can read nearly real view out of a demo. You should know that one already fala.

Now last reason I already imaginary drawn elsewhere in a small post:
When you set timenudge to -30, it draws a player 30 msec ahead of his known position.
Now no matter what ping, think about this:
there is a wall on place 350/0/0 (x/y/z).
A player stands on the point -8/0/0 (if i am right, hitbox 16 units large), using fragbox model (so model = hitbox).
If he runs for 1 second to the right and stops exactly, he should be unit exact behind the wall.
A player using -30 timenudge however will see his arm for exactly 30 msec, because the player is drawn ahead and therefor you see what is not there.
You can basically code a hack out of that, if a player runs simple directions, draw it ahead for like, 100msec? It would give you 100msec reaction advantage together with zero Wallhack moments, since you still have to hear the enemys.

I can already hear you guys saying 30 msec aint much, but the difference between 30 and 60msec ingame is already giantic. It is so huge, that anything above 40 was unplayable in osp without timenudge. Same goes for quakelive, without its unplayable because you cant hit shit. Even the difference between 160msec and 130msec reactions are giantic.

So want a legit hack? Timenudge is one of those together with subdivisions.

ps: Here a fast drawing about the mess:
[URL=http://imageshack.us/photo/my-images/194/timenudge.png/][/URL

wrote:

wrote:

sorry man, most of the things u say about timenudge is not true :} since timenudge does not draw targets sooner at all, it just removes the prediction applied by yours client, and this means all what u have said is not valid. When u receive snaps u get the exact position of the target, before u receive new snapshot u can aim only what yours client predict, and if a player during that time changes his position, or stop the move, u will miss the shot. It does not draw information sooner on yours client at all, it applies less prediction client side!

Source? Because logically and experienced based I can only tell you your quake draws the predicted way between 2 snapsshots after the newest snapshot arrived. Means all actions are behind Server time, nothing is drawn ahead as you mention. Timenudge 0 means Snapshot 0 is drawn exactly when snapshot 1 arrives, because that moment the path is clear. Coder pls clear it up (nevertheless imagine a player having his ping jump my 30 msec anytime, you will see him lag, ur so called "predicted" enemys don't lag).
Further note, why timenudge "lowers ping" in scoreboard when it effectively just gives Linear output according to your argumentation? Delay should keep 30ms for a player then.

wrote:

(please don't tell me that u didn't knew how the corner decoy technic work)

Technically there is no explanation, because on lan its linear. It effectively works by letting urself seen less time then enemy needs to react, means he will miss because he doesn't react fast enough. It has nothing to do with netcode. (and by timing you can totally get those guys).
Anyways lets not bring in gameplay stuff, because then we both discuss endlessly fala.

wrote:

Also i am quite sure that i already disused with easy about unlagged and he have wrote server predicts clients movement. U can search the forum for the post if u want ;}

We all know the easy way of coding... Eh and beast changed unlagged code after 1.04

wrote:

For now i have talked about minimal settings, without even touching syncing packets to the frame rate of server or client. Id like to believe that having very high value of snaps "999" will reduce the prediction applied even more, very small of difference but still, since the snapshot will be drawn as soon it will arrive on yours client u will going to have more correct position of it. If i am right? Dunno if ppl thinks this helps against prediction errors then why not trying? Also u could say syncing it to the frame rate or servers snaps can give benefits, but hmm those data is send over internet and delayed also the ping times from packet to packet also vary and makes the data unsynced in their very roots. So i think there is no possibility of syncing that to the server, but if u like to think that syncing it to client fps givies any benefits if its not the client that interpretates this then idk but something is generally wrong about that idea of syncing it after all ;P

basically you dont sync with the server, you sync with your fps. Having maxpackets 63 means your command gets send to server in 16msec timestamps.

wrote:

btw. pro mspaint skills xD

ty, you know, I can do that better then shady :3

wrote:

I have't say that it draws snapshot sooner, U did... That's why i have say u are wrong about Client simply can't draw a snapshot before it arrive to it ! all that what u have say about timenudge makes no logic, u can't enforce recieving snaps sooner and know the location of the target before snaps arrive! basta !

Maybe you misunderstood my post, if you put timenudge to -30, it predicts the position where the enemy gotta be in 30 msec based upon the last both snapshots and their info of the player direction.