112 replies to this topic

[MrMadguy]

El Bandito, on 09 September 2016 - 11:21 PM, said:

Higher.

Yeah. Thx. Game feels so much more enjoyable, when enemy can't just two-shot you, but dmg is being spread between all your components.

Neema Teymory, on 09 September 2016 - 12:30 PM, said:

Hey MrMadguy, I can understand your frustration on these various issues. Unfortunately, these things are not within my control to change. PSR was a system our design team came up with after they felt that the previous ELO system was a failure. PSR on the whole has been better received than the previous matchmaking system, and as such we feel it has been a success. That is not to say it is perfect. In general, for these types of complaints or specific feedback you can direct them to our CSR team, they compile them and direct them to the appropriate department. That doesn't guarantee they will be changed, but at least it raises the concern.

I don't ask you to answer my questions or make any changes. I just want some living human being to listen for my feedback and relay it to other developers. Believe me or not, but I've tried all other ways to provide feedback, including directly twetting Russ and Paul.

I just don't know, how players with so low personal stats, as mine ones, can be happy. For example all, I usually do - is leveling not mastered 'Mechs in stock or "just for fun" builds. My skill is pretty low - in most cases I rush into battle too actively, don't even know, what to do on some maps, that lack cover, so all I usually do there - is either AFK behind my teammates till enemies won't come closer (to finish me in most cases) or rush into "suicidal" attack, if I'm way too bored. Also my video card failed recently, so I play with 20-30FPS instead of 75 and with lower resolution. Aiming is really difficult with such FPS due to "jumping" crosshair, so all I can do - is to aim at enemies' silhouettes. So with such low skill and performance I should definitely be in a Tier 4. But guess what?

And my PSR fluctuates at this level for a long time already. And no matter, how bad my performance is - it just stays there.

Don't you think, that all players, who happy with current PSR are:
1) Top skill players, who just don't have opponents with their level of skill
2) Constantly create new smurf accounts to reset their PSR

I would create smurf account too, but I invested too much $$$ into this one.

Edited by MrMadguy, 10 September 2016 - 12:18 AM.

[MrMadguy]

Another great example from nearby thread. Yeah, it always feels exactly like this, when you play against Arctic Cheetahs, Firestarters and Spiders - like they have holes in their hit boxes. It has always seemed to me, that they had some sort of animation sync problems - i.e. for example body inclination wasn't handled by server.

This is:
1) HSR fail?
2) Broken hit boxes?
3) Convergence fail?

You know, some people even think, that hitreg is broken on Lights intentionally, cuz if they would take all the damage, they should - nobody would play them.

Edited by MrMadguy, 10 September 2016 - 05:44 AM.

[ForceUser]

Convergence, definitely. Going from 1000m+ convergence to 60m in a few milliseconds is why the guns missed in this case. This is why these things should be PMed to them or to support. The vast majority of these so called hit reg problems people post, usually isn't but confirmation bias makes it hard for people to accept that they missed by a millimeter, or that a game mechanic is to blame rather than hitreg. There are legit cases but players are not the most objective to judge them.

[MrMadguy]

ForceUser, on 11 September 2016 - 08:10 AM, said:

Convergence, definitely. Going from 1000m+ convergence to 60m in a few milliseconds is why the guns missed in this case. This is why these things should be PMed to them or to support. The vast majority of these so called hit reg problems people post, usually isn't but confirmation bias makes it hard for people to accept that they missed by a millimeter, or that a game mechanic is to blame rather than hitreg. There are legit cases but players are not the most objective to judge them.

Convergence has been made instant exactly for HSR support. Weapons are being instantly converged at point, you're aiming at. As I can see, when OP pressed his trigger, he was aiming exactly at Cheetah's face. Literally at Cheetahs face. Zero doubt.


This crap can have only one possible explanation - Cheetah has big enough hole in his hitboxes between his head and his shoulder. As you can see on this video, at height, OP was aiming at, Cheetah shouldn't have any holes in hitboxes. And here is the problem - many 'Mechs has such terrible hitboxes, that cause constant loses of convergence. I.e. when all of a sudden you hit some tiny slit between body and arm. And it completely messes your convergence - leads to complete miss. Stormcrows has such hitboxes for example. And there is only one possible solution, I have been suggesting for a long time already - add "soft" hitboxes around 'Mechs, that will keep weapons converged at this 'Mech - i.e. simply remove all tiny holes and slits. And in case of Lights we need even better feature - it would be nice to have "Converge at my current target" feature. I.e. make it so leading won't kill our convergence and Lights won't be so cheating.

Edited by MrMadguy, 11 September 2016 - 09:54 AM.

