**WINTER OF WOE - BONUS OBJECTIVE POINT**
As previously announced, the team will be distributing an additional point toward milestones to anyone who completed the Absorbing Man fight in the first step of the Winter of Woe.
This point will be distributed at a later time as it requires the team to pull and analyze data.
The timeline has not been set, but work has started.
There is currently an issue where some Alliances are are unable to find a match in Alliance Wars, or are receiving Byes without getting the benefits of the Win. We will be adjusting the Season Points of the Alliances that are affected within the coming weeks, and will be working to compensate them for their missed Per War rewards as well.

Additionally, we are working to address an issue where new Members of an Alliance are unable to place Defenders for the next War after joining. We are working to address this, but it will require a future update.

"Why is it so Hard to Navigate Input Issues?"

12467

Comments

  • BigBlueOxBigBlueOx Posts: 1,541 ★★★★★

    So you stop getting info that you need and instead of making something interesting for players, you just threw us into the control issues hell? Why not make some rewards for "bug hunters"? For example, you get helpful info about bug (with descriptions you need and video with recording taps and swipes) and give player for that titles or profile pic or tokens that can be exchanged for some gold or iso maybe? Why you want to get required info from players suffering?

    Good point, you’d think the “cost associated to experiencing this bug” might be if interest to the team too, but that’s left out as well.
  • DNA3000DNA3000 Posts: 18,558 Guardian
    BigBlueOx said:

    Also, why would the input reactor effect champs months down the road? That doesn’t make sense with what we’ve been told either

    The "input system refactor" is a bit of a misnomer. It technically describes what was done, but it doesn't properly evoke the scale and scope of what that means if you don't understand how input systems work in game engines. If I said that what they needed to do after the Unity engine update that changed the behavior of iOS timestep calculations as "changing how the game processes the timing of all events relative to how players interact with the game" I think that would better describe the scope of the change to the game.

    The engine update altered how the game processes time. This altered the precise moments when things designed to happen in specific time sequences occurred. This caused the relationship between when inputs were processed as happening in the engine relative to when internal events were sequenced to occur. This caused problems ranging from inputs registering at different frames relative to animations (which would cause time-sensitive events like Parry from not occurring) to inputs not registering at all because they occurred during windows where such actions are forbidden, even though the animations would visually suggest they were allowed, to inputs being processed differently because input queues now behaved differently, to effects interacting in different ways independent of inputs because their relative timing was now shifted, which then meant future inputs would not generate the behavior that was originally intended or expected.

    What changed was not something like the game needed to process taps and swipes differently. What happened was the game's sense of time changed, and with that everything that depends on time also changed. Which is potentially: everything. Not only everything that exists now, but things designed in the future that use the same design rules that worked in the past might break in weird ways that didn't happen before, but now can happen.

    What makes this a lot more complex than people think is that we experience time continuously but the game experiences time discretely, in ticks of the clock. Everything that happens 0.5 seconds later and 0.533 seconds later happens at the exact same moment to the game engine (15 frames later). Assuming game frames are being processed *exactly* when they should, which in practice never happens. So sometimes frame 15 happens 0.5 seconds later and sometimes 0.501 seconds later. When that happens, the event that is supposed to happen 0.5 seconds later and the event that is supposed to happen 0.51 seconds later no longer happen in the same frame. Or maybe they do because the game engine tries to compensate for this. Honestly, I've seen Unity documentation go both ways here.

    Most games do not need to care about this kind of stuff, because precise timing doesn't really affect them. Whether something happens now or one frame later will not do something that a player will notice in an FPS shooter or a side scroller. It is only games that require this event to happen at the exact same time as that event that will be affected in a noticeable way. MCOC happens to be one of those games.
  • [Deleted User][Deleted User] Posts: 0
    The user and all related content has been deleted.
  • BigBlueOxBigBlueOx Posts: 1,541 ★★★★★
    DNA3000 said:

    BigBlueOx said:

    Also, why would the input reactor effect champs months down the road? That doesn’t make sense with what we’ve been told either

    The "input system refactor" is a bit of a misnomer. It technically describes what was done, but it doesn't properly evoke the scale and scope of what that means if you don't understand how input systems work in game engines. If I said that what they needed to do after the Unity engine update that changed the behavior of iOS timestep calculations as "changing how the game processes the timing of all events relative to how players interact with the game" I think that would better describe the scope of the change to the game.

    The engine update altered how the game processes time. This altered the precise moments when things designed to happen in specific time sequences occurred. This caused the relationship between when inputs were processed as happening in the engine relative to when internal events were sequenced to occur. This caused problems ranging from inputs registering at different frames relative to animations (which would cause time-sensitive events like Parry from not occurring) to inputs not registering at all because they occurred during windows where such actions are forbidden, even though the animations would visually suggest they were allowed, to inputs being processed differently because input queues now behaved differently, to effects interacting in different ways independent of inputs because their relative timing was now shifted, which then meant future inputs would not generate the behavior that was originally intended or expected.

    What changed was not something like the game needed to process taps and swipes differently. What happened was the game's sense of time changed, and with that everything that depends on time also changed. Which is potentially: everything. Not only everything that exists now, but things designed in the future that use the same design rules that worked in the past might break in weird ways that didn't happen before, but now can happen.

    What makes this a lot more complex than people think is that we experience time continuously but the game experiences time discretely, in ticks of the clock. Everything that happens 0.5 seconds later and 0.533 seconds later happens at the exact same moment to the game engine (15 frames later). Assuming game frames are being processed *exactly* when they should, which in practice never happens. So sometimes frame 15 happens 0.5 seconds later and sometimes 0.501 seconds later. When that happens, the event that is supposed to happen 0.5 seconds later and the event that is supposed to happen 0.51 seconds later no longer happen in the same frame. Or maybe they do because the game engine tries to compensate for this. Honestly, I've seen Unity documentation go both ways here.

    Most games do not need to care about this kind of stuff, because precise timing doesn't really affect them. Whether something happens now or one frame later will not do something that a player will notice in an FPS shooter or a side scroller. It is only games that require this event to happen at the exact same time as that event that will be affected in a noticeable way. MCOC happens to be one of those games.
    I appreciate the thorough response but a year later why are things getting worse not better?
  • DNA3000DNA3000 Posts: 18,558 Guardian
    BigBlueOx said:

    DNA3000 said:

    BigBlueOx said:

    Also, why would the input reactor effect champs months down the road? That doesn’t make sense with what we’ve been told either

    The "input system refactor" is a bit of a misnomer. It technically describes what was done, but it doesn't properly evoke the scale and scope of what that means if you don't understand how input systems work in game engines. If I said that what they needed to do after the Unity engine update that changed the behavior of iOS timestep calculations as "changing how the game processes the timing of all events relative to how players interact with the game" I think that would better describe the scope of the change to the game.

    The engine update altered how the game processes time. This altered the precise moments when things designed to happen in specific time sequences occurred. This caused the relationship between when inputs were processed as happening in the engine relative to when internal events were sequenced to occur. This caused problems ranging from inputs registering at different frames relative to animations (which would cause time-sensitive events like Parry from not occurring) to inputs not registering at all because they occurred during windows where such actions are forbidden, even though the animations would visually suggest they were allowed, to inputs being processed differently because input queues now behaved differently, to effects interacting in different ways independent of inputs because their relative timing was now shifted, which then meant future inputs would not generate the behavior that was originally intended or expected.

    What changed was not something like the game needed to process taps and swipes differently. What happened was the game's sense of time changed, and with that everything that depends on time also changed. Which is potentially: everything. Not only everything that exists now, but things designed in the future that use the same design rules that worked in the past might break in weird ways that didn't happen before, but now can happen.

    What makes this a lot more complex than people think is that we experience time continuously but the game experiences time discretely, in ticks of the clock. Everything that happens 0.5 seconds later and 0.533 seconds later happens at the exact same moment to the game engine (15 frames later). Assuming game frames are being processed *exactly* when they should, which in practice never happens. So sometimes frame 15 happens 0.5 seconds later and sometimes 0.501 seconds later. When that happens, the event that is supposed to happen 0.5 seconds later and the event that is supposed to happen 0.51 seconds later no longer happen in the same frame. Or maybe they do because the game engine tries to compensate for this. Honestly, I've seen Unity documentation go both ways here.

    Most games do not need to care about this kind of stuff, because precise timing doesn't really affect them. Whether something happens now or one frame later will not do something that a player will notice in an FPS shooter or a side scroller. It is only games that require this event to happen at the exact same time as that event that will be affected in a noticeable way. MCOC happens to be one of those games.
    I appreciate the thorough response but a year later why are things getting worse not better?
    I haven't personally noticed them getting worse. It seems that different players see different things. But to the extent that people have been seeing things apparently getting worse, Kabam is clearly still refining the system. Presumably those refinements are changing things in ways that players are noticing as regression problems, or as different problems that just seem to be a recurrence of the same problem.

    It is also possible that besides the game engine changing and the data changing, the design rules of thumb themselves have to change with the new systems. In the same way players have to fight muscle memory when the game changes behavior, devs have to change their rules of thumb for how to make things or change things or adjust things. Those design rules may not have fully adapted to the new game engine behavior, so sometimes we see regressions.
  • DNA3000DNA3000 Posts: 18,558 Guardian
    R_jay0027 said:

    I guess the question I would ask is can the newer system be tuned more to what was more accustomed to?

    From what I understand, only to a point, but not perfectly. I wouldn't take this literally, but sometimes the old engine made "mistakes" in our favor, generating behavior we grew accustomed to. The new engine cannot replicate that behavior not because it was "wrong" but rather because it wasn't deterministic. The old engine would do this in this circumstance and that in other circumstances. The new engine can only do one or the other, without putting so many exceptions into the engine that it would collapse under the weight of the extra complexity. The old engine didn't have two behaviors because it was more complex, but because the engine didn't behave consistently across all circumstances. It only behaved consistently to the players, because the players learned how it behaved in every circumstance.

    To the players, every situation is unique. But to the game engine, there's only one situation with a few variables. When it starts behaving differently based on situation when no code tells it to do that the players learn how the game works in a way a new engine cannot replicate.

    One of the most famous examples in video game history of a behavior players just assumed happened by design but was actually originally a circumstantial inconsistency (which was exploited by the game designers during implementation) was the behavior of the alien invaders in the classic Space Invaders game. In Space Invaders, the more enemies you kill the faster the remaining ones attack you. Everyone assumed this was programmed deliberately, to make the game increasingly fast paced as it went along. As it turns out, that wasn't an original intent of the game programmers. Instead, the problem was the game hardware was so underpowered that it literally took longer to draw the alien ships than it took to refresh the screen, so when there were a lot of alien ships they moved slower on screen because that was as fast as the hardware could draw them. But as the player killed them, the number of aliens the hardware had to draw dropped, and it could draw them faster, and so they moved faster on the screen. During development the creators of Space Invaders decided to exploit this behavior rather than try to fix it, and the rest is history.

    You can stare at the code of Space Invaders all day and not see the speed ramp up, because it doesn't exist (well, technically it exists in the sound synchronization code for the game). One of the most famous aspects of the game, a feature that is often credited with *inventing* the game design idea of difficulty ramp up in video games, was a side effect of the hardware being too slow to run the game properly. Today we can reproduce that behavior exactly with modern computer hardware, but at the time this would have been difficult to reproduce *exactly* because Space Invaders itself wasn't doing it deliberately.
  • BigBlueOxBigBlueOx Posts: 1,541 ★★★★★
    @DNA3000 again, thanks for weighing in, at the end of the day, if they knew that this was the case and that we as players would have to trouble shoot all this… my position remains unchanged. The bug report has a glaring hole it in regards to the cost of the bug to the player, and if what you hypothesize is true then it’s poor form that compensation for the input/timing issues was ceased.
  • CatmanndoCatmanndo Posts: 738 ★★★
    Not that compensation weighs heavily on a broken game, but it does alleviate some bad vibes and it’s a welcome gesture as empathy towards those suffering through.
    Why was the opt out beta removed? Both my apple devices are neatly incompatible now.
  • DNA3000DNA3000 Posts: 18,558 Guardian
    BigBlueOx said:

    @DNA3000 again, thanks for weighing in, at the end of the day, if they knew that this was the case and that we as players would have to trouble shoot all this… my position remains unchanged. The bug report has a glaring hole it in regards to the cost of the bug to the player, and if what you hypothesize is true then it’s poor form that compensation for the input/timing issues was ceased.

    I get it. In fact, I've been working on a post detailing my position on the true cost of the input system issues. There's one problem that affects me personally and I suspect affects many players, but it isn't discussed directly often, and isn't one that is fixable by just tweaking the new systems.

    But that's probably a Monday thing.
  • BigBlueOxBigBlueOx Posts: 1,541 ★★★★★
    DNA3000 said:

    BigBlueOx said:

    @DNA3000 again, thanks for weighing in, at the end of the day, if they knew that this was the case and that we as players would have to trouble shoot all this… my position remains unchanged. The bug report has a glaring hole it in regards to the cost of the bug to the player, and if what you hypothesize is true then it’s poor form that compensation for the input/timing issues was ceased.

    I get it. In fact, I've been working on a post detailing my position on the true cost of the input system issues. There's one problem that affects me personally and I suspect affects many players, but it isn't discussed directly often, and isn't one that is fixable by just tweaking the new systems.

    But that's probably a Monday thing.
    Looking forward to it, appreciate the exchange
  • TerminatrixTerminatrix Posts: 1,080 ★★★★
    edited March 2023
    Ok thanks for the great explanation. It's better than the scripted "restart your device" by the support team. I hope these issues can be resolved.

    In the meantime, these issues are currently still affecting players and causing unecessary losses, especially in competitive parts of the game. This can also cause a drop in rankings.

    So what are players to do Kabam? Do we keep spending money and units on revives and health pots to get through fights with confirmed bugs and issues, or do we quit playing the game?

    What do you want us to do? Because I'd like for y'all to help us out here by compensating us some free, generous amount of progression based revives and health pots for dealing with these issues all these years.

    That's only fair.
  • TheGoauldTheGoauld Posts: 33
    Dave7099 said:

    I just want when I hit block/parry for it to work. That's it. That's not to much to ask

    believe me they want us to believe it's hard to fix. it's not astrophysics
  • SearmenisSearmenis Posts: 1,545 ★★★★★
    I said it last year, and I ll say it again: if they started making their system and AI programming from scratch, 2 years ago, now we will have a nice running game, without 90% of the players complaining, without all this frustration, and without kabam employees having to deal with us, and trying to fix the unfixable.
  • RykerRyker Posts: 45
    I literally cannot evade now w/o perfectly timed specials into my face!

    Please increase the evade window!

    I get it, your AI wants 7 evades now instead of 5.

    I just can’t keep up.
  • DNA3000DNA3000 Posts: 18,558 Guardian
    Searmenis said:

    I said it last year, and I ll say it again: if they started making their system and AI programming from scratch, 2 years ago, now we will have a nice running game, without 90% of the players complaining, without all this frustration, and without kabam employees having to deal with us, and trying to fix the unfixable.

    That is in effect what they are doing. The problem is that the new input system has an extra burden you don't list: matching the expectations of the existing players. If they started literally from scratch, with a new game engine with new input system and new data and new players almost all these problems would be gone. Because the new players would only have known the new systems, and have nothing to compare them to.

    We will always be the last legacy system that doesn't match the rest of the game.
  • CyrillFromTulaCyrillFromTula Posts: 43
    I get used to changes in timing, but now system defines action and reacting wrongly. Maybe some methods or events may not had time or info to properly respond. It happens when i try to dex while blocking. Main question - what's next? Like they said last time: "avoid hard content"? Or we can get back button to turn this off and team will find another way to communicate with us for bug info?
  • SearmenisSearmenis Posts: 1,545 ★★★★★
    DNA3000 said:

    Searmenis said:

    I said it last year, and I ll say it again: if they started making their system and AI programming from scratch, 2 years ago, now we will have a nice running game, without 90% of the players complaining, without all this frustration, and without kabam employees having to deal with us, and trying to fix the unfixable.

    That is in effect what they are doing. The problem is that the new input system has an extra burden you don't list: matching the expectations of the existing players. If they started literally from scratch, with a new game engine with new input system and new data and new players almost all these problems would be gone. Because the new players would only have known the new systems, and have nothing to compare them to.

    We will always be the last legacy system that doesn't match the rest of the game.
    I think if a completely new system appears, free of bugs etc, people will eventually be happy after spending some time learning it. After we learn the new time/screen reactions etc, we ll be able to play smoothly at last, and everyone will be happy in the end.
    It will be like learning 250 Quicksilvers :p
  • KLZKLZ Posts: 134
    edited March 2023
    Kabam employees, do you even play this game? If so, do you never encounter bugs such as these??
    You're asking us to record and send you videos, but even playing for 10 mins you will face them, because every mode is full of lag, weird and jacked up AI, parry dex issues and so on, even fricking Arena, lol...
    And what about Battlegrounds? At this point i don't even care about modders (haven't met that many, i'm just thronebreaker..), because so many times the game is just unplayable... i have lost so many Bg matches because of bugs, but i also won some due to them :D
    A few days ago i submitted a ticket asking about the status of Season 5 compensation, and they requested proof, LOL!!
    What do you really want from us?? To record hundreds of fights and send them all?
  • Lestat2499Lestat2499 Posts: 262 ★★★
    How is that tappsalot doing. Is it helping to identify issues? We all face them and it’s disappointing to see the response we have been receiving.
  • CyrillFromTulaCyrillFromTula Posts: 43
    New aw season is coming up and inputs are still horrible. When we can expect any updates on situation? It will be nice to know if i need to look for lower tier alliance
This discussion has been closed.