Mordhau

Still no fix

Knight 528 3385
  • 24 Jan '18
 rob_owner

okay so from what i found, if you join a server that was empty and up for a while (theres probably a reason i dont know for why this happens but those two qualities were both consistent when i tested), theres a chance that the server tracers are not synced with your tracers/weapons, and stabs will hit SLIGHTLY early, so will everything else. This is different from regular instahits (which are already pretty brutal) and it looks like thats whats happenin in some of your clips.

i tested on Nal's server with the commands m.drawtracers 1 and the showauthtracers 1 command, you need to be logged in as admin to see the server tracers, but if you join a server that was up and empty for a while, chances are they will be desynced, it was consistent when i tried it. If you just change the map it will fix it. If you set the server speed with slomo to like 0.2 or 0.5 it becomes extremely overt.

pretty sure devs already know and are working on it among other things

3234 4264
  • 24 Jan '18
 Havoc

Feels

396 454
  • 25 Jan '18
 JasonBourne

Nice find Rob.

988 6974
  • 25 Jan '18
 marox — Project Lead

@rob_owner said:
okay so from what i found, if you join a server that was empty and up for a while (theres probably a reason i dont know for why this happens but those two qualities were both consistent when i tested), theres a chance that the server tracers are not synced with your tracers/weapons, and stabs will hit SLIGHTLY early, so will everything else. This is different from regular instahits (which are already pretty brutal) and it looks like thats whats happenin in some of your clips.

i tested on Nal's server with the commands m.drawtracers 1 and the showauthtracers 1 command, you need to be logged in as admin to see the server tracers, but if you join a server that was up and empty for a while, chances are they will be desynced, it was consistent when i tried it. If you just change the map it will fix it. If you set the server speed with slomo to like 0.2 or 0.5 it becomes extremely overt.

pretty sure devs already know and are working on it among other things

Nice! This isn't something we were aware of. Any idea how long they were up and empty? Are the desyncs consistent, do other people get them as well?

Due to how Unreal handles world time and how it computes delta time between frames from that time, this might be caused by deterioration in floating point accuracy. I've feared this for some time after initially looking over the engine source, but couldn't really believe Epic would leave such a rookie mistake in for so long. This would require the map to be running for quite a while, but it would fix itself on map change, so it feels like it could be responsible, I'm just not entirely sure it's the culprit. It would easily be fixed by making the map change itself after a while regardless if the server is empty, but I'd prefer to tackle the root of the problem as well.

Knight 1836 2232
  • 25 Jan '18
 Void

@marox said:
Due to how Unreal handles world time and how it computes delta time between frames from that time, this might be caused by deterioration in floating point accuracy.

Yes, it's all clear to me now.

17-26-19-ea84c54d6b21ffd6fb293a8cf881987c.jpeg

You sound like a mad scientist lol

Duke 5556 13282
  • 1
  • 25 Jan '18
 Jax — Community Manager

Floating point accuracy void, explained by someone who doesn't really understand quick mafs-

Pretty sure that's why Minecraft turns into the twilight zone when you go to the edge of the world

So like if the tracers are supposed to be at x 1.374 whatever but it degrades and the tracer is at x 1.391 or some shit. The server loses accuracy

If a duel server is empty for example, the map timer doesn't start, it just stays at 20 minutes until someone spawns in IIRC. So you leave your server up overnight and that map has been running since the day before and this happens

I think

Edit: I've harnessed the power of Google

https://msdn.microsoft.com/en-us/library/c151dt3s.aspx

Binary code of 0 and 1's sometimes doesn't perfectly translate numbers so you get inaccuracy

Knight 697 1611
  • 25 Jan '18
 das

That explains why you hit invisible walls on an empty server until map is changed.

Caveman explanation: Computer think in 1 and 0. Integer. No demical point. Must do tricky thing for decimal points. Number with decimals has float.

Empty server keeps counting timer because no one joins. No one joined in very long time. Computer server keep counting. Count so much, float number is counting weird now. Game no like weird, game going to register hit on wrong time now! Game frame and server tick no longer synchronize same time! Me smash!

Knight 528 3385
  • 25 Jan '18
 rob_owner

I reckon the longer its up for the worse the desyncs are, becuase sometimes just Winding up will make damage happen, other times the damage is sneakily ahead of the weapon and you kinda do have to slow it down to be completely sure.