[Quicksilver Aberration]

MrMadguy, on 11 September 2016 - 09:36 AM, said:

make it so leading won't kill our convergence and Lights won't be so cheating.

If you git gud lights won't be cheating.

[MrMadguy]

I still think, you should look for some causes of desync. May be desync is caused by intentional colliding with other 'Mechs? Many Lights exploit this bug, that grants them temporal invulnerability. May be some degree of invulnerability persists even after Lights are being synced back?

Also I have another question. More interesting question. How do you deal with quantization problems? I.e. aiming and 'Mech movement can look smooth on our screens, but at the end your servers have just 30FPS. That means, that 'Mechs, that move faster, than 100kph, can simply move per frame further, than their own size. For server it looks like 1FPS on following video:

And, I guess, the same happens with twisting and aiming. How do you deal with this situation? How can you guarantee, that targets, that move faster, than 100kph, can even be hit with projectiles, that can move with up to 2kps speed? Same interpolation algorithm, as for Ballistic lag compensation?

Edited by MrMadguy, 12 September 2016 - 04:54 AM.

[Kangarad]

what is the maximum speed deviation the lag compensation can handle safely ?

[Quicksilver Aberration]

MrMadguy, on 12 September 2016 - 04:49 AM, said:

For server it looks like 1FPS on following video:

If you do a bit of math you can figure out how far a mech will move per tick, which won't be more than the mech. At 150kph a mech only moves around 1.3888m per tick which is not more than their own size. Moving more than their own size is actually more of a problem with projectiles because they naturally are faster and tend to be small pieces of geometry. That's where ray-tracing and prediction can help out.

Edited by Quicksilver Kalasa, 12 September 2016 - 07:00 AM.

[Neema Teymory]

MrMadguy, on 09 September 2016 - 11:16 PM, said:

Do you mean, it can happen with 'Mech, that has weapon doors only?

Yes, the bug I was referring to was specifically a weapon door related bug

MrMadguy, on 09 September 2016 - 11:16 PM, said:

I ask it, cuz I experienced this problem with many different 'Mechs. Quickdraw for example. I guess, there have been moments, when I have been invulnerable too - in my Firebrand for example. Also sometimes it seems, that problem is caused by some sort of desync. I.e. you aim at CT, but hit arms instead. And this can happen even with huge slow 'Mechs, such as Atlas for example. Also if this problem occurs, it occurs for all 'Mechs in this match - i.e. not only I experience such problems, but it seems, that at least all 'Mechs in my team experience them too. Funny thing, but when all 'Mechs are affected by this problem, game feels much more enjoyable due to much higher TTK.

Yeah, we will definitely investigate the problem further.

MrMadguy, on 10 September 2016 - 05:21 AM, said:

You know, some people even think, that hitreg is broken on Lights intentionally, cuz if they would take all the damage, they should - nobody would play them.

I can confirm that there is no special code that makes light intentionally harder to hit

MrMadguy, on 11 September 2016 - 09:36 AM, said:

Convergence has been made instant exactly for HSR support. Weapons are being instantly converged at point, you're aiming at.

This is correct. There is no delayed convergence. Convergence is instantaneous and therefore the server can trust whatever the client's convergence is. If convergence had delays associated with it, we could no longer trust the client, since this would need to become a server controlled feature--otherwise it would be exploitable. Adding delayed convergence introduces another level of complexity in terms of both aiming skill and network synchronization. This feature was considered in the past, but we decided not to add it for various reasons.

MrMadguy, on 12 September 2016 - 04:49 AM, said:

I still think, you should look for some causes of desync. May be desync is caused by intentional colliding with other 'Mechs? Many Lights exploit this bug, that grants them temporal invulnerability. May be some degree of invulnerability persists even after Lights are being synced back?

As I mentioned before, collisions are very problematic right now, and will definitely cause desyncs. This would cause a perceived invulnerability, since the simulated position on your client and the server's position will no longer match. This should not persist after a collision occurs, the simulation should be corrected relatively quickly, which is why you see the snapping and rubberbanding.

MrMadguy, on 12 September 2016 - 04:49 AM, said:

Also I have another question. More interesting question. How do you deal with quantization problems? I.e. aiming and 'Mech movement can look smooth on our screens, but at the end your servers have just 30FPS. That means, that 'Mechs, that move faster, than 100kph, can simply move per frame further, than their own size. For server it looks like 1FPS on following video: And, I guess, the same happens with twisting and aiming. How do you deal with this situation? How can you guarantee, that targets, that move faster, than 100kph, can even be hit with projectiles, that can move with up to 2kps speed? Same interpolation algorithm, as for Ballistic lag compensation?

