How or Why is this possible?!

[Troo]

How or Why is this possible?!

• 1,000+ bidding
• Selling them for 1 or 100
• 2 did sell for 120,000 but not the rest

Broken?

[kwsapphire]

I am not TOTALLY sure how the conversion system works, but I am guessing this is due to a conversion. That is, the auction house will convert certain items into other similar items to fill players' bids. Might also be typos from people making bids. "Oops extra zero!" and all that? 

[Hedgefund]

Just curious, might some of your bids be for some form of Gaus to-hit?

[Yomo Kimyata]

19 minutes ago, Hedgefund said:

Just curious, might some of your bids be for some form of Gaus to-hit?

 

That's the only explanation I could come up with.  You can't sell it if you have a bid at the same or a higher price.

[Andreah]

I assumed it was that you couldn't sell if your own bid for an item is the highest outstanding bid. It does the query, find the highest bid, sees that it is yours, and since you can't sell to yourself, it doesn't go through. Then it stops looking. So even if there are bids, it wont' find them.

 

However, it could be as Yomo described too.  A little experimentation could clear it up I would think.

Edited January 24, 2022 by Andreah

[Troo]

6 hours ago, Hedgefund said:

Just curious, might some of your bids be for some form of Gaus to-hit?

 

Yes.

But I don't have 1,000+ bids for this item.

I removed the bids and still stuck. 45 minutes.

 

At the time, tested a different item that I had about the same number of bids on.. no issue.

 

So weird.

 

[note: these did eventually clear by the next time I logged back in 6-7 hours later]

 

Edited January 24, 2022 by Troo

[Yomo Kimyata]

It doesn't matter how many bids you have.  As long as you have even one in, you won't sell until either your bids get filled or someone else bids higher.

 

When you offer something, the system asks:  is the highest bid equal to or higher than this offer?  If so, great!  But then it checks:  is that highest bid by the same person (no self dealing allowed)?  If so, you won't transact until someone else enters the system at a higher price.

 

I call this the locked/inverted market bug.  It can be exploited.  I've been logging bugs with HC since the beginning but they are all "working as intended".

[Ura Hero]

52 minutes ago, Yomo Kimyata said:

I call this the locked/inverted market bug.  It can be exploited.  I've been logging bugs with HC since the beginning but they are all "working as intended".

 

When someone else drops a bowl of spaghetti on the floor do you really want to clean it up? 

[Andreah]

This is the sort of thing that happens when you write your own subsystem in-house instead of getting a cots or even open source version to use. Those both can be a hassle, but they're worth it in the long run. Partly you're not reinventing the wheel, and partly you get a wheel that's reasonably round.

 

As I understand it from previous threads, the auction uses an in-house coded heap or binary tree of some sort to implement the bids (and offers on the other side) as a priority queue.  This is potentially fast at getting the absolute highest priority (in this case, priority is price) element, but not satisfy it the way of, say, a properly formed SQL query where it would have been easily restricted to the highest bid price from a user other than the offeror; and so you get this particular bug. 

 

I'm sure it's fixable even in the current code. But exactly where, and how, to do it? That now requires very specialized understanding of this code. And after the changes, one need to perform rigorous testing on it, and that's complicated because it's detailed, possibly very complex and poorly documented low level code you're fooling with instead of a simple SQL query string, where you know the database will retrieve the results if the query is properly formed, and knowledge of query syntax is common as dirt and queries are easy to inspect and test. 

[Ura Hero]

Bah.  SQL.  Back in my day we managed our databases with sticks and rocks and we liked it!

[wjrasmussen]

1 hour ago, Ura Hero said:

Bah.  SQL.  Back in my day we managed our databases with sticks and rocks and we liked it!

Oh, very nice, we used our fingers in the sandy beach.

[Andreah]

To be honest, in the last few years I've started to really like unstructured and triple-store databases.

 

Databases have never been the core focus of my work experience; which is likely true of many developers. All the more reason not to try to homebrew them. And I think that applies to many other things we might want to use. These subsystems are things people put careers in to, not a couple of nights hopped up on jolt cola.

[iBot]

10 hours ago, Andreah said:

To be honest, in the last few years I've started to really like unstructured and triple-store databases.

 

Databases have never been the core focus of my work experience; which is likely true of many developers. All the more reason not to try to homebrew them. And I think that applies to many other things we might want to use. These subsystems are things people put careers in to, not a couple of nights hopped up on jolt cola.

A big part of programming is knowing when to use a system and when not to.  I think the trap a lot of people fall into is trying to make everything fit into whatever new shiny they just learned.  Databases are like everything else.  A well designed one can be a thing of beauty to watch chew over massive amounts of data without a single glitch.  Poorly designed, or better put poorly implemented ones are a nightmare.

 

Again, I've never seen this code, but my gut says they tried to implement this thing as a game loop system not realizing the amount of data required to model the stock exchange.  That is essentially what the AH is... a model of NASDAQ.  And even on a much smaller scale that gets out of hand very quickly.  I'm willing to bet good inf that the original devs had enough time to put a rough system into place and then could not spare time to clean up the mess which led to quick patch "fixes" which only made the implementation even more fragmented and devolved into pure spaghetti puree.

[Without_Pause]

2 hours ago, iBot said:

A big part of programming is knowing when to use a system and when not to.  I think the trap a lot of people fall into is trying to make everything fit into whatever new shiny they just learned.  Databases are like everything else.  A well designed one can be a thing of beauty to watch chew over massive amounts of data without a single glitch.  Poorly designed, or better put poorly implemented ones are a nightmare.

 

