Merchant Archive
Thread: ATTN: Chataka RE Vendor appetite
That is pretty much the theory since Monday and it has been passed along to the dev team. I can only assume that finding that code and dealing with it is a lot more difficult than it seems to you or I from where we sit.
It follows that what keeps items from being deleted pre publish was something that happens to the item when you put it back on sale from the stockroom. Since now you aren't doing that after 7 days it gets to 14 and gets deleted. That means that retiring things to your stock room and putting them back on sale MIGHT work.. but I'm not risking it myself. If someone wants to test this by putting an item nearing 14 days into the stock room and rotating it out and having it survive the 14 day window that would be great and would be a better alternative to pulling it out of the vendor. The other question about that is what timer does it get put on from the stockroom? 7 or 30? I've heard both. My own experience was 30 if it had been on sale previously and 7 if it had not (bought from an offer)
I believe there is an extremely simple solution to this coding error.
In the player vendor code there is going to be at least 1 line of code where a destroy item command is being issued. The items in the player vendors are not being lost, they are being destroyed by a call to destruct item within the vendor code. The solution is look at that line of code first. If it can't be fixed quickly, then the next solution is to remove or block any and all lines of code that issue a destroy item command within the player vendor code, until it can be coded right.
The code is working correctly and that's the problem. Everything its being told to do its doing. The oversight was to change one timer and not changing the one which monitors inactive items and issues the destroy item command. They have to check all lines of code where a destroy item command can be issued in the player vendor code. Now, I am sure the player vendor code is l;arge enough to cause anyone headaches when reading through all of it, but look at the ramifications of this coding oversight.
It has become the single most bug responsible for the largest player item loss to date in the history of online gaming. It requires immediate attention and a change in thought on the current CSR policy treating player item loss.
What it shows is that the development team has alot on their plate right now. It also shows they, like most programmers in the industry are human, overworked, and underpaid. Its the only way to describe how something so basic could have been overlooked. They instituted a change in their code without following how it affected the rest of the code in that function. The result was you suddenly had one timer told to destroy items which was now less than the timer used for listing items for sale. That is why items placed for sale in player vendors are being destroyed before the timer for listing items expires.
It is understandable that when coders are overworked they're going to make mistakes, some of them incredibly absurd, but its human nature to make mistakes. This is acceptable. The current CSR policy treating item loss due to bad code simply put is not. Somewhere within the myriad lines of code that this game involves will be log files. One of those logs will be monitoring events that take place when destruct code is called by a funtion somewhere in the game code. The compiler in the host machine is sent a command to destroy an item. That event gets flagged and then logged. Right now that logfile will be enormous, but its going to cover all the items destroyed by the player vendor code among others.
The only way to return items inadvertantly destroyed by the player vendor code is for someone to check that log file. Imagine the size of it by now? The sudden growth in this log file should have been a red flag to someone on the Dev Team. Once again you draw the conclusion that these poor guys have way too much on their plate to handle responsibly. That or they're just poor at what they do. Judging by the graphics code alone in this game, you recognize the latter is false. They are good at what they do. Their priorities lie elsewhere currently. Which will be a monumental mistake on their part, if they choose to ignore this coding flaw and let it continue further.
Bugs like this do not take long to fix, but they require someone's attention. The question is: Whose working on it now?
BignoseJoe wrote:
The only way to return items inadvertantly destroyed by the player vendor code is for someone to check that log file. Imagine the size of it by now? The sudden growth in this log file should have been a red flag to someone on the Dev Team. Once again you draw the conclusion that these poor guys have way too much on their plate to handle responsibly. That or they're just poor at what they do. Judging by the graphics code alone in this game, you recognize the latter is false. They are good at what they do. Their priorities lie elsewhere currently. Which will be a monumental mistake on their part, if they choose to ignore this coding flaw and let it continue further.
That's a good point.. but somehow I doubt anyone monitors these things. Or they would have seen the problem and reacted to it a lot faster.
If I had to guess, I'd say the graphics code and database code is being handled by two totally different sets of programmers. I think it's VERY obvious where the programming "talent" resides. The database programming behind this game is just inexcusably bad (think back to when they renamed several bazaars, totally hosing anyone doing business in those locations).
Ri'a Ocolo, Master Tailor of Keren/Naboo/Kettemoor
The losses are staggering. I am in shock. No way to know what was lost, but vendors that had hundreds of items in them are now empty. Hundreds of schematics stored are gone. Millions of resources lost. All my contruction parts are gone. Special non replacable items gone forever.
I just can't even bring myself to log on.
Swiggy
Without knowing anything about the code you used for coding your vendors I will tell you why its happening and where to look.
Problem: The inactive destroy item timer was not changed when vendors were recoded to list items in personal vendors from 7 days to 30 days.
What occurs now, is the old timer which monitored items that went 7 days and into the storage room, then a subsequent 7 days in the stockroom before being destroyed is still in place and operating on a 14 day inactive destroy item command within the vendor code. It was left in place and was not changed when vendors were changed to list items for 30 days.
In answer to your questions on the previous thread.
Any and all items placed in my 3 vendors on Kauri after the major patch have now vanished. Items which reached the 7 day expiration that went into the vendor pre-patch went to the stockroom. Some were put up for sale from my inventory. Some went from the stockroom back to up for sale. In all cases, any item remaining up for sale vanished after 14 days(or the length of the old timer, whatever the timer length was set to prior to the destroy item command taking place within the vendor code).
This bug should be obvious and you need look no further in the vendor code than to check all lines of code that issue a destroy item command. If they are running on a timer, which I would guess some or all of them are, the code needs to be changed to reflect the new length of time items were intended to be up for sale before being moved to the stockroom.
If there are logs for these destroy item commands, then it would be nice if someone had the time to look them over. The amount of items destroyed throughout all the servers due to this coding oversight will be significant and staggering.
In closing, you have destroy item commands listed in the merchant vendor code. All those lines need to be checked ASAP, if it hasn't been done so already. That's where the problem lies.
You know, gathering the bits and pieces of information from Blair's post on today's hot fix and Saturday's planned patch to restore deleted items, I'm guessing the restoration of deleted items caused the bigger headache of the two.
They understimated the bug's effect and it might have been someone taking a look at the size of the log on item deletions that woke them up to its seriousness. The log was in place and coded well enough that it allowed someone on the dev team to write a perl script that will flag any item that was given a function call to destruct item stemming from the secondary timer that was inside the vendor code. The script was probably more of a task than the actual bug fix.
On the bug fix you had 2 timers called for in the vendor code. A primary timer for how long an item was to list for. When this timer expired the function call was given to move the item to the stockroom. The secondary timer was a memory saving feature to enable the code to remove unattended items left in the stockroom. When this secondary timer expired the function was given to destroy the item. It was the placement of the two timers and running them concurrently that caused the bug because the secondary timer ran with a shorter clock than the primary timer with the 30 day listing. The secondary timer expired first in this case and caused the destruction of the item before the primary clock was able to count to 0 and make the move item function call, which was designed to move items to the stockroom.
Now the code will call for both timers, but they will no longer run concurrently. The primary timer will apply to listed items only and the secondary timer will apply to stockroom items only. The primary timer will be a 30 day clock whether the item comes from player inventory or the stockroom. The secondary timer will be a 7 day clock. This should eliminate the inadvertant loss of listed items, but will continue to act on items left unattended in a vendor stockroom, as initially intended.
The perl script will need to something similar to this. The perl script will need to flag items from within the destruct log that were given a function call to destruct item from this secondary timer from the vendor code. It will then need to trace the route back to the player vendor and identify the item using the item ID. Identifying all these items will take along time and the reason were going to see items return on tommorow's maintenance shutdown rather than today's is because of how long it will take to run this type of perl script through such a large log file.
But the information gathered by running this perl script will allow them to run a second script which will clone all the identified items by using a function call to create item followed by a function call to move item back to the player vendor. There's probably also some code that may or may not force it to move to the sale window with a 30 day listing applied to it. Let's hope they make the added effort to do this, in the event an absentee merchant is unable to return in time to restock before the secondary timer expires.
All of this is conjecture on my part and is a best guess based on my limited experience as an amatuer coder on one of the old LPC MUDs. I do not profess to be an expert coder or program debug guy. I do this solely in the hope that it might be close enough to the truth to shed a bit more light on what might be taking place in respect to the vendor bug hotfix to those still in the dark on what's taking place with their vendors and items lost from the bug.