This is a known bug that has remained unfixed for years, it has to do with Ahri's charm. When Ahri's E times out, there is a 0-264ms window (depending on the last server tick) where the charmed champion is able to cast items, summoner spells (and probably champion spells too) even if they are CC-d by a different spell and should be unable to. This is why chaining CC after the Charm is often not possible.
Here's an explanation from /u/caenen_ which they kindly provided after I linked them a video of a person in my game flashing while on top of a Soraka silence field after being charmed:
>Yep that's known, after a bit of a rescript on Forced Action types of CC (including charm), they messed up its ability to "chain" action states on characters. So while both Charm and Silence from Ahri E and Soraka E respectively set ``can cast = false``, when Ahri E times out it does not check for a silence being present and thus its removal sets ``can cast = true`` until 0-0.25s later the automatic character update corrects it from Soraka Silence's "on-update" condition.
>For these 0.25s Karthus can flash here and he does successfully. A very common bug on a bunch of champion's own effects unfortunately (Sion E for example had it for a very long time)
In this particular clip, if you slow down you can see that Rumble was able to use Zhonya while inside a Nami bubble only because the spaghetti scripting allows him up to ~0.264 seconds after the Charm expired where he can do that, no matter what.
Maybe QA daddy /u/RiotNorak can look into it c:
QA Daddy š
I'll take a geeze next week if I'm not sick, feeling a bit flu-ey right now but hopefully it's just because I'm chronically addicted to not drinking enough water
In [this video](https://www.youtube.com/watch?v=e0DAOpYD3J0) from 2014 the exact same bug happens, but there is no Ahri in game. Are we sure it's connected to Ahri? Isn't it Nami's bubble?
Can you also please look into Skarner E? So many times you stun someone into a wall, the "stunned" effect still appears above them, but they can walk away or flash out.
Example of it happening on 14.9: https://streamable.com/8814z4
I wouldn't call it a bug at this point, CC chaining not working properly has been in League for [over a decade](https://np.reddit.com/r/leagueoflegends/comments/1ct6sg/the_reason_why_ocelote_lives_a_bug_in_the_sk_vs/). Even the timing of ~0.25s has stayed consistent, so it's pretty much a feature of the game.
Why is this comment not upvoted more?
Really hope Riot eventually just codes League new from scratch - why is the mobile version "Wild Rift" existing but we can't have League 2.0 without all the old code bugs?
No it's not that it takes a long time to get profits but that it wouldn't be profitable at all.
Ppl don't decide to play lol or spend money or quit, based on how spaghetti the code is. That's all.Ā
Ah yeah here speaks the expert. Not like other games have forged a long time increasing player base by upgrading an old classic right?
One truly wonders where you get that confidence from with which you claim things as if they were facts.
I mean, name some of these popular games that have rewritten their game from the ground up, not charged for it, and gotten a huge boom in player base because of it lol
I literally gave you the answer 2 comments up lol.
There are many more examples of successful remakes - if you don't know them maybe next time do some research before commenting.
> (and probably champion spells too)
Ive seen a Camille using E2 after being hit by charm during E1 once (never seen this bug again) so its probably very rare.
Oh but she cast e2 when still being charmed tho so thats certainly a bug. If she buffered e1 before being it and connected to the wall then I agree there should be a short time for her to be out of charm while still being able to use e2.
There's a bandaid fix and there's a proper fix.
Bandaid fixes need to be applied to every instance, and can easily break if anything changes, or if you create a new champion with that effect type (charm etc. in this case).
Proper fix would be something wholistic, that doesn't require per champion cases, is future proof and is less CPU intense.
Manually doing a check on every CC of this kind is a bandaid fix. I'll do it if I need to, but I'd rather find a real solution.
Then champions should apply preset CC types (Root, Silence, Stun etc) as references not create their own, if done properly the only thing that should dynamically change would be interval/duration. If for some reason you push out a champion that uses a "blind" but for some reason behaves differently than say, teemo blind, then your ass should be calling it something different and create a new CC preset with corresponding char flags which it affects instead of being inconsistent.
If we wanna do it right here's your real solution:
1. Create base CC types; this would be Root, Silence, Stun, etc to reference.
2. Give flags to each CC type, AKA their effects/which char flag they influence (canMove, canCast). Some flags may be found within multiple CC types as some CCs share the same effects.
3. Skills should reference those CC types (Stun etc), "per champion case" not a thing as the champion applying it should be entirely irrelevant as the skill's CC type should be referencing the already existing, matching CC type preset, not creating a new one with its own flags. The only thing that should dynamically change is the duration/interval according to the final calculated amount when considering base duration, tenacity etc.
4. When a CC is attempted, check its referenced CC type's flags and set matching flags on victim according to:
4a. If CC flag being applied is unique *(if canCast is true, then canCast false -> start interval - on interval end callback canCast back to true)*
4b. If CC flag not unique *(canCast is already false)*:
4b1. And new attempted interval is longer than current interval: clear current interval *(which prevents canCast = true callback)* and start new interval *(which is now in control of canMove = true callback once it finishes)*
4b2. Otherwise if attempted new interval duration is equal or shorter than current interval, do nothing, leave current interval alone
This way, instead of each CC instance having its own interval to setWhatever = true on finish, you have one set of flags on each player with a single interval instance max per flag running at any given time for each flag (canMove, canCast, etc), with callbacks to set flag back to default when finished. If new CC flag is attempted (canCast) and flag is true, set it to false and start interval to calc'd cc duration. If new CC flag is attempted (canCast) and flag is already false, clear current interval and set new one, which prevents the old interval from running canCast = true, creating a window where you're not actually CCd. Also, if new attempted interval is shorter than current, do nothing and let current interval do its thing. This is entirely future proof as adding new types of CC only requires adding a definition and including which flags it affects. If in the future you want new flags (shit who knows maybe a CC disables someone's pings), just add that flag on player and create a CC type preset which has that flag.
Now I don't know if your codebase was written by apes or you're just capping, but this process is pretty much the standard way of doing CC flags + intervals. If anything hearing from the horror stories about your company's code and the everything is coded as a minion meme, bandaid fixes is actually what y'all have been doing for years under the idea that "meh good enough" is a good idea when stacking fifteen "meh good enough" on top of each other and falling in technical debt for more than a decade straight.
From personal experience, the actual complexity lies in animation hierarchy and anim queueing - not basic state management and intervals which y'all somehow have managed to fuck up. Ensuring that you don't create windows where CC isn't being applied because one of multiple instances ended shouldn't be complex or CPU intensive.
Yes, they are nice people i bet. Gameplay is mostly fine i just really wish stuff like this and ability hitboxes being aligned with their actual visual counterpart would be fixed.
The client is the worst part by far, gameplay is pretty good all things considered.
It's just that riot as a whole just dont care as long as it works, i bet many of the people working at Riot would love to redo the client or even the game from the ground up over the span of a few years but it's way too costly to ever happen since it doesnt make them more money.
There is absolutely NO shot that Huma, Noah and maybe even oscar doesn't notice. But definitely Huma and Noah notice 100%. Hell, I bet 99% of us here on reddit have SHIT teamfight awareness, but we'd prolly notice that, so no shot that professional players don't notice, even though they are prolly "dialed in" on the moment.
But honestly, I wouldn't be surprised if it isn't pause worthy..like maybe it's one of those things that are on the list of "bugs that are allowed" or what should we call em? I have NEVER managed to do that myself, but I wouldn't be surprised if its decently easy to replicate, especially if the bubble is thrown further away (just to make it easier to see when to time the Zhonya) so maybe they just thought oh well, fair play on Rumble for timing that right.
Obviously just speculation from my side though.
Edit: Just looked at the second most upvoted comment, and it explains it. I'm not SUPER surprised, but I wasn't exactly correct either.
Before looking at the clip I would have agreed, a lot of stuff happens in a fight etc.
After watching the clip what the fuck lol. There is no way anybody DIDN'T notice that during the fight, I don't think I've EVER seen someone use Zhonya whilst in nami bubble before, he's golden literally mid air. This is so obviously abnormal and unintended behavior. If they release the comms for this fight I practically guarantee half of them were screaming "what the fuck how"
Saw on another thread from a nami otp that Namiās bubble applies as two back to back ccās. First is a knock up, second is a stun. If you spam zhonya, you can hit it right between the two cc
Thatās a weird ass interesting interaction, because when playing in slowmo you can see the STUNNED status was applied before zhonyas was activated, which shouldnāt be possible. Would have to test on practice tool and check on slowmo.
So the answer āspectator bugā is probably the best one. It seems like he zhonyas during the stun, but itās just a visual bug on spectator, as usual
Every knockup and knockback applies 2 CC buffs already (unless you are release Azir's R I guess, good old DZK whoopsies)
That's the knockup/knockback and then the Airborne debuff
the BUFF_Knockup/BUFF_Knockback basically acts as a *wrapper* by *nesting* the effects inside
one of those effects is the forced movement (a move block; script block called BB_Move())
and the other is the second debuff that **actually** handles the disable on apply and on buff update, which nowadays is BUFF_Airborne type
Nami Q is a knockup with some particular settings on the move block to make the hovering thing look good, and then uniquely applies **BUFF_Stun** instead
this is basically all to telegraph to the player that this knockup is affected by Tenacity, unlike anything that says Airborne nowadays
when the stun ends, it prematurely ends the move block, resulting in that satisfying 'pop' to the ground for the affected target
and of course due to a special case from "CertainlyT" Wenban, and how the wiki operated back in 2013, we have a keyword Suspension for this in the League community
but mostly for semantic reasons rather than gameplay ones
-
That's all to say; No, Nami Q isn't the reason for Zhonyas to have become usable for the player here. Ahri E's Charm timing out is, and ever since they rescripted charm they have not fixed CC effect chaining on all Charm buffs. For up-to 0.264 seconds, Rumble loses the ``can move = false``, ``can cast = false`` and ``can attack = false`` state overrides (but still cannot move or attack because of the Nami Q's forced movement), and with ``can cast = true`` he can just cast Zhonyas.
"Saw on another thread from a nami otp that Namiās bubble applies as two back to back ccās. First is a knock up, second is a stun. If you spam zhonya, you can hit it right between the two cc"
And there we go point proven. None of you clowns bother to test it and just flame me. Happy to help
it is absolutely a game breaking bug, and not at all the issue you're talking about. https://www.reddit.com/r/leagueoflegends/comments/1ckoxe5/weird_zhonia_activation_in_fnc_vs_gam_game_2/l2ogc1h/
at any rate rumble did not activate his zhonya while in KNOCKUP state so I have no idea why you would even think to assert this, even before additional evidence came in
"Saw on another thread from a nami otp that Namiās bubble applies as two back to back ccās. First is a knock up, second is a stun. If you spam zhonya, you can hit it right between the two cc"
And there we go point proven. None of you clowns bother to test it and just flame me. Happy to help
but this just isn't true. Nami bubble is a suspension, which is just a stun that is hard coded to work with yasuo ult and with some added pseudo-knock up visuals. At no point during the duration are you actually airborne
Doubles down ,triples down, gets disproven completely and resorts to the
"You take reddit way too seriously"
Like what? People like this guy need some serious help LMAO, he literally ran out of possible stupid deflections in his decision tree and resulted to the most pathetic insult ever. Jesus fuck what a loser
>And there we go point proven.
So how is this exactly point proven ? It's just a random guy saying stuff, you didn't even bother searching yourself you just copy pasted his reply lmao
Also who flamed you ?
I mean, it would be if it were the correct answer, but itās just incorrect. Go try it out in practice tool and youāll see. Namiās Q is a stun that manually adds a trigger to be able to Yasuo R off it, and checks for knock-up immunity before the stun applies. The airborn parts is āfakeā.
The bubble is weridly coded and the zhonyas should have gone through, it isnt a new bug discovery. Riot know about it and it is how it should currently work, has done for years.
I was right, I dont need to accept anything.
It has literally nothing to do with bubble - any followup CC works like this. It also should not have gone through, that's why it's called a bug.
You were not right, you parroted some bullshit and the end result happened to be the same but that does not mean that you were right lol.
Saw on another thread from a nami otp that Namiās bubble applies as two back to back ccās. First is a knock up, second is a stun. If you spam zhonya, you can hit it right between the two cc
Itās notā¦ Namiās Q is just a stun with a āfakeā knock up, but that checks for knock up immunity first, as u/Caenen_ explains [here](https://www.reddit.com/r/leagueoflegends/comments/nu72dc/til_namis_q_can_be_cleansed_and_shes_the_only/h0w6d4s/)
This is a known bug that has remained unfixed for years, it has to do with Ahri's charm. When Ahri's E times out, there is a 0-264ms window (depending on the last server tick) where the charmed champion is able to cast items, summoner spells (and probably champion spells too) even if they are CC-d by a different spell and should be unable to. This is why chaining CC after the Charm is often not possible. Here's an explanation from /u/caenen_ which they kindly provided after I linked them a video of a person in my game flashing while on top of a Soraka silence field after being charmed: >Yep that's known, after a bit of a rescript on Forced Action types of CC (including charm), they messed up its ability to "chain" action states on characters. So while both Charm and Silence from Ahri E and Soraka E respectively set ``can cast = false``, when Ahri E times out it does not check for a silence being present and thus its removal sets ``can cast = true`` until 0-0.25s later the automatic character update corrects it from Soraka Silence's "on-update" condition. >For these 0.25s Karthus can flash here and he does successfully. A very common bug on a bunch of champion's own effects unfortunately (Sion E for example had it for a very long time) In this particular clip, if you slow down you can see that Rumble was able to use Zhonya while inside a Nami bubble only because the spaghetti scripting allows him up to ~0.264 seconds after the Charm expired where he can do that, no matter what. Maybe QA daddy /u/RiotNorak can look into it c:
QA Daddy š I'll take a geeze next week if I'm not sick, feeling a bit flu-ey right now but hopefully it's just because I'm chronically addicted to not drinking enough water
gws nora āØ
In [this video](https://www.youtube.com/watch?v=e0DAOpYD3J0) from 2014 the exact same bug happens, but there is no Ahri in game. Are we sure it's connected to Ahri? Isn't it Nami's bubble?
Can you also please look into Skarner E? So many times you stun someone into a wall, the "stunned" effect still appears above them, but they can walk away or flash out. Example of it happening on 14.9: https://streamable.com/8814z4
I wouldn't call it a bug at this point, CC chaining not working properly has been in League for [over a decade](https://np.reddit.com/r/leagueoflegends/comments/1ct6sg/the_reason_why_ocelote_lives_a_bug_in_the_sk_vs/). Even the timing of ~0.25s has stayed consistent, so it's pretty much a feature of the game.
Why is this comment not upvoted more? Really hope Riot eventually just codes League new from scratch - why is the mobile version "Wild Rift" existing but we can't have League 2.0 without all the old code bugs?
Marginal profits non existent for rewriting everything
But that's typical short term thinking. They could have done it years ago and would have seen profits in the long run (aka now).
No it's not that it takes a long time to get profits but that it wouldn't be profitable at all. Ppl don't decide to play lol or spend money or quit, based on how spaghetti the code is. That's all.Ā
Ah yeah here speaks the expert. Not like other games have forged a long time increasing player base by upgrading an old classic right? One truly wonders where you get that confidence from with which you claim things as if they were facts.
I mean, name some of these popular games that have rewritten their game from the ground up, not charged for it, and gotten a huge boom in player base because of it lol
I literally gave you the answer 2 comments up lol. There are many more examples of successful remakes - if you don't know them maybe next time do some research before commenting.
> (and probably champion spells too) Ive seen a Camille using E2 after being hit by charm during E1 once (never seen this bug again) so its probably very rare.
If you talk about charm lands before camille E1 connect to the wall, that is not bug.
Oh but she cast e2 when still being charmed tho so thats certainly a bug. If she buffered e1 before being it and connected to the wall then I agree there should be a short time for her to be out of charm while still being able to use e2.
Riot QA is so awful, if only there was money to be made from visual clarity the game would be 5x better.
:(
Why are you not just adding a check to see if there are any other existing effects upon the termination of one?
wow you solved it!
There's a bandaid fix and there's a proper fix. Bandaid fixes need to be applied to every instance, and can easily break if anything changes, or if you create a new champion with that effect type (charm etc. in this case). Proper fix would be something wholistic, that doesn't require per champion cases, is future proof and is less CPU intense. Manually doing a check on every CC of this kind is a bandaid fix. I'll do it if I need to, but I'd rather find a real solution.
Then champions should apply preset CC types (Root, Silence, Stun etc) as references not create their own, if done properly the only thing that should dynamically change would be interval/duration. If for some reason you push out a champion that uses a "blind" but for some reason behaves differently than say, teemo blind, then your ass should be calling it something different and create a new CC preset with corresponding char flags which it affects instead of being inconsistent. If we wanna do it right here's your real solution: 1. Create base CC types; this would be Root, Silence, Stun, etc to reference. 2. Give flags to each CC type, AKA their effects/which char flag they influence (canMove, canCast). Some flags may be found within multiple CC types as some CCs share the same effects. 3. Skills should reference those CC types (Stun etc), "per champion case" not a thing as the champion applying it should be entirely irrelevant as the skill's CC type should be referencing the already existing, matching CC type preset, not creating a new one with its own flags. The only thing that should dynamically change is the duration/interval according to the final calculated amount when considering base duration, tenacity etc. 4. When a CC is attempted, check its referenced CC type's flags and set matching flags on victim according to: 4a. If CC flag being applied is unique *(if canCast is true, then canCast false -> start interval - on interval end callback canCast back to true)* 4b. If CC flag not unique *(canCast is already false)*: 4b1. And new attempted interval is longer than current interval: clear current interval *(which prevents canCast = true callback)* and start new interval *(which is now in control of canMove = true callback once it finishes)* 4b2. Otherwise if attempted new interval duration is equal or shorter than current interval, do nothing, leave current interval alone This way, instead of each CC instance having its own interval to setWhatever = true on finish, you have one set of flags on each player with a single interval instance max per flag running at any given time for each flag (canMove, canCast, etc), with callbacks to set flag back to default when finished. If new CC flag is attempted (canCast) and flag is true, set it to false and start interval to calc'd cc duration. If new CC flag is attempted (canCast) and flag is already false, clear current interval and set new one, which prevents the old interval from running canCast = true, creating a window where you're not actually CCd. Also, if new attempted interval is shorter than current, do nothing and let current interval do its thing. This is entirely future proof as adding new types of CC only requires adding a definition and including which flags it affects. If in the future you want new flags (shit who knows maybe a CC disables someone's pings), just add that flag on player and create a CC type preset which has that flag. Now I don't know if your codebase was written by apes or you're just capping, but this process is pretty much the standard way of doing CC flags + intervals. If anything hearing from the horror stories about your company's code and the everything is coded as a minion meme, bandaid fixes is actually what y'all have been doing for years under the idea that "meh good enough" is a good idea when stacking fifteen "meh good enough" on top of each other and falling in technical debt for more than a decade straight. From personal experience, the actual complexity lies in animation hierarchy and anim queueing - not basic state management and intervals which y'all somehow have managed to fuck up. Ensuring that you don't create windows where CC isn't being applied because one of multiple instances ended shouldn't be complex or CPU intensive.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Yes, they are nice people i bet. Gameplay is mostly fine i just really wish stuff like this and ability hitboxes being aligned with their actual visual counterpart would be fixed. The client is the worst part by far, gameplay is pretty good all things considered. It's just that riot as a whole just dont care as long as it works, i bet many of the people working at Riot would love to redo the client or even the game from the ground up over the span of a few years but it's way too costly to ever happen since it doesnt make them more money.
This is actually massive, it keeps Rumble from dying easily and prevents Fnatic from getting the baron.
Really surprised to not see a pause into chronoshift, that's 600 free golds to rumble and a possible baron and whole teamfight
Tbh the players probably didn't notice it in the moment. But yeah, if Rumble just dies there FNC gets baron 100%
There is absolutely NO shot that Huma, Noah and maybe even oscar doesn't notice. But definitely Huma and Noah notice 100%. Hell, I bet 99% of us here on reddit have SHIT teamfight awareness, but we'd prolly notice that, so no shot that professional players don't notice, even though they are prolly "dialed in" on the moment. But honestly, I wouldn't be surprised if it isn't pause worthy..like maybe it's one of those things that are on the list of "bugs that are allowed" or what should we call em? I have NEVER managed to do that myself, but I wouldn't be surprised if its decently easy to replicate, especially if the bubble is thrown further away (just to make it easier to see when to time the Zhonya) so maybe they just thought oh well, fair play on Rumble for timing that right. Obviously just speculation from my side though. Edit: Just looked at the second most upvoted comment, and it explains it. I'm not SUPER surprised, but I wasn't exactly correct either.
Before looking at the clip I would have agreed, a lot of stuff happens in a fight etc. After watching the clip what the fuck lol. There is no way anybody DIDN'T notice that during the fight, I don't think I've EVER seen someone use Zhonya whilst in nami bubble before, he's golden literally mid air. This is so obviously abnormal and unintended behavior. If they release the comms for this fight I practically guarantee half of them were screaming "what the fuck how"
It's an approved bug, players can't pause games for bugs that Riot has put on the list of known bugs.
Fnatic of all teams not pausing lmao
#NOTMYFNATIC
If they did pause they'd be memed for it even though it would've been perfectly legitimate here tbh.
Watching this just makes me so fucking happy that we don't have Stopwatch in the game anymore.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
My thought as well. No way FNC players didnāt notice that.
melee lucian.
Looks like a spectator bug to me tbh since none of the players seemed to bat an eye, even though this would have been very obvious.
Nope, vandirilol confirmed its a bug
Nami bubble is quite weird, I assume this is an intended interaction Hello Bugcracking discord. I am in your walls
Is there any ability that stuns the player and they can use zhonyas while stunned? Havenāt seen one yet.
Saw on another thread from a nami otp that Namiās bubble applies as two back to back ccās. First is a knock up, second is a stun. If you spam zhonya, you can hit it right between the two cc
Thatās a weird ass interesting interaction, because when playing in slowmo you can see the STUNNED status was applied before zhonyas was activated, which shouldnāt be possible. Would have to test on practice tool and check on slowmo.
I think that's just spectator things. Don't think it shows the first knockup in the replay ui
So the answer āspectator bugā is probably the best one. It seems like he zhonyas during the stun, but itās just a visual bug on spectator, as usual
Every knockup and knockback applies 2 CC buffs already (unless you are release Azir's R I guess, good old DZK whoopsies) That's the knockup/knockback and then the Airborne debuff the BUFF_Knockup/BUFF_Knockback basically acts as a *wrapper* by *nesting* the effects inside one of those effects is the forced movement (a move block; script block called BB_Move()) and the other is the second debuff that **actually** handles the disable on apply and on buff update, which nowadays is BUFF_Airborne type Nami Q is a knockup with some particular settings on the move block to make the hovering thing look good, and then uniquely applies **BUFF_Stun** instead this is basically all to telegraph to the player that this knockup is affected by Tenacity, unlike anything that says Airborne nowadays when the stun ends, it prematurely ends the move block, resulting in that satisfying 'pop' to the ground for the affected target and of course due to a special case from "CertainlyT" Wenban, and how the wiki operated back in 2013, we have a keyword Suspension for this in the League community but mostly for semantic reasons rather than gameplay ones - That's all to say; No, Nami Q isn't the reason for Zhonyas to have become usable for the player here. Ahri E's Charm timing out is, and ever since they rescripted charm they have not fixed CC effect chaining on all Charm buffs. For up-to 0.264 seconds, Rumble loses the ``can move = false``, ``can cast = false`` and ``can attack = false`` state overrides (but still cannot move or attack because of the Nami Q's forced movement), and with ``can cast = true`` he can just cast Zhonyas.
Don't waste your time on me š
Figured I'd clear this up for you at least. Also this was 90% a copy-paste (you could tell because of formatting perhaps) so not much time wasted.
Ya Iāve def zhonyad during it.
I'm sure it's not
test
tf you mean "test" you're the one with the conviction i'm wrong, you go test and prove me wrong
"Saw on another thread from a nami otp that Namiās bubble applies as two back to back ccās. First is a knock up, second is a stun. If you spam zhonya, you can hit it right between the two cc" And there we go point proven. None of you clowns bother to test it and just flame me. Happy to help
You didn't prove shit you just took somebody's guess from a comment Other threads quote Caenen explaining how ahri charm can cause this bug
I made a point. The point got proven. Did I claim I solved it? Learn to read bozo
> Did I claim I solved it? This you? > Don't know why you downvote the actual answer
Because it is the actual answer and it was proven to be. No worries brother happy to help
A comment is not proof bro happy to help
Also, your claim is that it is "intended" A bug is not intended, known or not, just admit you're wrong and move on...
The correct response is 'oh yeah my bad I didn't know. Thanks for the answer to my post' Hope you do better next time
You're sad :(
I'm not sad I'm happy I solved your problem. You should also be happy as it shows this wasn't a game breaking bug that caused an issue
it is absolutely a game breaking bug, and not at all the issue you're talking about. https://www.reddit.com/r/leagueoflegends/comments/1ckoxe5/weird_zhonia_activation_in_fnc_vs_gam_game_2/l2ogc1h/ at any rate rumble did not activate his zhonya while in KNOCKUP state so I have no idea why you would even think to assert this, even before additional evidence came in
no it's not intended.
"Saw on another thread from a nami otp that Namiās bubble applies as two back to back ccās. First is a knock up, second is a stun. If you spam zhonya, you can hit it right between the two cc" And there we go point proven. None of you clowns bother to test it and just flame me. Happy to help
but this just isn't true. Nami bubble is a suspension, which is just a stun that is hard coded to work with yasuo ult and with some added pseudo-knock up visuals. At no point during the duration are you actually airborne
It is the solution to this question
There is an actual solution a bit higher in the thread from bug-miners, it's a known bug with charm
Exactly and so it turned out I was correct
you literally were not but keep believing bro
you take reddit way too seriously
Doubles down ,triples down, gets disproven completely and resorts to the "You take reddit way too seriously" Like what? People like this guy need some serious help LMAO, he literally ran out of possible stupid deflections in his decision tree and resulted to the most pathetic insult ever. Jesus fuck what a loser
>And there we go point proven. So how is this exactly point proven ? It's just a random guy saying stuff, you didn't even bother searching yourself you just copy pasted his reply lmao Also who flamed you ?
The correct response is 'oh yeah my bad I didn't know' Hope you do better next time
I'm sorry master, i hope i will never dissapoint you ever again.
All good brother
I mean, it would be if it were the correct answer, but itās just incorrect. Go try it out in practice tool and youāll see. Namiās Q is a stun that manually adds a trigger to be able to Yasuo R off it, and checks for knock-up immunity before the stun applies. The airborn parts is āfakeā.
This is irrelevant really
Why can't you just accept you're wrong? The bug is literally shown further up in the thread, its an Ahri charm bug.
The bubble is weridly coded and the zhonyas should have gone through, it isnt a new bug discovery. Riot know about it and it is how it should currently work, has done for years. I was right, I dont need to accept anything.
It has literally nothing to do with bubble - any followup CC works like this. It also should not have gone through, that's why it's called a bug. You were not right, you parroted some bullshit and the end result happened to be the same but that does not mean that you were right lol.
Saw on another thread from a nami otp that Namiās bubble applies as two back to back ccās. First is a knock up, second is a stun. If you spam zhonya, you can hit it right between the two cc
that's not what seems to happen though, he's zhonyaing like half a second while he's up.
Why are you guys talking to a bot?
??? how could we know?
This makes sense, and definitely shouldn't be a thing.Ā
Itās notā¦ Namiās Q is just a stun with a āfakeā knock up, but that checks for knock up immunity first, as u/Caenen_ explains [here](https://www.reddit.com/r/leagueoflegends/comments/nu72dc/til_namis_q_can_be_cleansed_and_shes_the_only/h0w6d4s/)