@rockykoston to continue our conversation here, I’m not saying the unity engine only updated for IOS. I’m saying that update only caused the parry dex issue for IOS and not Android. I’d encourage you to read the entire post again, because I’m afraid you’ve misunderstood that aspect. I don’t mean that in a patronising way, just that if you think Kabam are saying Android players don’t have an issue with parry or dex, then you haven’t read the whole thing.
Please read it again, but I’ll direct you to this part which explains the IOS issues.
“ When we refer to the “Parry and Dex issue”, we’re not actually talking about an issue with Parry or Dex, but a framerate and control input issue exclusive to iOS devices that is most noticeable when trying to Parry or Dex, since these are two mechanics players rely on quite often.
Marvel Contest of Champions is built on a 3rd Party Game Engine built by our partners at Unity, which has an input system built-in. We’ve relied on Unity's input system since the game was built, and have regularly updated the Engine as they have released updates. With the most recent update to the Engine, a bug was fixed where iOS devices had been operating at the device’s own frame rate, instead of being capped to 30fps as it was set to. This meant that iOS devices had a slightly different input window than Android devices, but this was never identified.
Since this is how iOS devices had always worked with our game since launch, we had built game interactions around that input window. Now, because this bug in the engine has been fixed, it changed the input window of inputs for all iOS devices and pushed back the input window by mere milliseconds, but that is enough that it is noticeable when playing the game.
This is the issue that we are working to address, and our fix for it is to integrate an entirely new control input system from our partners at Unity. But this is not a quick or easy task.”
Only the IOS input window was pushed back, therefore it cannot be the cause of the Android issues.
Either they've not tested enough or they're afraid to acknowledge that Unity update is affecting android devices.
Now you'd ask why would they not accept it, because of the sheer variety of android devices, models, OS etc. They've never really been able to fix the android issue so if this is the same thing then it's nothing new.
iOS is clearly much easier to identify and fix because of the small environment.
But the fact that they are dismissing android as a generic lag and stutter is what they've been doing forever.
The fact that android now has configurable screen refresh rate with phones going UpTo 144hz and no update to make that compatible, tells us everything.
They are not dismissing Android as a generic lag and stutter problem. And the fact that Android has configurable screen refresh rates means diddly, because the game is built upon Unity. As I'm not a Unity expert (certainly not 2020 era Unity) if there are any out there feel free to correct me, but Unity uses a composite clock. There's one clock that runs the internals of Unity - the physics, the geometry calculations, etc - and another that runs the rendering. In theory you can run the render pass at any refresh rate you want, subject to vsync limitations (to prevent screen tearing) but the update clock cannot run at arbitrary rates. I mean, you can, but if you attempt to run it faster than the platform can calculate you'll get strange behavior, and if you run it at an arbitrary rate calculated dynamically based on how fast the device is you will end up with weird update/render beat-mismatches.
A custom game engine might use a single clock and cram everything into intra-frame calculations, or they might use staggered clocking and perform physics and motion in a divide down clock, but if you attempt that in Unity you'll almost certainly create problems in MCOC because that's basically what's happening in iOS now.
While I'm on the subject of reminding people the game is built on Unity, it is worth pointing out that since Kabam doesn't write Unity, the information that their current Unity build changed timing for iOS comes from Unity. They are the only ones who would know what they changed in any particular Unity build.
Another thing to point out: while anything is possible, if Android has as widespread timing problems as many assert then Tapsalot will find them. Tapsalot does not need to test a thousand different Android devices to find a pervasive Android problem that appears to be affecting a substantial percentage of the Android players of the game. It is just like crystal conspiracies: anything is possible when it comes to one crystal. But a massive crystal rigging conspiracy that is affecting all crystals for all players in noticeable ways is detectable with trivial testing. You can't disprove that one crystal is rigged. But you can disprove that all of them are. Tapsalot changes the Android situation because we no longer need to rely on anecdotes. If there's a pervasive Android problem, Tapsalot will find it. Conversely, if Tapsalot doesn't find it, there is no pervasive Android problem. There might still be rare marginal problems because of Android heterogeneity. But widespread problems affecting a large percentage of Android players can be proven to either exist, or not exist, with certainty. To be honest, such clarity either way will be welcome, at least by those of us interested in the bottom line facts.
Belief doesn't matter. 60% of Android testers thought that one of two *identical* game clients worked noticeably better (and not to pick on Android players, because iOS players appear to be equally vulnerable to that self deception). Belief is for churches, not for troubleshooters.
Your reply is very condescending and patronizing. Thank you for the thoughts and good bye.
The post I was replying to was factually inaccurate and drawing inexplicable conclusions with unjustified confidence. Condescension is very difficult to avoid in that situation. Be less certain or less wrong or preferably both, or condescension will be a constant companion in your life.
While the robot is a brilliant way to get at actual measurement and to be able to test fixes with a controlled "fixed" input and response. It definitely will be impractical to test on even the few models of iOS, let alone the multiple manufacturers and models of android phones and tablets. If I could suggest, you might be able to use something like the parry training ground to crowd source some data for a beta test. Have something where you have to parry like 10 medium hits from 5-6 different characters and you should be able to gather a bunch of data from hundreds or thousands doing the exact same test on the same characters. I'm not saying this would prevent a robot uprising...but maybe delay it a bit
Unfortunately, it won't help. As we mentioned in the post, there is no way for us to measure this in software because the issue resides between the Game Engine and the Hardware.
Absolutely, I get that you can't actually measure the input timing that way. What I was thinking was more of a way to quantify if the fixes worked for players. So like if you repeated the "Does parry/dex feel better" experiment but instead of asking about feel could measure that it took say 16 mediums to get 10 parries on average for those with the released version, vs say 12 mediums to get 10 parries on the hotfix beta. Then no matter what they say parry felt like you would have data to show that parry was working better with the hotfix.
It just seemed like that type of data (parry success rate) could be gathered, since the training mode already recognizes when you landed a successful parry. But I have no real idea if that data is available under the hood or not.
Tapsalot eliminates the need for that kind of testing. Prior to Tapsalot, the devs had to guess at what changes might have caused a change in player feeling. But now that this can be quantified, either the new build replicates the old timing sufficiently well or it doesn't.
Keep in mind the task for Kabam is not to change the game until everyone's Parry skills improve. The task for Kabam is to replicate the old behavior. If they do and players are still missing Parries, that would be a psychological problem in their heads that the game client can't fix and can only be solved by the players readjusting to the old-new-old normal.
Tapsalot will eliminate that need for testing for any device that can be tested using Tapsalot. Automatically extending results found with an iPhone 12 max to other devices that have not been tested with Tapsalot would decidedly be poor scientific method. It would be like me saying my research using mice is automatically applicable to humans just because both are mammals. And it would seem that expanding the robot army to test the numerous different apple and android phones and tablets would rapidly become cost/time prohibitive.
So really what I was suggesting was like a phase I/ Phase II trials. In phase I, Tapsalot gives rapid data collection in a closed system with a relatively small number of devices. My theoretical phase II trial would then be releasing said potential fix to hundreds to thousands with multiple different devices and you could see if the fix works in the "wild" of a beta.
While the robot is a brilliant way to get at actual measurement and to be able to test fixes with a controlled "fixed" input and response. It definitely will be impractical to test on even the few models of iOS, let alone the multiple manufacturers and models of android phones and tablets. If I could suggest, you might be able to use something like the parry training ground to crowd source some data for a beta test. Have something where you have to parry like 10 medium hits from 5-6 different characters and you should be able to gather a bunch of data from hundreds or thousands doing the exact same test on the same characters. I'm not saying this would prevent a robot uprising...but maybe delay it a bit
Unfortunately, it won't help. As we mentioned in the post, there is no way for us to measure this in software because the issue resides between the Game Engine and the Hardware.
Can you please comment on the frequency of planned single player compensation packages while the controls issues persist?
While the robot is a brilliant way to get at actual measurement and to be able to test fixes with a controlled "fixed" input and response. It definitely will be impractical to test on even the few models of iOS, let alone the multiple manufacturers and models of android phones and tablets. If I could suggest, you might be able to use something like the parry training ground to crowd source some data for a beta test. Have something where you have to parry like 10 medium hits from 5-6 different characters and you should be able to gather a bunch of data from hundreds or thousands doing the exact same test on the same characters. I'm not saying this would prevent a robot uprising...but maybe delay it a bit
Unfortunately, it won't help. As we mentioned in the post, there is no way for us to measure this in software because the issue resides between the Game Engine and the Hardware.
Absolutely, I get that you can't actually measure the input timing that way. What I was thinking was more of a way to quantify if the fixes worked for players. So like if you repeated the "Does parry/dex feel better" experiment but instead of asking about feel could measure that it took say 16 mediums to get 10 parries on average for those with the released version, vs say 12 mediums to get 10 parries on the hotfix beta. Then no matter what they say parry felt like you would have data to show that parry was working better with the hotfix.
It just seemed like that type of data (parry success rate) could be gathered, since the training mode already recognizes when you landed a successful parry. But I have no real idea if that data is available under the hood or not.
Tapsalot eliminates the need for that kind of testing. Prior to Tapsalot, the devs had to guess at what changes might have caused a change in player feeling. But now that this can be quantified, either the new build replicates the old timing sufficiently well or it doesn't.
Keep in mind the task for Kabam is not to change the game until everyone's Parry skills improve. The task for Kabam is to replicate the old behavior. If they do and players are still missing Parries, that would be a psychological problem in their heads that the game client can't fix and can only be solved by the players readjusting to the old-new-old normal.
Tapsalot will eliminate that need for testing for any device that can be tested using Tapsalot. Automatically extending results found with an iPhone 12 max to other devices that have not been tested with Tapsalot would decidedly be poor scientific method. It would be like me saying my research using mice is automatically applicable to humans just because both are mammals. And it would seem that expanding the robot army to test the numerous different apple and android phones and tablets would rapidly become cost/time prohibitive.
So really what I was suggesting was like a phase I/ Phase II trials. In phase I, Tapsalot gives rapid data collection in a closed system with a relatively small number of devices. My theoretical phase II trial would then be releasing said potential fix to hundreds to thousands with multiple different devices and you could see if the fix works in the "wild" of a beta.
You'd have to find testers whose feedback meant something. In their limited beta test, humans were statistically incapable of being able to correctly identify when the problem changed or didn't change.
@rockykoston to continue our conversation here, I’m not saying the unity engine only updated for IOS. I’m saying that update only caused the parry dex issue for IOS and not Android. I’d encourage you to read the entire post again, because I’m afraid you’ve misunderstood that aspect. I don’t mean that in a patronising way, just that if you think Kabam are saying Android players don’t have an issue with parry or dex, then you haven’t read the whole thing.
Please read it again, but I’ll direct you to this part which explains the IOS issues.
“ When we refer to the “Parry and Dex issue”, we’re not actually talking about an issue with Parry or Dex, but a framerate and control input issue exclusive to iOS devices that is most noticeable when trying to Parry or Dex, since these are two mechanics players rely on quite often.
Marvel Contest of Champions is built on a 3rd Party Game Engine built by our partners at Unity, which has an input system built-in. We’ve relied on Unity's input system since the game was built, and have regularly updated the Engine as they have released updates. With the most recent update to the Engine, a bug was fixed where iOS devices had been operating at the device’s own frame rate, instead of being capped to 30fps as it was set to. This meant that iOS devices had a slightly different input window than Android devices, but this was never identified.
Since this is how iOS devices had always worked with our game since launch, we had built game interactions around that input window. Now, because this bug in the engine has been fixed, it changed the input window of inputs for all iOS devices and pushed back the input window by mere milliseconds, but that is enough that it is noticeable when playing the game.
This is the issue that we are working to address, and our fix for it is to integrate an entirely new control input system from our partners at Unity. But this is not a quick or easy task.”
Only the IOS input window was pushed back, therefore it cannot be the cause of the Android issues.
Either they've not tested enough or they're afraid to acknowledge that Unity update is affecting android devices.
Now you'd ask why would they not accept it, because of the sheer variety of android devices, models, OS etc. They've never really been able to fix the android issue so if this is the same thing then it's nothing new.
iOS is clearly much easier to identify and fix because of the small environment.
But the fact that they are dismissing android as a generic lag and stutter is what they've been doing forever.
The fact that android now has configurable screen refresh rate with phones going UpTo 144hz and no update to make that compatible, tells us everything.
They are not dismissing Android as a generic lag and stutter problem. And the fact that Android has configurable screen refresh rates means diddly, because the game is built upon Unity. As I'm not a Unity expert (certainly not 2020 era Unity) if there are any out there feel free to correct me, but Unity uses a composite clock. There's one clock that runs the internals of Unity - the physics, the geometry calculations, etc - and another that runs the rendering. In theory you can run the render pass at any refresh rate you want, subject to vsync limitations (to prevent screen tearing) but the update clock cannot run at arbitrary rates. I mean, you can, but if you attempt to run it faster than the platform can calculate you'll get strange behavior, and if you run it at an arbitrary rate calculated dynamically based on how fast the device is you will end up with weird update/render beat-mismatches.
A custom game engine might use a single clock and cram everything into intra-frame calculations, or they might use staggered clocking and perform physics and motion in a divide down clock, but if you attempt that in Unity you'll almost certainly create problems in MCOC because that's basically what's happening in iOS now.
While I'm on the subject of reminding people the game is built on Unity, it is worth pointing out that since Kabam doesn't write Unity, the information that their current Unity build changed timing for iOS comes from Unity. They are the only ones who would know what they changed in any particular Unity build.
Another thing to point out: while anything is possible, if Android has as widespread timing problems as many assert then Tapsalot will find them. Tapsalot does not need to test a thousand different Android devices to find a pervasive Android problem that appears to be affecting a substantial percentage of the Android players of the game. It is just like crystal conspiracies: anything is possible when it comes to one crystal. But a massive crystal rigging conspiracy that is affecting all crystals for all players in noticeable ways is detectable with trivial testing. You can't disprove that one crystal is rigged. But you can disprove that all of them are. Tapsalot changes the Android situation because we no longer need to rely on anecdotes. If there's a pervasive Android problem, Tapsalot will find it. Conversely, if Tapsalot doesn't find it, there is no pervasive Android problem. There might still be rare marginal problems because of Android heterogeneity. But widespread problems affecting a large percentage of Android players can be proven to either exist, or not exist, with certainty. To be honest, such clarity either way will be welcome, at least by those of us interested in the bottom line facts.
Belief doesn't matter. 60% of Android testers thought that one of two *identical* game clients worked noticeably better (and not to pick on Android players, because iOS players appear to be equally vulnerable to that self deception). Belief is for churches, not for troubleshooters.
Your reply is very condescending and patronizing. Thank you for the thoughts and good bye.
Here's my question, if you're told the answer as detailed as humanly possible in an official statement, followed up with specific questions that are answered by a representative from Kabam and given a little more insight by a third party who has prior knowledge in game software development, why are you still reacting as if you're not being told what you want to hear?
Why are you taking this opportunity to just be angry when everyone's giving you as much information as humanly possible? I mean ultimately what would alleviate your concerns or give you the peace of mind that we're all looking for in this moment with everything is going on?
While the robot is a brilliant way to get at actual measurement and to be able to test fixes with a controlled "fixed" input and response. It definitely will be impractical to test on even the few models of iOS, let alone the multiple manufacturers and models of android phones and tablets. If I could suggest, you might be able to use something like the parry training ground to crowd source some data for a beta test. Have something where you have to parry like 10 medium hits from 5-6 different characters and you should be able to gather a bunch of data from hundreds or thousands doing the exact same test on the same characters. I'm not saying this would prevent a robot uprising...but maybe delay it a bit
Unfortunately, it won't help. As we mentioned in the post, there is no way for us to measure this in software because the issue resides between the Game Engine and the Hardware.
Absolutely, I get that you can't actually measure the input timing that way. What I was thinking was more of a way to quantify if the fixes worked for players. So like if you repeated the "Does parry/dex feel better" experiment but instead of asking about feel could measure that it took say 16 mediums to get 10 parries on average for those with the released version, vs say 12 mediums to get 10 parries on the hotfix beta. Then no matter what they say parry felt like you would have data to show that parry was working better with the hotfix.
It just seemed like that type of data (parry success rate) could be gathered, since the training mode already recognizes when you landed a successful parry. But I have no real idea if that data is available under the hood or not.
Tapsalot eliminates the need for that kind of testing. Prior to Tapsalot, the devs had to guess at what changes might have caused a change in player feeling. But now that this can be quantified, either the new build replicates the old timing sufficiently well or it doesn't.
Keep in mind the task for Kabam is not to change the game until everyone's Parry skills improve. The task for Kabam is to replicate the old behavior. If they do and players are still missing Parries, that would be a psychological problem in their heads that the game client can't fix and can only be solved by the players readjusting to the old-new-old normal.
Tapsalot will eliminate that need for testing for any device that can be tested using Tapsalot. Automatically extending results found with an iPhone 12 max to other devices that have not been tested with Tapsalot would decidedly be poor scientific method. It would be like me saying my research using mice is automatically applicable to humans just because both are mammals. And it would seem that expanding the robot army to test the numerous different apple and android phones and tablets would rapidly become cost/time prohibitive.
So really what I was suggesting was like a phase I/ Phase II trials. In phase I, Tapsalot gives rapid data collection in a closed system with a relatively small number of devices. My theoretical phase II trial would then be releasing said potential fix to hundreds to thousands with multiple different devices and you could see if the fix works in the "wild" of a beta.
The problem will ultimately be the people. Even if you announced ahead of time what the intentions the beta and specifically mention how only a handful of people are going to have access to it in comparison to the whole of the community, many will still jump to conclusions that the beta is really a fix and will have multiple threads of "how come mine isn't working when my friends is!?" and then people start complaining about NOT being chosen for the beta and that how do we know the people in the beta are "trustworthy" and turning this into a bigger misunderstanding causing more confusion and duress.
@rockykoston to continue our conversation here, I’m not saying the unity engine only updated for IOS. I’m saying that update only caused the parry dex issue for IOS and not Android. I’d encourage you to read the entire post again, because I’m afraid you’ve misunderstood that aspect. I don’t mean that in a patronising way, just that if you think Kabam are saying Android players don’t have an issue with parry or dex, then you haven’t read the whole thing.
Please read it again, but I’ll direct you to this part which explains the IOS issues.
“ When we refer to the “Parry and Dex issue”, we’re not actually talking about an issue with Parry or Dex, but a framerate and control input issue exclusive to iOS devices that is most noticeable when trying to Parry or Dex, since these are two mechanics players rely on quite often.
Marvel Contest of Champions is built on a 3rd Party Game Engine built by our partners at Unity, which has an input system built-in. We’ve relied on Unity's input system since the game was built, and have regularly updated the Engine as they have released updates. With the most recent update to the Engine, a bug was fixed where iOS devices had been operating at the device’s own frame rate, instead of being capped to 30fps as it was set to. This meant that iOS devices had a slightly different input window than Android devices, but this was never identified.
Since this is how iOS devices had always worked with our game since launch, we had built game interactions around that input window. Now, because this bug in the engine has been fixed, it changed the input window of inputs for all iOS devices and pushed back the input window by mere milliseconds, but that is enough that it is noticeable when playing the game.
This is the issue that we are working to address, and our fix for it is to integrate an entirely new control input system from our partners at Unity. But this is not a quick or easy task.”
Only the IOS input window was pushed back, therefore it cannot be the cause of the Android issues.
Either they've not tested enough or they're afraid to acknowledge that Unity update is affecting android devices.
Now you'd ask why would they not accept it, because of the sheer variety of android devices, models, OS etc. They've never really been able to fix the android issue so if this is the same thing then it's nothing new.
iOS is clearly much easier to identify and fix because of the small environment.
But the fact that they are dismissing android as a generic lag and stutter is what they've been doing forever.
The fact that android now has configurable screen refresh rate with phones going UpTo 144hz and no update to make that compatible, tells us everything.
They are not dismissing Android as a generic lag and stutter problem. And the fact that Android has configurable screen refresh rates means diddly, because the game is built upon Unity. As I'm not a Unity expert (certainly not 2020 era Unity) if there are any out there feel free to correct me, but Unity uses a composite clock. There's one clock that runs the internals of Unity - the physics, the geometry calculations, etc - and another that runs the rendering. In theory you can run the render pass at any refresh rate you want, subject to vsync limitations (to prevent screen tearing) but the update clock cannot run at arbitrary rates. I mean, you can, but if you attempt to run it faster than the platform can calculate you'll get strange behavior, and if you run it at an arbitrary rate calculated dynamically based on how fast the device is you will end up with weird update/render beat-mismatches.
A custom game engine might use a single clock and cram everything into intra-frame calculations, or they might use staggered clocking and perform physics and motion in a divide down clock, but if you attempt that in Unity you'll almost certainly create problems in MCOC because that's basically what's happening in iOS now.
While I'm on the subject of reminding people the game is built on Unity, it is worth pointing out that since Kabam doesn't write Unity, the information that their current Unity build changed timing for iOS comes from Unity. They are the only ones who would know what they changed in any particular Unity build.
Another thing to point out: while anything is possible, if Android has as widespread timing problems as many assert then Tapsalot will find them. Tapsalot does not need to test a thousand different Android devices to find a pervasive Android problem that appears to be affecting a substantial percentage of the Android players of the game. It is just like crystal conspiracies: anything is possible when it comes to one crystal. But a massive crystal rigging conspiracy that is affecting all crystals for all players in noticeable ways is detectable with trivial testing. You can't disprove that one crystal is rigged. But you can disprove that all of them are. Tapsalot changes the Android situation because we no longer need to rely on anecdotes. If there's a pervasive Android problem, Tapsalot will find it. Conversely, if Tapsalot doesn't find it, there is no pervasive Android problem. There might still be rare marginal problems because of Android heterogeneity. But widespread problems affecting a large percentage of Android players can be proven to either exist, or not exist, with certainty. To be honest, such clarity either way will be welcome, at least by those of us interested in the bottom line facts.
Belief doesn't matter. 60% of Android testers thought that one of two *identical* game clients worked noticeably better (and not to pick on Android players, because iOS players appear to be equally vulnerable to that self deception). Belief is for churches, not for troubleshooters.
Your reply is very condescending and patronizing. Thank you for the thoughts and good bye.
Here's my question, if you're told the answer as detailed as humanly possible in an official statement, followed up with specific questions that are answered by a representative from Kabam and given a little more insight by a third party who has prior knowledge in game software development, why are you still reacting as if you're not being told what you want to hear?
Why are you taking this opportunity to just be angry when everyone's giving you as much information as humanly possible? I mean ultimately what would alleviate your concerns or give you the peace of mind that we're all looking for in this moment with everything is going on?
The statement didn't give any test or proof for Android devices like it did for iOS. It means that they have not tested Android yet. Check kabammiike's reply to my post, he clearly states they need to verify more information with unity about Android.
@rockykoston to continue our conversation here, I’m not saying the unity engine only updated for IOS. I’m saying that update only caused the parry dex issue for IOS and not Android. I’d encourage you to read the entire post again, because I’m afraid you’ve misunderstood that aspect. I don’t mean that in a patronising way, just that if you think Kabam are saying Android players don’t have an issue with parry or dex, then you haven’t read the whole thing.
Please read it again, but I’ll direct you to this part which explains the IOS issues.
“ When we refer to the “Parry and Dex issue”, we’re not actually talking about an issue with Parry or Dex, but a framerate and control input issue exclusive to iOS devices that is most noticeable when trying to Parry or Dex, since these are two mechanics players rely on quite often.
Marvel Contest of Champions is built on a 3rd Party Game Engine built by our partners at Unity, which has an input system built-in. We’ve relied on Unity's input system since the game was built, and have regularly updated the Engine as they have released updates. With the most recent update to the Engine, a bug was fixed where iOS devices had been operating at the device’s own frame rate, instead of being capped to 30fps as it was set to. This meant that iOS devices had a slightly different input window than Android devices, but this was never identified.
Since this is how iOS devices had always worked with our game since launch, we had built game interactions around that input window. Now, because this bug in the engine has been fixed, it changed the input window of inputs for all iOS devices and pushed back the input window by mere milliseconds, but that is enough that it is noticeable when playing the game.
This is the issue that we are working to address, and our fix for it is to integrate an entirely new control input system from our partners at Unity. But this is not a quick or easy task.”
Only the IOS input window was pushed back, therefore it cannot be the cause of the Android issues.
Either they've not tested enough or they're afraid to acknowledge that Unity update is affecting android devices.
Now you'd ask why would they not accept it, because of the sheer variety of android devices, models, OS etc. They've never really been able to fix the android issue so if this is the same thing then it's nothing new.
iOS is clearly much easier to identify and fix because of the small environment.
But the fact that they are dismissing android as a generic lag and stutter is what they've been doing forever.
The fact that android now has configurable screen refresh rate with phones going UpTo 144hz and no update to make that compatible, tells us everything.
They are not dismissing Android as a generic lag and stutter problem. And the fact that Android has configurable screen refresh rates means diddly, because the game is built upon Unity. As I'm not a Unity expert (certainly not 2020 era Unity) if there are any out there feel free to correct me, but Unity uses a composite clock. There's one clock that runs the internals of Unity - the physics, the geometry calculations, etc - and another that runs the rendering. In theory you can run the render pass at any refresh rate you want, subject to vsync limitations (to prevent screen tearing) but the update clock cannot run at arbitrary rates. I mean, you can, but if you attempt to run it faster than the platform can calculate you'll get strange behavior, and if you run it at an arbitrary rate calculated dynamically based on how fast the device is you will end up with weird update/render beat-mismatches.
A custom game engine might use a single clock and cram everything into intra-frame calculations, or they might use staggered clocking and perform physics and motion in a divide down clock, but if you attempt that in Unity you'll almost certainly create problems in MCOC because that's basically what's happening in iOS now.
While I'm on the subject of reminding people the game is built on Unity, it is worth pointing out that since Kabam doesn't write Unity, the information that their current Unity build changed timing for iOS comes from Unity. They are the only ones who would know what they changed in any particular Unity build.
Another thing to point out: while anything is possible, if Android has as widespread timing problems as many assert then Tapsalot will find them. Tapsalot does not need to test a thousand different Android devices to find a pervasive Android problem that appears to be affecting a substantial percentage of the Android players of the game. It is just like crystal conspiracies: anything is possible when it comes to one crystal. But a massive crystal rigging conspiracy that is affecting all crystals for all players in noticeable ways is detectable with trivial testing. You can't disprove that one crystal is rigged. But you can disprove that all of them are. Tapsalot changes the Android situation because we no longer need to rely on anecdotes. If there's a pervasive Android problem, Tapsalot will find it. Conversely, if Tapsalot doesn't find it, there is no pervasive Android problem. There might still be rare marginal problems because of Android heterogeneity. But widespread problems affecting a large percentage of Android players can be proven to either exist, or not exist, with certainty. To be honest, such clarity either way will be welcome, at least by those of us interested in the bottom line facts.
Belief doesn't matter. 60% of Android testers thought that one of two *identical* game clients worked noticeably better (and not to pick on Android players, because iOS players appear to be equally vulnerable to that self deception). Belief is for churches, not for troubleshooters.
Your reply is very condescending and patronizing. Thank you for the thoughts and good bye.
Here's my question, if you're told the answer as detailed as humanly possible in an official statement, followed up with specific questions that are answered by a representative from Kabam and given a little more insight by a third party who has prior knowledge in game software development, why are you still reacting as if you're not being told what you want to hear?
Why are you taking this opportunity to just be angry when everyone's giving you as much information as humanly possible? I mean ultimately what would alleviate your concerns or give you the peace of mind that we're all looking for in this moment with everything is going on?
The statement didn't give any test or proof for Android devices like it did for iOS. It means that they have not tested Android yet. Check kabammiike's reply to my post, he clearly states they need to verify more information with unity about Android.
Don't be like that.
And if Unity says hey we're not seeing any problems with Android and it's a separate thing altogether, will you finally accept that as an actual answer or are you going to still demand answers where none exists?
@rockykoston to continue our conversation here, I’m not saying the unity engine only updated for IOS. I’m saying that update only caused the parry dex issue for IOS and not Android. I’d encourage you to read the entire post again, because I’m afraid you’ve misunderstood that aspect. I don’t mean that in a patronising way, just that if you think Kabam are saying Android players don’t have an issue with parry or dex, then you haven’t read the whole thing.
Please read it again, but I’ll direct you to this part which explains the IOS issues.
“ When we refer to the “Parry and Dex issue”, we’re not actually talking about an issue with Parry or Dex, but a framerate and control input issue exclusive to iOS devices that is most noticeable when trying to Parry or Dex, since these are two mechanics players rely on quite often.
Marvel Contest of Champions is built on a 3rd Party Game Engine built by our partners at Unity, which has an input system built-in. We’ve relied on Unity's input system since the game was built, and have regularly updated the Engine as they have released updates. With the most recent update to the Engine, a bug was fixed where iOS devices had been operating at the device’s own frame rate, instead of being capped to 30fps as it was set to. This meant that iOS devices had a slightly different input window than Android devices, but this was never identified.
Since this is how iOS devices had always worked with our game since launch, we had built game interactions around that input window. Now, because this bug in the engine has been fixed, it changed the input window of inputs for all iOS devices and pushed back the input window by mere milliseconds, but that is enough that it is noticeable when playing the game.
This is the issue that we are working to address, and our fix for it is to integrate an entirely new control input system from our partners at Unity. But this is not a quick or easy task.”
Only the IOS input window was pushed back, therefore it cannot be the cause of the Android issues.
Either they've not tested enough or they're afraid to acknowledge that Unity update is affecting android devices.
Now you'd ask why would they not accept it, because of the sheer variety of android devices, models, OS etc. They've never really been able to fix the android issue so if this is the same thing then it's nothing new.
iOS is clearly much easier to identify and fix because of the small environment.
But the fact that they are dismissing android as a generic lag and stutter is what they've been doing forever.
The fact that android now has configurable screen refresh rate with phones going UpTo 144hz and no update to make that compatible, tells us everything.
They are not dismissing Android as a generic lag and stutter problem. And the fact that Android has configurable screen refresh rates means diddly, because the game is built upon Unity. As I'm not a Unity expert (certainly not 2020 era Unity) if there are any out there feel free to correct me, but Unity uses a composite clock. There's one clock that runs the internals of Unity - the physics, the geometry calculations, etc - and another that runs the rendering. In theory you can run the render pass at any refresh rate you want, subject to vsync limitations (to prevent screen tearing) but the update clock cannot run at arbitrary rates. I mean, you can, but if you attempt to run it faster than the platform can calculate you'll get strange behavior, and if you run it at an arbitrary rate calculated dynamically based on how fast the device is you will end up with weird update/render beat-mismatches.
A custom game engine might use a single clock and cram everything into intra-frame calculations, or they might use staggered clocking and perform physics and motion in a divide down clock, but if you attempt that in Unity you'll almost certainly create problems in MCOC because that's basically what's happening in iOS now.
While I'm on the subject of reminding people the game is built on Unity, it is worth pointing out that since Kabam doesn't write Unity, the information that their current Unity build changed timing for iOS comes from Unity. They are the only ones who would know what they changed in any particular Unity build.
Another thing to point out: while anything is possible, if Android has as widespread timing problems as many assert then Tapsalot will find them. Tapsalot does not need to test a thousand different Android devices to find a pervasive Android problem that appears to be affecting a substantial percentage of the Android players of the game. It is just like crystal conspiracies: anything is possible when it comes to one crystal. But a massive crystal rigging conspiracy that is affecting all crystals for all players in noticeable ways is detectable with trivial testing. You can't disprove that one crystal is rigged. But you can disprove that all of them are. Tapsalot changes the Android situation because we no longer need to rely on anecdotes. If there's a pervasive Android problem, Tapsalot will find it. Conversely, if Tapsalot doesn't find it, there is no pervasive Android problem. There might still be rare marginal problems because of Android heterogeneity. But widespread problems affecting a large percentage of Android players can be proven to either exist, or not exist, with certainty. To be honest, such clarity either way will be welcome, at least by those of us interested in the bottom line facts.
Belief doesn't matter. 60% of Android testers thought that one of two *identical* game clients worked noticeably better (and not to pick on Android players, because iOS players appear to be equally vulnerable to that self deception). Belief is for churches, not for troubleshooters.
Your reply is very condescending and patronizing. Thank you for the thoughts and good bye.
Here's my question, if you're told the answer as detailed as humanly possible in an official statement, followed up with specific questions that are answered by a representative from Kabam and given a little more insight by a third party who has prior knowledge in game software development, why are you still reacting as if you're not being told what you want to hear?
Why are you taking this opportunity to just be angry when everyone's giving you as much information as humanly possible? I mean ultimately what would alleviate your concerns or give you the peace of mind that we're all looking for in this moment with everything is going on?
The statement didn't give any test or proof for Android devices like it did for iOS. It means that they have not tested Android yet. Check kabammiike's reply to my post, he clearly states they need to verify more information with unity about Android.
Don't be like that.
When talking about the beta test they did with iOS and Android users:
“Data also showed that many Android users felt that Parry or Dex felt better or worse, but as far as we know, this issue does not affect Android users.”
@rockykoston to continue our conversation here, I’m not saying the unity engine only updated for IOS. I’m saying that update only caused the parry dex issue for IOS and not Android. I’d encourage you to read the entire post again, because I’m afraid you’ve misunderstood that aspect. I don’t mean that in a patronising way, just that if you think Kabam are saying Android players don’t have an issue with parry or dex, then you haven’t read the whole thing.
Please read it again, but I’ll direct you to this part which explains the IOS issues.
“ When we refer to the “Parry and Dex issue”, we’re not actually talking about an issue with Parry or Dex, but a framerate and control input issue exclusive to iOS devices that is most noticeable when trying to Parry or Dex, since these are two mechanics players rely on quite often.
Marvel Contest of Champions is built on a 3rd Party Game Engine built by our partners at Unity, which has an input system built-in. We’ve relied on Unity's input system since the game was built, and have regularly updated the Engine as they have released updates. With the most recent update to the Engine, a bug was fixed where iOS devices had been operating at the device’s own frame rate, instead of being capped to 30fps as it was set to. This meant that iOS devices had a slightly different input window than Android devices, but this was never identified.
Since this is how iOS devices had always worked with our game since launch, we had built game interactions around that input window. Now, because this bug in the engine has been fixed, it changed the input window of inputs for all iOS devices and pushed back the input window by mere milliseconds, but that is enough that it is noticeable when playing the game.
This is the issue that we are working to address, and our fix for it is to integrate an entirely new control input system from our partners at Unity. But this is not a quick or easy task.”
Only the IOS input window was pushed back, therefore it cannot be the cause of the Android issues.
Either they've not tested enough or they're afraid to acknowledge that Unity update is affecting android devices.
Now you'd ask why would they not accept it, because of the sheer variety of android devices, models, OS etc. They've never really been able to fix the android issue so if this is the same thing then it's nothing new.
iOS is clearly much easier to identify and fix because of the small environment.
But the fact that they are dismissing android as a generic lag and stutter is what they've been doing forever.
The fact that android now has configurable screen refresh rate with phones going UpTo 144hz and no update to make that compatible, tells us everything.
They are not dismissing Android as a generic lag and stutter problem. And the fact that Android has configurable screen refresh rates means diddly, because the game is built upon Unity. As I'm not a Unity expert (certainly not 2020 era Unity) if there are any out there feel free to correct me, but Unity uses a composite clock. There's one clock that runs the internals of Unity - the physics, the geometry calculations, etc - and another that runs the rendering. In theory you can run the render pass at any refresh rate you want, subject to vsync limitations (to prevent screen tearing) but the update clock cannot run at arbitrary rates. I mean, you can, but if you attempt to run it faster than the platform can calculate you'll get strange behavior, and if you run it at an arbitrary rate calculated dynamically based on how fast the device is you will end up with weird update/render beat-mismatches.
A custom game engine might use a single clock and cram everything into intra-frame calculations, or they might use staggered clocking and perform physics and motion in a divide down clock, but if you attempt that in Unity you'll almost certainly create problems in MCOC because that's basically what's happening in iOS now.
While I'm on the subject of reminding people the game is built on Unity, it is worth pointing out that since Kabam doesn't write Unity, the information that their current Unity build changed timing for iOS comes from Unity. They are the only ones who would know what they changed in any particular Unity build.
Another thing to point out: while anything is possible, if Android has as widespread timing problems as many assert then Tapsalot will find them. Tapsalot does not need to test a thousand different Android devices to find a pervasive Android problem that appears to be affecting a substantial percentage of the Android players of the game. It is just like crystal conspiracies: anything is possible when it comes to one crystal. But a massive crystal rigging conspiracy that is affecting all crystals for all players in noticeable ways is detectable with trivial testing. You can't disprove that one crystal is rigged. But you can disprove that all of them are. Tapsalot changes the Android situation because we no longer need to rely on anecdotes. If there's a pervasive Android problem, Tapsalot will find it. Conversely, if Tapsalot doesn't find it, there is no pervasive Android problem. There might still be rare marginal problems because of Android heterogeneity. But widespread problems affecting a large percentage of Android players can be proven to either exist, or not exist, with certainty. To be honest, such clarity either way will be welcome, at least by those of us interested in the bottom line facts.
Belief doesn't matter. 60% of Android testers thought that one of two *identical* game clients worked noticeably better (and not to pick on Android players, because iOS players appear to be equally vulnerable to that self deception). Belief is for churches, not for troubleshooters.
Your reply is very condescending and patronizing. Thank you for the thoughts and good bye.
The post I was replying to was factually inaccurate and drawing inexplicable conclusions with unjustified confidence. Condescension is very difficult to avoid in that situation. Be less certain or less wrong or preferably both, or condescension will be a constant companion in your life.
There's no need to reply anymore because clearly you're not equipped enough, all your statement are based on assumptions and conjecture.
Ignorance is bliss, stay that way.
Is this art imitating life? His responses are based on an extensive knowledge of these things. You can say what you will about DNA, but he's like an Ent. He doesn't say anything that isn't worth taking the time to say.
@rockykoston to continue our conversation here, I’m not saying the unity engine only updated for IOS. I’m saying that update only caused the parry dex issue for IOS and not Android. I’d encourage you to read the entire post again, because I’m afraid you’ve misunderstood that aspect. I don’t mean that in a patronising way, just that if you think Kabam are saying Android players don’t have an issue with parry or dex, then you haven’t read the whole thing.
Please read it again, but I’ll direct you to this part which explains the IOS issues.
“ When we refer to the “Parry and Dex issue”, we’re not actually talking about an issue with Parry or Dex, but a framerate and control input issue exclusive to iOS devices that is most noticeable when trying to Parry or Dex, since these are two mechanics players rely on quite often.
Marvel Contest of Champions is built on a 3rd Party Game Engine built by our partners at Unity, which has an input system built-in. We’ve relied on Unity's input system since the game was built, and have regularly updated the Engine as they have released updates. With the most recent update to the Engine, a bug was fixed where iOS devices had been operating at the device’s own frame rate, instead of being capped to 30fps as it was set to. This meant that iOS devices had a slightly different input window than Android devices, but this was never identified.
Since this is how iOS devices had always worked with our game since launch, we had built game interactions around that input window. Now, because this bug in the engine has been fixed, it changed the input window of inputs for all iOS devices and pushed back the input window by mere milliseconds, but that is enough that it is noticeable when playing the game.
This is the issue that we are working to address, and our fix for it is to integrate an entirely new control input system from our partners at Unity. But this is not a quick or easy task.”
Only the IOS input window was pushed back, therefore it cannot be the cause of the Android issues.
Either they've not tested enough or they're afraid to acknowledge that Unity update is affecting android devices.
Now you'd ask why would they not accept it, because of the sheer variety of android devices, models, OS etc. They've never really been able to fix the android issue so if this is the same thing then it's nothing new.
iOS is clearly much easier to identify and fix because of the small environment.
But the fact that they are dismissing android as a generic lag and stutter is what they've been doing forever.
The fact that android now has configurable screen refresh rate with phones going UpTo 144hz and no update to make that compatible, tells us everything.
They are not dismissing Android as a generic lag and stutter problem. And the fact that Android has configurable screen refresh rates means diddly, because the game is built upon Unity. As I'm not a Unity expert (certainly not 2020 era Unity) if there are any out there feel free to correct me, but Unity uses a composite clock. There's one clock that runs the internals of Unity - the physics, the geometry calculations, etc - and another that runs the rendering. In theory you can run the render pass at any refresh rate you want, subject to vsync limitations (to prevent screen tearing) but the update clock cannot run at arbitrary rates. I mean, you can, but if you attempt to run it faster than the platform can calculate you'll get strange behavior, and if you run it at an arbitrary rate calculated dynamically based on how fast the device is you will end up with weird update/render beat-mismatches.
A custom game engine might use a single clock and cram everything into intra-frame calculations, or they might use staggered clocking and perform physics and motion in a divide down clock, but if you attempt that in Unity you'll almost certainly create problems in MCOC because that's basically what's happening in iOS now.
While I'm on the subject of reminding people the game is built on Unity, it is worth pointing out that since Kabam doesn't write Unity, the information that their current Unity build changed timing for iOS comes from Unity. They are the only ones who would know what they changed in any particular Unity build.
Another thing to point out: while anything is possible, if Android has as widespread timing problems as many assert then Tapsalot will find them. Tapsalot does not need to test a thousand different Android devices to find a pervasive Android problem that appears to be affecting a substantial percentage of the Android players of the game. It is just like crystal conspiracies: anything is possible when it comes to one crystal. But a massive crystal rigging conspiracy that is affecting all crystals for all players in noticeable ways is detectable with trivial testing. You can't disprove that one crystal is rigged. But you can disprove that all of them are. Tapsalot changes the Android situation because we no longer need to rely on anecdotes. If there's a pervasive Android problem, Tapsalot will find it. Conversely, if Tapsalot doesn't find it, there is no pervasive Android problem. There might still be rare marginal problems because of Android heterogeneity. But widespread problems affecting a large percentage of Android players can be proven to either exist, or not exist, with certainty. To be honest, such clarity either way will be welcome, at least by those of us interested in the bottom line facts.
Belief doesn't matter. 60% of Android testers thought that one of two *identical* game clients worked noticeably better (and not to pick on Android players, because iOS players appear to be equally vulnerable to that self deception). Belief is for churches, not for troubleshooters.
Your reply is very condescending and patronizing. Thank you for the thoughts and good bye.
Here's my question, if you're told the answer as detailed as humanly possible in an official statement, followed up with specific questions that are answered by a representative from Kabam and given a little more insight by a third party who has prior knowledge in game software development, why are you still reacting as if you're not being told what you want to hear?
Why are you taking this opportunity to just be angry when everyone's giving you as much information as humanly possible? I mean ultimately what would alleviate your concerns or give you the peace of mind that we're all looking for in this moment with everything is going on?
The statement didn't give any test or proof for Android devices like it did for iOS. It means that they have not tested Android yet. Check kabammiike's reply to my post, he clearly states they need to verify more information with unity about Android.
Don't be like that.
When talking about the beta test they did with iOS and Android users:
“Data also showed that many Android users felt that Parry or Dex felt better or worse, but as far as we know, this issue does not affect Android users.”
"As far as we know"
I don't think they've gone far enough, that's all.
I use Android and didn't feel like I was having any issues beyond the ongoing Android issues that we have had for years now when everyone else was talking about how bad things had become. When they released the first "fix" I had no reason to believe that it would change anything for me for better or worse because I wasn't seeing the new consistent and widespread issues everyone else had suddenly been talking about.
As soon as I had the update installed I began to have intermittent issues with parry not causing stun even though it did block (a few times could obviously be a timing issue on my part but not with the frequency it was occuring), parry/block not occuring at all, my champ freezing in place when I tried to attack/use special/move, my champ moving the opposite direction of the way I swiped, increased lag/freezing/stuttering and basically every other issue that has since been reported. Again, I acknowledge that some of these issues if happening much more infrequently could be user error but not with the amount of times these things were all suddenly happening.
I understand they have said the Unity people said they only changed a bug with iOS but I don't believe for a second that I am just suffering from a psychological delusion that these things are happening so much worse for me all of a sudden when as I said I expected absolutely nothing to change for me with the first fix since I wasn't experiencing those issues before the fix like apparently only the iOS people were.
I am curious as to whether Kabam are going to investigate whether whatever was in the fix download I had to install could be responsible for the issues that I and other Android players have reported as starting AFTER the fix and not just say that we are either suffering from the memory leak issues that I believe they are saying were either ongoing for quite a while or had started with the engine update or that these suddenly much worse issues are just the same as has been going on for years. Many of us have indicated a clear difference for the worse after the fix as opposed to saying we had the problems all along that Kabam are saying really only affected iOS players.
Lastly, I am still quite curious as to the reasoning behind stopping the aq packages but starting the aw ones before finally (hopefully) restarting the aq packages on a regular basis as well as why the packages for regular content are not a weekly thing as well. If the thought process behind not providing much (or regular) solo content potions and revives is that it is long term content so we just shouldn't do it until/if you fix things if our game doesn't work well enough unlike the aq/aw content that needs done each week I would like to point out that that doesn't apply to EQ and given your emphasis on pushing players to complete harder solo content to advance to uncollected/cavalier/throne breaker to get better rewards/offers/compensation/etc it isn't really fair to say to wait on doing that content either.
Unless you plan on giving everyone the highest rewards regardless of their progress level or level of content they can currently complete with the game issues (which would be ridiculous) it seems only fair to regularly provide solo content packages until the vast majority of players on ALL device types have their newish issues resolved because telling us to hold still with our progress if things are too messed up for months more to come while at the same time saying if we want better rewards we need to push forward is pure cognitive dissonance. As long as you admit the game is messed up so much that we need assistance in one mode you shouldn't be claiming it is not an equal issue in other modes when we are all aware the issues are not content specific.
@rockykoston to continue our conversation here, I’m not saying the unity engine only updated for IOS. I’m saying that update only caused the parry dex issue for IOS and not Android. I’d encourage you to read the entire post again, because I’m afraid you’ve misunderstood that aspect. I don’t mean that in a patronising way, just that if you think Kabam are saying Android players don’t have an issue with parry or dex, then you haven’t read the whole thing.
Please read it again, but I’ll direct you to this part which explains the IOS issues.
“ When we refer to the “Parry and Dex issue”, we’re not actually talking about an issue with Parry or Dex, but a framerate and control input issue exclusive to iOS devices that is most noticeable when trying to Parry or Dex, since these are two mechanics players rely on quite often.
Marvel Contest of Champions is built on a 3rd Party Game Engine built by our partners at Unity, which has an input system built-in. We’ve relied on Unity's input system since the game was built, and have regularly updated the Engine as they have released updates. With the most recent update to the Engine, a bug was fixed where iOS devices had been operating at the device’s own frame rate, instead of being capped to 30fps as it was set to. This meant that iOS devices had a slightly different input window than Android devices, but this was never identified.
Since this is how iOS devices had always worked with our game since launch, we had built game interactions around that input window. Now, because this bug in the engine has been fixed, it changed the input window of inputs for all iOS devices and pushed back the input window by mere milliseconds, but that is enough that it is noticeable when playing the game.
This is the issue that we are working to address, and our fix for it is to integrate an entirely new control input system from our partners at Unity. But this is not a quick or easy task.”
Only the IOS input window was pushed back, therefore it cannot be the cause of the Android issues.
Either they've not tested enough or they're afraid to acknowledge that Unity update is affecting android devices.
Now you'd ask why would they not accept it, because of the sheer variety of android devices, models, OS etc. They've never really been able to fix the android issue so if this is the same thing then it's nothing new.
iOS is clearly much easier to identify and fix because of the small environment.
But the fact that they are dismissing android as a generic lag and stutter is what they've been doing forever.
The fact that android now has configurable screen refresh rate with phones going UpTo 144hz and no update to make that compatible, tells us everything.
They are not dismissing Android as a generic lag and stutter problem. And the fact that Android has configurable screen refresh rates means diddly, because the game is built upon Unity. As I'm not a Unity expert (certainly not 2020 era Unity) if there are any out there feel free to correct me, but Unity uses a composite clock. There's one clock that runs the internals of Unity - the physics, the geometry calculations, etc - and another that runs the rendering. In theory you can run the render pass at any refresh rate you want, subject to vsync limitations (to prevent screen tearing) but the update clock cannot run at arbitrary rates. I mean, you can, but if you attempt to run it faster than the platform can calculate you'll get strange behavior, and if you run it at an arbitrary rate calculated dynamically based on how fast the device is you will end up with weird update/render beat-mismatches.
A custom game engine might use a single clock and cram everything into intra-frame calculations, or they might use staggered clocking and perform physics and motion in a divide down clock, but if you attempt that in Unity you'll almost certainly create problems in MCOC because that's basically what's happening in iOS now.
While I'm on the subject of reminding people the game is built on Unity, it is worth pointing out that since Kabam doesn't write Unity, the information that their current Unity build changed timing for iOS comes from Unity. They are the only ones who would know what they changed in any particular Unity build.
Another thing to point out: while anything is possible, if Android has as widespread timing problems as many assert then Tapsalot will find them. Tapsalot does not need to test a thousand different Android devices to find a pervasive Android problem that appears to be affecting a substantial percentage of the Android players of the game. It is just like crystal conspiracies: anything is possible when it comes to one crystal. But a massive crystal rigging conspiracy that is affecting all crystals for all players in noticeable ways is detectable with trivial testing. You can't disprove that one crystal is rigged. But you can disprove that all of them are. Tapsalot changes the Android situation because we no longer need to rely on anecdotes. If there's a pervasive Android problem, Tapsalot will find it. Conversely, if Tapsalot doesn't find it, there is no pervasive Android problem. There might still be rare marginal problems because of Android heterogeneity. But widespread problems affecting a large percentage of Android players can be proven to either exist, or not exist, with certainty. To be honest, such clarity either way will be welcome, at least by those of us interested in the bottom line facts.
Belief doesn't matter. 60% of Android testers thought that one of two *identical* game clients worked noticeably better (and not to pick on Android players, because iOS players appear to be equally vulnerable to that self deception). Belief is for churches, not for troubleshooters.
Your reply is very condescending and patronizing. Thank you for the thoughts and good bye.
Here's my question, if you're told the answer as detailed as humanly possible in an official statement, followed up with specific questions that are answered by a representative from Kabam and given a little more insight by a third party who has prior knowledge in game software development, why are you still reacting as if you're not being told what you want to hear?
Why are you taking this opportunity to just be angry when everyone's giving you as much information as humanly possible? I mean ultimately what would alleviate your concerns or give you the peace of mind that we're all looking for in this moment with everything is going on?
The statement didn't give any test or proof for Android devices like it did for iOS. It means that they have not tested Android yet. Check kabammiike's reply to my post, he clearly states they need to verify more information with unity about Android.
Don't be like that.
And if Unity says hey we're not seeing any problems with Android and it's a separate thing altogether, will you finally accept that as an actual answer or are you going to still demand answers where none exists?
First off, if kabam is starting a trend of showing us response time graphs, windows etc. i.e. test scenarios, I want to see that they share with us the same test scenarios for Android as well whether they pass or fail or whatever is the observation in the tests.
Once that tests are shared with the users and we actually have all the information for both platforms, it'll be clear whether the issue only exists in IOS or not.
Until then the issue is on iOS and Android had the generic stutter/lag issue.
Yes, unity can provide their input but that'll depend on the data that kabam shares with them, so if we're going for transparency and barring IP rights, we need to see that data for Android as well. Thank you for reading.
While the robot is a brilliant way to get at actual measurement and to be able to test fixes with a controlled "fixed" input and response. It definitely will be impractical to test on even the few models of iOS, let alone the multiple manufacturers and models of android phones and tablets. If I could suggest, you might be able to use something like the parry training ground to crowd source some data for a beta test. Have something where you have to parry like 10 medium hits from 5-6 different characters and you should be able to gather a bunch of data from hundreds or thousands doing the exact same test on the same characters. I'm not saying this would prevent a robot uprising...but maybe delay it a bit
Unfortunately, it won't help. As we mentioned in the post, there is no way for us to measure this in software because the issue resides between the Game Engine and the Hardware.
Absolutely, I get that you can't actually measure the input timing that way. What I was thinking was more of a way to quantify if the fixes worked for players. So like if you repeated the "Does parry/dex feel better" experiment but instead of asking about feel could measure that it took say 16 mediums to get 10 parries on average for those with the released version, vs say 12 mediums to get 10 parries on the hotfix beta. Then no matter what they say parry felt like you would have data to show that parry was working better with the hotfix.
It just seemed like that type of data (parry success rate) could be gathered, since the training mode already recognizes when you landed a successful parry. But I have no real idea if that data is available under the hood or not.
Tapsalot eliminates the need for that kind of testing. Prior to Tapsalot, the devs had to guess at what changes might have caused a change in player feeling. But now that this can be quantified, either the new build replicates the old timing sufficiently well or it doesn't.
Keep in mind the task for Kabam is not to change the game until everyone's Parry skills improve. The task for Kabam is to replicate the old behavior. If they do and players are still missing Parries, that would be a psychological problem in their heads that the game client can't fix and can only be solved by the players readjusting to the old-new-old normal.
Tapsalot will eliminate that need for testing for any device that can be tested using Tapsalot. Automatically extending results found with an iPhone 12 max to other devices that have not been tested with Tapsalot would decidedly be poor scientific method. It would be like me saying my research using mice is automatically applicable to humans just because both are mammals. And it would seem that expanding the robot army to test the numerous different apple and android phones and tablets would rapidly become cost/time prohibitive.
So really what I was suggesting was like a phase I/ Phase II trials. In phase I, Tapsalot gives rapid data collection in a closed system with a relatively small number of devices. My theoretical phase II trial would then be releasing said potential fix to hundreds to thousands with multiple different devices and you could see if the fix works in the "wild" of a beta.
You'd have to find testers whose feedback meant something. In their limited beta test, humans were statistically incapable of being able to correctly identify when the problem changed or didn't change.
Which is exactly why you would never use any sort of feeling or self reported response for the data. It would only be measuring, in this theoretical trial, parry success rate or the number of medium attacks to get 10 parries. As long as the groups each include a similar cross section of the player base the average across each group should represent the actual difference between the current and potential fixed versions. Granted any study using humans as subjects will be biased as you can only include people who actually want to be included. But if you look at an actual test of a measurable skill vs asking how does it feel, you should get a reasonable approximation of how that change is working in a live version with people on different devices with different levels of wifi or cellular data, which should be a wider pool than could be done with Tapsalot.
@rockykoston to continue our conversation here, I’m not saying the unity engine only updated for IOS. I’m saying that update only caused the parry dex issue for IOS and not Android. I’d encourage you to read the entire post again, because I’m afraid you’ve misunderstood that aspect. I don’t mean that in a patronising way, just that if you think Kabam are saying Android players don’t have an issue with parry or dex, then you haven’t read the whole thing.
Please read it again, but I’ll direct you to this part which explains the IOS issues.
“ When we refer to the “Parry and Dex issue”, we’re not actually talking about an issue with Parry or Dex, but a framerate and control input issue exclusive to iOS devices that is most noticeable when trying to Parry or Dex, since these are two mechanics players rely on quite often.
Marvel Contest of Champions is built on a 3rd Party Game Engine built by our partners at Unity, which has an input system built-in. We’ve relied on Unity's input system since the game was built, and have regularly updated the Engine as they have released updates. With the most recent update to the Engine, a bug was fixed where iOS devices had been operating at the device’s own frame rate, instead of being capped to 30fps as it was set to. This meant that iOS devices had a slightly different input window than Android devices, but this was never identified.
Since this is how iOS devices had always worked with our game since launch, we had built game interactions around that input window. Now, because this bug in the engine has been fixed, it changed the input window of inputs for all iOS devices and pushed back the input window by mere milliseconds, but that is enough that it is noticeable when playing the game.
This is the issue that we are working to address, and our fix for it is to integrate an entirely new control input system from our partners at Unity. But this is not a quick or easy task.”
Only the IOS input window was pushed back, therefore it cannot be the cause of the Android issues.
Either they've not tested enough or they're afraid to acknowledge that Unity update is affecting android devices.
Now you'd ask why would they not accept it, because of the sheer variety of android devices, models, OS etc. They've never really been able to fix the android issue so if this is the same thing then it's nothing new.
iOS is clearly much easier to identify and fix because of the small environment.
But the fact that they are dismissing android as a generic lag and stutter is what they've been doing forever.
The fact that android now has configurable screen refresh rate with phones going UpTo 144hz and no update to make that compatible, tells us everything.
They are not dismissing Android as a generic lag and stutter problem. And the fact that Android has configurable screen refresh rates means diddly, because the game is built upon Unity. As I'm not a Unity expert (certainly not 2020 era Unity) if there are any out there feel free to correct me, but Unity uses a composite clock. There's one clock that runs the internals of Unity - the physics, the geometry calculations, etc - and another that runs the rendering. In theory you can run the render pass at any refresh rate you want, subject to vsync limitations (to prevent screen tearing) but the update clock cannot run at arbitrary rates. I mean, you can, but if you attempt to run it faster than the platform can calculate you'll get strange behavior, and if you run it at an arbitrary rate calculated dynamically based on how fast the device is you will end up with weird update/render beat-mismatches.
A custom game engine might use a single clock and cram everything into intra-frame calculations, or they might use staggered clocking and perform physics and motion in a divide down clock, but if you attempt that in Unity you'll almost certainly create problems in MCOC because that's basically what's happening in iOS now.
While I'm on the subject of reminding people the game is built on Unity, it is worth pointing out that since Kabam doesn't write Unity, the information that their current Unity build changed timing for iOS comes from Unity. They are the only ones who would know what they changed in any particular Unity build.
Another thing to point out: while anything is possible, if Android has as widespread timing problems as many assert then Tapsalot will find them. Tapsalot does not need to test a thousand different Android devices to find a pervasive Android problem that appears to be affecting a substantial percentage of the Android players of the game. It is just like crystal conspiracies: anything is possible when it comes to one crystal. But a massive crystal rigging conspiracy that is affecting all crystals for all players in noticeable ways is detectable with trivial testing. You can't disprove that one crystal is rigged. But you can disprove that all of them are. Tapsalot changes the Android situation because we no longer need to rely on anecdotes. If there's a pervasive Android problem, Tapsalot will find it. Conversely, if Tapsalot doesn't find it, there is no pervasive Android problem. There might still be rare marginal problems because of Android heterogeneity. But widespread problems affecting a large percentage of Android players can be proven to either exist, or not exist, with certainty. To be honest, such clarity either way will be welcome, at least by those of us interested in the bottom line facts.
Belief doesn't matter. 60% of Android testers thought that one of two *identical* game clients worked noticeably better (and not to pick on Android players, because iOS players appear to be equally vulnerable to that self deception). Belief is for churches, not for troubleshooters.
Your reply is very condescending and patronizing. Thank you for the thoughts and good bye.
Here's my question, if you're told the answer as detailed as humanly possible in an official statement, followed up with specific questions that are answered by a representative from Kabam and given a little more insight by a third party who has prior knowledge in game software development, why are you still reacting as if you're not being told what you want to hear?
Why are you taking this opportunity to just be angry when everyone's giving you as much information as humanly possible? I mean ultimately what would alleviate your concerns or give you the peace of mind that we're all looking for in this moment with everything is going on?
The statement didn't give any test or proof for Android devices like it did for iOS. It means that they have not tested Android yet. Check kabammiike's reply to my post, he clearly states they need to verify more information with unity about Android.
Don't be like that.
When talking about the beta test they did with iOS and Android users:
“Data also showed that many Android users felt that Parry or Dex felt better or worse, but as far as we know, this issue does not affect Android users.”
"As far as we know"
I don't think they've gone far enough, that's all.
You’re moving the goalposts now, first it was they haven’t tested Android, then it’s they haven’t gone far enough to test android.
I think it’s evident you just want to believe your opinion no matter what counterpoints are given to you. You call people who correct you patronising and condescending for taking the time to inform you. It’s ok to be wrong, it’s not ok to be wrong in the face of evidence. I don’t see much point continuing this conversation.
The evidence points to Android not having the issue caused by the unity update based on Kabams own confirmation, you can continue believing you know better based on absolutely nothing, but I know where I’d wager my money.
@rockykoston to continue our conversation here, I’m not saying the unity engine only updated for IOS. I’m saying that update only caused the parry dex issue for IOS and not Android. I’d encourage you to read the entire post again, because I’m afraid you’ve misunderstood that aspect. I don’t mean that in a patronising way, just that if you think Kabam are saying Android players don’t have an issue with parry or dex, then you haven’t read the whole thing.
Please read it again, but I’ll direct you to this part which explains the IOS issues.
“ When we refer to the “Parry and Dex issue”, we’re not actually talking about an issue with Parry or Dex, but a framerate and control input issue exclusive to iOS devices that is most noticeable when trying to Parry or Dex, since these are two mechanics players rely on quite often.
Marvel Contest of Champions is built on a 3rd Party Game Engine built by our partners at Unity, which has an input system built-in. We’ve relied on Unity's input system since the game was built, and have regularly updated the Engine as they have released updates. With the most recent update to the Engine, a bug was fixed where iOS devices had been operating at the device’s own frame rate, instead of being capped to 30fps as it was set to. This meant that iOS devices had a slightly different input window than Android devices, but this was never identified.
Since this is how iOS devices had always worked with our game since launch, we had built game interactions around that input window. Now, because this bug in the engine has been fixed, it changed the input window of inputs for all iOS devices and pushed back the input window by mere milliseconds, but that is enough that it is noticeable when playing the game.
This is the issue that we are working to address, and our fix for it is to integrate an entirely new control input system from our partners at Unity. But this is not a quick or easy task.”
Only the IOS input window was pushed back, therefore it cannot be the cause of the Android issues.
Either they've not tested enough or they're afraid to acknowledge that Unity update is affecting android devices.
Now you'd ask why would they not accept it, because of the sheer variety of android devices, models, OS etc. They've never really been able to fix the android issue so if this is the same thing then it's nothing new.
iOS is clearly much easier to identify and fix because of the small environment.
But the fact that they are dismissing android as a generic lag and stutter is what they've been doing forever.
The fact that android now has configurable screen refresh rate with phones going UpTo 144hz and no update to make that compatible, tells us everything.
They are not dismissing Android as a generic lag and stutter problem. And the fact that Android has configurable screen refresh rates means diddly, because the game is built upon Unity. As I'm not a Unity expert (certainly not 2020 era Unity) if there are any out there feel free to correct me, but Unity uses a composite clock. There's one clock that runs the internals of Unity - the physics, the geometry calculations, etc - and another that runs the rendering. In theory you can run the render pass at any refresh rate you want, subject to vsync limitations (to prevent screen tearing) but the update clock cannot run at arbitrary rates. I mean, you can, but if you attempt to run it faster than the platform can calculate you'll get strange behavior, and if you run it at an arbitrary rate calculated dynamically based on how fast the device is you will end up with weird update/render beat-mismatches.
A custom game engine might use a single clock and cram everything into intra-frame calculations, or they might use staggered clocking and perform physics and motion in a divide down clock, but if you attempt that in Unity you'll almost certainly create problems in MCOC because that's basically what's happening in iOS now.
While I'm on the subject of reminding people the game is built on Unity, it is worth pointing out that since Kabam doesn't write Unity, the information that their current Unity build changed timing for iOS comes from Unity. They are the only ones who would know what they changed in any particular Unity build.
Another thing to point out: while anything is possible, if Android has as widespread timing problems as many assert then Tapsalot will find them. Tapsalot does not need to test a thousand different Android devices to find a pervasive Android problem that appears to be affecting a substantial percentage of the Android players of the game. It is just like crystal conspiracies: anything is possible when it comes to one crystal. But a massive crystal rigging conspiracy that is affecting all crystals for all players in noticeable ways is detectable with trivial testing. You can't disprove that one crystal is rigged. But you can disprove that all of them are. Tapsalot changes the Android situation because we no longer need to rely on anecdotes. If there's a pervasive Android problem, Tapsalot will find it. Conversely, if Tapsalot doesn't find it, there is no pervasive Android problem. There might still be rare marginal problems because of Android heterogeneity. But widespread problems affecting a large percentage of Android players can be proven to either exist, or not exist, with certainty. To be honest, such clarity either way will be welcome, at least by those of us interested in the bottom line facts.
Belief doesn't matter. 60% of Android testers thought that one of two *identical* game clients worked noticeably better (and not to pick on Android players, because iOS players appear to be equally vulnerable to that self deception). Belief is for churches, not for troubleshooters.
Your reply is very condescending and patronizing. Thank you for the thoughts and good bye.
Here's my question, if you're told the answer as detailed as humanly possible in an official statement, followed up with specific questions that are answered by a representative from Kabam and given a little more insight by a third party who has prior knowledge in game software development, why are you still reacting as if you're not being told what you want to hear?
Why are you taking this opportunity to just be angry when everyone's giving you as much information as humanly possible? I mean ultimately what would alleviate your concerns or give you the peace of mind that we're all looking for in this moment with everything is going on?
The statement didn't give any test or proof for Android devices like it did for iOS. It means that they have not tested Android yet. Check kabammiike's reply to my post, he clearly states they need to verify more information with unity about Android.
Don't be like that.
When talking about the beta test they did with iOS and Android users:
“Data also showed that many Android users felt that Parry or Dex felt better or worse, but as far as we know, this issue does not affect Android users.”
"As far as we know"
I don't think they've gone far enough, that's all.
You’re moving the goalposts now, first it was they haven’t tested Android, then it’s they haven’t gone far enough to test android.
I think it’s evident you just want to believe your opinion no matter what counterpoints are given to you. You call people who correct you patronising and condescending for taking the time to inform you. It’s ok to be wrong, it’s not ok to be wrong in the face of evidence. I don’t see much point continuing this conversation.
The evidence points to Android not having the issue caused by the unity update based on Kabams own confirmation, you can continue believing you know better based on absolutely nothing, but I know where I’d wager my money.
How can I know how much they've tested Android when they don't say how much.
Where's the evidence that there's nothing wrong with Android?
The only proof they're showing is tapsalot testing iphone xs max
I hope we receive a decent single player potions / revives or units. These will be more helpful since we are also exploring solo / event quest in which most of the time frustrating due to issues. The AW and AQ compensations are no longer useful and just a waste when its expiring.
Are there going to be some new machines like Swipesalot and Blocksalot?
I'd like to see if there're any input performance differences with devices with high sampling rate, high refresh rate, and devices that are recording or that play with enhanced sound like Dolby Atmos. It would be great if we could resolve some performance issues by turning off or tuning device-level settings.
I see green text PARRY and yellow text DEXTERITY but they do not register. On parry there is no stun and on dexterity i just get hit even if i dexed. The easyest example is on re-parry. I do the dexterity re-parry because i am not proficient enough to just tap the screen. So in my case there should be one of the THREE scenarios. Either it parries and the enemy gets stunned, either the dexterity works and he misses OR! he just hits me because i'm a noob. Even so! When i parry, green PARRY appears, when i dex yellow text appears. If miss both, i just get hit. Now! When i do "my" dex-parry (or whatever is called among super sayans) i swipe left left left and i get green green green parry parry parry. Still! the enemy keeps coming after me. I would understand a "timing issue" if no text would appear. But the text is there so the parry or dex should register. It IS! a game issue but i have absolutely no idea how to fix it. What i am willing to do is enroll in any test program KABAM sets up to fix this issue. But make NO MISTAKE! kabam! This is not just numbers, latency and "a feel". Who told you about the feel should not be part of the program. They are not helping. Put me in the program and i can supply REAL EXPERIENCE! not "feelings". I am using Samsung S10 with Android 11 and the latest version of the game.
@rockykoston to continue our conversation here, I’m not saying the unity engine only updated for IOS. I’m saying that update only caused the parry dex issue for IOS and not Android. I’d encourage you to read the entire post again, because I’m afraid you’ve misunderstood that aspect. I don’t mean that in a patronising way, just that if you think Kabam are saying Android players don’t have an issue with parry or dex, then you haven’t read the whole thing.
Please read it again, but I’ll direct you to this part which explains the IOS issues.
“ When we refer to the “Parry and Dex issue”, we’re not actually talking about an issue with Parry or Dex, but a framerate and control input issue exclusive to iOS devices that is most noticeable when trying to Parry or Dex, since these are two mechanics players rely on quite often.
Marvel Contest of Champions is built on a 3rd Party Game Engine built by our partners at Unity, which has an input system built-in. We’ve relied on Unity's input system since the game was built, and have regularly updated the Engine as they have released updates. With the most recent update to the Engine, a bug was fixed where iOS devices had been operating at the device’s own frame rate, instead of being capped to 30fps as it was set to. This meant that iOS devices had a slightly different input window than Android devices, but this was never identified.
Since this is how iOS devices had always worked with our game since launch, we had built game interactions around that input window. Now, because this bug in the engine has been fixed, it changed the input window of inputs for all iOS devices and pushed back the input window by mere milliseconds, but that is enough that it is noticeable when playing the game.
This is the issue that we are working to address, and our fix for it is to integrate an entirely new control input system from our partners at Unity. But this is not a quick or easy task.”
Only the IOS input window was pushed back, therefore it cannot be the cause of the Android issues.
Either they've not tested enough or they're afraid to acknowledge that Unity update is affecting android devices.
Now you'd ask why would they not accept it, because of the sheer variety of android devices, models, OS etc. They've never really been able to fix the android issue so if this is the same thing then it's nothing new.
iOS is clearly much easier to identify and fix because of the small environment.
But the fact that they are dismissing android as a generic lag and stutter is what they've been doing forever.
The fact that android now has configurable screen refresh rate with phones going UpTo 144hz and no update to make that compatible, tells us everything.
They are not dismissing Android as a generic lag and stutter problem. And the fact that Android has configurable screen refresh rates means diddly, because the game is built upon Unity. As I'm not a Unity expert (certainly not 2020 era Unity) if there are any out there feel free to correct me, but Unity uses a composite clock. There's one clock that runs the internals of Unity - the physics, the geometry calculations, etc - and another that runs the rendering. In theory you can run the render pass at any refresh rate you want, subject to vsync limitations (to prevent screen tearing) but the update clock cannot run at arbitrary rates. I mean, you can, but if you attempt to run it faster than the platform can calculate you'll get strange behavior, and if you run it at an arbitrary rate calculated dynamically based on how fast the device is you will end up with weird update/render beat-mismatches.
A custom game engine might use a single clock and cram everything into intra-frame calculations, or they might use staggered clocking and perform physics and motion in a divide down clock, but if you attempt that in Unity you'll almost certainly create problems in MCOC because that's basically what's happening in iOS now.
While I'm on the subject of reminding people the game is built on Unity, it is worth pointing out that since Kabam doesn't write Unity, the information that their current Unity build changed timing for iOS comes from Unity. They are the only ones who would know what they changed in any particular Unity build.
Another thing to point out: while anything is possible, if Android has as widespread timing problems as many assert then Tapsalot will find them. Tapsalot does not need to test a thousand different Android devices to find a pervasive Android problem that appears to be affecting a substantial percentage of the Android players of the game. It is just like crystal conspiracies: anything is possible when it comes to one crystal. But a massive crystal rigging conspiracy that is affecting all crystals for all players in noticeable ways is detectable with trivial testing. You can't disprove that one crystal is rigged. But you can disprove that all of them are. Tapsalot changes the Android situation because we no longer need to rely on anecdotes. If there's a pervasive Android problem, Tapsalot will find it. Conversely, if Tapsalot doesn't find it, there is no pervasive Android problem. There might still be rare marginal problems because of Android heterogeneity. But widespread problems affecting a large percentage of Android players can be proven to either exist, or not exist, with certainty. To be honest, such clarity either way will be welcome, at least by those of us interested in the bottom line facts.
Belief doesn't matter. 60% of Android testers thought that one of two *identical* game clients worked noticeably better (and not to pick on Android players, because iOS players appear to be equally vulnerable to that self deception). Belief is for churches, not for troubleshooters.
Your reply is very condescending and patronizing. Thank you for the thoughts and good bye.
The post I was replying to was factually inaccurate and drawing inexplicable conclusions with unjustified confidence. Condescension is very difficult to avoid in that situation. Be less certain or less wrong or preferably both, or condescension will be a constant companion in your life.
There's no need to reply anymore because clearly you're not equipped enough, all your statement are based on assumptions and conjecture.
Ignorance is bliss, stay that way.
Actually, they are based on my knowledge of game engines, my knowledge of Unity, my knowledge of Kabam's testing process, my conversations with the developers, the fact that I was in the beta test for the Unity build, and the fact that I've been helping test the memory leak bug off and on since May.
Your turn. You said "the fact that android now has configurable screen refresh rate with phones going UpTo 144hz and no update to make that compatible, tells us everything." Who is "us" and what does that tell you, exactly? It is your turn to share your expertise. The forums are here for players to discuss the game with other players. Here's your chance to aid your fellow MCOC players with your knowledge of game clients.
Where's the evidence that there's nothing wrong with Android?
Why would anyone need to provide evidence for a statement they did not make? Perhaps you need to read the announcement again. At no time did they say there's nothing wrong with Android. They said they found an issue that specifically affects iOS. That's not remotely the same thing.
@rockykoston to continue our conversation here, I’m not saying the unity engine only updated for IOS. I’m saying that update only caused the parry dex issue for IOS and not Android. I’d encourage you to read the entire post again, because I’m afraid you’ve misunderstood that aspect. I don’t mean that in a patronising way, just that if you think Kabam are saying Android players don’t have an issue with parry or dex, then you haven’t read the whole thing.
Please read it again, but I’ll direct you to this part which explains the IOS issues.
“ When we refer to the “Parry and Dex issue”, we’re not actually talking about an issue with Parry or Dex, but a framerate and control input issue exclusive to iOS devices that is most noticeable when trying to Parry or Dex, since these are two mechanics players rely on quite often.
Marvel Contest of Champions is built on a 3rd Party Game Engine built by our partners at Unity, which has an input system built-in. We’ve relied on Unity's input system since the game was built, and have regularly updated the Engine as they have released updates. With the most recent update to the Engine, a bug was fixed where iOS devices had been operating at the device’s own frame rate, instead of being capped to 30fps as it was set to. This meant that iOS devices had a slightly different input window than Android devices, but this was never identified.
Since this is how iOS devices had always worked with our game since launch, we had built game interactions around that input window. Now, because this bug in the engine has been fixed, it changed the input window of inputs for all iOS devices and pushed back the input window by mere milliseconds, but that is enough that it is noticeable when playing the game.
This is the issue that we are working to address, and our fix for it is to integrate an entirely new control input system from our partners at Unity. But this is not a quick or easy task.”
Only the IOS input window was pushed back, therefore it cannot be the cause of the Android issues.
Either they've not tested enough or they're afraid to acknowledge that Unity update is affecting android devices.
Now you'd ask why would they not accept it, because of the sheer variety of android devices, models, OS etc. They've never really been able to fix the android issue so if this is the same thing then it's nothing new.
iOS is clearly much easier to identify and fix because of the small environment.
But the fact that they are dismissing android as a generic lag and stutter is what they've been doing forever.
The fact that android now has configurable screen refresh rate with phones going UpTo 144hz and no update to make that compatible, tells us everything.
They are not dismissing Android as a generic lag and stutter problem. And the fact that Android has configurable screen refresh rates means diddly, because the game is built upon Unity. As I'm not a Unity expert (certainly not 2020 era Unity) if there are any out there feel free to correct me, but Unity uses a composite clock. There's one clock that runs the internals of Unity - the physics, the geometry calculations, etc - and another that runs the rendering. In theory you can run the render pass at any refresh rate you want, subject to vsync limitations (to prevent screen tearing) but the update clock cannot run at arbitrary rates. I mean, you can, but if you attempt to run it faster than the platform can calculate you'll get strange behavior, and if you run it at an arbitrary rate calculated dynamically based on how fast the device is you will end up with weird update/render beat-mismatches.
A custom game engine might use a single clock and cram everything into intra-frame calculations, or they might use staggered clocking and perform physics and motion in a divide down clock, but if you attempt that in Unity you'll almost certainly create problems in MCOC because that's basically what's happening in iOS now.
While I'm on the subject of reminding people the game is built on Unity, it is worth pointing out that since Kabam doesn't write Unity, the information that their current Unity build changed timing for iOS comes from Unity. They are the only ones who would know what they changed in any particular Unity build.
Another thing to point out: while anything is possible, if Android has as widespread timing problems as many assert then Tapsalot will find them. Tapsalot does not need to test a thousand different Android devices to find a pervasive Android problem that appears to be affecting a substantial percentage of the Android players of the game. It is just like crystal conspiracies: anything is possible when it comes to one crystal. But a massive crystal rigging conspiracy that is affecting all crystals for all players in noticeable ways is detectable with trivial testing. You can't disprove that one crystal is rigged. But you can disprove that all of them are. Tapsalot changes the Android situation because we no longer need to rely on anecdotes. If there's a pervasive Android problem, Tapsalot will find it. Conversely, if Tapsalot doesn't find it, there is no pervasive Android problem. There might still be rare marginal problems because of Android heterogeneity. But widespread problems affecting a large percentage of Android players can be proven to either exist, or not exist, with certainty. To be honest, such clarity either way will be welcome, at least by those of us interested in the bottom line facts.
Belief doesn't matter. 60% of Android testers thought that one of two *identical* game clients worked noticeably better (and not to pick on Android players, because iOS players appear to be equally vulnerable to that self deception). Belief is for churches, not for troubleshooters.
Your reply is very condescending and patronizing. Thank you for the thoughts and good bye.
The post I was replying to was factually inaccurate and drawing inexplicable conclusions with unjustified confidence. Condescension is very difficult to avoid in that situation. Be less certain or less wrong or preferably both, or condescension will be a constant companion in your life.
There's no need to reply anymore because clearly you're not equipped enough, all your statement are based on assumptions and conjecture.
Ignorance is bliss, stay that way.
Actually, they are based on my knowledge of game engines, my knowledge of Unity, my knowledge of Kabam's testing process, my conversations with the developers, the fact that I was in the beta test for the Unity build, and the fact that I've been helping test the memory leak bug off and on since May.
Your turn. You said "the fact that android now has configurable screen refresh rate with phones going UpTo 144hz and no update to make that compatible, tells us everything." Who is "us" and what does that tell you, exactly? It is your turn to share your expertise. The forums are here for players to discuss the game with other players. Here's your chance to aid your fellow MCOC players with your knowledge of game clients.
You probably signed an NDA or something because there's no details on what's been tested for Android and I'm not saying beta test, I'm asking about the functional/ performance test that was done.
I have several alliance mates and ppl in incursions complaining of the parry bug, heck, I just spent 3 revives on a fight where I'd normally spend zero, because the parry tap didn't register.
I'm playing on mi 10t pro that has 144hz screen but I play on 90hz because at 144hz the game just skips inputs and animations.
What kind of testing is kabam doing? Are they capturing their userbase based on varied types of devices or just OS?
I know bugs can happen in any application but the fact that this parry bug is making everyone spend so many resources is why ppl are making more noise.
Not playing the game is not really a solution, if anyone says that.
While the robot is a brilliant way to get at actual measurement and to be able to test fixes with a controlled "fixed" input and response. It definitely will be impractical to test on even the few models of iOS, let alone the multiple manufacturers and models of android phones and tablets. If I could suggest, you might be able to use something like the parry training ground to crowd source some data for a beta test. Have something where you have to parry like 10 medium hits from 5-6 different characters and you should be able to gather a bunch of data from hundreds or thousands doing the exact same test on the same characters. I'm not saying this would prevent a robot uprising...but maybe delay it a bit
Unfortunately, it won't help. As we mentioned in the post, there is no way for us to measure this in software because the issue resides between the Game Engine and the Hardware.
Absolutely, I get that you can't actually measure the input timing that way. What I was thinking was more of a way to quantify if the fixes worked for players. So like if you repeated the "Does parry/dex feel better" experiment but instead of asking about feel could measure that it took say 16 mediums to get 10 parries on average for those with the released version, vs say 12 mediums to get 10 parries on the hotfix beta. Then no matter what they say parry felt like you would have data to show that parry was working better with the hotfix.
It just seemed like that type of data (parry success rate) could be gathered, since the training mode already recognizes when you landed a successful parry. But I have no real idea if that data is available under the hood or not.
Tapsalot eliminates the need for that kind of testing. Prior to Tapsalot, the devs had to guess at what changes might have caused a change in player feeling. But now that this can be quantified, either the new build replicates the old timing sufficiently well or it doesn't.
Keep in mind the task for Kabam is not to change the game until everyone's Parry skills improve. The task for Kabam is to replicate the old behavior. If they do and players are still missing Parries, that would be a psychological problem in their heads that the game client can't fix and can only be solved by the players readjusting to the old-new-old normal.
Tapsalot will eliminate that need for testing for any device that can be tested using Tapsalot. Automatically extending results found with an iPhone 12 max to other devices that have not been tested with Tapsalot would decidedly be poor scientific method. It would be like me saying my research using mice is automatically applicable to humans just because both are mammals. And it would seem that expanding the robot army to test the numerous different apple and android phones and tablets would rapidly become cost/time prohibitive.
So really what I was suggesting was like a phase I/ Phase II trials. In phase I, Tapsalot gives rapid data collection in a closed system with a relatively small number of devices. My theoretical phase II trial would then be releasing said potential fix to hundreds to thousands with multiple different devices and you could see if the fix works in the "wild" of a beta.
You'd have to find testers whose feedback meant something. In their limited beta test, humans were statistically incapable of being able to correctly identify when the problem changed or didn't change.
Which is exactly why you would never use any sort of feeling or self reported response for the data. It would only be measuring, in this theoretical trial, parry success rate or the number of medium attacks to get 10 parries. As long as the groups each include a similar cross section of the player base the average across each group should represent the actual difference between the current and potential fixed versions. Granted any study using humans as subjects will be biased as you can only include people who actually want to be included. But if you look at an actual test of a measurable skill vs asking how does it feel, you should get a reasonable approximation of how that change is working in a live version with people on different devices with different levels of wifi or cellular data, which should be a wider pool than could be done with Tapsalot.
Unfortunately that doesn't work. It might seem that Parry success rates are objective data, but that presumes humans are robots that can execute Parries in a predictable way, and thus any difference in the data must be due to a change in the game client. But that's not how humans work. We should take it as a given that if a player reports that "Parry got worse" they aren't reporting a random guess, they are actually seeing their Parries fail. The subjective nature isn't in whether players are correctly remembering if their Parries are working or not, it is in whether or not the players are doing the same things successfully or not.
Or to put it in baseball terms, we can't tell the difference between a player whose game client changed behavior, and a player who only thinks the game client changed behavior and gets the yips. The beta test they conducted suggests this is not just a theoretical problem, it actually happens to players asked to test the game, and are presumably trying to avoid just such a problem.
The only way to eliminate this problem would be to do a double blind test: change half the players clients without telling them and see if you see a change in problem reports. But that would be difficult to do, and maybe even slightly unethical to do, because you could be making some players' experience worse without telling them and letting them opt into testing voluntarily.
I have a bit of trouble digesting this whole “feel” thing .. if i can consistently produce the “bug”, how is it just a feel thing?
I think all it means is that they couldn’t definitively find the problem by feel alone. They mention that in the beta test they gave half the players a fix, and half the control with no fix. And the results were inconclusive because players were asked to “feel” whether it was wrong. 61% of the players with the fix said it was better, 63% without the fix said it was better.
Android users even said the fix was better or worse. And this shows that it was a psychological change, not anything measurable.
All it means is that this test they tried didn’t work. It would be like a coffee company testing a new coffee and giving the test group a new one, and a control group the old one then, the control group says that their coffee tastes better than before, even though it’s the same coffee.
They’re not saying the bug is just a feel thing, the feel direction was one way they tried to solve it, and in the end decided it wouldn’t work. They then decided to create the robot Sir Tapsalot, to give them something to actually measure.
So instead of asking you or me whether we felt like parry was better or worse, they made the robot that can map when the window of input for parry is.
But how did they select the players? I know people playing for 6 years who get hit by iron mans sp1, what good is their input to this process?
They’ll have been chosen randomly from those who signed up for the beta. Any statistical test will be random to make sure there’s no bias
That’s not correct though. A bias towards getting a more informed opinion is not wrong. It won’t represent everyone but this isn’t a referendum on people’s rights, this is a technical issue that they are trying to pin down. With the timing window that small, they should have gone to CCP, summoner showdown finalists or tier 1 AW players.
While the robot is a brilliant way to get at actual measurement and to be able to test fixes with a controlled "fixed" input and response. It definitely will be impractical to test on even the few models of iOS, let alone the multiple manufacturers and models of android phones and tablets. If I could suggest, you might be able to use something like the parry training ground to crowd source some data for a beta test. Have something where you have to parry like 10 medium hits from 5-6 different characters and you should be able to gather a bunch of data from hundreds or thousands doing the exact same test on the same characters. I'm not saying this would prevent a robot uprising...but maybe delay it a bit
Unfortunately, it won't help. As we mentioned in the post, there is no way for us to measure this in software because the issue resides between the Game Engine and the Hardware.
Absolutely, I get that you can't actually measure the input timing that way. What I was thinking was more of a way to quantify if the fixes worked for players. So like if you repeated the "Does parry/dex feel better" experiment but instead of asking about feel could measure that it took say 16 mediums to get 10 parries on average for those with the released version, vs say 12 mediums to get 10 parries on the hotfix beta. Then no matter what they say parry felt like you would have data to show that parry was working better with the hotfix.
It just seemed like that type of data (parry success rate) could be gathered, since the training mode already recognizes when you landed a successful parry. But I have no real idea if that data is available under the hood or not.
Tapsalot eliminates the need for that kind of testing. Prior to Tapsalot, the devs had to guess at what changes might have caused a change in player feeling. But now that this can be quantified, either the new build replicates the old timing sufficiently well or it doesn't.
Keep in mind the task for Kabam is not to change the game until everyone's Parry skills improve. The task for Kabam is to replicate the old behavior. If they do and players are still missing Parries, that would be a psychological problem in their heads that the game client can't fix and can only be solved by the players readjusting to the old-new-old normal.
Tapsalot will eliminate that need for testing for any device that can be tested using Tapsalot. Automatically extending results found with an iPhone 12 max to other devices that have not been tested with Tapsalot would decidedly be poor scientific method. It would be like me saying my research using mice is automatically applicable to humans just because both are mammals. And it would seem that expanding the robot army to test the numerous different apple and android phones and tablets would rapidly become cost/time prohibitive.
So really what I was suggesting was like a phase I/ Phase II trials. In phase I, Tapsalot gives rapid data collection in a closed system with a relatively small number of devices. My theoretical phase II trial would then be releasing said potential fix to hundreds to thousands with multiple different devices and you could see if the fix works in the "wild" of a beta.
You'd have to find testers whose feedback meant something. In their limited beta test, humans were statistically incapable of being able to correctly identify when the problem changed or didn't change.
Which is exactly why you would never use any sort of feeling or self reported response for the data. It would only be measuring, in this theoretical trial, parry success rate or the number of medium attacks to get 10 parries. As long as the groups each include a similar cross section of the player base the average across each group should represent the actual difference between the current and potential fixed versions. Granted any study using humans as subjects will be biased as you can only include people who actually want to be included. But if you look at an actual test of a measurable skill vs asking how does it feel, you should get a reasonable approximation of how that change is working in a live version with people on different devices with different levels of wifi or cellular data, which should be a wider pool than could be done with Tapsalot.
Unfortunately that doesn't work. It might seem that Parry success rates are objective data, but that presumes humans are robots that can execute Parries in a predictable way, and thus any difference in the data must be due to a change in the game client. But that's not how humans work. We should take it as a given that if a player reports that "Parry got worse" they aren't reporting a random guess, they are actually seeing their Parries fail. The subjective nature isn't in whether players are correctly remembering if their Parries are working or not, it is in whether or not the players are doing the same things successfully or not.
Or to put it in baseball terms, we can't tell the difference between a player whose game client changed behavior, and a player who only thinks the game client changed behavior and gets the yips. The beta test they conducted suggests this is not just a theoretical problem, it actually happens to players asked to test the game, and are presumably trying to avoid just such a problem.
The only way to eliminate this problem would be to do a double blind test: change half the players clients without telling them and see if you see a change in problem reports. But that would be difficult to do, and maybe even slightly unethical to do, because you could be making some players' experience worse without telling them and letting them opt into testing voluntarily.
Of course people are not robots, that's the whole point. All human data is going to have variation. Hell all data from any living system is going to have variation. The point would be to test if you can actually detect a difference over a reasonably large sample size. I am not talking about testing with 3 or 20 people and seeing if they can successfully parry. I am talking about testing hundreds to thousands of people in different groups. Which is exactly how you test highly variable natural systems. Because when you start to get a large number of responses to a test you can basically average out the outliers. So you would not care if someone got the yips or not because you are just as likely to have someone who has the yips in the other group.
And as to doing it blinded (pedantic point, it could not be double blinded without Kabam also not knowing which groups got which client to test), not only could they totally do that, but they already did in the beta test you referenced.
"During the Beta Test, we split players into 2 Groups, a control group and a test group that received an update for the fix. We asked players to let us know if the version they downloaded felt better, worse, or the same. Approximately 61% of Summoners that received the version with the update felt that Parry and Dex felt better than before. Comparatively, 63% of our Control group, who did not receive a potential fix, felt that Parry and Dex felt better. Data also showed that many Android users felt that Parry or Dex felt better or worse, but as far as we know, this issue does not affect Android users."
Basically I am saying do this again, but don't ask how they feel about parry, test their parry skills and see what the data says. You can even tell them that some of them will get the current client and some will get the update. As long as both groups get the same information at the start it should affect them the same. Now if this is technically not feasible, cool, I haven't coded anything other than getting SAS to run my stats in like 20 years so I have no idea what it would take to actually get the game to output the data on parry success from this type of test. But having been running, analyzing and publishing results from experiments in living systems for going on 19 years now, I do know that if that data is obtainable it would be able to show even small differences due to the client even if stratified by OS and device.
@Kabam Miike A question regarding the single player compensation. If it contains revives, potions it wouldn’t be useful for those who’ve already completed the available content. I hope Kabam has considered this aspect while deciding what should be the compensation.
The compensation bundle will stay in the Rewards stash for 30 days, and once you claim it, any overflow of revives/potions will stay in the Items stash for another 2 weeks. That should be long enough to delay into the November update if you want to save them for that long.
(Though if V8 is released a week or two into the Nov release, that might not leave much time to use them.)
I have and I did. I also said that the fact that they have dismissed an android problem, is a kick in the teeth.
They haven't dismissed the android problem. They said that there was a bug fix from Unity with regards to timing on IOS devices and therefore it's not possible for Android to have that problem. They also said that they are still testing and looking at data from both sets of devices and is working with Unity to fix this problem. Maybe Android is affected after all who knows. If Kabam were 100% certain there wasn't any issue with android, they wouldn't have mentioned that they would be testing Tapsalot on Android devices as well.
As said somewhere else, IOS devices have THE parry/dex issues caused by the unity game engine update. Android has A parry/dex issue and Kabam believe that an asset memory leak is another issue causing stuttering and framerate drops in general and will be coming out with patches to fix it soon. Saying that Kabam dismissed android issues is not even an exaggeration, but blatantly false.
Better yet, do you play the game and are you on Ios or android? If it's Ios, just stop. If it's android, I don't believe you, if you don't even play the game... I'd give it a 25% chance.
I play on Android. Don't believe me, then don't. You can scroll through all my posts and you will find I only play on an android (Samsung Galaxy Tab A). I play the game daily. Your loss if you don't believe me. Either way, this is a moot point cuz even people who don't play regularly can you know, read the actual post. All of what I mentioned above is in Kabam's post and the mods subsequent posts.
Thanks, but I really don't care to look at any of your posts, you made an assumption of me based on the "cherrypicking" of a quote, also stated that I didn't read the entire post to begin with. You, at this point, are going to pretend to be affronted when countered with the same? Come on. I elicited the exact response that I expected, thank you for validating.
Comments
So really what I was suggesting was like a phase I/ Phase II trials. In phase I, Tapsalot gives rapid data collection in a closed system with a relatively small number of devices. My theoretical phase II trial would then be releasing said potential fix to hundreds to thousands with multiple different devices and you could see if the fix works in the "wild" of a beta.
Why are you taking this opportunity to just be angry when everyone's giving you as much information as humanly possible? I mean ultimately what would alleviate your concerns or give you the peace of mind that we're all looking for in this moment with everything is going on?
Don't be like that.
“Data also showed that many Android users felt that Parry or Dex felt better or worse, but as far as we know, this issue does not affect Android users.”
His responses are based on an extensive knowledge of these things. You can say what you will about DNA, but he's like an Ent. He doesn't say anything that isn't worth taking the time to say.
I don't think they've gone far enough, that's all.
As soon as I had the update installed I began to have intermittent issues with parry not causing stun even though it did block (a few times could obviously be a timing issue on my part but not with the frequency it was occuring), parry/block not occuring at all, my champ freezing in place when I tried to attack/use special/move, my champ moving the opposite direction of the way I swiped, increased lag/freezing/stuttering and basically every other issue that has since been reported. Again, I acknowledge that some of these issues if happening much more infrequently could be user error but not with the amount of times these things were all suddenly happening.
I understand they have said the Unity people said they only changed a bug with iOS but I don't believe for a second that I am just suffering from a psychological delusion that these things are happening so much worse for me all of a sudden when as I said I expected absolutely nothing to change for me with the first fix since I wasn't experiencing those issues before the fix like apparently only the iOS people were.
I am curious as to whether Kabam are going to investigate whether whatever was in the fix download I had to install could be responsible for the issues that I and other Android players have reported as starting AFTER the fix and not just say that we are either suffering from the memory leak issues that I believe they are saying were either ongoing for quite a while or had started with the engine update or that these suddenly much worse issues are just the same as has been going on for years. Many of us have indicated a clear difference for the worse after the fix as opposed to saying we had the problems all along that Kabam are saying really only affected iOS players.
Lastly, I am still quite curious as to the reasoning behind stopping the aq packages but starting the aw ones before finally (hopefully) restarting the aq packages on a regular basis as well as why the packages for regular content are not a weekly thing as well. If the thought process behind not providing much (or regular) solo content potions and revives is that it is long term content so we just shouldn't do it until/if you fix things if our game doesn't work well enough unlike the aq/aw content that needs done each week I would like to point out that that doesn't apply to EQ and given your emphasis on pushing players to complete harder solo content to advance to uncollected/cavalier/throne breaker to get better rewards/offers/compensation/etc it isn't really fair to say to wait on doing that content either.
Unless you plan on giving everyone the highest rewards regardless of their progress level or level of content they can currently complete with the game issues (which would be ridiculous) it seems only fair to regularly provide solo content packages until the vast majority of players on ALL device types have their newish issues resolved because telling us to hold still with our progress if things are too messed up for months more to come while at the same time saying if we want better rewards we need to push forward is pure cognitive dissonance. As long as you admit the game is messed up so much that we need assistance in one mode you shouldn't be claiming it is not an equal issue in other modes when we are all aware the issues are not content specific.
Once that tests are shared with the users and we actually have all the information for both platforms, it'll be clear whether the issue only exists in IOS or not.
Until then the issue is on iOS and Android had the generic stutter/lag issue.
Yes, unity can provide their input but that'll depend on the data that kabam shares with them, so if we're going for transparency and barring IP rights, we need to see that data for Android as well. Thank you for reading.
I think it’s evident you just want to believe your opinion no matter what counterpoints are given to you. You call people who correct you patronising and condescending for taking the time to inform you. It’s ok to be wrong, it’s not ok to be wrong in the face of evidence. I don’t see much point continuing this conversation.
The evidence points to Android not having the issue caused by the unity update based on Kabams own confirmation, you can continue believing you know better based on absolutely nothing, but I know where I’d wager my money.
Where's the evidence that there's nothing wrong with Android?
The only proof they're showing is tapsalot testing iphone xs max
I'd like to see if there're any input performance differences with devices with high sampling rate, high refresh rate, and devices that are recording or that play with enhanced sound like Dolby Atmos. It would be great if we could resolve some performance issues by turning off or tuning device-level settings.
Even so! When i parry, green PARRY appears, when i dex yellow text appears. If miss both, i just get hit.
Now! When i do "my" dex-parry (or whatever is called among super sayans) i swipe left left left and i get green green green parry parry parry. Still! the enemy keeps coming after me.
I would understand a "timing issue" if no text would appear. But the text is there so the parry or dex should register.
It IS! a game issue but i have absolutely no idea how to fix it.
What i am willing to do is enroll in any test program KABAM sets up to fix this issue.
But make NO MISTAKE! kabam! This is not just numbers, latency and "a feel". Who told you about the feel should not be part of the program. They are not helping. Put me in the program and i can supply REAL EXPERIENCE! not "feelings".
I am using Samsung S10 with Android 11 and the latest version of the game.
Your turn. You said "the fact that android now has configurable screen refresh rate with phones going UpTo 144hz and no update to make that compatible, tells us everything." Who is "us" and what does that tell you, exactly? It is your turn to share your expertise. The forums are here for players to discuss the game with other players. Here's your chance to aid your fellow MCOC players with your knowledge of game clients.
I have several alliance mates and ppl in incursions complaining of the parry bug, heck, I just spent 3 revives on a fight where I'd normally spend zero, because the parry tap didn't register.
I'm playing on mi 10t pro that has 144hz screen but I play on 90hz because at 144hz the game just skips inputs and animations.
What kind of testing is kabam doing?
Are they capturing their userbase based on varied types of devices or just OS?
I know bugs can happen in any application but the fact that this parry bug is making everyone spend so many resources is why ppl are making more noise.
Not playing the game is not really a solution, if anyone says that.
Or to put it in baseball terms, we can't tell the difference between a player whose game client changed behavior, and a player who only thinks the game client changed behavior and gets the yips. The beta test they conducted suggests this is not just a theoretical problem, it actually happens to players asked to test the game, and are presumably trying to avoid just such a problem.
The only way to eliminate this problem would be to do a double blind test: change half the players clients without telling them and see if you see a change in problem reports. But that would be difficult to do, and maybe even slightly unethical to do, because you could be making some players' experience worse without telling them and letting them opt into testing voluntarily.
And as to doing it blinded (pedantic point, it could not be double blinded without Kabam also not knowing which groups got which client to test), not only could they totally do that, but they already did in the beta test you referenced.
"During the Beta Test, we split players into 2 Groups, a control group and a test group that received an update for the fix. We asked players to let us know if the version they downloaded felt better, worse, or the same. Approximately 61% of Summoners that received the version with the update felt that Parry and Dex felt better than before. Comparatively, 63% of our Control group, who did not receive a potential fix, felt that Parry and Dex felt better. Data also showed that many Android users felt that Parry or Dex felt better or worse, but as far as we know, this issue does not affect Android users."
Basically I am saying do this again, but don't ask how they feel about parry, test their parry skills and see what the data says. You can even tell them that some of them will get the current client and some will get the update. As long as both groups get the same information at the start it should affect them the same. Now if this is technically not feasible, cool, I haven't coded anything other than getting SAS to run my stats in like 20 years so I have no idea what it would take to actually get the game to output the data on parry success from this type of test. But having been running, analyzing and publishing results from experiments in living systems for going on 19 years now, I do know that if that data is obtainable it would be able to show even small differences due to the client even if stratified by OS and device.
(Though if V8 is released a week or two into the Nov release, that might not leave much time to use them.)
As said somewhere else, IOS devices have THE parry/dex issues caused by the unity game engine update. Android has A parry/dex issue and Kabam believe that an asset memory leak is another issue causing stuttering and framerate drops in general and will be coming out with patches to fix it soon. Saying that Kabam dismissed android issues is not even an exaggeration, but blatantly false.
You, at this point, are going to pretend to be affronted when countered with the same? Come on. I elicited the exact response that I expected, thank you for validating.