So i assume if its up and empty for a REALLY long time, everyone who winds up will be doing super speed damage during their windup, that did happen one time. If it was up for maybe 8 hours ( i'll test when my pc is fixed if no one else does) then most people are gonna notice something is off, but its super obvious when you slow down the server.

As long as the server has fermented for a while, everyone will be able to hit earlier, the intensity is contingent on the time it was idle. im pretty sure its because what does damage is the server tracers and thats the case for everyone, and thats what gets desynced.

Knight 1836 2232
  • 25 Jan '18
 Void

Thanks for the explanation guys!

3234 4264
  • 26 Jan '18
 Havoc

So the "input lock bug" is actually the "animations and player models are desynced causing very early hits on your client via receiving accels" bug.

988 6974
  • 26 Jan '18
 marox — Project Lead

@Havoc said:
So the "input lock bug" is actually the "animations and player models are desynced causing very early hits on your client via receiving accels" bug.

Not sure what input has to do with this, can you elaborate?

3234 4264
  • 26 Jan '18
 Havoc

@marox said:

@Havoc said:
So the "input lock bug" is actually the "animations and player models are desynced causing very early hits on your client via receiving accels" bug.

Not sure what input has to do with this, can you elaborate?

The input lock bug may just be desync.

988 6974
  • 26 Jan '18
 marox — Project Lead

@rob_owner said:
okay so from what i found, if you join a server that was empty and up for a while (theres probably a reason i dont know for why this happens but those two qualities were both consistent when i tested), theres a chance that the server tracers are not synced with your tracers/weapons, and stabs will hit SLIGHTLY early, so will everything else. This is different from regular instahits (which are already pretty brutal) and it looks like thats whats happenin in some of your clips.

i tested on Nal's server with the commands m.drawtracers 1 and the showauthtracers 1 command, you need to be logged in as admin to see the server tracers, but if you join a server that was up and empty for a while, chances are they will be desynced, it was consistent when i tried it. If you just change the map it will fix it. If you set the server speed with slomo to like 0.2 or 0.5 it becomes extremely overt.

pretty sure devs already know and are working on it among other things

Can now confirm this is an issue, we're working on a fix.

3234 4264
  • 26 Jan '18
 Havoc

@marox said:

@rob_owner said:
okay so from what i found, if you join a server that was empty and up for a while (theres probably a reason i dont know for why this happens but those two qualities were both consistent when i tested), theres a chance that the server tracers are not synced with your tracers/weapons, and stabs will hit SLIGHTLY early, so will everything else. This is different from regular instahits (which are already pretty brutal) and it looks like thats whats happenin in some of your clips.

i tested on Nal's server with the commands m.drawtracers 1 and the showauthtracers 1 command, you need to be logged in as admin to see the server tracers, but if you join a server that was up and empty for a while, chances are they will be desynced, it was consistent when i tried it. If you just change the map it will fix it. If you set the server speed with slomo to like 0.2 or 0.5 it becomes extremely overt.

pretty sure devs already know and are working on it among other things

Can now confirm this is an issue, we're working on a fix.

THANk

988 6974
  • 26 Jan '18
 marox — Project Lead

@Havoc said:

@marox said:

@Havoc said:
So the "input lock bug" is actually the "animations and player models are desynced causing very early hits on your client via receiving accels" bug.

Not sure what input has to do with this, can you elaborate?

The input lock bug may just be desync.

I'm guessing you're not referring to an actual general input lock, but a specific case of not being able to parry in a specific scenario which you mentioned last time? Shouldn't be related to that in any way unless it magically goes away on map change. It's only related to time (and by proxy) some animations desyncing between server and clients, and since servers run the logic they decide when hits happen. I'm not sure if it's an issue that would become problematic in actions other than attack hitreg.

396 454
  • 26 Jan '18
 JasonBourne

How will this affect servers that change map every 10 mins with players ?

988 6974
  • 26 Jan '18
 marox — Project Lead

@JasonBourne said:
How will this affect servers that change map every 10 mins with players ?

It won't, because this issue does not pertain to them

3234 4264
  • 26 Jan '18
 Havoc

@marox said:

@Havoc said:

@marox said:

@Havoc said:
So the "input lock bug" is actually the "animations and player models are desynced causing very early hits on your client via receiving accels" bug.

Not sure what input has to do with this, can you elaborate?

The input lock bug may just be desync.

I'm guessing you're not referring to an actual general input lock, but a specific case of not being able to parry in a specific scenario which you mentioned last time? Shouldn't be related to that in any way unless it magically goes away on map change. It's only related to time (and by proxy) some animations desyncing between server and clients, and since servers run the logic they decide when hits happen. I'm not sure if it's an issue that would become problematic in actions other than attack hitreg.

Any idea what the inability to parry or chamber riposte/chamber accels issue is then?

Count 671 1131
  • 26 Jan '18
 Zexis

@Havoc said:

@marox said:

@Havoc said:

@marox said:

@Havoc said:
So the "input lock bug" is actually the "animations and player models are desynced causing very early hits on your client via receiving accels" bug.

Not sure what input has to do with this, can you elaborate?

The input lock bug may just be desync.

I'm guessing you're not referring to an actual general input lock, but a specific case of not being able to parry in a specific scenario which you mentioned last time? Shouldn't be related to that in any way unless it magically goes away on map change. It's only related to time (and by proxy) some animations desyncing between server and clients, and since servers run the logic they decide when hits happen. I'm not sure if it's an issue that would become problematic in actions other than attack hitreg.

Any idea what the inability to parry or chamber riposte/chamber accels issue is then?

are you referring to higher ping like you showed me in-game awhile back

3234 4264
  • 26 Jan '18
 Havoc

@Zexis said:

@Havoc said:

@marox said:

@Havoc said:

@marox said:

@Havoc said:
So the "input lock bug" is actually the "animations and player models are desynced causing very early hits on your client via receiving accels" bug.

Not sure what input has to do with this, can you elaborate?

The input lock bug may just be desync.

I'm guessing you're not referring to an actual general input lock, but a specific case of not being able to parry in a specific scenario which you mentioned last time? Shouldn't be related to that in any way unless it magically goes away on map change. It's only related to time (and by proxy) some animations desyncing between server and clients, and since servers run the logic they decide when hits happen. I'm not sure if it's an issue that would become problematic in actions other than attack hitreg.

Any idea what the inability to parry or chamber riposte/chamber accels issue is then?

are you referring to higher ping like you showed me in-game awhile back

It is more noticeable with higher pings, and I've seen it proc on 25 ping on Jax's high iq server