Jump to content
Koumei & the Five Fates: Share Bug Reports and Feedback Here! ×

Of All Things, They Nerfed The Shield Lancer...


Madotsuki
 Share

Recommended Posts

You all remember shield lancers right? The grineers with black shields whose signature move and most dangerous ability is to charge at you and bash you onto the ground with their shield?

As of Update 7.11, shield lancers have lost the ability to bash people. I'm serious, if you see a shield lancer in-game now, just kill everything else and then stand there. Let the shield lancer charge at you. I've had a shield lancer charge up against my body, running in place, and not bash me. WTF?

Of ALL the things that actually needed some tweaking, they chose to stealth nerf the shield lancer. Not the Disruptors that take away all of your energy and shields in a single hit and can knock you down and even get a guaranteed second hit after knockdown; not the Rollers that are hard to hit and stunlock you; not the chargers who can swarm and stunlock you; not the shockwave moas who can, as long as there's more than one, knock you down while you are ALREADY knocked down. Nope, they nerf the shield lancer and take away his shield bash, his one defining feature, and one of the few mobs in this game whose knockdowns are justified and can't stunlock you.

I'm hoping this is a glitch, and that it'll be fixed soon, because this stealth nerf is just absurd.

Link to comment
Share on other sites

Instead of all that hyperbole, why not just post a bug report?

Because it seems unlikely that it's an accidental bug. The Shield Lancers were not changed in any other way, so it seems that the removal of shield bashing seems to be on purpose. The "I hope it's just a glitch" is just me giving DE a bit of the benefit of the doubt.
Link to comment
Share on other sites

Because it seems unlikely that it's an accidental bug. The Shield Lancers were not changed in any other way, so it seems that the removal of shield bashing seems to be on purpose. The "I hope it's just a glitch" is just me giving DE a bit of the benefit of the doubt.

 

If bugs were easy to predict they wouldn't exist outside of incompetence. In reality sometimes you make a change, and something you think is entirely unrelated is affected. A game like this is not a simple nor small amount of code.

Link to comment
Share on other sites

@Akivoodoo
As a professional programmer I can vouch for that completely.

I can make changes to one part of the code that I dont think will affect anything yet it can affect a large number of things simply by how they are related.  And it is not easy to predict, nor possible all the time.  Bugs and glitches get in when you are changing one or two things because programmers honestly cant predict how a small change in say timing of one function can cause half a dozen other functions to fail.

@Madotsuki
Just because the shield lancers were not changed does not mean that one of changes that they did make does affect them.  There could be any number of factors that affect when it uses its shield bash.  From internal CD of that attack to range to just an outright priority of when to use it compared to something else.  Any code change to how the game handles internal CDs, general attack range, or enemy move priority could have caused the shield lancer to stop using the ability.

Link to comment
Share on other sites

If bugs were easy to predict they wouldn't exist outside of incompetence. In reality sometimes you make a change, and something you think is entirely unrelated is affected. A game like this is not a simple nor small amount of code.

That's what testing is for.

 

Is it that hard to run through a single level of every faction before a patch? That's an extra half an hour to spot things like messed up leech ospreys, shield lancers not bashing, glitched impassable doors etc.

Link to comment
Share on other sites

@Argoms
Depending on how the bug manifests it could have been that they did not notice that the shield lancers weren't doing the shield bash.

Until he mentioned it I had not noticed that they weren't doing it either.

Also when doing unit tests over things you dont test every last thing every time you build.  You test what could have broken as well as a few general quality tests and then move on.  You focus on what changes you have made and test around those, because you cant predict that ti would have affected doors.  So instead of spend man hours testing something which probably hasn't changed/broken they spend it testing what most likely would have changed/broken.

Link to comment
Share on other sites

I don't think they test the actual game at all. Let's look at a recent update- fusion moas. During this update, ospreys gained stupid amounts of health and were scaled up massively. Additionally, shockwave moas all turned green. Both of these are corpus-faction enemies with pretty obvious changes, and the fact that these bugs happened in our game implies that nobody played through a corpus level to test the moas.

Link to comment
Share on other sites

@Argoms
Depending on the time limit that projects have, especially for the coders, they test it to go "Does it work and does this mob do x, y, and z properly?"  if the answer is yes to both of those questions they will build and commit that build.  Then they go back through and clean up code and find and fix bugs/glitches.  And depending on the project mangers they will either push the committed changes and go "Here is the patch/update" even though the coders are still working on the bugs and glitches.

Its not always that they don't test it, its also internal politics and mangers that can easily cause bugs and glitches to get into the game.  And its usually because they have a hard dead-line and need to get something out by then and as long as it runs they'll push it out.  And before you bring up game crashes they cant possibly test on all hardware/software configurations so a few might crash and they wont know about them until people start reporting them.

