Good job zos broke overload with today's incremental

ZOS_RyanRuzich

~A wild programmer appears~
The fix for the dodgeroll exploit added a bit of code to the function that gets called whenever you cancel a cast in progress. Whenever you switch hotbars, we also cancel your current cast (this prevents a multitude of exploits). Overload switches your hotbar to your overload hotbar, thus calling the cancel cast function, and the new code. The checks added incorrectly triggered on Overload, thus cancelling the Overload ability's cast. Hope this sheds a bit of light on how the two are related. It was an honest mistake, and one we're glad we could provide a quick fix for thanks to your reports.

Rune_Relic

@ZOS_RyanRuzich Thanks for the update on the 3rd bar weapon swapping issue. Much appreciated.

Mujuro

ZOS_RyanRuzich wrote: »

~A wild programmer appears~
The fix for the dodgeroll exploit added a bit of code to the function that gets called whenever you cancel a cast in progress. Whenever you switch hotbars, we also cancel your current cast (this prevents a multitude of exploits). Overload switches your hotbar to your overload hotbar, thus calling the cancel cast function, and the new code. The checks added incorrectly triggered on Overload, thus cancelling the Overload ability's cast. Hope this sheds a bit of light on how the two are related. It was an honest mistake, and one we're glad we could provide a quick fix for thanks to your reports.

I'm going out on a limb here ... but don't you all do any sort of systems/integration testing for things that you change? I'm not even talking about regression -- we already know ZOS doesn't do that. Stated another way, if you're going to change something that impacts hotbar swapping, shouldn't reasonable practices in testing dictate that your team actually TESTS what you changed with switching hotbars including, but not limited to, overload hotbars? Or am I just missing something here?

Zyle

ZOS_RyanRuzich wrote: »

~A wild programmer appears~
The fix for the dodgeroll exploit added a bit of code to the function that gets called whenever you cancel a cast in progress. Whenever you switch hotbars, we also cancel your current cast (this prevents a multitude of exploits). Overload switches your hotbar to your overload hotbar, thus calling the cancel cast function, and the new code. The checks added incorrectly triggered on Overload, thus cancelling the Overload ability's cast. Hope this sheds a bit of light on how the two are related. It was an honest mistake, and one we're glad we could provide a quick fix for thanks to your reports.

When it was broken someone found out that you could activate it and spam bash to get it to cast, is this an indicator that the code isn't properly stopping casts even though it should have been in this case?

Malmai

Woeler wrote: »

Why do these topics always have to be titled in such a dramatic and accusative way?

"Good job ZOS", seriously, how old are we? 12?

Pretty sure it will get fixed before tomorrow IF this is something everyone experiences.

Pretty sure its not gonna be like you said.

eventide03b14a_ESO

ZOS_RyanRuzich wrote: »

~A wild programmer appears~
The fix for the dodgeroll exploit added a bit of code to the function that gets called whenever you cancel a cast in progress. Whenever you switch hotbars, we also cancel your current cast (this prevents a multitude of exploits). Overload switches your hotbar to your overload hotbar, thus calling the cancel cast function, and the new code. The checks added incorrectly triggered on Overload, thus cancelling the Overload ability's cast. Hope this sheds a bit of light on how the two are related. It was an honest mistake, and one we're glad we could provide a quick fix for thanks to your reports.

Thank you so much for that explanation. I'm very pleased to see that the matter was addressed quickly. Good job.

Lava_Croft

TIL: ZOS has programmers that can speak and write English.

Taonnor

ZOS_RyanRuzich wrote: »

~A wild programmer appears~
The fix for the dodgeroll exploit added a bit of code to the function that gets called whenever you cancel a cast in progress. Whenever you switch hotbars, we also cancel your current cast (this prevents a multitude of exploits). Overload switches your hotbar to your overload hotbar, thus calling the cancel cast function, and the new code. The checks added incorrectly triggered on Overload, thus cancelling the Overload ability's cast. Hope this sheds a bit of light on how the two are related. It was an honest mistake, and one we're glad we could provide a quick fix for thanks to your reports.

Hmm, you should take some effort into automated regression tests for your nightly build to avoid these side effects. There are good tools around for automated tests like TestComplete or Squish.

Darlgon

ZOS_RyanRuzich wrote: »

~A wild programmer appears~
The fix for the dodgeroll exploit added a bit of code to the function that gets called whenever you cancel a cast in progress. Whenever you switch hotbars, we also cancel your current cast (this prevents a multitude of exploits). Overload switches your hotbar to your overload hotbar, thus calling the cancel cast function, and the new code. The checks added incorrectly triggered on Overload, thus cancelling the Overload ability's cast. Hope this sheds a bit of light on how the two are related. It was an honest mistake, and one we're glad we could provide a quick fix for thanks to your reports.

