2017-10-09 08:12:35 -07:00
High priority:
*
Mid priority:
2018-08-20 12:53:47 -07:00
*
2017-10-09 08:12:35 -07:00
Low priority:
* Improve chest protection (the anti-hopper code is inefficient).
* Support for more than 8 trades
* More types of block shops? -> clicking button to open shop
* Virtual shops (command to edit and open trade menu), would allow tons of possibilities for other plugins / server admins to use shopkeeper shops in other contexts
Major rewrite of the processing of trades:
Overview over (unrelated) changes performed during the rewrite, which
ended up in the same commit now:
* Fix: All inventory operations are now limited to storage contents.
This might fix issues with hiring cost items being removed from armor or
extra slots.
* Improvement: Normal player shops are now slightly smarter when
figuring out whether the chest has enough space for the traded currency
items, by allowing a variable ratio between high and low currency items.
* Internal/Fix: All general inventory operations now work on content
arrays (inventory snapshots) instead of the inventories directly. (This
might even fix a few severe issues, which were unnoticed so far..)
* Internal: Minor javadoc improvements.
* Internal: Removed a few redundant final modifiers.
* Internal: Added Settings#isHighCurrencyEnabled() and using that now
everywhere.
* Internal: Settings#isHighCurrencyItem() now returns false if high
currency isn't enabled.
* Internal: Minor refactoring related to setting up the editor window
and handling of editor clicks.
* Internal: Updated the TODO list and added a few more ideas.
* Internal/Improvement: Buying shopkeepers are now slightly smarter when
removing currency items from the chest: It prioritizes low currency
items over high currency items, partial stacks over full stacks, and is
able to split more than one large currency item and return the excess
change to the chest (previously it only converted at most 1 high
currency item). This should help keeping the chest more compact.
* Internal: Added a debug message for every trade processed by
Shopkeepers.
* Fix: The purchase log was missing the header row since a previous
commit (35bbfc0bc01ba41a6792449fecca3a664dd6f111). (Also forgot to
mention on that previous commit: The logged data now contains the
players uuid as well, in parentheses inside the 'PLAYER' column.)
* Improvement: The collect-to-cursor inventory action is now allowed
inside the trading window, as long as the result slot doesn't match the
item on the cursor.
Major rewrite of the processing of trades:
Shopkeepers is now implementing the inventory actions that might trigger
trades itself.
Previously, trading with player shopkeepers only allowed simple left
clicks of the result slot. We predicted the trading outcome (rather
simple when only allowing left clicking..) and then let minecraft handle
the click like normal. Any other inventory actions (ex. shift-clicks)
were prevented, because so far we weren't able to predict the outcome of
those.
I finally took the time to dive into minecraft's and craftbukkit's
internals to figure out, how it processes the various clicking types and
resulting inventory actions, how those can trigger trades, and how
minecraft processes those trades.
Supporting more advanced inventory actions for trading requires at
minimum being able to reliably predict the outcome of those inventory
actions, and by that already requires re-implementing of large parts of
the vanilla logic (which is one of the reasons why this wasn't done so
far). The step to also apply those predicted inventory changes ourselves
then isn't that much of an additional effort on top, but has a few
advantages:
For one, we can be quite sure that the predicted outcome of a trade
actually matches what gets applied in the end. This should reduce the
risk of inconsistencies between minecraft's behaviour and our
predictions resulting in bugs (also with future minecraft updates in
mind).
Secondly, when relying on minecraft's implementation we are only able to
allow or cancel the inventory action as a whole. The shift-clicking
inventory action however is able to trigger multiple trades in a row
(possibly even for different trades). By implementing this ourselves, we
are able to apply as many trades as are possible with regards to
available stock and chest capacity.
Implementing the trading ourselves has a few advantages, but also comes
with caveats:
Caveats:
* Increased maintenance and testing effort.
* Increased possibility for inconsistencies between vanilla
inventory/trading behaviour and our own implementation.
* Minecraft performs some map initialization when certain map items are
created by crafting or via trades: This seems to be responsible for
updating the scaling (after crafting a larger map) and enabling tracking
(this doesn't seem to be used anywhere inside minecraft though). Since
this is only the case if the map item has some special internal nbt data
(which shouldn't be obtainable in vanilla minecraft), we currently
simply ignore this inside Shopkeepers.
Neutral:
* The usage count of the used trading recipes doesn't get increased
anymore. But since these are only temporarily existing and aren't used
for anything so far, this shouldn't be an issue.
* The player's item crafting statistic doesn't get increased anymore for
traded items.
* The player's traded-with-villager statistic doesn't get increased
anymore for shopkeeper trades.
I could manually replicate some of these, but since these are custom
trades anyways I don't see the need for it right now. But if there is a
justified interest in this, let me know and I might add a config option
for it.
Advantages:
* Support for more advanced inventory actions when trading with
shopkeepers:
* Currently supported are: Shift-clicking, and moving traded items to a
hotbar slot.
* Not (yet) supported are:
* Dropping the traded item: Exactly reproducing the vanilla behaviour
for dropping the traded item is actually rather tricky / impossible with
pure bukkit API so far.
* Trading by double-clicking an item in the player inventory: The
behaviour of this inventory action is rather arbitrary in vanilla
already (trades zero, one, or two times depending on the other items in
the inventory), and it is affected by a bug
(https://bugs.mojang.com/browse/MC-129515)
* Simpler API: A single ShopkeeperTradeEvent is called for each trade
(might be multiple per click depending on the used inventory action, ex.
shift-clicking). The ShopkeeperTradeCompletedEvent was removed. (API
breakage, sorry.)
* Fixed: The logging of purchases should now actually be accurate for
shift-clicks. It logs each trade individually.
* Eventually this might allow for more options for customization of the
trading behaviour in the future.
Potential issues (that have existed before already):
* If minecraft adds new inventory actions, those are initially not
supported by shopkeepers: If those inventory actions involve clicking on
the result slot, they will simply be prevented. If they however allow
players to trigger trades by clicking on items inside the player's
inventory (similar to the existing collect-to-cursor action by
double-clicking), they might introduce bugs which players might be able
to exploit.
Other changes as consequence of the trade-handling changes:
* Internal: Added a version-dependent function which matches items in
the same way as minecraft does it: Minecraft allows the offered items to
contain additional metadata and still accept them for the trade.
* Internal/Fix: Minor refactoring during updating to the new trade
handling. This might even fix a few small potential bugs/inconsistencies
related to handling of high-currency items.
* Internal: Due to the changes regarding the handling of trades, the
trading count listener (added in a previous commit) is now solely used
to detect trades with non-shopkeeper merchants (ex. vanilla villagers).
This can be useful when comparing vanilla trading behaviour with
shopkeeper's new trading behaviour.
* The ShopkeeperTradeEvent now directly provides access to the items
offered by the player and the order in which they were matched to the
used trading recipe.
2018-05-17 15:26:05 -07:00
* Add debug categories (debug mode can produce quite a lot of spam currently)
* Change amount-per-click from 10 to 8 when clicking items in the player shopkeeper editor? (feels more intuitive due to minecraft's stack sizes)
* Compress currency items in the chest (low currency to high currency)? To maximize available storage capacity. This would also mean that the usage of the high-currency-min-cost setting would be limited to creating the trading recipes, and not be used when adding currency items to the shop chests.
* Maybe prevent any unrecognised types of clicks if running in compatibility mode? To reduce the risk of minecraft updates with new clicking actions causing issues.
2018-06-18 10:49:03 -07:00
2018-06-18 09:12:15 -07:00
* introduce separate editor window to be able to add new player editing options
* add an option to reposition shops: button pressed > window closes + message > player clicks a block > runs new/updated/smarter placement logic there, checks distance to chest, option (default true) to not allow it for shops that are not directly placed on top of the shop chest (because those were probably created via command and it is unclear whether players are meant to be able to reposition those shops)
2018-10-27 07:53:05 -07:00
* Or allow shops to be picked up (with all their data) inside an item (probably not possible right now via bukkit API)
2018-06-18 09:12:15 -07:00
* Remove AbstractType#matches with aliases
* remove AbstractType#isEnabled() and instead dynamically register and unregister enabled/disabled types?
2018-06-18 10:49:03 -07:00
* might change the order of the types dynamically though.. determine the order differently, via config?
2018-06-18 09:12:15 -07:00
* set entity attributes before spawning the entity on newer versions (nicer looking)
* rename registry#getShopkeeperByBlock() to getShopkeeperBySignBlock or similar?
* properly separate loading/unloading from activation/deactivation in debug messages/method names/etc
2017-10-09 08:12:35 -07:00
2018-06-29 08:52:46 -07:00
* Rename ShopkeeperRegistry and ShopkeeperStorage to ShopkeepersRegistry and ShopkeepersStorage?
2018-08-21 16:30:45 -07:00
* Another major api break though.. maybe do this with the next larger API changes. Or not at all.
2018-06-29 08:52:46 -07:00
2019-05-06 08:37:01 -07:00
* More editor options for mob shopkeepers
* Allow equipping (and unequipping again) items to mobs
2019-05-08 15:40:50 -07:00
* Mobs riding other mobs?
* Rabbit: type
* Enderman: carrying block
* Slime, MagmaCube: size.
* Phantom: size
* Puffer fish: puff up state.
* Shulker: color
* Snowman: derp
* Tropical fish: color, pattern, pattern color
* Vex: charged state?
2019-05-07 07:08:41 -07:00
* Add individual config options for the different editor options?
2019-05-28 12:12:11 -07:00
* Allow switching between editor options back and forth via left and right clicking
* Sign shopkeepers temporarily load the chunk on plugin reloads
2019-02-18 18:28:52 -08:00
2019-04-24 18:18:01 -07:00
# 1.14:
* Allow changing the sign text color?
2019-04-25 12:43:22 -07:00
* Set villager trades and test if they display trade-able items when the player holds corresponding items
2019-04-24 18:18:01 -07:00
2017-10-09 08:12:35 -07:00
Ideas:
* Per-Trade/Shopkeeper settings, maybe via written books:<br>
-> by adding another row to the shopkeeper-editor inventory window each trade option and shopkeeper could have a slot for a written-book<br>
-> which could contain additional meta-data, per-trade/shopkeeper settings, which could be used (ex. by other plugins) to trigger certain actions when a specific trade is used <br>
* Maybe move shop options (like currently name, profession, etc.) into a separate inventory view to have additional space there<br>
* Add message to default zero-currency items explaining how to increase/decrease costs.
* Add zero-cost items in trading shopkeeper, with lore which explains how to setup the trade.
2018-08-21 16:30:45 -07:00
* Store shopkeeper data (save.yml) in smaller chunks? Maybe 1 file per world?
2017-10-09 08:12:35 -07:00
* Makes only sense for very large numbers of shops, with many trades -> TODO benchmark