And usually the biggest reason that they get it out the door fast instead of taking *extra* time to run a fine tooth-comb over the code for bugs?
Because, and I have heard this more than a few times in my career, "The customers wont be happy if we have to slip our dates out." and most companies would rather have a little bit of frustration over bugs rather than anger that their update will be late.

Edited by Tsukinoki
Link to comment
Share on other sites

You do realize WE are here to find these bugs right?

"Beta testing comes after alpha testing and can be considered a form of external user acceptance testing. Versions of the software, known as beta versions, are released to a limited audience outside of the programming team. The software is released to groups of people so that further testing can ensure the product has few faults or bugs. Sometimes, beta versions are made available to the open public to increase the feedback field to a maximal number of future users."

Link to comment
Share on other sites

@Argoms

Depending on the time limit that projects have, especially for the coders, they test it to go "Does it work and does this mob do x, y, and z properly?"  if the answer is yes to both of those questions they will build and commit that build.  Then they go back through and clean up code and find and fix bugs/glitches.  And depending on the project mangers they will either push the committed changes and go "Here is the patch/update" even though the coders are still working on the bugs and glitches.

Its not always that they don't test it, its also internal politics and mangers that can easily cause bugs and glitches to get into the game.  And its usually because they have a hard dead-line and need to get something out by then and as long as it runs they'll push it out.  And before you bring up game crashes they cant possibly test on all hardware/software configurations so a few might crash and they wont know about them until people start reporting them.

And usually the biggest reason that they get it out the door fast instead of taking *extra* time to run a fine tooth-comb over the code for bugs?

Because, and I have heard this more than a few times in my career, "The customers wont be happy if we have to slip our dates out." and most companies would rather have a little bit of frustration over bugs rather than anger that their update will be late.

I would think, at least concerning enemies, it shouldn't be THAT hard to test some basic functionality. It's not hard to make a "dev stage" where they keep, like, one of every enemy and boss in a little pen so that the devs can just go in and give each enemy a minor test run. It won't spot every problem, but hell it would fix stuff like stupid miscolors (Vor and Tyl Regor's armor turning white for SEVERAL updates, Shockwave Moa turning green etc.) or basic health/shields amount (Osprey health going on steroids, shields stop showing damage), or if they take a little more time, even some major behaviour glitches (Nef Anyo infinite cloak). They don't actually have to go and run levels or anything.

And, at least personally, I would rather have a delayed update that works properly, than an on-time update filled to the brim with bugs and glitches.

Link to comment
Share on other sites

@Madotsuki
Sadly most people would rather they get their update on time then have it slip a few days/a week because of bug fixes.  I work in an environment where I have to fix as much as I can and leave in the non-critical bugs that dont really affect the usage because we *need* to get the product to the consumers.  And the reason?  *Most* consumers would rather have a slightly buggy release *now* and then get a few quicker patches rather than wait for a perfect release later.

And as I said it's usually office politics which also have a role.  A coder might say "I got in features X and Y but it has caused errors A and B."  The manger will go "Are those *breaking* bugs?" and if they aren't they'll release them because the manager has to release something or they will get in trouble.

And for errors like Nef Anyo's cloak, in order to fix it you have to figure out where exactly the AI routine gets stuck in a loop and fix it, while at the same time not breaking anything else the enemy does.  AI is *very* fickle and sometimes you cant do much else but go "It could take 3 weeks to debug and find out where this glitch lies." and in *most* cases the consumer doesnt want to wait 3 extra weeks for a relatively small bug fix when the rest of the patch works.  Same with the recolouring bugs.

From the consumers point of view they want their software *now* and they want it working.  Small bugs may frustrate them but they wont get as angry over small bugs as they will if they are forced to wait a few weeks to get their patch.

Edited by Tsukinoki
Link to comment
Share on other sites

I don't think they test the actual game at all. Let's look at a recent update- fusion moas. During this update, ospreys gained stupid amounts of health and were scaled up massively. Additionally, shockwave moas all turned green. Both of these are corpus-faction enemies with pretty obvious changes, and the fact that these bugs happened in our game implies that nobody played through a corpus level to test the moas.

There is also the bugs with Iron Skin - testing against any of the factions should have revealed the knockdown/stagger one.

Plus we also have the Skana costing more than the Cronus. I think they rushed out the latest path without much though to give us something. Like Tsukinoki said, customers tend to want updates rather than having to wait. One one hand I appreciate that they did give us something, on the other it has seemingly obvious problems.

