cool

omfg!!!!

the link for the ezquake test build doesnt work tho

Added mirror.

Very interesting concept. Does this basically mean that all instant hit weapons would work like with 12ms regardless of actual ping?

"Real" 12ms is worse than this feature enabled, regardless of the ping.

So you can get shot after you duck behind a wall, because your lagged opponent still sees you?

sounds like that, but sassa will work against this

the serverside of this feature is what would be needed to make maxpayne like stuff in the client

xerpxerpxerp

more like xerp-a-derp

sounds like it would lead to stuff like Kalma said. also it would be quite irritating to have a lagfree shotgun but a lagged rl for instance.

i like qw's honesty about your connection, if your connection is bad you're gonna lag. we all are used to this by now. all attempts to improve lag with software tricks never really worked, look at the mess hl2/tf2 is in that regard.

creepy, very creepy : O

this works! this is perfect to remove the major difference ms makes in tournament games. implement on all servers and make a new stable ezQ asap!

I'd like to know whether it's significantly easier to hit lg on 12ms with antilag on.

If it is, this is probably bad. If not, we should support it and I will get raped up and down every server all day long. Hurray.

Could anyone with 12ms to intarweb or qw.fi check it out for a while and report back?

Stev, me and maga (both pov enthusiasts tried it out on 12ms and I have to say that I am not even sure if I noticed any difference at all.

God fucking damn it. I guess I'll support it then. :/

Rikoll +1

bulat good with antilag

bulat kill all

But.. What can noobs blame without a ping-difference?

I'd like someone to reply on #7 Kalma's comment...

#22 answer is yes

Doesn't this open up for cheats that changes the packages sent?

I think client prediction interpolation and whatever is fine. But this i dont think is a good idea.

I think Kalma's point makes this feature unusable for serious play. I guess it can be generalized for fast evasive movement that becomes not so fast because of the lag, etc? Either way pings would still have to be fair for real games for rockets, movement etc.

http://bigfoot.morphos-team.net/test/ezaimbot.mvd

Oh look, it's possible to cheat. No one would have guessed that. What an amazing and constructive post! Your open-mindedness towards the qw-dev projects is a constant source of constructive criticism!

Dear Stev,

I long ago learned that trying to be constructive with these guys is entirely futile.

What I don't find constructive is building an aimbot like no aimbot was ever possible before directly into the server. I can even shoot through walls now! What's even better is that it requires no modifications whatsoever, all you have to do is make an aimbot bind. Works in any client.

Nothing wrong with my open-mindedness, but some people apparently just can't handle the obvious truth being pointed out. Shoot the messenger. Business as usual.

It's an alpha build. File a bug report.

ah, bigfool, again with his irrelevant posts - "look at me look at me I can break it!", *yawn*

Need more proof than the above, Stev?

you sure got those ezcrap guys, breaking an experimental feature, high five josti

You got to be kidding me.

Qqshka's aimbot - built in the ezQuake (cl_aimbot 1 (OMG?!?)) could hit me 100% at 170ms with this feature enabled even if I tried maximally to dodge it.

Therefore, this feature is total horseshit, developing qw is a waste of time and we should IMMEDIATELY svn del mvdsv (and ezQuake) and svn commit -m "this is the end, bye".

In my experience the qw-dev crew have always tried to churn out useful features, and game-changing things have always been toggleable or removed outright if proven too controversial or impractical. In any case, polite feedback is always more effective than hate-speech.

I often wonder why you don't just set aside your differences, largepod, and work with the qw-dev crew instead of developing a rival client. Surely they can't be that irreconcilable?

Dear Stev,

I'm sorry that I have to ask this, but are you blind? I don't mean this in any offensive way, but did you read any of the posts preceding yours?

I see what looks like a group of people who constantly shout at each other and then wonder why the other side shouts back, but I'm sure there's more to it than that and I don't want to hijack the thread anymore.

surely the point about 'experimental' features is to prove how they are flawed.
if its experimental, why are you claiming bigfoot's post is irrelevent?

Renzo, qqshka's cl_aimbot, while clearly a cheat, cannot hit through walls, and requires client modifications.
This new aimbot could work in any client, and shoot through walls, anywhere on the map, instantly, regardless of speed and lag.
So yeah, the fact that it can shoot through anything and still hit them makes it a much better aimbot than one that gives 100% accuracy.
I'm sure the accuracy could be improved with better binds or actually modifying the client, the later would give 100% accuracy through whatever walls, without changing your movement direction, without having to spam a bind, even with 500ms ping and an enemy running faster than a bunny on steroids with added rocket boosters.

But hey, experimental features and all that... I'm allowed to give feedback, right?

In my personal opinion this is what the crowd has been asking for a long time now. Whether youre from southern europe, or even from the yanks, you can still give somewhat competition with this setup, i can only imagine what for example pericles can do with this feature. And as far as i can reply to Kalmas #7 comment: no, this really isnt possible, since it requires both server and clientside adjustment to make it happen, so basically, if someone sets it up serverwise, it shouldnt be such of a problem to everyone in the server to type in ./cl_antilag 1, so no, you cant shoot the opponent behind the wall and gain advantage from his lag, if the setting is the same fr all the players in the server.

So...
in the past bigfoot tried to (politely) show you guys how dumb it was to simply ask the client if he was cheating and unless he said "yes I am", he was clean. At that time, 99% of you were screaming at him, calling him this and that, and the whole time he was just taking it, being a bigger person and answering you back politely, displaying all kinds of proofs you requested.

He tried to help, many times he has offered his help. He seemed to be way ahead of you on the "anti-cheat" field and yet you guys do not listen to his advices. Only when you have pissed him enough you decide to ask for help...

It is time to grow up guys. Accept that you were wrong, hear what he has to say and please, please DON'T TRY TO MAKE ANOTHER "security" dll that simply asks the client if he is cheating feel safe when it answers: "hum.... no..."

Look, I'm really thankful for all the work you did with Kombat Teams. In the matter of fact, I'm really thankful to the whole Euro quake scene that will not let the best game ever created die. But please, don't fall into the Human Race description on the Hitchhiker's Guide To the Galaxy. We are able to learn from other people mistakes. Use that gift wisely

@ Spike

Yeah, I know how bad the feature can be if the client always sends info "enemy under crosshair" to the server. There are a lot of things I don't like about this feature currently, and all of them has to be addressed somehow. Also there are some known bugs too that should be fixed.

A lot of people have obviously missed the few very last lines of the news item. Perhaps time to check what it actually says, then do something and uh, maybe some things will improve.

if this really works, it can be the best thing it can happen in modern qw.

i've been playing some quakelive, it has better netcode than qw, no doubt. i can hit what i see with 70ms

In my view clientside hit detection (by detection, I'm talking basing it on client viewpoint, even if it is 'secure') is inherently bad at least some of the time. Basically it means you can get shot through walls, at least in implementations I've seen more.

I'm sure there are some circumstances where it works OK. Stuff like playing povdmm4, sure, I can see the benefit there. But what about when you are playing 4on4 and bunnyhopping away from some guy with boomstick. You think you are safe and have escaped round the corner, but no, SPLAT, because one of the guys on the server was from another continent, effectively you've been left behind.

Another point to consider:



Could cause some interesting scenarios some guy has picked up an item that is out of sight, but he gets killed because you shot him. So you think you prevented him from getting that item (because you killed him), yet actually you didn't. An elite bit of boomsticking on your part you think, I got the bastard before he could grab that RL. But it's gone!

Then how about the knockback affect? You could get some pretty weird shit going on presumably, where you get pushed in a situation where it isn't expected.

Wonder if there is any capability for potential exploits using cl_delaypacket or similar too, it's one of those situations where most of the time you'd probably fail to gain any advantage but it still raises some questionmarks for me.

Just specced some pov, it's weird, cos it looks like the enemy shaft is missing you and yet your health is going down lol Guess we'll need clientside sg/ssg pellets back too.

Edited by HangTime on 29 Oct 09 @ 01:47CET

Dear Renzo,

Who besides you and qqshka failed to read the last two sentences? I don't see anyone else.

Also the reactions are very, uhm, interesting. I wonder what would happen if I also commented on the technical aspects of this, rather than just the practical problems. Got those torches and pitchforks ready?

Bigfoot: So long as your comments are factual I do not see how any one can fault it, unless another individual can dispute your facts with evidence. However, it is then how those facts become interpretted/dealt with, that is where the drama seems to arise. But we all want a better and more accessible game, so I hope every one can pull their resources and work together as one reasonable individual to another.

Peace

nice feature

//Offtop. I was always wonder how online-games runs so smooth on PS3 and you don't care about servers/pings/qizmos/etc (you just can't see this stuff in games). Seems that we can get same in QW.
qqshka > PS3 team

If what Hangtime just said is true and happens then I don't think this is a good thing. It would be awesome if mushi was able to play on equal terms with north Europe, but if it's flawed let's not use it. I haven't tried it, but it sounds a bit like the impossible been made possible which isn't possible

How good pings could ppl in lets say Portugal, Eastern US/Canada and middle/far east Russia get to servers in Denmark, Holland and Germany if they had better connections and routing? Perhaps they have to wait for this instead of implementing this feature and change our game even more

I agree with kwibus

Instead of talk, go play the feature enabled and stop guessing. When and IF something happens, report it, like it says in the news post. Hell, try to break it/make it do unwanted things whatever you might think of, and if you accually succeed, that would be the best, just don't forget to tell us about it.


It's more like a rule now with new features. People X say this and people Y say the opposite, but noone actually tests the feature to see if it even affects things like suggested.

Someone up server with this feature in Australia please, i want to crush reload

If I got it right, I don't think the pickup of items is changed anyhow.

That's nolimit baby :E

It sounds like this is based on the client telling the server whether or not it hit? Which I don't think is a very good idea. If it were more Q3/HL style where I believe it takes into account client latency and says 'was there a target there x ms/frames ago?' then I'd be more keen.

Hahaha, the long awaited drama!

Maybe server could check that target is in line of sight in "server reality" to prevent round the corner shots? This way anything impossible doesn't become possible? :I

Ok surely works, tested vs 12ms blAze on quakeworld.fi:
Results:
51ms, antilag OFF --> 29% LG fakeshaft OFF (20-27)
51ms, antilag ON --> 37,5% LG fakeshaft OFF (21-25)
51ms, antilag ON --> 40,5% LG fakeshaft 70% (24-23)

Yesterday's news, as much as the highest possible difference/distance between real position and client reported position, among few other things.

Regaring cheats and "bugs":
1) You can always cheat, so I don't care (almost).

That similar to wiked bigfoot's logic about security.dll "security.dll may be haxed, so get rid of it", great logic, why humans use locks if not even best in the worl thief can pick a lock. bigfoot, do you use locks? Since you should not, there I chance what it may be haxed! Locks gives some BASIC security, it gives HOPE, and NOT 100% protection, same with dll, but he just can't get it, its not a binary world where only 0 (unprotected) or 1 (invincible) but rather real world there exist 0.1 (some resistance) too.

2) Regaring particular feature and cheats.

