Development Cycle Archive
Thread: Vendor and Stockroom Issues Pt 2
Nurani_ENT wrote:
i'm pretty sure when most of us are suffering the same issue and come up with the same numbers that we know what the problem is...
untested code and devs that have "more important" things to do...
I can't argue with that, of course you all know what the endresult of the problem is. What I am saying is that there is no way any of us could know what is causing it to happen in the first place.
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
Um...I am not storing items in my vendors. I am trying to sell YOU and the rest of the people on my server medicines and resources. These things are getting lost.
Maybe if you started losing your clothing, weapons, armor and pets out of your datapad you might sing a different tune.
- Ki
speardancer wrote: Just an observation here, Old system: 7 days on vendor, 7 days in stockroom, item deletes, no e-mail sent. New system (with bug) 14 days, item disapears, no error or email sent.... 14 = 7 + 7 Coincidence? Tell someone to look at the item cleanup code....
*puts finger on nose* Precisely what I or anyone else with even a little programming background would surmise, dancer.
Now, after you tell someone to look at that code, find the person who wrote the code in the first place, and put a 14 day "delete this item"timer on newly listed items rather than having the7 day "move from vendor to stockroom"timer kick off a new 7 day "delete from stockroom" timer. Ask them why they did that. Then hit them with a trout.
Or, if the architecture is somehow unable to support that (which would be another problem worth looking at), use a simple trick like preprocessor definitions:
#define SWG_MERCHANT_SALE_TIMER 7
#define SWG_STOCKROOM_CLEAR_TIMER SWG_MERCHANT_SALE_TIMER + 7
And then use those #defined constants in the rest of your code. The end goal is that when at some later point you want to change the merchant sale length from 7 to 30, you canchange that ONE NUMBER in the code from 7 to 30, and you don't break anything else. It's like magic!
It's beginning to become clear to me why the devs cite so much difficulty in making what seem like they should be simple changes to the code. If something as simple as this got fouled up so badly, I shudder to think what tangles got introduced into the more complex bits.
Forget fixing professions. Take a month off to clean up all that code - and the parts you can't clean up, put copious comments in so the next person to come along and do maintenance won't have to guess at what he/she is breaking by making what look like innocuous changes. It'll be time well spent.
And in between cleaning and commenting code, come read the forums. The fact that TH posted TODAY and asked for repro steps on this EXTENSIVELY documented problem (which more than one of us has already been able to take a pretty reasonable shot at diagnosing and could probably fix in a heartbeat given access to your source) tells me that not enough time is being spent paying attention to yourcustomers/QA team out here.
p4Samwise wrote:
Forget fixing professions. Take a month off to clean up all that code - and the parts you can't clean up, put copious comments in so the next person to come along and do maintenance won't have to guess at what he/she is breaking by making what look like innocuous changes. It'll be time well spent.
Why do you assume it is unclean and uncommented? What if all the introductory level programming practices you mention are already being used and the problem is simply a typo in a single conditional expression in a data base query?
That's all it would take to cause exactly what everyone is observing. I'm not saying it is the cause, but to assume the code is badly written and poorly documented because of an issue like this is just silly.
A friend of mine quit crafting for good today. He lost millions of credits worth of items. CS's answer is they cannot refund his stuff because they have no record of it.
That's just not right.
Well someone needs to give them ideas cuz quite frankly it doesnt appear they are all that concerned about it. I mean waiting till next publish instead of hot fixing it when they find it? What message does that send? Low importance, thats what that sends.
Malitevv wrote:
Tarinth2 wrote:
This is great, players sitting aronud speculating on possible causes of the bug, doing the debugging for SOE. You won't be paid any real-life cash, you won't get compensated in the game...Maybe Thunderheart will give you an 'atta boy though.
I don't know if that reply was to me. I already said it's pointless to speculate on what might be causing the problem.
In my case, I'm just annoyed when people assume they know what the problem is and start giving advice on how to fix it. So I pointed outa viable alternativeexplanation of the problemwhich completely contradicts what the "here's how to fix it" people, are assuming. My only point being to demonstrate how silly it is to be making such assumptions in the first place.
None of us could possibly know what the real problem is.
p4Samwise wrote:
The fact that TH posted TODAY and asked for repro steps on this EXTENSIVELY documented problem (which more than one of us has already been able to take a pretty reasonable shot at diagnosing and could probably fix in a heartbeat given access to your source) tells me that not enough time is being spent paying attention to yourcustomers/QA team out here.
I agree that TH's request for that info was silly.
But all that tells me is that TH either hasn't read the thread carefully or doesn't really understand what people are saying.
It doesn't tell me that the people actually debugging the problem don't understand the issue.
p4Samwise wrote:
Malitevv, if you were to see someone at a restaurant begin gagging, turning blue, and clutching at his throat, would you say to yourself "He might be choking" and try the Heimlich maneuver? Or would you shrug, say "none of us here can really know what the problem is," suggest someone call 911, and then wait for the paramedics to arrive?
I'm I would give them the heimlich maneuver. But that rhetorical question is completely irrelevant to the issue.
In that analogy, your assumption that the code is badly written and poorly commented,is analogous to me assuming that the choking guy at the restaurant has a deformed wind pipe.
p4Samwise wrote:
Because the fact that the time from listing the item on the vendor to deletion is exactly the same points to the existence of a timer that measures out that time interval.
Maybe. It may also mean that some bandwidth optimization in the code that queries the vendor's data base sorts through the items based upon their age, starting with the youngest item first and that a debug flag which cuts off the search at items which are 14 days old was left in the code that does the query and wasn't noticed until now because before now, nothing ever was in the vendor for more than 14 days.
Malitevv wrote:
but that only works if the items actually are being deleted. What if they aren't being deleted and the problem is that they are hidden from you? Then that accomplishes nothing.
Oracle74 wrote:
Trentmare wrote:
Here's a helpful hint.. turn off auto item deletion in vendors in a hot fix right now..
/cheer
I'll answer that, since it was my suggestion.. simple really, they have nothing to lose and everything to gain. If the items are just being 'hidden' then they will continue to do so and will eventually 'reappear' .. right? But if they're being deleted and they are already telling people we can't replace anything .. then they can stop the deletions and there will be less loss.
At this point.. any kind of damage control won't hurt. They are losing all confidence of the consumers, and that is the worst possible thing they can have happen.
This loss of data with no action at all on their part and a blanket policy of deny and refuse to replace, is not the best way to operate an mmorpg.
And that's not an example of code that needs to be cleaned up or commented?
Malitevv wrote:
Maybe. It may also mean that some bandwidth optimization in the code that queries the vendor's data base sorts through the items based upon their age, starting with the youngest item first and that a debug flag which cuts off the search at items which are 14 days old was left in the code that does the query and wasn't noticed until now because before now, nothing ever was in the vendor for more than 14 days.
