bug ? many hits but no kill...

[Gibstick]

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.

[Luc@s]

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.

:D I don't know anticheat code but I think it should work anyway, but you're right, it's better to test...

[ärkefiende]

Unfortunately, he's taking a bath ATM.

Does the whole world need to know that? o_O

[Panda]

He didn't say you were masturbating, so chill ;)

I hope the fix works, GJ on finding a bug like that Lucas.

[Brahma]

Yes... I vote (again) for Lucas become a dev. :)

[Gibstick]

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.

[Brahma]

:|

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?

[Gibstick]

Maybe it was the cumulative effect of anticheat and wait<gs.gunwait[e.gun] (?????)?

[Brahma]

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.

[Luc@s]

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

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.

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
if(!m_demo && !m_coop) checkshoot(sender, shot, hits, tcn);

[V-Man]

my first contribution will be to REMOVE THIS STUPID BLINKING THINGS FROM THE CODE :D

He passed the test!

[jAcKRoCk*]

my first contribution will be to REMOVE THIS STUPID BLINKING THINGS FROM THE CODE :D

He passed the test!

i lol'd

[Jason]

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?

[Roflcopter]

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?

[Brahma]

As soon as I stabilize here... (one or two weeks).

[Luc@s]

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.

[sebacious]

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!

[Roflcopter]

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.

[tempest]

UDP is after all a best-effort protocol -- it doesn't guarantee packets even make it to the server.

That's why we have ENet. It ensures that every packet reaches its destination. You could say it's sort of a TCP on top of UDP.

[V-Man]

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.

[flowtron]

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.

[tempest]

Correct me if I'm wrong, but AFAIK PJ just measures how many packets were lost and therefore had to be resent.

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...

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.

[flowtron]

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:

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.

[sebacious]

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!

[BunnySoul]

Not yet :).

[OpenSource]

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.

[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:

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.

[V-Man]

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.

[eftertanke]

I can just imagine the hordes of cheaters storming a server to vote anticheat off.

* eftertanke calls a vote: Moar hax0rz plzkthkbai!

[Blue_Pr!nt]

votes can have more restrictions then just player/admin - i would suggest that is used for the anticheat off vote