Aintilag feature gives you(normal player) same acuracy with hits regarding of the ping,
so aimbot accuracy with such feature does not suffer from ping too. But its all obvious things, or you expected what feature which allow normal skilled players to get 50% lg with ping 100ms does not allow aimbot to get 100% lg?
I hope you don't expected it...

People does not like what there client send some data to the server. OK, say I did something on the server what make hit detection more accurate (WITHOUT client help) with high ping, but NORMAL aimbot became more accurate too, quite obvious.

So, basic idea is what it does not matter how you did it, you can still cheat anyway,
and at ping 12ms aimbot with or without antilag gives SAME accuracy.

Regarding shooting through walls, funny, Spike, you REALLY think I can't imagine that without bigfoot's demo? Such possibility directly follows from Kalma's "duck behind a wall" notice, but I realise it even before implemented in code, well, I read some docs at http://developer.valvesoftware.com and how they did it, some nice articles,
obviously articles explains drawbacks(Kalama's note for example), so bigfoot with his uber cool aimbot is laughtable and irrelevant, as usual thought. And now I need spend my time energy and emotions just to explain OBVIOUS things, to whom?

Ah, and "shooting through walls" as well as "duck behind a wall" may be fixed like Kalma suggest in #56. I am not fixed it yet because: lazy, need proove of conception and general community acceptance. If acceptance is just in fixing "duck behind a wall" then I can do it.
Also, funny, ONLY Kalma suggest way it may be fixed, not our polite and smart dear bigfoot, he rather spend time on writing pointless aimbot which prove nothing.

Well, main idea in that pathetic post: "duck behind a wall" fixable.
Ah, and bigfoot is baaaaad

Duck behind wall is fixable, agreed. What about delayed knockback etc?

Improving hit-scan weapons beyond 12ms is changing balance of game

but how can this work 'check server reality if target is in sight'? this whole feature is about 'client reality' you're supposed to hit what *you* see, not what happens on server side, right?
this seems to be a principal problem not something easily fixable?

at least i have my doubts, because like i said in hl2 and teamfortress 2 multiplayer this whole prediction/lagfree stuff is one big mess with different hitboxes and whatnot. it sucks. compared to qw i hate how inaccurate and deceiving the tf2 way of doing things is.

The main problem here is the speed of light. It's too slow. Even if someone created a 100% efficient network, with 100% optimal routing, using a straight line, it would still be physically impossible for Americans to be pinging 26ms or better in Denmark because it's just so damned far away.

'bug'-report: the lg beam doesn't come from out of your player model anymore but from some point besides the player model. or it looks like this from the opponents view.

OT: Speed of light is not a restriction. It manages to travel around the globe a few times in a millisecond im sure. Delay in routers and repeaters is what is causing the problem and these are being improved.

lol?
So its fine for other people to explain the obvious to you, but not for you to explain the obvious to people who have never even looked at the netcode?
Mmkay.
Quoting from http://developer.valvesoftware.com
Doing the back tracking of player positions and dealing with precision errors while hit detection could be done client-side way easier and with pixel precision. The client would just tell the server with a "hit" message what player has been hit and where. We can't allow that simply because a game server can't trust the clients on such important decisions.

So you make it use origins instead of sending who's in the crosshair at the time (Actually, DP does this - part of DP_PRYDONCURSOR is that it says the ent number that is in the crosshair - I'm not quite sure how well that works with shotguns, of course, but I digress)...
After all, origins can't be faked, right?
What is obvious to me is obviously not obvious to others. But then I guess I'm wasting my time and energy explaining this.