Yes, we use interpolation to deal with these inter-frame cases. It's true that not all mech motions are linear, so the interpolation isn't perfectly correct, but it happens to be a very good approximation since the change between these frames are relatively small. Imagine approximating a circle with a lot of tiny lines. At a certain point, your eye can't tell the difference. That is not to say that your eye won't be able to see the difference between these two frames, but it is close enough that a linear approximation is very accurate.

Kangarad, on 12 September 2016 - 06:04 AM, said:

what is the maximum speed deviation the lag compensation can handle safely ?

.

The lag compensation algorithm is not limited by the speed of mechs, only player pings. The limit of the rewind system is 500ms, but even when you start to get close to 500ms things get dodgy. Realistically, it should work relatively well up until ~450ms. With that said, the faster targets can move, the more potential there will be for error between the client's simulation and the server state and that could result in more mispredictions.

[Pariah Devalis]

Neema Teymory, on 12 September 2016 - 11:49 AM, said:

The lag compensation algorithm is not limited by the speed of mechs, only player pings. The limit of the rewind system is 500ms, but even when you start to get close to 500ms things get dodgy. Realistically, it should work relatively well up until ~450ms. With that said, the faster targets can move, the more potential there will be for error between the client's simulation and the server state and that could result in more mispredictions.

I know a while ago the "speed limit" of mechs was around 171 KPH to aid in accuracy of HSR. Since then, you had done a tune up on the HSR system. Assuming ping does not exceed the limitations of the system, how fast would you predict a mech could move before you expect to see noticeably more mispredictions?

[Neema Teymory]

Pariah Devalis, on 13 September 2016 - 05:21 AM, said:

I know a while ago the "speed limit" of mechs was around 171 KPH to aid in accuracy of HSR. Since then, you had done a tune up on the HSR system. Assuming ping does not exceed the limitations of the system, how fast would you predict a mech could move before you expect to see noticeably more mispredictions?

It's tough for me to give you a number. We would need to do some tests to be able to answer that question

[Imperius]

Maybe you can't answer this.

My understanding of the current engine is CryEngine 2.5ish (To keep DX 9 support). From that you and others have coded the collision and hit registration code that works with dedicated servers because at the time this was not available with the current version of the CryEngine being used.

If hypothetically you were able to switch to Unreal Engine 4 which comes with a lot of this coding built in with easy to use checkboxes on how objects and projectiles collide and act with the world. Would switching to an engine or upgrading fix a lot of these bugs and issues?

Also would it help things like top speed and allowing more destructable environments?

If you can not answer just say so and I'll accept that.

Edited by Imperius, 13 September 2016 - 10:59 AM.

[MrMadguy]

Imperius, on 13 September 2016 - 10:53 AM, said:

Maybe you can't answer this.

My understanding of the current engine is CryEngine 2.5ish (To keep DX 9 support). From that you and others have coded the collision and hit registration code that works with dedicated servers because at the time this was not available with the current version of the CryEngine being used.

If hypothetically you were able to switch to Unreal Engine 4 which comes with a lot of this coding built in with easy to use checkboxes on how objects and projectiles collide and act with the world would switching to an engine or upgrading fix a lot of these bugs and issues?

Also would it help things like top speed and allowing more destructable environments?

If you can not answer just say so and I'll accept that.

How many times should we say, that new engine won't magically fix all problems, simply because they have nothing to do with engine? May be you should stop posting your "Let's change engine just for the sake of changing engine" BS?

Neema Teymory, on 12 September 2016 - 11:49 AM, said:

Yes, we use interpolation to deal with these inter-frame cases. It's true that not all mech motions are linear, so the interpolation isn't perfectly correct, but it happens to be a very good approximation since the change between these frames are relatively small. Imagine approximating a circle with a lot of tiny lines. At a certain point, your eye can't tell the difference. That is not to say that your eye won't be able to see the difference between these two frames, but it is close enough that a linear approximation is very accurate.

Yeah, this may be true for large slow 'Mechs, but how about those ones, that have so tiny hit boxes, that several inches - is difference between hit and miss? That's, what I'm talking about: are you sure, that your servers can handle so tiny 'Mechs with so complicated hit boxes, moving with so high speeds? May be you should implement "soft" hit boxes around Lights and some Mediums (like Stormcrow) in order to make sure, that hitting silhouette = hitting 'Mech itself? I.e. to avoid something, like that. I mean, everybody suggests to aim at Lights' legs. But... How can you aim at this matches, they flap, like it's fly's wings.

Edited by MrMadguy, 13 September 2016 - 11:23 AM.

[Imperius]

MrMadguy, on 13 September 2016 - 11:02 AM, said:

How many times should we say, that new engine won't magically fix all problems, simply because they have nothing to do with engine? May be you should stop posting your "Let's change engine just for the sake of changing engine" BS?


Yeah, this may be true for large slow 'Mechs, but how about those ones, that have so tiny hit boxes, that several inches - is difference between hit and miss? That's, what I'm talking about: are you sure, that your servers can handle so tiny 'Mechs with so complicated hit boxes, moving with so high speeds? May be you should implement "soft" hit boxes around Lights and some Mediums (like Stormcrow) in order to make sure, that hitting silhouette = hitting 'Mech itself? I.e. to avoid something, like that. I mean, everybody suggests to aim at Lights' legs. But... How can you aim at this matches, they flap, like it's fly's wings.

I'm going to say this once. Your opinion means absolutely nothing to me period! I'm not talking to you so I will ask you do not answer for another person that question was directed to which is Neena.

[Quicksilver Aberration]

MrMadguy, on 13 September 2016 - 11:02 AM, said:

Yeah, this may be true for large slow 'Mechs, but how about those ones, that have so tiny hit boxes, that several inches - is difference between hit and miss?

Did you just completely ignore my post, at fastest they only move around 1.3m per tick, which is not more than their mech size per frame, so interpolation should work just fine.

Edited by Quicksilver Kalasa, 13 September 2016 - 11:56 AM.

[Neema Teymory]

Imperius, on 13 September 2016 - 10:53 AM, said:

Maybe you can't answer this.

My understanding of the current engine is CryEngine 2.5ish (To keep DX 9 support). From that you and others have coded the collision and hit registration code that works with dedicated servers because at the time this was not available with the current version of the CryEngine being used.

If hypothetically you were able to switch to Unreal Engine 4 which comes with a lot of this coding built in with easy to use checkboxes on how objects and projectiles collide and act with the world. Would switching to an engine or upgrading fix a lot of these bugs and issues?

Also would it help things like top speed and allowing more destructable environments?

If you can not answer just say so and I'll accept that.

Switching engines is a massive undertaking. To avoid mincing words here, switching engines can more or less be equated to making a whole new game. So, if you are asking if we are to make a whole new game would it be possible to improve the current state of hit detection and make other improvements to the game? Yes, it's certainly possible, but this is not necessarily related to any specific game engine. It's also possible with the current state of the game to improve hit detection further. Which is why I still encourage people to provide reports, and when we have time we will work on improving things further

[Imperius]

Neema Teymory, on 13 September 2016 - 12:39 PM, said:

Switching engines is a massive undertaking. To avoid mincing words here, switching engines can more or less be equated to making a whole new game. So, if you are asking if we are to make a whole new game would it be possible to improve the current state of hit detection and make other improvements to the game? Yes, it's certainly possible, but this is not necessarily related to any specific game engine. It's also possible with the current state of the game to improve hit detection further. Which is why I still encourage people to provide reports, and when we have time we will work on improving things further

Thank you for your response.

[Greyhart]

I have a question.

As anyone who reads these forums know the idea of a Cone of Fire is often brought up.

So would a Cone of Fire present additional problems for the hit registration, like convergence? Or would it be a neutral change for hit reg calculation?

[Imperius]

Greyhart, on 14 September 2016 - 12:52 AM, said:

I have a question.

As anyone who reads these forums know the idea of a Cone of Fire is often brought up.

So would a Cone of Fire present additional problems for the hit registration, like convergence? Or would it be a neutral change for hit reg calculation?

Not answering for Neema but I do believe this was answered at some point as yes. Something along the lines of each weapon would have its own host rewind. Currently each mech has one. So the server depending on the mech would have to calculate each weapon on each mech. 24 * (max number of weapons) instead of just 24.

I could be wrong though.

[Greyhart]

Imperius, on 14 September 2016 - 01:08 AM, said:

Not answering for Neema but I do believe this was answered at some point as yes. Something along the lines of each weapon would have its own host rewind. Currently each mech has one. So the server depending on the mech would have to calculate each weapon on each mech. 24 * (max number of weapons) instead of just 24.

I could be wrong though.

I am not sure that's right. as the current system has to draw the line periodically (as not every human keeps everything perfectly still and none moving) from each starting point. All a CoF would do is move that line about a small amount.

Alternatively you needn't have each weapon have its own individual movement within the CoF but the entire group could move as one.

If the current system doesn't account for the placement of each weapon then when you hit with one weapon you'd hit with all the ones fired. Even if those weapons had obstacles in the way.

I could be wrong too of course. I am no expert by a large margin.

Edited by Greyhart, 14 September 2016 - 02:27 AM.