Development Cycle Archive
Thread: In-Test: Merchant Vendor Changes
Martha wrote:
soooooooo...what happens to existing vendors for people without any artisan/merchant skills? I have an ex-master merchant who currently has NO artisan skills at all, but has 6 vendors - will these remain in place with me simply unable to access them, or will they go away?
My interpretation of this is that they will continue to function but you will not be able to add any items until you are under your limit.
Items would go on sale for 30 days and then expire to the stockroom.
If you don't have the skill to support the vendor, you would not be able to re-list anything.
Two weeks later, your empty vendor would be purged.
MagenShae wrote:
once upon a time, on a thread far far away......
SW:G - we're going to limit houses to hold only 25 items
SW:G community - *big uproar*
SW:G - well, ok... 75 items per lot your house takes up, up to 250
SW:G community - oh.. whew.. thats much better than 25
- Will backpacks and containers continue to count as 1 item or will they count as 1 + contents like in a house?
This is a big deal to me as a smith who usually sells armor as suits in bags. Knowing this would go a long way toward helping me decide how my shop will look after the revamp. Any answer would be appreciated. 
Moepple wrote:
PlayeroftheDay wrote:
Moepple wrote:
TH, thats not nice, thats a compromise I didnt expect, and you turned mysuggestion into something thats on the bottom end of what people might expect.
However, maybe you find the time to explain ab bit why there has to be a limit and why it has to be so low?
This is still below what a lot of us Merchant wants, and to accept it, it would be good to know why. In my Eyes, its not a balance Issue, because the number of available Vendors will go down due to the removal of exploited vendors we need high limits for those legal vendors. Otherwise noone plays Merchant and the economy is as broken in the future as it is now.
And btw, maybe you could peek into my post in the merchant-forum :-)
Shubashi/Gorath
Message Edited by Moepple on 08-16-2004 03:21 PM
As a database programmer the logic is simple. When you have to query a large array of data it takes longer than having to query a small array of data. Yes, it's the same amount of data overall but it's not nearly the same. Ask yourself this question:
Is it easier to eat an apple in one bite or in several small bites?
Until database query logic is improved there isn't much us programmers can do but give out bite-sized chewable data that the database can handle.
I am pretty aware how a database works. But you did not read my arguments. The overall number of items will be greatly decreased by those changes. People will have to actually delete stuff cause they loose their thousands of items storage vendors.
That given, the database will be much faster cause its smaller. Beside the fact that todays databases are fast enough to handle the vendors as they are implemented now, as we can see, there has to be another reason.
Sorry, I missed your arguements...for clarification are they in another thread? I couldn't find an origional post in regards to,
"TH, thats not nice, thats a compromise I didnt expect, and you turned mysuggestion into something thats on the bottom end of what people might expect."
I think the bottom line is, they may have many reasons for lowering the limits. I'm sure in part to database integrity/performance as well as nerfing the "vendor storage" problems. This may also be tied in with JtL in someway, they may be using a different/improved architecture in JtL, the bottom line is we just don't know. Quite frankly, as a database progammer (im sure your sick of that one), you probably shouldn't know. They have their reasons and that's pretty much all that matters, the fact that they gave us additional vendors to up the limit makes me happy. If this can even slightly improve the lag in other areas of the game (which I doubt, but hey!) I'll be a happy camper. One thing to keep in mind is this database encompasses everything, not just vendors. We are talking about professions statistics, experience, inventories, bazzars, shuttleport wait times, waypoints, datapads, house locations, so freaking many things it would leave you boggled and amazed it's running when it's all said and done.
I apologize for not reading your argument, it wasn't there.
Message Edited by PlayeroftheDay on 08-16-2004 04:07 PM
PlayeroftheDay wrote:
Moepple wrote:TH, thats not nice, thats a compromise I didnt expect, and you turned my suggestion into something thats on the bottom end of what people might expect.However, maybe you find the time to explain ab bit why there has to be a limit and why it has to be so low?This is still below what a lot of us Merchant wants, and to accept it, it would be good to know why. In my Eyes, its not a balance Issue, because the number of available Vendors will go down due to the removal of exploited vendors we need high limits for those legal vendors. Otherwise noone plays Merchant and the economy is as broken in the future as it is now.And btw, maybe you could peek into my post in the merchant-forum :-)Shubashi/GorathMessage Edited by Moepple on 08-16-2004 03:21 PM
As a database programmer the logic is simple. When you have to query a large array of data it takes longer than having to query a small array of data. Yes, it's the same amount of data overall but it's not nearly the same. Ask yourself this question:
Is it easier to eat an apple in one bite or in several small bites?
Until database query logic is improved there isn't much us programmers can do but give out bite-sized chewable data that the database can handle.
It's the same amount of data either way. The server still has to query every row in a particular table for any given query. The only real difference is that less complex queries that return a larger set of data are more network-intensive (assuming queries are done over a network, and not locally), while the more complex queries that specify certain necessary values for the result set are more resource-intensive (since the server has to verify multiple columns for each row in order to generate a correct result).
In this case, I'm guessing the devs are shooting for a less network-intensive system, since the query structure for retrieving vendor item lists hasn't been changed, just the updates and insertions of new data.
Message Edited by Raistlin-TM on 08-17-2004 01:09 AM