If bigfoot had simply said 'really easy to exploit' instead of posting a demo proving it, he'd have just gotten flamed and laughed at till he proved it (security module discussions would serve as evidence for this). But noone hinted at doubts towards aimbots until post #24. Which kinda goes to show, its not always 'OBVIOUS' to someone who has never looked at net code.

dont mind my calculation error. It is a factor i realised.

Just i did the math, think its 133ms around the world one time

Few things I noticed while testing this feature vs Meshuggah in povdmm4:

1. Shafting with high ping (90-150) is actually easier compared to shafting with low ping due to the fact that the enemys bolt model isn't straightly in your face all the time and rather looks like it doesn't hit you at all.
2. Because of the point 1 it's nearly impossible to know wheter the enemys LG is actually hitting you or not. Your health and armor just seem to disappear randomly. This critically affects the possibility to dodge it.
3. Playing against high ping player with lower ping causes irritating kickbacking which also seems random because of the observation 2.
4. The feature trashes the skill earned by years of honest training about knowing how to use the LG and other hitscan weapons with different pings. Personally I dislike this.

I also agree Willgurht with making shafting easier beyond 12ms as a bad thing.

And please don't take me as one of those people against every new feature regardless of the effects. I really love ezQuake and KTX and have great respect for the developers for basically keeping this game alive for so many years. I like many of the new features. cl_earlypackets for example.

@Spike

"After all, origins can't be faked, right?" Is it sarcasm or rhetoric practice? If so then I am not person who can help you with that, I simpy have not time and will for that, try talk seriously and without double meaning or I am not reply since it take too much time to understand and reply in similar maner, sorry.

About "OBVIOUS" part, most parts of my post can be understanded even by non developer, and some parts which I explain particulary to you actually should be obvious for you, so why you take my time? That annoying.

"If bigfoot had simply said 'really easy to exploit' instead of posting a demo proving it"
Oh cmon, like I don't (or did't) know it can't be exploited, or bigfoot proves evering with demos? Personaly I will belive him if he tell me he can abuse it, but no, better write some bot and made demo and then billion posts about it about him and hit greatness and how he fight for truth plus this fans talking about this polite (laught my ass, really) and other offtopic shit.

"But noone hinted at doubts towards aimbots until post #24."
Noone? Its first what come in your head, but I answered ALL what I tink regarding cheats in my previous post, also, from Kalama's post you can guess everying about how this feature may be abused, its #7, actualy you can guess it just from decription how this feature works, but yeah, for non developers its kinda hard, probably. But nothing I want to add to it, just read my previous post.

Have you something what can help me or qw, if you have better solution(and even better you can code it...), I whould be glad to forget about how to code (like i know) and wear t-shirt labeled "Spike rulz! I can do irl shit now! k, thx!", since atm guys, you does not help, instead we wasting time.

I love you QQ, nice job!!

@ #55 tonic: yepps, this is what I have been waiting for

Willgurht did you count in the fact that the signal is not travelling in a vacuum, but in fiber optics that also slows down the speed of light.

The only question most people care about is "Can this feature be made suitable for competitive play"? Security is a distant secondary concern, surely.

