Menehune, on 22 January 2013 - 03:29 PM, said:
As far as I'm concerned, as some others have mentioned, ArenaNet have fulfilled their responsibility by 1st blocking then fixing the bug apparently as soon as they could since it was done fairly quickly.
C'mon, as a dev yourself, you know perfectly well, or should know that variable type mismatch is among the most common causes of bugs and can lurk in software for years before being "triggered". Similar to unchecked data length that can lead to buffer overflow which is a common cause of security issues. Not to mention that a lot of lazy devs, of whom hopefully none work for ArenaNet, make liberal and injudicious use of type casting which can make code a nightmare to debug. Such bugs can even be found in open source software after hundreds or even thousands of eyballs have inspected the code. Java anyone?
In that case nothing more needs to be done. No bans need be issued. But in that case, the profits of the exploit should be removed.
Variable type mismatches, sure. In numerical values maybe as being the wrong precision (unsigned char variable being assigned the value 1000) or using integers in divisions when you want decimals in the result... But consider that recipes are probably don't exist as literals in the code, they are probably in a database somewhere. Since you can't use a noninteger amount of crafting material, the field for each component count is probably specified as integer. Even if not, the structure that is read from the database probably use integers. Actually, if not, then it's so badly done that we'd probably see all kinds of bugs everywhere.
Eh, yeah, true, we do. But even more, I mean. Recipes would be the least problem.
XPhiler, on 22 January 2013 - 03:34 PM, said:
Only one problem, they didnt put the feature there without thinking or by being careless like one would do if they threw the banana peel on the street. The wanted to be nice, provide a way of getting good gear cheaply for christmas, like say storing the banana peel in your backpack until you come across a bin to dispose of it properly. Here we're talking about a good deed (a nice xmasy recipe you can craft for cheap) that unforseen by them allowed for abuse.
Now this is even better, why should the business model used have any bearing on anything? What if this had a subscription? would you be pushing for jail sentences for developers? It does matter if we paid or not for the game. It doesnt matter they were not good enough to forsee the exploit before it got out (thought that would have been nice) we know people arent perfect and they make mistake. What matters is how people act. Arenanet did their part, when they became aware of the exploit they stopped it and took corrective action. I am not sure what more can you possibly expect?
You're assuming one person handles the process of creating a recipe from top to bottom. This is defenitely not the case. Also keep in mind this was a holiday item intended to be cheaper on purpose. Like I said you're underestimating the complexities a tester or even the content developer had to go through. The item itself was purposefully cheap to make. I mean it was many times easier to get a snowflake then an actual gem stone. snowflakes had obviously no historical price as they were new. Also the jewel being salvaged in itself was not the problem either. The problem was that such items when they were level 75+ and salvage have a 90% chance of dropping an ecto that was never part of the recipe. Thus looking at the ingredents that made up the item and how much of those ingredients you can get back if you salvage them was not enough to find the problem since the problem was external to that. And lets not forget that you're doing all of this under the pressure of a pretty hard deadline.
Once again macros arent a problem, artifically sticking a key to keep repeating while you're away from the keyboard has nothing to do with macros. And its not just nexon, thats just the first thing I came across with a quick search. I've seen multiple companies claim they'd consider that the same as botting and thats the right way to view it in my opinion.
You love playing with words dont you. But once again no one was banned for coming across the bug (if you can even call it that) people were banned for finding an exploit and exploited it. You said multiple times these exploiters should not have been blamed and instead Anet should be to blame. So you dont want to blame arenanet for introducing the bug, you want to blame arenanet for the exploit. You're free to blame whoever you want that doesnt mean you're right and most certainly doesnt mean that just cause you decided to shift the blame from the party thats really guilty (exploiters) that party should walk away free like nothing happened.
Sure if the whole game consisted of this one recipe you'd be right but guess what there is a ton more to it. Unless the company you work for has millions of testers, you know well enough that no tester is dedicated to test one single thing and that one single thing alone. There are thousands of test cases that need to be addressed in a limited span of time. Just cause testing a single recipe doesnt involve test on multiple architectures it doesnt mean that testing department does have to infact do tests on multiple architectures to test say jumping puzzles and other new instances that could have an effect on the underlying architecture the client runs on.
Once again this recipe was not the only thing that required testing and as Menehune correctly said before it most like had a low priority on the testing queue as well because like you correctly said how much damage can a simple recipe do? As long as it crafts correctly using different material ordering to be safe it works as intended, there done test the next recipe since there are another 273 to go and thats just covering recipes, then we have to test the new maps, the open world presents, the magic snow, the jumping puzzle, the guitar hereo chime bell thing, the toyapocalipse, the toy dungeon, the golem airship entrace in each of the 5 cities, the new mobs, the setup for entering the dungeons, the snowball fight etc... and lets not forget we need to test many of these using multiple combination, we to test the snowball fight using 5 races / 8 professions / 3 roles each can choose when pariticipating in the snowball fight and each of these we have to do on multiple architectures, using multiple languages. And when all you finish all that you need to regression test all the client again because you never know, one of those changes might have caused a sideeffect somewhere else.
yeah .... no its definitely not just get this one recipe and test it against every possible conseavable issue, there is much much more work QA has to do then that.
Look at what you made the mods do. Don't * around, quote the entire post instead.
Yes they did put in this carelessly, that's the entire point here. It was careless. If they had taken care, they would not have caused all these exploits to happen.
The business model is important because ANet is a company and companies can be expected to act in the way that generates the maximum profit. If it would be profitable to them to hire more QA staff, then they would do so - and that would lead to a better game for us.
How do you know how many people are involved in creating a recipe? It's likely to be not much more than one. In either case, the problem was that when creating the item, the recipe for crafting it was apparently created without caring about the results of salvage. 90% chance for ecto? Come on lol. Obviously when creating a crafted item the recipe and the salvage ratios should be developed side by side.
Why do you think that holding down a key is a bot? What if I sit at my desk holding down the key using just my finger, is that a bot too?
What if I put that weight on the key while I still sit there? Does the weight become a bot when I stop watching it? I better watch out, that weight must be some kinda transformer robot!
For me as a player, ANet is guilty of the exploit. Because there will always be unsavory characters, enabling them to exploit
will mean that exploits happen. Merely fixing the bug is not enough: ANet must bear
full responsibility for it, and that means
not using the banhammer.
Well duh of course a jumping puzzle would need to be tested in a different manner than recipes would. That is because jumping puzzles and recipes are completely different types of content. When we are discussing someone who got banned for exploiting a jumping puzzle we can get back to that line of discussion.
Apparently a recipe can do a lot more damage than an
INVISIBLE WALL IN THE MIDDLE OF A WvW MAP especially when people use that wall to become invincible. And yet people get banned for the recipe while no one gives a shit about the WvW map. There's still a WvW bug that lets you vibrate through walls etc. but people rarely get banned for it.
But durr hurr the economy, who cares about WvW. Well in that case the QA should match that.
And it doesn't.
Matterdor, on 22 January 2013 - 03:47 PM, said:
From a development standpoint what you are saying below does sound like "random things".
But it goes directly to the number of testers that they require and how they spread those testers around. Any business is in it to make money. Testers costs money. It all comes down to the complexity of the system. To make matters worse, all complex systems have a large amount of shared code so changing any of that shared code will effect both the client and the server.
This is the part that doesn't make sense. Recipes, skills, etc will not use scripts at all as that would be highly inefficient. These would be simple database values with various random components included (materials, visual effects, outputs, etc). Scripting, which has a much higher processing component, would be used for things like boss actions, dynamic events and the flow of these events. It is also possible for a recipe to trigger a client disconnect or graphical problem because it may create a sequence of events on the client that have not occurred before.
Their motive will always be to create as bug free code as possible within the constraints of the budget. They are not going to have 3 testers sitting waiting to just test how recipes can be abused. That would be an inefficient use of resources and would only make the game (or expansions) more expensive and give us less bang for buck. It's about balancing the number of bugs against the cost and release time for the software. Testing works on diminishing returns, you find fewer and fewer bugs as you test more and more. A/Net have to balance the cost, release timeframe and quality. It doesn't help to have perfect software if the Wintersday event is 3 weeks late, nor does it make any sense to release software if they are making a loss.
Well now we're getting somewhere. Yes it goes to the number of testers they use. And also how much time they spend on dry running/code inspection/etc. As it is now, they do as little of that as they can get away with. When a bug appears, they are comfortable with not catching it because they can just ship the bug and then ban anyone who exploits it. As long as the playerbase accepts this, there will not be a profit motive in finding bugs before they ship. If we didn't accept it though, the shittiness of their software would cost more money than the extra testers would.
Yes, recipes would probably be database values, not scripts. What i meant was that they are not part of the actual engine code, instead being on the same level as scripts development-wise, handled by game designers, not programmers.
I don't really see how the recipe could create a disconnect or graphical problem. The item being created, yes, possibly.
Of course they should not, and don't, have three testers sitting around checking for recipe abusing possibilities. That this item would be open to abuse by repeated crafting and salvage would be self evident without using a tester for anyone who saw the full data for the item. 90% chance for ecto when salvaged?, but no ecto used for crafting? The salvage ratios are probably also database values, but when creating a brand new item there should be a review (it could be as short as a matter of seconds) for creation and salvage. I don't mean running it in game, I mean looking at the values that you enter into the database.
That is obviously not done that way, but doing it would be the requisite QA procedure.
XPhiler, on 22 January 2013 - 03:50 PM, said:
How did you expect them to take responsability exactly? What more should they have done to satisfy you exactly?
Its always about how far you want to take your testing. A recipe is unlikely to effect the client but can none the less. There are always insidious bugs that can be hard to forsee. How about a situation where you introduce a number new ingredients and due to human error 2 ingredients are given the same ID. Crafting works fine because the ID exist but when it comes to salvaging and the client tried to retrieve the ingredient associated with that ID returns 2 ingredients even though its expecting 1. That causes an exception but no problem the client handles that and generates a report for it but we got an issue the UI didnt get the ingredient it was excepting and retries the query causing the exception again and gets stuck in this loop. That results in a memory leak as well as the client hanging. The bug would never have been caught because prior to this ficticious update there was never a case where 2 ingredients shared the same id so part of the client that was thought as robust turns out is not so robust after all.
A recipe can also have bugs based on language as well. What if a recipe is called something that when translated involves unicode characters and the client didnt support that. You send it for translation and the translator that is most likely not even part of your company might have no clue he is support to restrict himself to the basic ascii set.
So I would suggest one should never understimate what can go wrong.
Uh... If the same ID is given to two ingredients then a multitude of possibilities exist. If the code is robust enough it would be literally impossible, as the code that reads the tables of what ingredient has what ID, name, icon and so on would detect that two have the same ID. Also since they have probably existed in a database somewhere and the ID probably was used as primary key it would again not be possible.
But let's be XPhiler and pretend that some completely improbable situation matters to this discussion. The same ID for two different ingredients. Possibility 1 is that the data structure used for these is some sort of map which means that when the second ingredient is read it overwrites the first. Ingredient number 1 would not exist in the system. I guess this would be detected quickly. Possibility two, some inefficient piece of shit way is used to keep track of ingredients, so that two with the same ID can co-exist. In this case, whenever you need to find an ingredient, you need to scan for it in your data structure... Probably the first one you find will be returned.
Bet let's be XPhiler and pretend that these events, which are improbable in themselves but probable under our assumptions, don't actually happen. Instead the single ingredient variable somehow becomes an array of variables (violating type checking in compile time, but this is XPhiler world where that doesn't matter), and the presence of an array for some reason causes an error report. For some reason this, which is probably the most well-tested component of the UI, stops working and instead happens to query for an ingredient, and since we're doing the whole infinitely-impossible scenario, the error report box always queries for the ingrdient with the duplicated ID.
This bug will "never" be caught because no one ever saw the error report dialog box that queries for ingredients.
THIS IS GW2, you see that damn box at least once per play session.
Also do you have any idea of how string tables work?
Gli, on 22 January 2013 - 04:15 PM, said:
I guess I forgot about the option to irrationally expect miracles and post on forums about it until you're blue in the face.
I don't expect miracles. I expect companies to take responsibiltiy for their own products.
Oh wait, yes, ok I see what you mean. Why would they do that when they have a playerbase that not only bends over but also literally applies the lube themselves?
2
This topic is locked
it doesn't matter much who exploited and who didn't, what matters is the inconvenience caused by the exploit. That will happen at any time when an exploit is possible, since the supply of unsavory players can be approximated by infinity.
