According to the patch notes, yesterday's patch had to do with the following things:

Submitting support tickets

The Cartel Market

Trading

French audio

So how did a patch to these areas of the game manage to break companion functionality? Nothing in the patch has anything to do with companions at all. There seems to be no connection between the patch and the bug that came out with the patch.

So what happened? Is SWTOR's code so broken and tangled that fixing French audio or putting Cartel items on sale can somehow break Companion stats? That would be very odd. It seems more likely that some programmer decided to mess around with companion gear functionality without telling anybody and broke it. Genius.

We are quick to blame testing when a bug comes out, but if the testers are looking at the same patch notes as us, they really had no reason at all to test companion functionality. If I'm a tester looking at those patch notes, I'm submitting test support tickets, I'm buying the items that are on sale to make sure I get the discount, I'm testing out trading with a preferred account under level 10, I'm playing the conversations with General Avrun in French... basically testing everything that supposed to be affected by the patch. Testers can't test every inch of the game every time a patch is released. They have to focus their testing on what was changed. I think the problem is that they are not being told everything that is changed with each patch. And neither are we, for that matter.

According to the patch notes, yesterday's patch had to do with the following things:

Submitting support tickets

The Cartel Market

Trading

French audio

 

So how did a patch to these areas of the game manage to break companion functionality? Nothing in the patch has anything to do with companions at all. There seems to be no connection between the patch and the bug that came out with the patch.

 

So what happened?

You are under the wrong assumption that only what is documented in the patch notes is the limit and extent of changes in the patch.

No disrespect, but you really should know better if you have played MMOs for any length of time at all.

You are under the wrong assumption that only what is documented in the patch notes is the limit and extent of changes in the patch.

 

No disrespect, but you really should know better if you have played MMOs for any length of time at all.

It would just as wrong to assume they touched anything to do with companions.

It would just as wrong to assume they touched anything to do with companions.

Not when there is a known problem with HK-51. I can totally see where someone was inside the code tinkering with something to try to fix that. And if they were careless as they did so... who knows what got broken.

Nothing in the patch has anything to do with companions at all. There seems to be no connection between the patch and the bug that came out with the patch.

Just a thought, but I noticed that companion preview of equipment was not working properly. If they were trying to fix this feature that happened to be in the Cartel Market patch, then it may be related.

For whatever reason, I could only ever see the feet for my companions after F2P was released. It was like this on PTS as well. Prior to this patch release, I could at least look at certain gear for my companions. Also, switching between companions in the preview didn't work properly for me either.

This may be flimsy, but what if the gear preview paperdoll was somehow involved?

Just a thought, but I noticed that companion preview of equipment was not working properly. If they were trying to fix this feature that happened to be in the Cartel Market patch, then it may be related.

 

For whatever reason, I could only ever see the feet for my companions after F2P was released. It was like this on PTS as well. Prior to this patch release, I could at least look at certain gear for my companions. Also, switching between companions in the preview didn't work properly for me either.

Good points. You are correct, it was working flaky after 1.5 went live.

On the one hand, it is possible that pest control at BioWare's development offices is not all that good.

On the other hand, it's entirely possible that there is enough spaghetti code in the game already that when someone pulls on, say, making HK-51's default equipment bound to only the HK-51 it came from, that something about all companions got yanked in the process. (Note how original companion gear will say something like "Requires Lieutenant Iresso" but HK's original gear says "Requires Companion.Companion" ... something ain't right there).