@qq, if you read the valve devs page, you would surely come to the conclusion that thier input packets contain an interpolated echo of the server's time (which I might add helps protect against speedcheats), and using that it can look up the entity posisitions that it last told the client. There's no real way to move other clients around with that. And if the weapon traces are properly synced to player movement (ie: weapon shots happen before movement to compensate for monitor latency) then you get fully reliable origins without depending upon anything the client says other than time - which you already depend upon anyway. Plus, you can clamp the time more easily, measure pings more easily and more easily detect speed cheats (based on which packet they're acknowledging etc, while you can't outright ban them, you can ignore the catchup bursts a bit).
I would have thought the above was reasonably obvious.
The only two differences that I can see between halflife/counterstrike and quakeworld are 1) that other players are predicted in quakeworld, which essentually just means that a qw server that implements this would have to track velocities too.
And 2) qw clients don't traditionally echo the server time, only an input packet duration, which means that you'd likely still need one value sent client->server, but at least its one that can be easily bounded, and with that, you can enforce bounds upon cmd msecs too. Strictly speaking, when you have 72 packets per second, there's less of a need to do this, so if its not present you can probably anti-lag well enough anyway (fuhquake etc users will thank you for that).

Additionally, if you place the lag compensation code inside SV_Move then you can compensate for lag upon rockets and other projectiles too.
However, that really does bring in to question the whole issue with dodging.
Heh, I wonder how sane it would be to add/remove extra lag on rockets/nails based on the firer's latency in relation to your own. Grenades would be more awkward, but should still be possible.

Regarding being behind a corner when you get hit, I think the problem with that is overrated. Its not going to happen that often, at least if you're running away... and if you're not running away, the people with low ping would experience the same issues as the person with a high ping. Just the oposite direction. Its fair, but its different.

Regarding dodging lightning gun beams... Yeah, I really have no idea how to make that 'fair'. I'd say split the lag difference 50/50 as that's fair... but you'd have to aim at different locations for different clients... and that's even worse than lagged!
I suppose it might be possible to rotate the angle of the beam based on the new locations of the targetted player, but then you have to guess who they're targetting. Could just assume the player its sent to, as other players getting hit really doesn't matter nearly as much.

But yeah, any skills previously learned regarding the compensation of lag (can no doubt change scoreboards lots) would be effectively useless with this stuff. And yeah, best to minimise the undesired side effects. Heh, could enforce a fixed amount of lag so those skills arn't entirely lost, just more consistant.

But then you wouldn't be able to make an 'aimbot' with a single bind command.

@Willgurt
Electrical signals travel at about 2/3s the speed of light. For intercontinental routes, its not uncommon for packets to enter orbit and bounce off satelites. Data cables generally do not travel in straight lines. But usually, a significant amount is added within the 10 miles or so to your home. Or something like that.
If you've got a cable connection... blame your neighbours.
If you're near france, blame french internet. Sorry... but gah. IPTV. NOT GOOD!

Dear qqshka,

Could you please try not to fail logic so spectacularly in the very same post as you complain about other people's logic? I'm still trying to pick myself up from the floor from a hysterical laughing fit. Thank you.

It's obvious that you're still not getting it about the obscurity module. Even though it's off-topic, I'll recap it here. I know that if you reply, which you likely won't, you'll just take out one thing, say something irrelevant about it and ignore the rest. Anyway, here goes:
1) It's 'security' through obscurity. As security history has taught us again and again, security through obscurity does not work.
2) Connected to 1, it's fundamentally flawed. It's like basing a justice system on asking the suspect if he's guilty or not.
3) It's a client lock-in. This is actually personally my biggest problem with it, but as per above, you'll now say 'just buy a new computer, install Windows and use Ezquake' and then you think you handled the whole thing well.
4) The actual implementation that you all trusted in and worshipped didn't work. No, I don't mean in the theoretical sense. I mean in the practical sense. It didn't work. I don't even mean the fact that it never prevented any cheats in the first place. It literally didn't fucking work. You could change your Ezquake executable and it would go completely unnoticed. Good fucking job. Besides that there were so many bugs in it that if code bugs were a source of energy, it would keep the world lit for at least a thousand years. Oh, and did I mention that it breached the GPL, the license that made Ezquake possible in the first place?

And now, to your logic: You compare using an obscurity module to locking the door to your home. You say that since there's someone who can break in anyway, as you mention by picking the lock, or more effectively, just knocking the door/wall in, there's no need to lock the door... If you compare it to the obscurity module.

So here are is difference:
When someone picks a lock in real life, or knocks down the door, it does not mean that all doors in the world are picked and/or knocked down. When one person spends 20 minutes (15 if not slowed down by WINE) and does the obvious thing to the obscurity module, then all copies of the obscurity module in the world are broken. Do you understand this important difference? Also, as you mention, locks give basic security... The obscurity module didn't

Oh, and just for the fun of it... When I lived in Montreal, I actually DIDN'T lock my door unless I would be away for a long time

Next point... Again you miss it. The point, that is. The point is not that aimbots could now be made better. The point is that you have no built an aimbot into every single QW client there is. All you have to do is bind the right command. The aimbot wasn't there before. Whether by ignorance or malice, I do not know, but you created it.

... and about wasting time. You're currently wasting my time. You're wasting Spike's time. You're wasting a lot of people's time. And it sure as fucking hell isn't the first time. And you know what? You don't give a flying fuck. If you're slightly inconvenienced by a few people pointing out the obvious flaws, then you know what? I don't think anyone gives a flying fuck about that either.

And about things being obvious... Well, apparently the obvious even escapes you.

The original post calls out for reporting anomalies. I did that. With the expected result. Shoot the messenger. And then Renzo complaining that noone tries it and reports any problems. Go figure, huh?

So yes, maybe you should concentrate more about the problems than who reports them. People have reported PLENTY of problems, theoretical and practical. A few people have come up with some, again, very obvious improvements. The only thing that has been responded so far is 'bigfool is a moron'.

OK, next up... You say I wrote a bot and made a demo of it. No, qqshka, again, YOU wrote the bot. I did make a demo of it, though, that's correct.

And lastly I'd like to take you up on the offer. Of course I know you've got no intention whatsoever of honouring it. Too bad, could have saved the rest of us a lot of time

I didn't complain in any way, I just urged people to go test it and see if it really makes the feature do those things everyone is bringing up. So far I've seen few reports of the feature working, a lot of opinions (obviously without any real-world testing (except few people I know tested it)) and then even more bla bla bla bla.

The best part of the evening seems to be this:

...and later I read the comments here and find out:

Well...

... and later you read the comments here and completely ignore the lengthy post Spike wrote detailing out the painfully obvious in a way that hopefully even qqshka can understand?