Again, I've never seen this code, but my gut says they tried to implement this thing as a game loop system not realizing the amount of data required to model the stock exchange.  That is essentially what the AH is... a model of NASDAQ.  And even on a much smaller scale that gets out of hand very quickly.  I'm willing to bet good inf that the original devs had enough time to put a rough system into place and then could not spare time to clean up the mess which led to quick patch "fixes" which only made the implementation even more fragmented and devolved into pure spaghetti puree.

I've seen my fair share of databases created by people who clearly were not DBAs. More striking are people who know enough to make them but not use basic rules when creating said databases. I have worked for a number of big name companies pretty much any American would know and repeatedly seen basic database design errors. There was an instance when I was an intern the database was so poorly designed I told a fellow student what was going on, and they buckled over in laughter. Sticking more than one table's worth of data into a single table is sadly far too common. Again, we are talking billion dollar companies. Side note, as an intern I was tasked with designing a system, and when I told someone outside of the company what I was doing their response was, "Wait, they don't have an electronic version of that system already?" When I confirmed the company didn't, their jaw dropped. That was less than a decade ago, IIRC.

 

I have zero doubt the code behind the market is an unruly mess. The fact that it hit live broke and never got fixed confirms to me whoever designed it was out of their league. Also telling is it remains broke under HC.

[iBot]

2 hours ago, Without_Pause said:

Again, we are talking billion dollar companies.

My experience has been that the size or wealth of the company makes little difference.  I think a lot of times the original design is done by someone that is drafted into the project who is not remotely a data specialist rather than someone that has the training and experience to do it properly.  It is down hill from there.  And the type of industry really doesn't matter.  I've seen tech companies that were tech companies from day one have inventory or accounting systems that are complete disasters to the point where they have four or five different identifiers for the same object just because no one could figure out the original numbering system so the invented a new one and tried to tack in on.  So you end up with lookup tables for lookup tables that reference another unrelated lookup table because that is where the original manufacturer part number is.  And if you dig deep enough the original document they used was an excel spreadsheet. 🤪

[Andreah]

There's never money to do it right, and never time to do it over.

[Ura Hero]

7 hours ago, Without_Pause said:

There was an instance when I was an intern the database was so poorly designed I told a fellow student what was going on, and they buckled over in laughter. 

 

 

I got to look under the hood of a $250k small CRM system that didn't work worth a flip.  Whoever made it did not make the Company or the Contact the primary key or any key for that matter.  The only key in the entire database was the call number.  It was nearly unsearchable for useful data.  Data entry was fine, but retrieval took an atom bomb and a handful of Advil.    There were about a dozen unused tables that weren't connected to anything.  It looked like something a first year CS student would put together by reading the class notes without ever actually going to class.  I still can't believe that the company bought it without any of the IT staff actually looking at it.  Thankfully it's dead and buried now.  It's loss was not mourned.

[seebs]

On live, I used to have a character pick a random common salvage, place a bunch of bids at 300inf, list everything I got at 1inf, and just watch the money pile up. My record was getting 600k for a ruby I had listed at 1inf.

[golstat2003]

On 1/24/2022 at 7:21 PM, Ura Hero said:

Bah.  SQL.  Back in my day we managed our databases with sticks and rocks and we liked it!

 

Late comment. But as someone who deals with SQL on a regular basis (Lead QA Analyst) and trains others in how to use it, yeah you really need to know what you are doing as Andreah mentioned, in terms of testing if you're going to implement it on top of spaghetti code. (The city of heroes Auction House spaghetti code being the issue, not SQL).

 

I'm NOT AT ALL shocked that HC volunteers aren't eager to jump into Paragon Studios ancient (and probably nonsensical) setup for the Auction House. So yeah not shocked a lot of the bugs reported by Yomo Kimyata came back as "working as intended". I don't blame HC one bit. 😛 

Edited February 18, 2022 by golstat2003

[golstat2003]

On 1/25/2022 at 12:16 PM, Without_Pause said:

I've seen my fair share of databases created by people who clearly were not DBAs. More striking are people who know enough to make them but not use basic rules when creating said databases. I have worked for a number of big name companies pretty much any American would know and repeatedly seen basic database design errors. There was an instance when I was an intern the database was so poorly designed I told a fellow student what was going on, and they buckled over in laughter. Sticking more than one table's worth of data into a single table is sadly far too common. Again, we are talking billion dollar companies. Side note, as an intern I was tasked with designing a system, and when I told someone outside of the company what I was doing their response was, "Wait, they don't have an electronic version of that system already?" When I confirmed the company didn't, their jaw dropped. That was less than a decade ago, IIRC.

 

I have zero doubt the code behind the market is an unruly mess. The fact that it hit live broke and never got fixed confirms to me whoever designed it was out of their league. Also telling is it remains broke under HC.

 

Yeah. Again, if I were HC I would not want to dive into that mess. So I don't blame them. Hell I don't think ANY of the current COH servers will EVER want to dive into that mess now that we've all seen what's under the hood. (And it's given us nightmares).

 

All good points. Based on my 10+ years experience in IT (sound like you have way more lol) DBA are severely undervalued at pretty much any company I've worked at. 

 

[golstat2003]

On 1/25/2022 at 7:56 PM, Ura Hero said:

 

I got to look under the hood of a $250k small CRM system that didn't work worth a flip.  Whoever made it did not make the Company or the Contact the primary key or any key for that matter.  The only key in the entire database was the call number.  It was nearly unsearchable for useful data.  Data entry was fine, but retrieval took an atom bomb and a handful of Advil.    There were about a dozen unused tables that weren't connected to anything.  It looked like something a first year CS student would put together by reading the class notes without ever actually going to class.  I still can't believe that the company bought it without any of the IT staff actually looking at it.  Thankfully it's dead and buried now.  It's loss was not mourned.

 

Yeah the second you make that mistake, it's super downhill from there. At that point you might as well throw out the whole database, because you will eventually run into the exact problems you explained they did.