Development Cycle Archive
Thread: Vendor and Stockroom Issues Pt 2
I can help reproduce this. It's kinda complicated and difficult, so you need to pay real close attention:
you... *pause for dramatic effect*... put stuff on your vendor, and 14 days later they vanish.
Thunderheart wrote:
If anyone can show us how to duplicate and repeat any of these errors consistently, it would be very helpful.
Never claimed to be certain did I. 
I'm merely "almost certain".
And when we have the developers sending TH in to ask for repro steps when they'realready posted on every page of every thread on this topic, well, it shakes my confidence in their highly sophisticated debugging process.
Malitevv wrote:
I don't mean to be talking down my nose at you p4Samwise. Sorry if it came off that way. It was a general "you" and wasnt' meant to be directed at you personally. But you are changing the subject. The point is that nobody knows if the code is badly written. Nobody knows if it is poorly commented. And nobody knows what the exact source of the bug is, despite appearances.
I don't mean to sound rude, but all this back-and-forth about who knows more about programming and how stupid we all are for making assumptions about the code when none of us knows how it's set up is really off topic, and a distraction from the issue.
There's a bug, we need them to understand it (which based on all the responses in the various threads on it should no longer be too hard), they need to fix it, they need to compensate those who lost items, and they need to communicate with us during this process. Can we please please keep the attention in this thread on the problem, where it deserves to be?
Captn wrote:
Why don't all you Merchants top cheating the house limits by storing things in you vendors, I have to follow the rules and you don't. I can personally say I am glad these things are happening maybe if the items were up for sale instead of storage you guys would not be having this issue.
/flameon
Are you serious? Please tell me that you at least have the minimal intelligence required to read any one of the posts on the prior 4.5 pages of this thread and understand what's actually happening. As many others have pointed out, these items *were* up for sale.
It will be interesting to see how "glad" you are when your favorite weaponsmith / armorsmith / doctor / architect / BE / smuggler / DE / resource supplier / tailor (i.e., ANYONE who sells items through a vendor) has to raise their prices to compensate for their unrecovered losses - or decides to quit altogether. This situation hurts the customer as well as the crafter, and everyone should recognize that.
This has been catastrophic for so many people.. it's just unbelievable. The fact that they're letting it continue to happen - inexcusable.
Captn wrote:
Why don't all you Merchants top cheating the house limits by storing things in you vendors, I have to follow the rules and you don't. I can personally say I am glad these things are happening maybe if the items were up for sale instead of storage you guys would not be having this issue.
/flameon
NERF THE MERCHANTS!
</sarcasm>
Thunderheart wrote:
Just a heads up,there are lots of people working on this right now. Its a top priority. In addition, Im working with the Merchant Correspondent and some other regulars to chase this down.
If anyone can show us how to duplicate and repeat any of these errors consistently, it would be very helpful.
(and no, no one wiped out items to clean the database. thats just silly.
In reference to your first statement... If this is top priority then I assume you've taken the liberty of notifying all players? Or adding a message to the login screen?
In reference to your second statement... This sounds supiciously like you are trying to buy a 14 day "window" before any steps are taken...
In reference to your third statement... Are you confirming that you WILL in fact be reimbursing players?
I don't think that anyone intentionally started this to clean out the database, but it does seem that you are taking advantage of this bug to let it do just that.
Malitevv wrote:
the other point p4Samwise is that trivializing the debug process they way you are (by implying that simple competence is all it takes to avoid these kinds of issues) is an insult to software developers every where.
I'm going totake offense at that whether you are one of us or not.
Well without getting embroiled too deeply in your discussion I'd just like to mention that it may or may not be a case of 'trivializing' the debug process - or that of quality control etc. In this particular instance, from what several people have gathered and what also makes sick sense from an educated standpoint, that THIS problem is a trivial catch.
Sure, all software has bugs. Sure, it's a bit assertive to claim one knows exactly the problem when one has never worked with said code. Not exactly to know. But we have been 'using' this code for a while now.Don't underestimate the powers of deduction. It's not hard to watch an item go below 16 days remaining, thereby meaning 14 days have gone by, and watching it disappear - and then assume that the old 7 day sale timer and 7 day stockroom lifespan that happens to add up to 14 days is related. You may wish to split hairs on how people are claiming to know 'exactly' the problem. It's just a word. If it helps you feel any better substitute 'this IS the root cause' and replace with 'evidence strongly suggests this is the case'. It doesn't change the general gist of the thrust of what people are saying. You claim taking umbrage at someone trivializing the debug process - well then I suggest you don't trivialize powers of deduction by an intelligent group of people. Do you see posts like "**edit** TH j00 n00b fix this now thx bye", or several detailed posts on the circumstances leading up to this along with conclusions based on the evidence?
This particular case - IS trivial. Whose fault is it, is up in the air. Do they have their own QA, or rely on TC? Do we open fire on TC for not picking this one up? Neither here nor there. Simple, simple case of testing - whose responsibility? Not sure. But what is sure is quite obvious - this is a dead simple problem to have 'caught'. How tough it is to trace, to fix, is not under debate.
A new feature extends sales to a 30 day timer. What's the first test? Does it run for 30 days, of course.
And in the end this would have been caught the first second post 14 days elapsing.
Is it really related to stock time out? None of us can be 100% sure. But we can draw some pretty intelligent conclusions. Regardless of the root cause, it IS happening.
Personally, I'm a professional software tester and have been in this field for 7 years. Commercial - because the gaming industry has a less than stellar attitude towards it's audience from a QA perspective and generally has little to no QA (there are exceptions ... generally, not universally). When I find a bug, I do my best to narrow down and deduce where it is, and suggest possible root causes of the problem. Do I know the code form the inside? No. But most of the time I'm right and it's appreciated from the developers. I don't ever say 'this is the exact problem' - I clearly state this is my deduction based on what I see - but I don't have to know the code to make a very good stab at the problem at all.
Fact - there is a problem. Fact - people are losing inventory by the truckload. Fact - people are reporting items are missing after 14 days are passing by. Fact - the old sales timer was 7 days and stockroom timeout was 7 days. Fact - items in stockroom over 7 days get deleted. Fact - 7+7=14.
Split hairs all you want, but I'd dare say the evidence at hand here suggests pretty strongly that these are related issues. It's obvious that theuser base pays more attention to the overall system then developers do - as is mirrored in most software projects I ever worked with. Especially in large projects, developers have a very focussed knowledge on particular areas they are responsible and do not really look at the system operating as a whole. When dozens upon dozens of users come to the same conclusion (and mostly independently) based on pretty strong evidence and experience - I wouldn't spend time, as a developer, saying 'You guys have no idea really what's going on at all because you didn't write this.'
Because THAT is the real insult.
Hmmm isint that 'exploiting'
ntyatecafe wrote:
...
I don't think that anyone intentionally started this to clean out the database, but it does seem that you are taking advantage of this bug to let it do just that.
Thunderheart wrote:
If anyone can show us how to duplicate and repeat any of these errors consistently, it would be very helpful.
http://forums.station.sony.com/swg/board/message?board.id=merchant&message.id=15412
Thatthread's content was pastedsomewhere elseinto this threadat least once by the merchant correspondent.
Attn: Thunderheart
Look at the obvious. There is no need to duplicate the bug. Go directly to the function call in the player vendor code that issues a destroy item command.
This function call is being made before the new 30 day timer for item listing runs to completion.
Until you can sort out the details the first step should be to disable any function calls that issue a destruct command.
All the knowledge being gleaned from various people is just spectacular and the community should applaud itself in trying to determine what is causing the problem.
However...THE question to be answered is that what will be done to reimburse us all for ALL the items/sales lost due to no fault of our own? Thunder? Q? George?
Personally, free game time is not an option as I believe that most of us use sales to replace resources, items we need in order to craftthe wares we sell.
time to pack up and move on...
http://forums.station.sony.com/swg/board/message?board.id=Developers&message.id=14299
these are hot fixes for tomorrow... You notice how they won't even post a public message to warn the players of this serious issue, but the have the time to "fix" another bug being exploited concerning merchants. The priorities in the game are unbeleivable.