Yeah, that's you, Renzo.

#62

I was fairly sure they cant get 26ms or better but perhaps around 50-70ms atleast? I was just wondering how good the connections could be under ideal circumstances

#77
ideal connection would be a server in the core of the earth with packets delayed only by the speed of light
Which would be ~11ms one way. so maybe 23ms ping.

If you keep the cables above ground, the physical limitation would be 33ms one-way a quarter around the globe. 67ms ping time maybe.

ok, that isnt so bad

maybe players like bulat and squeeze can really rule the european quakeworld soon then

BULAT BEST AIM WORLD etc

I never ignored spike in any way. Unlike you, he is reasonable, so the only person I'm ignoring is basically you.

Your doing things is flaming other (qw-related) projects without the slightest bit of constructiveness, like seen here: There's a new feature, and what do you do? You IMMEDIATELY find an abuse point and then wait for the flaming to start. And this is not the first time, is it?

Yeah, that's you, bigfoot.

I dont know how you will take this after reading all the arguments and stuff.
Since this is not that constructive, but here it goes:

Don't go down this road, Ive seen this before several times with this exact same feature.

Light in an optical fiber travels at 200001000.6 m/s
New York to Sweden distance is around 6338000 m
Therefore time it takes for the data to travel one way is 0.0316898415 s = 31.7ms

Someone said earlier that ping should be double the one way delay, therefore 63.4ms...

Of course if someone invented a cable which had light travelling within a vacuum then this could be reduced to ~41ms... and it doesn't take into account data conversion at routers and such, or that the cables aren't in straight lines, or that the light bounces around inside the optical fiber.

I'd like to see a demo of someone bunnying around the bridge -> YA corner on DM3, and somebody lagged standing near the corner and shafting them just before they go out of sight - to see which bit of high-YA they get pushed up towards/onto. Should be a bit further around the corner which would obv be impossible on low pings. Not that that's a bad thing, although all the dodging stuff which people have been hardwiring into their brains for the last 13 years now being slightly incorrect in a few different ways will potentially disadvantage good dodgers playing against HPBs.

I'm very surprised by this. This feature will give the advantage to the player with the HIGHER latency in some respects, consider you as a latent client have an erroneous view of the other players' movements (set of positions) your client makes a best guess about how other players move and in doing so simplifies their actual movement, so the onus is on the lower latency player to consider the HPB's erroneous, simplified perspective, incurring hits which are not possible and being perturbed in drastically more unpredictable ways than ever before.

@#43 mushi, /kill
/quit
1.ql has clientside hit calculation
2.ql cant even represent the models where the hitbox functionally is
3.ql is relatively bandwidth hungry
4.QW is drastically more skill divisive. ql is such a motherfuckingly mass-appeal billboard of a game that you couldn't even make a relevant judgement of netcode with referenced to QW.
case-motherfucking-closed.

Some people need a biit of a physics lesson... light going around the world in a milllisecond? vaccum/glass lightspeed being a significant factor? you guys really shouldnt be so ignorant.

to be pedantic, its not that the light travels (significantly) slower, its that the light travels a path longer than the cable length due to internal reflection.

isnt that what darff said tho Runamkok.foe.

Im sure most of us had those physics lessons and have some basic knowledge, even tho I didn't knew the exact lightspeed constant when writing my first post. If i thought it was important, i could have edited my post.

> Therefore time it takes for the data to travel one way is 0.0316898415 s = 31.7ms

That's just because you are trying to use light. If they would be using simple copper cable this wouldn't be an issue at all. You move one electron in and one is pushed out at the far end instantaneously. That's how good old telephones used to work. Much faster that way, but copper is getting expensive of course.

Jjonez just invented faster than light data transferral. gg.

subspace connections o_O
nt qqshka, respect for the russians

@bigfoot, I read your post few times but failed to understand, the way you think(or write) is obscurity for me, much much longer explanation can lit some light but doubt its needed, also its offtopic.

"OK, next up... You say I wrote a bot and made a demo of it. No, qqshka, again, YOU wrote the bot. I did make a demo of it, though, that's correct."
What? I did a bot? Please explain.

"And lastly I'd like to take you up on the offer. Of course I know you've got no intention whatsoever of honouring it."
I don't get this at all, able to rephrase? For me it looks like insulting form of agree on willing to help.

@Spike, thx for the input, read it really carefully, not like I got all even from obvious part.

Sure I read how valve did it, and yes it is somehow possibile to implement in qw, however prediction code different in different clients (ezquake prediction code different than fuhquake, for example), also our users love to chance variables wich they have no idea, this makes it less and less accurate. But lets think they use proper client (read ezquake ) and not messed with cvars, yes I can reconstruct client point of view on the server just relaying on the client latency (you calling it interpolated echoed server time, you are more correct), player origins will be close to ideal (12ms ping accuracy, maybe worse, not sure), but local player movement simulated by client and sometimes it simulated wrong (for example you affected by rj or what much worse by weapon knock back etc, its really feels bad when you shooted by lg-er and you have high ping), so while client simulate it wrongly (with ping 100 it whould be for 50 ms, as I understands) you will aim from the wrong origin(from server point of view), however I am not sure how much it will affect accuracy in real life, hope I explained this particular issue clean.

Well, to get better accuracy I can mix valve and "my method", server whould relay on client data but discard some suspicious info ( vlen(sv_valve_client_pov - qq_client_pov) > SOMETHING, where SOMETHING is consederably low value ), this way you can't cheat too much, oh well...

Doubt you can do anyting regarding projectiles (but not even tried to think MUCH about it, it looks for me just impossibile or will work bad, at least atm I think so)

"Regarding being behind a corner when you get hit, I think the problem with that is overrated", agree.

Also, as I and Renzo mention, we more interested is this feature may be accepted as general, not particular implementation which may be tuned a bit (however IMO implementation is OK and cheat consedearation irrelevant and overated)

Just make the god damned poll already

We are not going to make any polls about this feature, it is irrelevant. What is needed has already been mentioned in the news itself and in the comments.

How is it irrelevant? Let me guess, you have decided to make it a default feature anyways.