On a slightly more constructive note, I think what happened is the same code that made Rhino invulnerable also provided his immunity. Or the immunity was a side effect of not taking damage. Canceling the attack before damage is dealt would also cancel any effects if they are applied after damage. Given the large amount of code Warframe has it is quite possible that the people making the Iron Skin change did not know how it worked. They probably assumed that immunities were coded in rather than a side effect. Which to be fair is a reasonable conclusion. Of course it still would have been revealed with testing but given the assumption made they probably didn't think they needed to test it.

The above shows how one change can have unintended consequences when programming. It is very likely that a change somewhere else caused the current problem with the Shield Lancer.

Link to comment
Share on other sites

@Unknown924
That does bring up a good point.  And also brings up a few more cases for some of the bugs we have seen.  Such as when they introduced fusion moas and the osprey they spawned the other osprey got a lot tankier.  I would bet that the group who made the fusion osprey thought it was too weak and tweaked some numbers in the base osprey class to make them tougher, not knowing how those numbers interacted with the rest of the osprey units.

Also I think you are onto something about why rhino is currently being affected by stuns and other things he should be immune to.  And I wouldn't have thought immeadiently that his being immune to damage was why he was immune to everything else, though it does make sense now that I think about it.  And they may not have had enough time to test it depending on how pushed they were to get a working version out the door.  And by working I mean it doesnt crash on their test systems and you can load missions and do the basic stuff.

A large number of bugs are caused simply because not everyone working on the project knows exactly how everything works together or what will affect what.  I've picked up a project and found what I thought to be a bug, but which was actually required in order for a few other things to work properly.  Took a major recoding effort after I "fixed" what was happening only for customers to tell me that everything else broke.

And especially when dealing with AI code and such, the code complexity is amazingly high which makes it very difficult to figure out what went wrong and where.

Edited by Tsukinoki
Link to comment
Share on other sites

Heck, I managed to cause solution verification code for one of my computer science projects to crash last semester. We had a getter method for a list of target vertices to use. I looped through the list removing vertices as I handled them until it was empty. Well, the list was passed by reference and was used by the verification code to check the solution. Said list was now empty. Of course we had no documentation on the verification code since we did not need it. I ended up having to copy the contents of the list to a new local list and remove from that.

Back to Warframe: What made me think status effects were linked to damage was that Ember players were reporting being sometimes immune to lower level disruptions. That made me think disruption requires dealing above a certain amount of damage for some reason.

Edited by Unknown924
Link to comment
Share on other sites

@Unknown924
That would be something for DE to look into and see if the level of damage caused is what is causing the disruptions to begin with.  And it would be something not easily noticed.  Say the disruption has to deal at least 50 points of damage, because it drains your shields fully as well as your energy no one would have noticed that it has to deal at lest 50 points of damage to take effect.

This could also be cause for them to look into knock backs/downs/stuns to see how much they are affected by the same rules, such as does a shockwave have to deal a minimum damage to knock people flying?

This rhino bug with the CC immunity could cause a whole slew of related things get discovered that would have otherwise been passed on by because of how they work.

Link to comment
Share on other sites

@Weird_Stealth
It is most likely a bug that caused this to happen, and with AI it is hard to figure out where the bug came from.

It could possibly be related to how they now have sawmen with saws and others with cleavers.  Hard to say but they are hopefully looking into it.

Link to comment
Share on other sites

@Weird_Stealth

It is most likely a bug that caused this to happen, and with AI it is hard to figure out where the bug came from.

How is scoring headshots a bug? I am just above the top of the shield, wait for the right second when the top of his head shows up, and fire, sometimes I even score a shot or two through the vent.

Link to comment
Share on other sites

Nitpick : it can't be a stealth nerf AND a glitch at the same time. It's one or the other. I'm betting on glitch.

 

What this guy said. Seriously.

 

How is scoring headshots a bug? I am just above the top of the shield, wait for the right second when the top of his head shows up, and fire, sometimes I even score a shot or two through the vent.

 

He's talking about the "no bashy-bashy" stuff, man. You don't seriously think he's THAT dumb to claim headshots vs lancers are bugs, do you?

 

can't be a stealth nerf. can not backstab shield lancers last time i checked. will test out in a moment anyway.

 

EDIT: tested out in mp and sp. your statement is false. you can't backstab shield lancers therefore this can't be stealth nerf.

 

...wow. Do you even know what "stealth nerf" means, dude? Damn...

 

----

 

And finally: this is a GLITCH, people. A BUG. AN UNFORESEEN CHANGE IN CODING. They didn't INTEND to change this. Seriously.

Edited by Captain_Seasick
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...