Thanks for the answer..

However, this brings up, cancel cast is tied to both dodge-roll and swapping hotbars, how? I was pretty sure players call that animation cancelling. And, you don't cancel a cast when you dodge-roll that I have ever seen, nor do I swap hotbars when I dodge roll..Sigh. NM. Maybe I dont really want to know.

Tomato

ZOS_RyanRuzich wrote: »

~A wild programmer appears~
The fix for the dodgeroll exploit added a bit of code to the function that gets called whenever you cancel a cast in progress. Whenever you switch hotbars, we also cancel your current cast (this prevents a multitude of exploits). Overload switches your hotbar to your overload hotbar, thus calling the cancel cast function, and the new code. The checks added incorrectly triggered on Overload, thus cancelling the Overload ability's cast. Hope this sheds a bit of light on how the two are related. It was an honest mistake, and one we're glad we could provide a quick fix for thanks to your reports.

When will you be putting the fix back in for the dodge roll exploit and others associated with this?

Elsonso

.

Tomato wrote: »

ZOS_RyanRuzich wrote: »

~A wild programmer appears~
The fix for the dodgeroll exploit added a bit of code to the function that gets called whenever you cancel a cast in progress. Whenever you switch hotbars, we also cancel your current cast (this prevents a multitude of exploits). Overload switches your hotbar to your overload hotbar, thus calling the cancel cast function, and the new code. The checks added incorrectly triggered on Overload, thus cancelling the Overload ability's cast. Hope this sheds a bit of light on how the two are related. It was an honest mistake, and one we're glad we could provide a quick fix for thanks to your reports.

When will you be putting the fix back in for the dodge roll exploit and others associated with this?

Depending on how Update 9 is coming along (schedule-wise) and how the dodge roll fix stacks up against that, in an upcoming incremental patch or in the Update itself. At this point, you have to expect that QA is very occupied with Update 9 in preparation for PTS, even if the devs have the time to fix this right away.

purple-magicb16_ESO

Anyone else still having issues with energy overload?
Still seems broken to me. It doesn't always fire on MB click. Light or heavy.

DDemon

purple-magicb16_ESO wrote: »

Anyone else still having issues with energy overload?
Still seems broken to me. It doesn't always fire on MB click. Light or heavy.

This problem has been in game since forever, you need to block once in order to get it working again. Sometimes it's persistent and you need to go out of overload and back in to get it to work.

Infinite12

ginoboehm wrote: »

just do one dungeon with 4 people every class and go and try pvp for 2 seconds this whole stuff would be found out that

Well this shows how little you understand how right Gina is. It's IMPOSSIBLE to check EVERY aspect. If they used your method of bug finding then that still wouldn't have found the bug that caused wrothgar quest givers to be stuck in ceilings. It really is impossible to check every aspect of the game for bugs. I don't often side with ZoS on many things but this one I have to.

purple-magicb16_ESO

DDemon wrote: »

purple-magicb16_ESO wrote: »

Anyone else still having issues with energy overload?
Still seems broken to me. It doesn't always fire on MB click. Light or heavy.

This problem has been in game since forever, you need to block once in order to get it working again. Sometimes it's persistent and you need to go out of overload and back in to get it to work.

Cool! Thanks for the work-around!

Iove

Seriously, a sorc skill gets broken and Devs are on it straight away. Some templar skills have been broken forever and no one cares still! Nice

Magdalina

nicab16_ESO wrote: »

Seriously, a sorc skill gets broken and Devs are on it straight away. Some templar skills have been broken forever and no one cares still! Nice

Afaik templar skills do work(sometimes), they're just extremely buggy. So is Overload. They just brought it back from "100% not working" to "extremely buggy". It still gets stuck in heavy every 3rd attack, occasionally locks bars til you bash/dodge/turn it on/off(this one seems even worse lately for me somehow), keeps working but stops showing the animation etc etc etc. It just does (usually) turn on again now.

daemonios

nicab16_ESO wrote: »

Seriously, a sorc skill gets broken and Devs are on it straight away. Some templar skills have been broken forever and no one cares still! Nice

That's been said before in this thread. Maybe by you. It's getting old. They didn't fix anything, they just removed a patch for roll dodge which also 100% broke overload. Which still has a number of bugs.

Iove

I

daemonios wrote: »

nicab16_ESO wrote: »

Seriously, a sorc skill gets broken and Devs are on it straight away. Some templar skills have been broken forever and no one cares still! Nice

That's been said before in this thread. Maybe by you. It's getting old. They didn't fix anything, they just removed a patch for roll dodge which also 100% broke overload. Which still has a number of bugs.

I haven't commented on this thread at all until then. It just seems really unfair. I'm allowed to post here just as you are.

Artjuh90

Magdalina wrote: »