I've seen grown men arguing about enabling/disabling fallbunny for over 20mins. I wonder how much time this feature averagely adds to prewar.

Let them develop the feature first. Voting may be relevant for next eql or something.

Are we going to ask you or anyone else what features we develop for KTX (or for any project) every time? No, it is our decision and our decision only what we add in KTX or not, not yours.

Regardless of the feature working or not, people themselves can decide if they want to use it or not, or even ban it's usage. Our job is only to make the feature work as good and safe as possible, and bug-free.

"No, it is our decision and our decision only what we add in KTX or not, not yours."

I can understand if I see this all the time in the old testament, but I don't understand if a developer uses this sort of card every once in a while. I also understand this if a child says it, but please.

id's final official QuakeWorld server version has a hardcoded cap of 10000 bytes per second.
id's final official QuakeWorld client has a default rate of 5750 bytes per second, or something like that.
KTX enforces a server->client rate of 10000 bytes per second.

Considering upstream bandwidth is considered more expensive (certainly rarer, adsl and all that), how do you feel the added bandwidth compares?

My maths may be incorrect here, but here goes...
Lets assume the client is using running at a network rate of 77 packets per second.
We'll also assume there are no player is in slot 10 or above (possible with spectators in an 8-player game).
Lets also assume all combat is in the 999-to-minus-999 range. It'll likely leave that range quite often, but will often make up for it on some other axis. We'll assume action is in the negative axis - yes, this is a worse-case, but it's a large chunk of the map.
With 3 coords of 4 bytes, a player number, and padding between, each player that is visible will increase the packet by 17 bytes.
The added data contains 4 bytes of overhead if any players are visible (but the local player is always visible).
So our formula is (overhead+playercount*numplayers)*packetrate.
When you're the only person on the server, that's 4+17*77 = extra overhead of 1617 bytes

Now...
FTE servers have a feature reminisicent of ktx's 'cmd fpslist' feature, accessed via 'cmd efpslist'. One of the bits of info this feature gives is incoming data rates.
With 77 packets per second, as the only player on the server, I get a base rate of about 1771.


off: 0 1771
1: 1617 3388
2: 2926 4697
3: 4235 6006
4: 5544 7315
5: 6853 8624
6: 8162 9933
7: 9471 11242
8: 10780 12551


So, simply put, with just a single person on the server, this implementation has nearly doubled the outgoing packet rate.
With 3 players, the client will send out 3.4 times as much data as it would if this feature was disabled.
With 6 players in sight, and a few team say binds, weapon changes, etc, clients will be sending out more data than the server was intended to.

In other news, I also gather that with a few chained waits and cunningly typed binds and aliases, bigfoot's lightning gun accuracy has reached untold heights. As have his targets, even if they were on the other side of the map, and all without the use of a compiler. I do love security modules!
Seriously, what do I have to do to convince you that this implementation is not 'OK'?

Dear Renzo,



Thank you for the praising words. However, I must disagree. So far you've ignored everyone who has had anything else to say than 'OMG, OMG, can I please lick your balls?'



Well, a bit of fail here. Let's get some facts on the table:
1) Before I had written one single damn word in this thread, I got flamed by both you and qqshka. Yes. 0 words said. Go read the thread again.
2) I found jack shit. By the time I posted the demo, I hadn't even taken a single peek at the KTX source code. Yes, that's right, I was just the second player in the demo. I didn't figure out how to use this feature. Lemme repeat it again, because otherwise I fear you will not understand it: It wasn't me. Two guys in the demo. See? The other guy told me how.

Despite this, you seem to think that attacking my person is more relevant than addressing all the weaknesses of this shoddy piece of programming.



Ah, finally we agree. No, it's not the first time you attack my person instead of concentrating on the actual issue. Why don't you start deleting my posts again when you can't handle it anymore?

Dear Renzo,



You're right, when you fuck up your own shit, it's your own problem. But when you break things for other people without even considering discussing it with the people affected, it earns you the reputation of being megalomaniac puff heads.



Then, dear Renzo, you fail pretty hard. You've been told several times in this thread how to do it properly, yet you found it more interesting to spend your time on attacking my person instead. Good game?

Dear qqshka,



You made an aimbot. With your code, I can go on a server and get 70-80% lg hit accuracy, and probably more if I could be arsed, with the latest release of Ezquake. Without your code, I can't. Thank you for the aimbot, qqshka. Like many others, I aim much better on povdmm4 now. In fact, with this great new invention, I haven't lost a single game.


Ah, so you're not always as daft as you make it look. Yes, I'm god damn tired of having to waste my time every time you fuck something up, so if all it takes to make you stop breaking things is doing this properly, then yes, I'll take you up on the offer. But again, we both know you won't honour it, don't we?

Spike: I'm not sure how the implementation is done right now, but I don't think your calculation is correct. I hope the client only sends the positions when a gun is fired (I haven't checked, but I guess that can be easily fixed if it's not like that already.) No gun fires at 77 FPS rate. Hit-scan weapons are sg, ssg, lg (maybe axe too?), lg has the highest rate - 10 FPS. I'd say real numbers will be 7.7 times lower - overhead only 210 bytes.
I'd also prefer the 'timestamp way', but anyway what about the issues with prediction qqshka mentioned?

Ah, I guess the client doesn't decide when 'fire' happens, so it has to send it all the time. Ignore my prev. post then

Actually I've read every single reply there is, I just haven't commented any of those (except yours).


Let's see my replies:

#4 is about mirroring ezquake exe
#6 is about the accuracy of the feature
#35 is sarcasm
#42 I reply to spike
#50 I suggest people go test the feature live
#58 is reply to Kalma's post about what we have discussed in the dev-team
#75 I repeat what I said earlier about testing the feature and I also paste what qqshka said in the irc about getting help, since I noticed the timestamp being BEFORE your comment here on news comments. You had (or have) no intention to really help Qqshka, you just made up that he will not accept your help just to make him look bad (or it seems like that).

At this point, it is YOU who attacks me personally.

#80 I reply to YOUR attack
#92 reply to dmt
#96 reply to dmt


- The feature is NOT forced
- As I said earlier, I have read all the replies above
- My reputation is irrelevant


