Development Cycle Archive
Thread: Vendor and Stockroom Issues Pt 2
Uhmm...I hear all this talk about it being in the c/c++ code. I do enough database programing that I know that may not in fact be the case. Its more likely to be a 'trigger' even in the database. Thats where I would have put it, a lot more accurate and timely. NOT something in the code. But I bet they're looking at all the code going "BUT ITS NOT HERE WHERE IS IT". LOL. and all of you are saying "hey idiots look at the CODE". Now wouldn't that be classic.
And for those saying "this is simple" uhmmm..no its not-they're obviously working on it and have not come up with a solution. I suspect this is one of those "simple" things that are hard.
PS if I am right about it being in the DB let me know if you have any job openings TH. LOL
greywar777 wrote:
Uhmm...I hear all this talk about it being in the c/c++ code. I do enough database programing that I know that may not in fact be the case. Its more likely to be a 'trigger' even in the database. Thats where I would have put it, a lot more accurate and timely. NOT something in the code. But I bet they're looking at all the code going "BUT ITS NOT HERE WHERE IS IT". LOL. and all of you are saying "hey idiots look at the CODE". Now wouldn't that be classic.
And for those saying "this is simple" uhmmm..no its not-they're obviously working on it and have not come up with a solution. I suspect this is one of those "simple" things that are hard.
PS if I am right about it being in the DB let me know if you have any job openings TH. LOL
Whether it is in the C++ or in the DB code, it still would appear that there are two timers in either case.
The C++ code and the DB code is so tightly coupled in this instance that from a high level point of view, they can be almost to be part of the same code module - even if they are distributed between the Oracle DB and the server side C++code.
If you are right, that there is a DB timer that has been set to 14 days when the item is placed in the DB, this triggershould have been changed. And I bet the time to destroy is being set from the Oracle interface code that is embedded in the server side code.
Eutock wrote:
It's not necessarily cut and dry. A function call may exist to delete vendor items, but that function may actually be a method inside an object, or the function (method) could be fired off by an event. Further, the function to delete a vendor item may be tied to other activities, such as deleting an itemintentionally or removing the item from the vendor onces it's sold. If it's an event problem, tracking down the exact firing of the event could be difficult. And of course, we hope that sufficient testing is done on any modifications to the vendor logic so that other, possibly worse (yes, worse) bugs are not introduced.
Eutock wrote:
It's not necessarily cut and dry. A function call may exist to delete vendor items, but that function may actually be a method inside an object, or the function (method) could be fired off by an event. Further, the function to delete a vendor item may be tied to other activities, such as deleting an itemintentionally or removing the item from the vendor onces it's sold. If it's an event problem, tracking down the exact firing of the event could be difficult. And of course, we hope that sufficient testing is done on any modifications to the vendor logic so that other, possibly worse (yes, worse) bugs are not introduced.
_______________________________________________________________________________________
I think the point was not how it was coded nor what needs to be done to correct the bug, in actuality. The point I made was somewhere in the vendor code are the line/s of code responsible for starting a countdown that monitors the idle activity in vendor items. When that clock counts down completely its final function is to issue a dest item command which deletes that item. This is where the debug needs to begin. The first step in the process needed to be disabling or removing this part of the vendor code altogether. This particular part of the code has an obvious task. It was designed to remove items left unattended in vendors for so long, as a memory saving feature. The problem is that this task now is performed before the feature it complements (the timer for how long items are to reamin up for sale) runs to completion. I think we are all in agreement on how these two functions should work and they should complement each other rather than have the second task over ride the first. An educated guess would be both timers now start when an item is put up for sale from a player inventory. The item timer monitoring when to delete the item now inadvertantly has a shorter clock and prevents the first timer from completing its task. This is the main problem here and why the code for the 2nd timer needed to be disabled prior to the actual debugging.
You and p4Samwise both make good points in your rsponses. It may or may not be a simple task to perform. Getting the vendor code right, but disabling the problem first buys time and puts in place one form of damage control.
You also have to ask why the 2nd timer wouldn't go into effect once an item reaches the stockroom rather than when it is placed up for sale.
_____________________________________________________________________________________
Eutock also wrote:
I was not sugesting that programming is "inherently extremely difficult", but that the process of debugging is not always as trivial an activity as it seems on the surface. Throw in QA and acceptance testing, and finally approvals, and the process draws out even further (and could also explain why a potential fix is not in tomorrow's patch).
The reference to "method inside an object" was a light suggestion to potential challenges in debugging objects.
______________________________________________________________________________________
Good point. However judging from what took place as a result to the changes in vendor code one must wonder about what approvals took place on this, if any.
gee i am not a programmer but have worked with MANY databases....hearing you allargue back and forthjust shows why it takes so long for any IT people to get anything done....
it just really seems to me that the most obvious thing to do is go to the or where ever in the program states the vendor listing parameters....where ever it says = 7, CHANGE it to 100....
it couldnt possibly hurt and could stop more deletions while they do proper debugging...i mean it couldnt really cause any worse problems
my experience in life has lead me to believe that computer nerds always try the most complicated and conveluted apprach to any problem
Naufragus wrote:
it just really seems to me that the most obvious thing to do is go to the or where ever in the program states the vendor listing parameters....where ever it says = 7, CHANGE it to 100....
it couldnt possibly hurt and could stop more deletions while they do proper debugging...i mean it couldnt really cause any worse problems
Now there's a debugging procedure for ya.
sed -e "s/7/100/" *.*
<sarcasm level=100>
No, I can't see how that could possibly cause any problems.
</sarcasm>
sam -- i am simply saying that where it sets the deletion limit to 7 days, just change them to a higher value...it just seems likely to me that would stopfurther deletions while they piddle around doing what ever it is that they do....
just makes sense to me...if the program is deleting items in 7 days simply change the expression...its just plugging another number in
Well, had someone changed a value from 14 to 37 when the 7 went to 30 for item listing in vendors there might not have been a problem. Sam may have a reasonable explanation for why things went awry. Lack of proper documentation when someone else works on code designed by another programmer.
My opinion is you've got a Dev team that went through a long hard push to get the game live. Since its gone live they've had to work even harder to meet deadlines for adding content and new features. The attention required to bug fixes on top of everything else has made for too many tasks trying to be done too soon by the team. New code gets piled on top of old code and not enough time is available to give the attention required to ensure the new code is going to work properly with the old code.
If you step back from the annoying bugs and take a look at the larger picture you have to be impressed with much of the code here. Alot more is working right than wrong and for the coder it can be an extremely thankless and unrewarding task. I'll say it right here. Thanks guys for all you've done so far.
Alot of what I read here is not a thread full of whines and rants as much as its an attempt by players to submit feedback on what they view as wrong with the game. Whether the developers choose to use any of this to their advantage is up to them. In some small way, we are doing our part as the developer's test pilots here. We play the game. We make mental notes on what we feel might be going wrong inside the game. Then we submit our observations as feedback.
Perhaps some of the dev team are due for vacations and could use some time away from their daily grind to recharge their batteries and come back with a fresh outlook and somewhat clearer mind when they return to work. Vacations are important to a hard working staff. Distancing yourself from the job for brief periods of time are important to reduce job stress. Coding is a stresful occupation when there are deadlines to meet. Burnout is going to occur. When you spot some of the bugs that seem to occur after the major patches you have to wonder how much of the above might be responsible for some of what we see on this subject.