Refactor/bazaar structs

[mkram17]

Use TransactionType(Side, Method) which resolves to a PriceType instead of an OrderType or sometimes PriceType and MarketType combo
Instead of using PriceInfo to store and query market prices, directly query utility classes

[0xar-ds]

I think before touching the feature-facing structures we have, we should first tackle No. 1 of #78; its the bare bone to any of those structures and the derived api/models/routines that the features that consume them, use them for its current API.

We should refactor our pricing utilities to a centralized product hash map of orders/offers, that we could source/update/orphan data into from the game itself in that of to always be in pair with what the server rate limits to the API.

Hypixel provides no intrinsic identity anyhow to no order/offer (lets call it a bid) on a product; we can only derive it with certainty for users orders and through superseding/merging multiple data sources at once.

What I have in mind is that the BazaarDataManager will hold two Map<ProductId, PriceLevelPool>, one for each side of the book, where we will insert, poll and splice given a ranking of our data sources:

• ApiSnapshot
  • Polled every 60 seconds, splices the last 30 price pools for each summary; splices the entire price level pool authoritatively.
• UserPlacement | GameChat
  • Derived off Chat | the screens themselves; aggregates/decrements a price level pool optimistically.
• GameScreen
  • ITEM_PAGE | (BUY|SELL)_(PRICE|AMOUNT) | ORDER_OPTIONS screens; splices the scoped price level pool authoritatively.

Besides the ranking we give them on a isSupersededBy(DataSource incoming) method we'd have, each data source can also have their own verbatisms, albeit, observedAt, placedAt, snapshotTs, for calculation of predominance/correctness.

[0xar-ds]

we can only derive it with certainty for users orders and through superseding/merging multiple data sources at once.

What I have in mind is that the BazaarDataManager will hold two Map<ProductId, PriceLevelPool>, one for each side of the book, where we will insert, poll and splice given a ranking of our data sources:

We will have a separate list for tracking live user orders, the price level pool is a reconciliation of "where the market is" and each tracked order would be the correctness of where user's order currently is within that pool.

[mkram17]

I think before touching the feature-facing structures we have, we should first tackle No. 1 of #78

I agree, though I think this should go into a separate pr

UserPlacement | GameChat
Derived off Chat | the screens themselves; aggregates/decrements a price level pool optimistically.
I think that UserPlacement should be split into two levels: derived from chat, and derived from screens. The chat messages are less reliable because when a transaction is over 10k coins they round/truncate(I forget which) the amount to the nearest whole number.

If we could consistently get the user transaction data from screens, we wouldnt even need tolerance, and we could have more accurate prices data.

[Copilot]

Pull request overview

This PR is an internal refactoring of the Bazaar-related data structures. It has two main goals: (1) extract market price caching into a dedicated MarketPrices class (separating it from PriceInfo), and (2) begin the migration from OrderType to TransactionType to better represent whether a transaction is a buy or sell, with two new supporting enums (PriceType moved out of BazaarDataManager, and new MarketType and TransactionType).

Changes:

• New MarketPrices class: Extracts the marketBuyPrice/marketSellPrice fields and associated logic from PriceInfo, creating an independent event-subscribing component that caches and auto-updates Bazaar market prices.
• New TransactionType + PriceType + MarketType enums: Lays the groundwork for replacing OrderType with a clearer TransactionType; PriceType is promoted to a top-level class from an inner class of BazaarDataManager; MarketType (previously nested in InputHelper) is promoted and extended with TransactionType-aware methods.
• Consumer refactoring: OrderInfo, Order, SignInputHelper, and BookmarkSearchWidget are updated to use MarketPrices instead of calling updateMarketPrice() directly, and Bookmark now stores a MarketPrices instance instead of a plain productID string.

Reviewed changes

Copilot reviewed 20 out of 20 changed files in this pull request and generated 11 comments.

Show a summary per file

File	Description
MarketPrices.java	New class extracting market price caching from PriceInfo; extends BUListener for automatic updates
PriceInfo.java	Removes marketBuyPrice/marketSellPrice fields and related methods now moved to MarketPrices
TransactionType.java	New enum for buy/sell intention, intended to replace OrderType
PriceType.java	Promoted from inner class of BazaarDataManager to top-level enum
OrderType.java	Marked @Deprecated; asPriceType() updated to use standalone PriceType
MarketType.java	Promoted from inner class of InputHelper to top-level; adds resolvePriceType(TransactionType)
OrderInfo.java	Adds marketPrices field; delegates price lookups to it
Order.java	Removes redundant updateMarketPrice() calls; delegates price methods to marketPrices
BazaarDataManager.java	Removes PriceType inner class; imports standalone PriceType
SignInputHelper.java	Uses MarketPrices instead of PriceInfo for price resolution
Bookmark.java	Record now holds MarketPrices instead of String productID
BookmarkSearchWidget.java	Uses Bookmark.marketPrices() for price lookups instead of creating OrderInfo
ToggleBookmarkButton.java	Creates MarketPrices instance when adding a bookmark
*AmountHelper.java / *PriceHelper.java	Import updates to use standalone MarketType and MarketPrices

[Copilot]

Pull request overview

Copilot reviewed 30 out of 30 changed files in this pull request and generated 9 comments.

[mkram17]

@0xar-ds what do you think about the two potential impls of TransactionType? I did one 37778a2 and one here f31189b . Still need to rebase but you get the gist of the refactors.

I personally prefer the second option because it is much easier to read and imo handles backend using PriceType better, but the first option is possible as well. Lmk if you have any other ideas.

[mkram17]

Cancellation isnt any type of current transaction. Should we add it to TransactionType?