Good idea, the comments have a lot of offtopic flaming and hate, so why not clean it up a bit?


Read the list I made above.

My sensors have detected epic win in this sector.

My sensors have detected a failure in communication. Instead of a mature "I'm OK - you're OK" level, we see a heated "I'm OK - you're NOT" level. This is not very helpful.

Ah, ok, I forget what ppl can use "cmd" directly, thx for notice
Practical usage of such aimbot is zero, since you can spot this bot in less than second, but yet this possibility escaped my mind, so thx.


I OFFICIALY ACCEPT your offer, and stop make decision for myself, you don't know me.
Why accept? Because yet again you insult me, this should not allow me accept your help, rather say FUCK OFF, you expects this, but no, I don't like when one force me to do this or that, so I accept your offer, hrm, funny. I hope you are not good mind player and don't expected that but even if I wrong, I don't loose, since if qw gains something from you, then I succeed in my little mission.
So, less bla bla bla. Since I can't code, can you offer proper or better solution? Actual code and not bla bla bla, you can do code to any server any mod any client, I can port it to ezquake ktx and mvdsv, or I think noone will be against give you svn access to such projects directly(Well, Johnny and Renzo may curse me, but who know... :E).


Spike, not technical details for sure, since its just concept, and its pointeless(too ealery) to fix tehnical aspects if feature will be not accepted in general for gameplay reasons.

Regarding bandwidth, I send data as text, when I code it I did some simply math and was not happy since with 32 active players I hardly can fit data in a single packet (1450 bytes), but yet again its technical details, If I whould use binary 6 bytes for axis and two bytes at begining of the data, single bit represnt if data contains info about particular user then it will be significantly less data, also, I think there not need to send origins for other players except self origin (that follows from valve solution and your posts), however precision will be worse, not sure how much, so... obviously I can fix (or decrease) most of the technical issues. Matter of my will and feature acceptance, well bigfoot's "insult" also helps , one of his little missions .

Make the feature work with no abuse points, and I'll accept the change in our project with absolutely no problem.


The whole point of this news was, like it says in the topic, WHAT IF...

If this feature can be issueless, would people accept the fact that hpbs can hit as good as lpbs. I know it would make tournaments (and other games of course) to have less problems with ping differences, and I wouldn't personally mind that at all.

Also, I think I replied to first bigfoot's post wrong, if he just tried to show what you can abuse feature without changing client, then it was helpful(since it escaped my mind), even its no obvious from just showing a demo and without description, so I can belive is was good intention. I am sorry then and take some words back!

*hugs coming*

If this feature can be implemented well I am sure it will be accept however I am still worried about how this would prevent cheating by having a program modifying the packets before they are sent (I believe this is a popular method to cheat in some MMOs)

you can relax about cheating and about replacing packets, at was possibile BEFORE this feature and will be posibile WITH that feature too, nothing you can do about it. all about cheats was mention somewhere in the above 100 posts, so stop adding new ones, it gives zero useful input.

With the difference that this would make that kind of cheat even worse. I don't know if it was useful before, and I doubt it but this I know makes that kind of cheat useful.

Are the things dmt noted in #68 mere technical issues, i.e. fixable, or inherent to the method?

//EDIT: english only

Edited by Renzo on 01 Nov 09 @ 21:14CET

Dear Renzo,

It seems that you are right, in the heat of things, I mixed up yours and Qqshka's comments. However, your posts were of a ridiculing nature. But anyway,



It may not be 'forced', but they way it is implemented, besides having loads of problems, means that people how have to use an alpha version of Ezquake to not be disadvantaged compared to those who do. That is fucking up things for others.

Congratulations, Qqshka, it only took you 67 posts after it was spelled out in plain and clear English for you to get the painfully obvious. You could also just have looked at the demo, thought 'I wonder how that was done' and, well, you know, come to the painfully obvious conclusion yourself, instead of wasting you time on shooting the messenger.



OK, this left me more confused than I was before reading it. Does this, combined with the recent news item, mean that you'll stop fucking things up?

According to statistics and logic to stop "fuck things up" I should stop code(no code -> no issues), ok, lost rest of motivation, I'm off qw developement. o/

Wouldn't discussion and keeping of standards between different developers be the better choice, that leaving something you enjoy? Now I don't know what motivate people, but my guess would be the enjoyment of seeing ones work being used.

qqshka: I'm sad to hear that but I can fully understand you.

Dear qqshka,



Could you make up your mind, please?

But no, I just want you to stop fucking up things for others - what you do to your own things I don't care about. What this means is that you should talk to your peers when you want to introduce new things in the protocol. They're generally a helpful and friendly bunch. This would prevent screwups such as this and make everyone happy.

seeing post #109 just confirm what I thought. It takes more than 100 posts to
notice that you were wrong.

By the way, I'm no one fan. I'm just seeing one fellow trying to do X and then
another fellow came and said: "dude, doing X will fuck things up". Well, I just
happen to agree with the second dude.

That is what peer review is all about. You guys asked our opinions about the new
"feauture". Well, we said. But it seems you guys do not like when things do not
go your way. Perhaps you should have made a simple poll instead. With just one
choice "yes, it is a great feauture!"

Look, I know you're trying to help. That is a good thing. I'm thankfull for the
effort. You guys are trying to help the quake world comunity. For free! But as
t was already stated before: you got to know how to handle constructive
criticism.

