Hi! I think it would be really nice if the /shops find owned command was able to show you if items are in stock or not! I think this would be super helpful as I'm always going to shops that are not stocked. Not sure if this is possible to implement but I think it would be a convenient addition for all players who actively use the command!

 

I really like this idea. It would be great for Survival as well.

That said, I believe this would be rather involved from a development perspective, if it is possible at all.

***Apologies in advance to the Dev team for anything below this line...I can't help it! =D***

Here's what I THINK would be necessary. Note that some of these pieces may already exist, or perhaps variations on these pieces. Note: I have no insights into the current codebase and thus at least some elements below may be flat out wrong.

First, it would require access to the /shops plugin's code base. No clue if we even have that. If not, full stop here.

Second, it would require a "shop_container_item" database table with a record for each shop container (i.e. a container associated with one or more shops) and item type in the container, which would hold a running count of the quantity of that item in that container. No record for a given item means 0 quantity of that item. Periodic maintenance tasks might be needed for this table to remain highly performant (e.g. index rebuilds).

Third, it would require a "shop_container" table that relates shops to containers in a one-to-many relationship (i.e. one container can have many shops associated with it). Such a table may already exist, in which case this step may not be necessary.

Fourth, it would require a listener to intercept inventory add/remove events (or whatever the Bukkit equivalent is) on all shop containers (or all containers, which are then evaluated to see if they are shop containers). These events would then need to upsert shop_container_item for that given container and item, to keep the record current. This would mean inserting a record if that item doesn't exist in the container and is being added for the first time or updating the record if the item exists and the quantity is being increased or decreased. Optionally, we could delete a record rather than leave it with a quantity of 0 if we're more concerned about the number of records in the table than DB fragmentation due to frequent inserts/deletions.

Fifth, it would require a listener to intercept the create/remove shop event (again, whatever that is...might be the place/break sign event, which is then evaluated to see if it's a shop sign) and insert or delete records in shop_container as appropriate (this might already be happening). This code would also have to find the container associated with the shop and capture its contents in shop_container_item (not sure how to do this, tbh).

Sixth, the code that runs when a shop is punched, which calculates the current number of trades available in the shop, would have to be run for every shop that corresponds to a given /shops find command. Not sure how performant that would be, but there may be ways to flatten (i.e. pre-calculate) the data periodically to keep it fast.

Seventh, shops with 0 trades for the item in question could be filtered out of the recordset before it is displayed in the GUI, thus avoiding the frustration that everyone has now.

I think that about covers it.

 

yeah what mafro said.

jk i didn't read it. but i support this.

 

This has already been suggested multiple times. Shops are already getting sorted based on the latest successful transaction timestamp. There is no clean way to implement this without making sacrifices since the new shop system got designed to be as performant and extensible as possible so the info that'd be necessary is not available. If I come up with an actually acceptable solution in the future I'll implement it but weakening the structure and design of the project for this would be a bad decision.

 

Completely understandable! Thank you dex