And on the other hand, I believe that all major software companies hire a hack-quality programmer (most likely the CEO's nephew or grandson) just to find pieces of code to mess with so that it keeps their talented programmers on their toes all the time. Companions have been officially hacked.

You are under the wrong assumption that only what is documented in the patch notes is the limit and extent of changes in the patch.

 

No disrespect, but you really should know better if you have played MMOs for any length of time at all.

Yes, I know this, but I would have expected that the changes are documented better internally. This seems to be the fundamental problem at Bioware -- communication. As players we often feel there is a lack of communication, and it looks like there's a lack of communication internally as well. If their internal testers had any idea that some changes had been made to companions, I have to believe they would have spotted that bug easily. It takes about 15 seconds to realize something is wrong there. But if they get the same minimal documentation of changes that we get, they are working on insufficient information and bugs like this companion bug will slip through all the time.

Yes, I know this, but I would have expected that the changes are documented better internally. This seems to be the fundamental problem at Bioware -- communication....

If you've ever worked in a development shop, you'd know that getting programmers to communicate clearly in the English language, or whatever their native tongue is, is like trying to herd cats. And any communication of changes in code will of necessity be wrapped by normal modes of communication.

Engineering programs are not known for the quality of their English/writing/speaking/communications classes. Well, except for technical writing. Which also does not count as a valid form of communication.

If you've ever worked in a development shop, you'd know that getting programmers to communicate clearly in the English language, or whatever their native tongue is, is like trying to herd cats.

Hehe... yeah... herding cats coughing up hair balls came to mind when I read your comment.

Comic relief aside... a lot of truth to what you say here.

On the one hand, it is possible that pest control at BioWare's development offices is not all that good.

 

On the other hand, it's entirely possible that there is enough spaghetti code in the game already that when someone pulls on, say, making HK-51's default equipment bound to only the HK-51 it came from, that something about all companions got yanked in the process. (Note how original companion gear will say something like "Requires Lieutenant Iresso" but HK's original gear says "Requires Companion.Companion" ... something ain't right there).

 

And on the other hand, I believe that all major software companies hire a hack-quality programmer (most likely the CEO's nephew or grandson) just to find pieces of code to mess with so that it keeps their talented programmers on their toes all the time. Companions have been officially hacked.

Because there's only bugs in software with Spaghetti code, and it could only have been caused by a hack programmer.

Everyone knows good programmers never produce bugs. Ever.

Yes, I know this, but I would have expected that the changes are documented better internally. This seems to be the fundamental problem at Bioware -- communication. As players we often feel there is a lack of communication, and it looks like there's a lack of communication internally as well. If their internal testers had any idea that some changes had been made to companions, I have to believe they would have spotted that bug easily. It takes about 15 seconds to realize something is wrong there. But if they get the same minimal documentation of changes that we get, they are working on insufficient information and bugs like this companion bug will slip through all the time.

Try communicating minor things with several hundred people within a company, it's not the easiest of tasks. Even with 30 people on a same team working on just programming for example, it's still quite the undertaking.

And sometimes changed may even be unintentional, maybe someone was just seeking to enhance the level of documentation on the companion code. Increasing the level of commenting to make it clear for others. However, e.g. accidently commented out a line which was not supposed to be commented out.

That would not even make it into any internal list of changes either, as it's not supposed to be a change.

Because there's only bugs in software with Spaghetti code, and it could only have been caused by a hack programmer.

 

Everyone knows good programmers never produce bugs. Ever.

Leaving only one conclusion to be drawn, good programmers do not exist.

We are quick to blame testing when a bug comes out, but if the testers are looking at the same patch notes as us, they really had no reason at all to test companion functionality.

That is not how QA works. QA works through process. It is doubly important with QA on software/coding that you test the direct changes or modifications being made and then go back through a set of standard tests to make sure nothing you are doing is having an unintended consequence to major aspects of the program, system or data community.

QA can be down right miserable because you end up testing the same 50+ standard things in addition to the direct changes each time a patch, change or modification is made but you do this to prevent exactly the kind of stuff that Bioware seems to consistently have happen.

You see in a real wold coding/software position you get fired when code you release breaks stuff for 24 hours. I do code work in manufacturing of food and if code we release were to put down even one line for 60 minutes we could lose 1000s of dollars per minute, so we don't get to make mistakes.

Our QA team is entirely separate and if they pass something they do so knowing if something breaks they are just as much dead and ready to get a pink slip as those of us coding the changes.

It is very clear the QA for SWTOR is either almost non-existent or severely lacking in process and oversight.

None of these people would have a job in a real world coding scenario. Games companies (and it appears their customers) seem to be very accepting of what most companies would find intolerable.

I would love to have a few of their QA in one of our Red meetings which are held after a bug or problem is introduced into our production environment. I've watched more than a few people be escorted out of the building by security with their box of trinkets in tow.

I suspect this goes on in gaming because people just accept it.

I also suspect if this bug had knocked the game off line for 24 hours none of you would be so supportive. The problem is, neither situation is acceptable.

How do bugs happen?

Well, when mummy bug and daddy bug "get together" the make baby bugs....

And thus the number of bugs grows.

On the one hand, it is possible that pest control at BioWare's development offices is not all that good.

 

On the other hand, it's entirely possible that there is enough spaghetti code in the game already that when someone pulls on, say, making HK-51's default equipment bound to only the HK-51 it came from, that something about all companions got yanked in the process. (Note how original companion gear will say something like "Requires Lieutenant Iresso" but HK's original gear says "Requires Companion.Companion" ... something ain't right there).

 

And on the other hand, I believe that all major software companies hire a hack-quality programmer (most likely the CEO's nephew or grandson) just to find pieces of code to mess with so that it keeps their talented programmers on their toes all the time. Companions have been officially hacked.

Common problem in coding:

A new command ends the class or procedure prematurely, then invalidating a large portion of the code. It happens all the time in software development.

You are under the wrong assumption that only what is documented in the patch notes is the limit and extent of changes in the patch.

 

No disrespect, but you really should know better if you have played MMOs for any length of time at all.

I hope that the dev's read your work flow you wrote up for them in that companion thread yesterday and make that SOP.

You have to realize that the fixes listed in the patch release notes are only a list of highlights and major changes.

They aren't going to list every single change they made because, for the most part, you simply won't even understand what they're talking about, and neither you nor they gain anything by even trying to communicate that. In a perfect world, you'd simply acknowledge that you don't know what they're talking about, but accept it as evidence that they know what they're doing and that work is getting done. In the real world, if you communicate things like that, the "experts" here (who have never coded a single line in their lives) will start nitpicking the statement, and simultaneously claiming that it changed nothing and is the cause of some new bug they just noticed.

Example: Yesterday, I fixed a bug that caused array index failures due to incorrect type assumptions during array comparison. Should I really put that in a release notice? Who gains value from that? Or should I just say: "...and also various bugfixes."?

So, like most software services, small-scale technical fixes are deployed silently. Now, it's been proven thousands of times over the history of software design that even small scale changes can produce significant bugs. In fact, I'd say that small scale changes have a greater chance of producing bugs, specifically because they are small scale and people don't always think of the full ramifications of the change.

I have no doubt that is what happened here. The companion previews were screwed up. Clearly, someone is looking through code dealing with companion equipment. They might have fixed display in a way that would not immediately suggest that stats would be affected.

Remember: Coding large applications is very, very complex. It is complex in a way that makes car engines seem simple. It is so complex that developers have to create software constructs to help them with the complexity. Almost always, that is a huge help. Sometimes, it hides potential problems until its too late.

And yes, someone in QA should have caught this. My conclusion is that QA is actually being done by human beings and not superheroes or the godlike beings inhabiting this forum, who never, ever make mistakes.

You have to realize that the fixes listed in the patch release notes are only a list of highlights and major changes.

 

They aren't going to list every single change they made because, for the most part, you simply won't even understand what they're talking about, and neither you nor they gain anything by even trying to communicate that. In a perfect world, you'd simply acknowledge that you don't know what they're talking about, but accept it as evidence that they know what they're doing and that work is getting done. In the real world, if you communicate things like that, the "experts" here (who have never coded a single line in their lives) will start nitpicking the statement, and simultaneously claiming that it changed nothing and is the cause of some new bug they just noticed.

 

Example: Yesterday, I fixed a bug that caused array index failures due to incorrect type assumptions during array comparison. Should I really put that in a release notice? Who gains value from that? Or should I just say: "...and also various bugfixes."?

 

So, like most software services, small-scale technical fixes are deployed silently. Now, it's been proven thousands of times over the history of software design that even small scale changes can produce significant bugs. In fact, I'd say that small scale changes have a greater chance of producing bugs, specifically because they are small scale and people don't always think of the full ramifications of the change.

 

I have no doubt that is what happened here. The companion previews were screwed up. Clearly, someone is looking through code dealing with companion equipment. They might have fixed display in a way that would not immediately suggest that stats would be affected.

 

Remember: Coding large applications is very, very complex. It is complex in a way that makes car engines seem simple. It is so complex that developers have to create software constructs to help them with the complexity. Almost always, that is a huge help. Sometimes, it hides potential problems until its too late.

 

And yes, someone in QA should have caught this. My conclusion is that QA is actually being done by human beings and not superheroes or the godlike beings inhabiting this forum, who never, ever make mistakes.

Most intelligent and coherant post in the entire thread.

You have to realize that the fixes listed in the patch release notes are only a list of highlights and major changes.

 

They aren't going to list every single change they made because, for the most part, you simply won't even understand what they're talking about, and neither you nor they gain anything by even trying to communicate that. In a perfect world, you'd simply acknowledge that you don't know what they're talking about, but accept it as evidence that they know what they're doing and that work is getting done. In the real world, if you communicate things like that, the "experts" here (who have never coded a single line in their lives) will start nitpicking the statement, and simultaneously claiming that it changed nothing and is the cause of some new bug they just noticed.

 

Example: Yesterday, I fixed a bug that caused array index failures due to incorrect type assumptions during array comparison. Should I really put that in a release notice? Who gains value from that? Or should I just say: "...and also various bugfixes."?

 

So, like most software services, small-scale technical fixes are deployed silently. Now, it's been proven thousands of times over the history of software design that even small scale changes can produce significant bugs. In fact, I'd say that small scale changes have a greater chance of producing bugs, specifically because they are small scale and people don't always think of the full ramifications of the change.

 

I have no doubt that is what happened here. The companion previews were screwed up. Clearly, someone is looking through code dealing with companion equipment. They might have fixed display in a way that would not immediately suggest that stats would be affected.

 

Remember: Coding large applications is very, very complex. It is complex in a way that makes car engines seem simple. It is so complex that developers have to create software constructs to help them with the complexity. Almost always, that is a huge help. Sometimes, it hides potential problems until its too late.

 

And yes, someone in QA should have caught this. My conclusion is that QA is actually being done by human beings and not superheroes or the godlike beings inhabiting this forum, who never, ever make mistakes.

Nicely written.

Oddly, I could not reproduce this bug at all. From reading the forums I thought this was some universal thing. I was solo, in a group of three, then a group of four, then of two and in no case could I reproduce the behavior. I even tried to deliberately induce it to check that the fix worked, but I couldn’t create the error. While it shouldn’t have happened, it may be a case that it’s not a universal bug. YMMV.

You have to realize that the fixes listed in the patch release notes are only a list of highlights and major changes.

 

They aren't going to list every single change they made because, for the most part, you simply won't even understand what they're talking about, and neither you nor they gain anything by even trying to communicate that. In a perfect world, you'd simply acknowledge that you don't know what they're talking about, but accept it as evidence that they know what they're doing and that work is getting done. In the real world, if you communicate things like that, the "experts" here (who have never coded a single line in their lives) will start nitpicking the statement, and simultaneously claiming that it changed nothing and is the cause of some new bug they just noticed.

 

Example: Yesterday, I fixed a bug that caused array index failures due to incorrect type assumptions during array comparison. Should I really put that in a release notice? Who gains value from that? Or should I just say: "...and also various bugfixes."?

 

So, like most software services, small-scale technical fixes are deployed silently. Now, it's been proven thousands of times over the history of software design that even small scale changes can produce significant bugs. In fact, I'd say that small scale changes have a greater chance of producing bugs, specifically because they are small scale and people don't always think of the full ramifications of the change.

 

I have no doubt that is what happened here. The companion previews were screwed up. Clearly, someone is looking through code dealing with companion equipment. They might have fixed display in a way that would not immediately suggest that stats would be affected.

 

Remember: Coding large applications is very, very complex. It is complex in a way that makes car engines seem simple. It is so complex that developers have to create software constructs to help them with the complexity. Almost always, that is a huge help. Sometimes, it hides potential problems until its too late.

 

And yes, someone in QA should have caught this. My conclusion is that QA is actually being done by human beings and not superheroes or the godlike beings inhabiting this forum, who never, ever make mistakes.

A brain has entered the room.

You have to realize that the fixes listed in the patch release notes are only a list of highlights and major changes.

 

They aren't going to list every single change they made because, for the most part, you simply won't even understand what they're talking about, and neither you nor they gain anything by even trying to communicate that. In a perfect world, you'd simply acknowledge that you don't know what they're talking about, but accept it as evidence that they know what they're doing and that work is getting done. In the real world, if you communicate things like that, the "experts" here (who have never coded a single line in their lives) will start nitpicking the statement, and simultaneously claiming that it changed nothing and is the cause of some new bug they just noticed.

 

Example: Yesterday, I fixed a bug that caused array index failures due to incorrect type assumptions during array comparison. Should I really put that in a release notice? Who gains value from that? Or should I just say: "...and also various bugfixes."?

 

So, like most software services, small-scale technical fixes are deployed silently. Now, it's been proven thousands of times over the history of software design that even small scale changes can produce significant bugs. In fact, I'd say that small scale changes have a greater chance of producing bugs, specifically because they are small scale and people don't always think of the full ramifications of the change.

 

I have no doubt that is what happened here. The companion previews were screwed up. Clearly, someone is looking through code dealing with companion equipment. They might have fixed display in a way that would not immediately suggest that stats would be affected.

 

Remember: Coding large applications is very, very complex. It is complex in a way that makes car engines seem simple. It is so complex that developers have to create software constructs to help them with the complexity. Almost always, that is a huge help. Sometimes, it hides potential problems until its too late.

 

And yes, someone in QA should have caught this. My conclusion is that QA is actually being done by human beings and not superheroes or the godlike beings inhabiting this forum, who never, ever make mistakes.

Baloney. There is no excuse for this level of bug to have made it through QA. No one who codes will argue that bugs happen but that is what QA is for. It is an unforgiving job that takes special skills and attributes to be thorough and be able to follow a designed process that is put in place to guarantee that few if any bugs make it through and those that do not be catastrophic in nature.

The nature of the bug that made it through is like releasing a patch for Microsoft Outlook that prevented people from accepting meeting invites. It should have been obvious to any QA process that was designed and overseen by people with even mediocre abilities and work habits.

Sorry, "its complicated" is not an answer in coding anymore. There are far too many ways to have built in error checking sub routines and compartmentalizing code so it is called only when needed so as to not let said code impact greater systems.

If this was a one off...ok, crap happens. The problem is, they do this every patch.

Their QA department and likely their coders would be out of jobs in any other industry.

They certainly wouldn't last a week in my department.