Just another thing. Here in Brazil, as far as I know, there is like half dozen
people that still play the game. Some of those STILL try to enter the server
with modified 'eyes' model. They say that without it, they can't see the player
when they take the ring (it's so sad that it is kind of funny). Then there are
some other still using movement scripts... And even if you take that out,
I don't think there are still players with decent competitive level still
playing the game. And even if there are a couple of those over here, I don't
think they'll be willing to challenge players from the other side of the world.
The last time I heard of something like this was when the guys from O CLA had a
very successfull season (EQL div 2 or 3, if I'm not mistaken), even with extreme
high pings. They knew they'd had the highest pings but they did not complain.
But that was some time ago and I don't know if they would do that again,
even with such a feauture. It would be great if they did, though. But if you
take these guys out, the rest of the Brazillian quake scene is pitfull. Every
tourney we had here, even when quake world was at its prime (here) and we had
more than 10 active players, ended because the teams were always afraid of
facing eachother (except for ANM, who I have never seen run from a match). Even
QiB which had some fanstastic guys (and that is not only skillwise, but also
because of how nice and helpfull they were to everyone else) ended up causing
some troubles on what I think was the last successfull tourney we had here. So,
you really wish waste you time on a feauture just to have some of US playing on
your servers?

Perhaps NA and Australia still have a somewhat active community, I don't know.
Perhaps they would like to see this implemented. I for one am against it. Lets
just wait for the internet speeds to catch up. I don't know if that is possible
or or not, I saw some guys discussing some posts above if the currently known
quantum theories would ever allow such a thing but I really did not pay much
attention

Meanwhile I'm more than happy simply downloading matches from CHTV

Summing up: I'm against it. Thanks for the effort though.

Just one other thing I forgot to add. Are there still so many people on Europe with high ping problems? I thought you guys were like, the bed of the fast connection speed and, if we take the whole Europe area, it is not much larger than Brazil's, and even with our connection speed, there was never (too much) problems with pings when we had players from one side of the country playing against players from the other side

The problem is that europe is not one country. Different countries with different telecommunications infrastructures in different stages of development dealing with the bureaucracy of linking them across international borders.

Another problem is that competitive quakeworld is very much centred around scandinavia, and some of the Portuguese players might as well play across the atlantic as try to play in Denmark.

And of course, different people have different ideas of what ping is "playable". Ask some of the Swedes or Finns to play on 40ms and they'll spit on you because they're so used to the lan ping they get across their home countries. Personally I can't bear to play on 50ms or over, although I have little choice these days.

I was encouraged on IRC to explain in detail how the above demo was made. Not by anyone who has anything to do with it, mind. But to satisfy the curiosity of those who are still wondering, here's the explanation:

In qqshka's solution, as long as a fire button is held, the client sends a list of positions of all players in the (extended) view of the player. This information is what is used to determine if a weapon hits or not. It is sent through a clc_stringcmd packet. This is the packet the client emits when you type /cmd <foo> in your client, which is something most QW players have done and do regularly.

Now, this player position information is sent as arguments to a command named 'al'. Keeping this in mind, all you have to do to always hit your opponent, is type 'cmd al <yourplayernumber> <yourposition> <opponentplayernumber> <opponentposition>' and your lg will always hit. Both your and the opponent's position can of course be anything at all, no rocket science needed there. Player numbers are sequential and can be derived from the joining order. If you join first and your opponent next, and there are noone else on the server, you are players 0 and 1.

The command that was used in the demo was: cmd al 0 239 239 -161 1 239 236 -161

That's it. Nothing else needed. Works in all clients I know it's been tested with (Fodquake, FTE, Ezquake). Now, for this to work reliably, it has to be sent every frame. How to do so I'll leave as an exercise to the reader.

Well, yeah, that possibile with CURRENT solution.

However I can simply change qw protocol in mvdsv and ezquake and send data as binary, so you will need actually hack client or use evilproxy. Btw, I can change qw protocl as I wish, qwfwd proxys will still work without any changed, they are not picky about protocol unlike qizmo, that what I like especially in qwfwd. Ah, and modified clients will still work on old servers too.

#126, you worded that like a threat.
But hey, one client, one server, one mod, feck off anyone who doesn't agree, eh?
Or did you mean 'extend' instead of 'change'?.. A subtle but important difference.

Cant we just play some quake?

Well, since "and modified clients will still work on old servers too" its backward compatibility, so its extend I understand? :E

I just noted what with qwfwd style proxy anyone can change qw protocol as they wish, sad part what FTE extensions does not work via qwfwd because of "weird"(more polite call it complicated, but seems it was done to be backward compatible (tm), there no other way?) client<->server extensions negotiation. *Above NOT an insult*

And to be honestly honest in my ideal world there is ONE mod, server and client.

Yes, nothing stops you from extending the protocols much like I have done with FTE.
You can use the same mechanism to add whatever extensions you feel you need - just use your own extension bitfield id.

FTE extension negotiation happens during the connection process so that everything is known and compatible by the time the connection happens.
That and because its a layer at which every single proxy that actually parses the quakeworld packets will strip/ignore (qizmo/cheapo/qtv/etc).
If you parse one thing, then what else do you parse?... If you get what I mean.
Working as intended, just not as desired.
Tbh, so long as no negotiated extensions affect the transport layer itself (fte already has at least one of these) and as long as the server sends nothing but the serverdata first, and the client acknowledges the serverinfo's bits as the authoritive supported stuff, then it doesn't really matter if the proxy told the client that the proxy supports more, when the server does not, so long as it also doesn't involve any usercommand stuff that can be sent in packets in which the client has no info for.
Okay, so that's quite a few conditions.
But you could add support to your qwfwd proxy, but your proxy would need to be aware of each extension bitfield
The fundemental point is that serverdata extensions override the connection process due to demos.
ZQuake extensions are intended to be entirely transparent to proxies using functionality that already exists, or unused bits that were present only for alignment that are generally forwarded anyway.


Theretically, you could just pack your al packets into client commands using 3 bytes per axis to make things more compact/awkward. Send only the players that are actually relevent (ie: not aiming at any and no extra stuff will be sent), and duplicate the client's cmd crc byte for that packet, or at least part of it, to prevent cmd exploits.
This would make your entire antilag implementation less laggy thus more robust and much harder to exploit, that is if you want to stick with echoing data off the clients (which I still greatly disaprove of).

i gots free cookies!

This cl_nolag is a nice dream. Keep working on it and if it works in a practical use someday, it'll unite us all!

I just read everything through and practical problems are the ones worrying me, not cheating or theoretic. If someone starts shooting people all around map through walls, you can always vote a kick as always. This "more efficient cheating" makes it easier to spot than before.

OMG how did I miss this thread? :>

Puhh.. too bad I was inactive in this period.. what an epic thread

so if the matrix had 'antilag 1' would the agents be able to hit Neo?