nicab16_ESO wrote: »

Seriously, a sorc skill gets broken and Devs are on it straight away. Some templar skills have been broken forever and no one cares still! Nice

Afaik templar skills do work(sometimes), they're just extremely buggy. So is Overload. They just brought it back from "100% not working" to "extremely buggy". It still gets stuck in heavy every 3rd attack, occasionally locks bars til you bash/dodge/turn it on/off(this one seems even worse lately for me somehow), keeps working but stops showing the animation etc etc etc. It just does (usually) turn on again now.

Yes toppling charge works great. although you have bout 10% chance not to be able to do anything after xD

mrdavis1118ub17_ESO

ZOS_GinaBruno wrote: »

Cazzy wrote: »

Out of curiosity, do patches get checked or tested before being applied?

Unfortunately, it's impossible to check each and every piece of the game before each patch..

This is "absolutely" incorrect, and I will tell you why. Unit testing. If your dev team was implementing this now STANDARD practice on 100% of their code, along with integration and automated GUI testing, you guys would not be running into these kinds of issues after every, single, incremental. Now if your current team inherited the spaghetti code mistakes of their predecessors, that is one thing, but it is not an excuse for new code (ie new items sets with new effects that didn't exist previously). If you are being told your team does unit testing, then its time to bring in an expert who can show them how it is done, because they are not doing it right. I suspect part of the problem is your QA process not giving the devs adequate feedback so they can write proper unit tests, as it is understandable that devs don't have enough time to "play the game" as is the common complaint of the player base, so it falls on the testing team. We have seen the testers play the game on ESO live (IC preview comes to mind) and it was blatantly obvious they don't "play the game" either. There is zero excuse for god mode combat tours, with completely random/arbitrary skill rotations, etc. which appears to happen every single time you show an employee demoing the game. I have played PTS for every DLC, and every incremental within, and most of the bugs are found within the first couple HOURS by a very small group of players, yet go weeks before being addressed/acknowledged, if at all (ie the OP about overload has actually been behaving like this all year, and there are posts to prove it.). Also, /bug being broken for as long as it has been is another indicator of the lack of priority in implementing a proper testing/bug reporting process, which should of been the very first thing listed on 2.3.0 patch notes. I apologize if this reply is coming off snarky, but the frustration in the community is real and tangible, and this year is going to be a turning point for this game, because console players are even less forgiving when it comes to bugs, and will rather just quit playing the game then report things. You have no real competition in the console market, but that will change quickly, and I can only hope your testing team can evolve quickly enough.

WatchYourSixx

mrdavis1118ub17_ESO wrote: »

ZOS_GinaBruno wrote: »

Cazzy wrote: »

Out of curiosity, do patches get checked or tested before being applied?

Unfortunately, it's impossible to check each and every piece of the game before each patch..

This is "absolutely" incorrect, and I will tell you why. Unit testing. If your dev team was implementing this now STANDARD practice on 100% of their code, along with integration and automated GUI testing, you guys would not be running into these kinds of issues after every, single, incremental. Now if your current team inherited the spaghetti code mistakes of their predecessors, that is one thing, but it is not an excuse for new code (ie new items sets with new effects that didn't exist previously). If you are being told your team does unit testing, then its time to bring in an expert who can show them how it is done, because they are not doing it right. I suspect part of the problem is your QA process not giving the devs adequate feedback so they can write proper unit tests, as it is understandable that devs don't have enough time to "play the game" as is the common complaint of the player base, so it falls on the testing team. We have seen the testers play the game on ESO live (IC preview comes to mind) and it was blatantly obvious they don't "play the game" either. There is zero excuse for god mode combat tours, with completely random/arbitrary skill rotations, etc. which appears to happen every single time you show an employee demoing the game. I have played PTS for every DLC, and every incremental within, and most of the bugs are found within the first couple HOURS by a very small group of players, yet go weeks before being addressed/acknowledged, if at all (ie the OP about overload has actually been behaving like this all year, and there are posts to prove it.). Also, /bug being broken for as long as it has been is another indicator of the lack of priority in implementing a proper testing/bug reporting process, which should of been the very first thing listed on 2.3.0 patch notes. I apologize if this reply is coming off snarky, but the frustration in the community is real and tangible, and this year is going to be a turning point for this game, because console players are even less forgiving when it comes to bugs, and will rather just quit playing the game then report things. You have no real competition in the console market, but that will change quickly, and I can only hope your testing team can evolve quickly enough.

While I understand what you are saying, I think what Gina's point was is that the game is simply too big to check everything before a new patch. If you have ever worked on coding a game before, you would know that even a simple game can have hundreds of lines of code. Imagine ESO as thousands and thousands of little simple games, and you easily get hundreds of thousands of lines of code. I have little experience with that, so I cannot say an estimate of how much there is, but its gotta be massive. The game is the largest game (GB wise) I have ever seen, and the different combinations of things in the game are impossible to test 100% before its sent out.

My 2 cents.

cosmic_niklas_93b16_ESO

Neeeeecro!
Not to mention that the issue has already been fixed, so no need to post here anymore.

mrdavis1118ub17_ESO

cosmic_niklas_93b16_ESO wrote: »

Neeeeecro!
Not to mention that the issue has already been fixed, so no need to post here anymore.

Actually, I was talking about the issue where light attacks stop working (as demonstrated in the Sypher video and mentioned multiple times in this thread and many other posts) and you have to block multiple times or swap to get "unstuck". This is still happening and very easy to reproduce. I was in error when I referred to the OP issue and this as one in the same, which as we all know they just rolled back from the completely broken state to the already existing "less broken" state it has been in for a long time, but my points are still valid.

mrdavis1118ub17_ESO

While I understand what you are saying, I think what Gina's point was is that the game is simply too big to check everything before a new patch. If you have ever worked on coding a game before, you would know that even a simple game can have hundreds of lines of code. Imagine ESO as thousands and thousands of little simple games, and you easily get hundreds of thousands of lines of code. I have little experience with that, so I cannot say an estimate of how much there is, but its gotta be massive. The game is the largest game (GB wise) I have ever seen, and the different combinations of things in the game are impossible to test 100% before its sent out.

My 2 cents.

Again, that assumption is completely incorrect. This is exactly what modern software testing techniques were created for. The larger the project, the greater the need to use these techniques. It automates the entire process of "looking for bugs", so you don't need a human at all to hunt things down. Oversimplified Example: Dev creates a new ability. They fine tune it and get it working the way they want. They then create a test case function that emulates a player using the ability, and check for the expected ability behavior. This test is then run after EVERY incremental patch. Fast forwarding a bit, an unrelated change to the codebase affects this new ability unintentionally, so then the test case returns an error, and the dev knows to go take a look and fix the ability. The larger the project, the more fine grained you have to make your tests. This also lets future devs know how the ability originally worked without having to make any assumptions. This is standard practice and any dev who has worked on a modern, multi-million project will know they are supposed to be doing this for 100% of the code they write, but often what you will see is cutting corners because it is significantly more work for the dev up front. Problem with that is, 6 months go by, you work on a million different things since then, so when xyz ability stops working the way it is supposed to, you create exponentially more work because you are having to dig through tons of debug logs and do detective work to find the cause, when doing it right the first time would remove the need for that entirely. It is blatantly obvious they are either not doing this at all, or writing ineffective tests, which means they need to bring someone else in.

https://en.wikipedia.org/wiki/Software_testing#Testing_levels

KraziJoe

mrdavis1118ub17_ESO wrote: »

While I understand what you are saying, I think what Gina's point was is that the game is simply too big to check everything before a new patch. If you have ever worked on coding a game before, you would know that even a simple game can have hundreds of lines of code. Imagine ESO as thousands and thousands of little simple games, and you easily get hundreds of thousands of lines of code. I have little experience with that, so I cannot say an estimate of how much there is, but its gotta be massive. The game is the largest game (GB wise) I have ever seen, and the different combinations of things in the game are impossible to test 100% before its sent out.

My 2 cents.

Again, that assumption is completely incorrect. This is exactly what modern software testing techniques were created for. The larger the project, the greater the need to use these techniques. It automates the entire process of "looking for bugs", so you don't need a human at all to hunt things down. Oversimplified Example: Dev creates a new ability. They fine tune it and get it working the way they want. They then create a test case function that emulates a player using the ability, and check for the expected ability behavior. This test is then run after EVERY incremental patch. Fast forwarding a bit, an unrelated change to the codebase affects this new ability unintentionally, so then the test case returns an error, and the dev knows to go take a look and fix the ability. The larger the project, the more fine grained you have to make your tests. This also lets future devs know how the ability originally worked without having to make any assumptions. This is standard practice and any dev who has worked on a modern, multi-million project will know they are supposed to be doing this for 100% of the code they write, but often what you will see is cutting corners because it is significantly more work for the dev up front. Problem with that is, 6 months go by, you work on a million different things since then, so when xyz ability stops working the way it is supposed to, you create exponentially more work because you are having to dig through tons of debug logs and do detective work to find the cause, when doing it right the first time would remove the need for that entirely. It is blatantly obvious they are either not doing this at all, or writing ineffective tests, which means they need to bring someone else in.

https://en.wikipedia.org/wiki/Software_testing#Testing_levels

sounds like someone is in an Ethics class or something...
I would love it if they did that kind of testing! What I wouldn't love is the price we would have to pay to play the game. Those testers don't work for free you know...