Im Confused about Broker

Color me cynical, but won't this just force FTP players to keep buying broker tokens?

That seems to be the simplest reason for the change.

I hadn't even thought about that. You're absolutely right.

You may be on to something here. I didn’t even think of this, as I’ve never been FTP. I’m inclined to agree with your cynicism.

You're brilliant! And probably right.

I’m just bumping this thread out of spite. Now that we (thanks to mouser) have possibly figured out at least part of the reason for this change that literally everyone hates, I think we need to complain more about this 10 day nonsense.

This thread probably played out. Maybe start another if you want more eyeballs on it.

I think its working, I am not getting lag on the broker anymore (never was tbh ) and there are far less pages of items now.
Great job devs!
You have fixed yet another problem that didn't exist

Yes, and no - once you put an item into the broker box, it's simply there. Whether it gets de-listed, it still remains in your broker box for potential sale. However, IF YOU REMOVE IT, then yes you would need a token to put it back into your broker box for selling.
This is equally true whether your account is strictly F2P (aka, Bronze), or Silver F2P.

What makes absolutely NO SENSE, is the same as the pricing & transaction cap changes - WHY did items listed before the change NOT GET AFFECTED??? I have several item across toons that have been listed since before the caps, and they haven't been taken off yet except by me manually.... /shrug

The real bottom line that actually matters is they are highly unlikely to respond OR change it, no matter how much the community complains. They do not admit to making mistakes, or at least ultra-rarely, and they won't back-pedal on such things either. Just have to accept that and move on along.

Why did items before the change remain unaffected? Maybe it's because they couldn't figure out a way to code and include preexisting broker items into this newly-coded equation. Maybe the trigger to flag a broker item for removal in 10 days is the placing of it into the broker, and/or the initial flagging of it for sale by the player.

YAAA I was curious about that too. It would be much better to de-list the stuff that's been on there for months and years. Instead of the 10 day thing.

It seems I’m the one, but I’m glad they didn’t remove old items. Either way though, the 10 day limit is super annoying. I used to sell 99% of my items for 1 copper. I figured I can help out low level and new players with some cheap items (I don’t need the plat). Some items would take a few weeks to sell but for the most part everything would sell in a couple months. Keeping items listed across multiple accounts and toons is an absolute nightmare. So now, I’ve just started destroying all my looted gear and adapt spells. I don’t have the patience to re-list all these items every 10 days. Because essentially it has become a daily chore.

30 - 60 days seems so much more reasonable.

That is the most mind-boggling design choice of which I can even conceive. I'm imagining developers on Linux boxes with zero RDBMS experience and no knowledge of set-based operations distributing everything out onto files because that's how everything else on Linux worked. Was it that bad? Who knows? Would it eventually lead to lag? Oh, you bet.

If these indeed are all stored in flat files, as Sigrdrifa has stated that the developers have said, then I can see searching for items by opening up a filestream and reading in line by line would get costly for 131,023 lines for every few hundred users would be doing this simultaneously. At the very least I think we can all agree that the artwork has for the item icons has to be a series of files kept in a directory.

Two items come immediately to mind. I've downloaded all the game files in my installation rather than letting them stream in as needed when I play the game. Has anyone asked who does and does not do this when talking about who does and who does not experience lag? In my own development experience, the more client-side operations that can be performed, the better. It reduces the number of network fetches and has an enormous impact on lag and concurrency. Things like artwork for hundreds or thousands of different icons are definitely something I would try to pre-load on the client. Regardless, there is going to be a different experience for players who have more server-side operations as opposed to client-side operations. Next, there is the matter of scale. How many of us have worked with RDBMS's? 131,023 rows in a table is a tiny number. That's the kind of size I would fiddle around with on a personal computer for my own development or learning. Depending on the data and data types, that would likely be only a few hundred megabytes, assuming that there are no BLOBs stored in the rows (a fair assumption if the artwork is kept in files.) There is a point at which a table scan is no more costly than a clustered index seek. 131,023 rows is not terribly far above that point.

If someone were to tell me that they needed to squeeze down from 131,023 rows in order to reduce lag, I would tell them that they need to re-design their tables. I've only seen a couple scenarios where that would make a difference, and both times it was because of extremely poor table design. If someone loaded up a table with a single column containing xml stored as a varchar or (worse) a varchar(max), and then had to parse the xml every time to retrieve the elements, that would make a 100K+ row table perform poorly. If they used a non-ascending GUID as a cluster key, that could make a 100K+ row table perform poorly. You get the idea. I've worked with tables containing in excess of a billion rows. I wouldn't let anyone suggest that storing 131,023 records is a problem.

I’ve often wondered about this too. At the time of development (20+ years ago), DB choices were far more limited than today. For example th DynamoDB wouldn’t have even been an option and today a lot of games utilize this. Even still, I agree with you, the amount of data we are talking about seems small even for older architecture designed on a relational DB.

This game is old, and patterned after an even older game. I wouldn't be surprised if all the data is stored in flat text files.

Nope. Punch cards!

Ahhh, the good old days of Fortran '77.

I remember those machines. LOL

Just, the noise!!!

Hey! I still have a deck of Hollerith cards around here somewhere with JCL and Fortran!