27 Feb 11, 07:34PM
I'm trying to get aerke to compile a server with your fix and anticheat, so we can isolate the problem. Unfortunately, he's taking a bath ATM.
bug ? many hits but no kill...
|
27 Feb 11, 07:34PM
I'm trying to get aerke to compile a server with your fix and anticheat, so we can isolate the problem. Unfortunately, he's taking a bath ATM.
27 Feb 11, 08:32PM
27 Feb 11, 10:33PM
27 Feb 11, 11:22PM
He didn't say you were masturbating, so chill ;)
I hope the fix works, GJ on finding a bug like that Lucas.
27 Feb 11, 11:52PM
Yes... I vote (again) for Lucas become a dev. :)
28 Feb 11, 02:15AM
We just tested, with the wait+40<gs.gunwait[e.gun] fix and anticheat enabled. AC felt much easier and I got several good kills from across douze. I had 5 ping, Jack.is had 70 ping.
28 Feb 11, 02:25AM
:|
What I would like to know now is: these misses happened in 1.0? Why they started to happen in 1.1? Is this psychological/placebo effect or the anticheats really need a better tuning?
28 Feb 11, 02:28AM
Maybe it was the cumulative effect of anticheat and wait<gs.gunwait[e.gun] (?????)?
Well... this is a good guess, imo... we should check.
But tbh I need to check the code carefully.... maybe I am not understanding this issue well yet. So, I would not expect then to be cumulative, since the damage is never done (and the anticheats never called) when this first condition disrupts the hit. But again... I will be able to study this only in two weeks. EDIT: As far I can remember, YES... it is very possible they are being called together.... The anticheat is being called even without the damage being considered. (27 Feb 11, 11:52PM)Brahma Wrote: Yes... I vote (again) for Lucas become a dev. :) IF I join dev my first contribution will be to REMOVE THIS STUPID BLINKING THINGS FROM THE CODE :D (28 Feb 11, 02:34AM)Brahma Wrote: Well... this is a good guess, imo... we should check. yes, shots are checked by the anticheat before they're processed : [SELECT ALL] Code: // this is called just after shot event is added to the shot events list
28 Feb 11, 05:32PM
Luc@s Wrote:my first contribution will be to REMOVE THIS STUPID BLINKING THINGS FROM THE CODE :DHe passed the test!
01 Mar 11, 08:35PM
01 Mar 11, 09:38PM
We tried this on a server with anti-cheat, but without the 'bugged' code, and also felt an improvement in results, but yet at the same time not as good as it was when both anti-cheat and the bugged code was removed. I know that it isn't very scientific, but could it be a bit of both?
07 Mar 11, 03:27AM
Castiel made a server in 1.1.0.4 with the change and we also tested in SVN and found no obvious issues.
Is this change going to be committed to SVN soon so we can test with anticheat?
07 Mar 11, 04:34AM
As soon as I stabilize here... (one or two weeks).
07 Mar 11, 10:22AM
(01 Mar 11, 09:38PM)Jason Wrote: We tried this on a server with anti-cheat, but without the 'bugged' code, and also felt an improvement in results, but yet at the same time not as good as it was when both anti-cheat and the bugged code was removed. I know that it isn't very scientific, but could it be a bit of both? you can test with a modified client, wich increments a counter when you hit someone (client side) and decrements it when the server apply the damage. You'll get the difference.
18 Mar 11, 04:39PM
Hi guys, just wondering if there was any progress on this bug and if there was anything I could do to help. Please drop a note if there is ever a Mac beta with a fix in place.
Thanks!
20 Mar 11, 07:05PM
By the way, I think another source of lost bullets may be simply packet loss. To counter this, shouldn't the game send packets multiple times (like in Urban Terror)? UDP is after all a best-effort protocol -- it doesn't guarantee packets even make it to the server.
20 Mar 11, 11:37PM
21 Mar 11, 03:23AM
Yo dawg...
I herd you liek ENet, so we put a TCP on yo UDP etc. If Urban Terra has to send packets multiple times just to ensure the information makes it at all, I'm impressed with how successfully AC transmits a packet at its target efficiency.
21 Mar 11, 05:36AM
Uhm, tempest is half-right - we do have something akin to "TCP via UDP" with ENet, but it's still UDP, so there's no guarantee of either the order packets arrive in or if they do at all. ENet does use a "reliable"-flag, to make sure certain packets do make it, but that's what PJ measures - the amount of packet-jump : the amount of packets expected but never received.
21 Mar 11, 09:02PM
Correct me if I'm wrong, but AFAIK PJ just measures how many packets were lost and therefore had to be resent.
http://enet.bespin.org/Features.html Wrote:ENet provides sequencing for all packets by assigning to each sent packet a sequence number that is incremented as packets are sent. ENet guarentees that no packet with a higher sequence number will be delivered before a packet with a lower sequence number, thus ensuring packets are delivered exactly in the order they are sent...and... http://enet.bespin.org/Tutorial.html Wrote:ENET_PACKET_FLAG_RELIABLE specifies that the packet must use reliable delivery. A reliable packet is guarenteed to be delivered, and a number of retry attempts will be made until an acknowledgement is received from the foreign host the packet is sent to. If a certain number of retry attempts is reached without any acknowledgement, ENet will assume the peer has disconnected and forcefully reset the connection. If this flag is not specified, the packet is assumed an unreliable packet, and no retry attempts will be made nor acknowledgements generated. Again AFAIK, all message types except PING and PONG are sent using reliable packets.
22 Mar 11, 04:08AM
This is getting a bit off-topic here. And pretty technical too ;-P
OK, so - UDP doesn't know about order or reliability; ENet compensates for this by providing the reliable-flag (see above post for explanation) and a general mechanism so the receiving end knows what index it's at. If you read one more sentence after the Features.html-quote from above: Quote:For unreliable packets, ENet will simply discard the lower sequence number packet if a packet with a higher sequence number has already been delivered.And tempest is right, most messages AC sends are flagged reliable. But SV_POSC, SV_POS and SV_PING (except for once) aren't. PJ (packet jump) get's it's values from parsed positions, so this is a measure of how bad the route between the client and the server is - those packets don't get resent; if they ever make it to the receiving end, they're simply dropped.
24 Mar 11, 06:46PM
Just an FYI, I just played two games on legacysrv.tk 9999 with anticheats off and the bug fix in place and the difference was HUGE!
My wholly unsolicited advice is to put the bug fix into 1.1.0.5 and make it possible to vote anticheats off. Thanks everyone, I can finally play this game seriously again!
24 Mar 11, 06:57PM
Not yet :).
24 Mar 11, 07:47PM
25 Mar 11, 04:10AM
(This post was last modified: 25 Mar 11, 04:12AM by Greifenstein.)
Funny i happen to see this thread _now_.
Well, back in the beginnings of 1.0, i was at a little LAN party at a friend´s house and played some AC during a break. I had a normal cable Gbit-Ethernet connection there instead of the WLAN i use at home. The thing i noticed was, that it seemed i needed a lot less effort to take down enemys, kills were faster. The ping reply was around 40ms instead of the ~55ms i´ve got at home. I blamed this experience on my WLAN connection. But now, on AC v1.1 it feels like this experience has "amplified". All the time, when playing clan matches, i receive 3 hits by a stupid AR, and die - while having pumped more than 8 shots into the enemy. Or hitting the enemy with the carbine once (registered hit), and again, but without the hit being registrated. "Unhits" if you want to call it like that. Again, i blame it on the WLAN ofc. Or FPS drops, though i rarely have them. Since i´m also playing UrT for a longer time now, this seemed logical to me. But still, with the little difference, that my unhits in UrT didn´t occure more often - in contrary to my experience in AC. When reading through this thread, this reply spoke out what i was thinking: (20 Mar 11, 07:05PM)Roflcopter Wrote: By the way, I think another source of lost bullets may be simply packet loss. To counter this, shouldn't the game send packets multiple times (like in Urban Terror)? UDP is after all a best-effort protocol -- it doesn't guarantee packets even make it to the server.Thank you for that one, RC. ;) Maybe i should just look through the source some day... so it´s hard to judge if it´s just a feeling, or a fact that packet loss increased with the anti-cheat in my situation. * Greifenstein is thankful for your dedication to that problem.
25 Mar 11, 07:03AM
(24 Mar 11, 07:47PM)DES|OpenSource Wrote:(24 Mar 11, 06:46PM)sebacious Wrote: My wholly unsolicited advice is to put the bug fix into 1.1.0.5 and make it possible to vote anticheats off.If there going to be able to vote anticheat off, then there has to be a made a switch server-side to make this admin only. I can just imagine the hordes of cheaters storming a server to vote anticheat off.
25 Mar 11, 07:36AM
25 Mar 11, 09:32PM
votes can have more restrictions then just player/admin - i would suggest that is used for the anticheat off vote
|
« Next Oldest | Next Newest »
|