forked from Shopkeepers/Shopkeepers
-
Notifications
You must be signed in to change notification settings - Fork 0
/
TODO.txt
100 lines (88 loc) · 8.46 KB
/
TODO.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
High priority:
*
Mid priority:
* For any commands allowing for a targeted shopkeeper: Print 'Ambiguous shopkeeper. Specify the shopkeeper explicitly instead.' error in case more than one shopkeeper is targeted?
* Instead of either only using the first shopkeeper, or applying the operation to all of them
Low priority:
* Make all config keys consistent: Avoid spaces (eg. 'owner uuid') and use hyphens rather than camelcase?
* German translation:
* Rename all occurrences of 'Shop/Shops' with 'Laden/Läden/Händler'?
* Command library revamp:
* Reverse the setup of arguments in parsing chains:
* Currently the parent argument delegates to child arguments, making the setup unnatural since fallbacks need to be specified first
* Instead, allow specifying the chain of arguments more naturally: argument.fallback(fallback).fallback(fallback) etc.
* Support advanced text features (eg. in helps page)
* Allow arguments to change the following arguments, similar to how subcommands have different chains of arguments
* Eg. /shopkeeper info ['own'|'admin'|<player>] <shopkeeper>: Different suggestions/allowed arguments for the second argument depending on the first argument
* But: Avoid duplicate definition of common argument chains, if different chains are not required/used
* Eg. by defining an argument chain once and then reusing it for different sub-commands/arguments
* Maybe even dynamically, by allowing arguments that get parameterized by the arguments parsed before
* Eg. /region <region> removeMember <member>: Only suggest members that are part of the region
* Bind executing code directly to an argument chain, to avoid having to manually check the CommandContext for which arguments got actually parsed
* Allow for easier debugging of command execution and argument parsing (without introducing plugin-specific logging dependencies into the library classes).
* Maybe define separate logging interface for the command lib, current the Log class is used directly
* The same applies for any other utilities and plugin-specific stuff
* Dealing with ambiguities:
* Example: /list [player (default:sender)] [page (default:1)])
* "/list 123" ("123" is a valid player name!)
* Also: "/list 123 2" would currently try to parse "123" as page number and then print an error due to the unexpected "2" due to the fallback mechanic used for the player argument
* Warning if command/arguments allow for ambiguity? Eg. by letting arguments provide a list of examples and evaluating all possible combinations
* Parse all possible argument assignments and print a warning if the input is ambigous?
* Allow resolving ambiguities by explicitly binding arguments, eg. "/list player=blablubbabc page=3"
* or '::' or ':=' or '!='? '=' might likely be used/useful in various arguments as well, and ':' alone is ambiguous because the use in namespaces
* or "/list -player blablubbabc -page 2" ? or "/list !player=blablubbabc !page=2"?
* or "/list --player blablubbabc --page 2"
* but: requires users to know the exact argument name: issue when arguments can have alises? (eg. for literals, especially if the command format uses an alias instead of the actual argument name)
* also: what about sub-arguments? Is it required to be able to explicitly specify which sub-argument an arg is meant to bind to? sub-arguments are usually an implementation detail
* or: "/list '' '2'" (quotes contain the arg(s) that get bound to specific arguments; including marking empty arguments explicitly)
* or: use some separator that marks which arg(s) get bound to which arguments, eg.: "/list | | 2"
* or: use special character/marker to explicitly mark missing arguments: "/list ! 2", or "/list _ 2"
* However: Does not allow resolving all kinds of ambiguities! eg. if arguments parse multiple args: "/cmd [multiple args (here] and there)" ('here' may be the last arg of the first argument, or the first arg of the second argument)
* -> Special character marks 'end of current argument': Allows marking missing arguments, as well as using it as argument delimiter
* Also allow for multi-part arguments: "/text text='some text'"
* And empty/missing argument: "/list player='' 1" (player argument is optional)
* Problem: FirstOf arguments with literals can internally have ambiguities as well, eg. "/list <'all'|player>" (with an existing player named 'all')
* This is only a problem if the sub arguments are joined to a single name in the argument format (which unusual if literal arguments are involved)
* Allow quoted string parsing "'some text'" (accepting "" and '' and ``)
* Also: "{some: map, like: data}"
* Prohibit multiple shopkeepers using the same chest (currently only possible by manually editing the save file)?
* Or make this an official 'feature'? (Allowing players to link multiple of their shops to the same chest.
* Maybe together with the ability to link shopkeepers to multiple chests (because otherwise this might not make much sense, since a single chest might be quite limiting if used by multiple shops)
* 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
* 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.
* 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)
* Or allow shops to be picked up (with all their data) inside an item (possible now via bukkit API? Limit on amount of data that can be stored?)
* Remove AbstractType#matches with aliases
* remove AbstractType#isEnabled() and instead dynamically register and unregister enabled/disabled types?
* might change the order of the types dynamically though.. determine the order differently, via config?
* set entity attributes (subtypes/look) before spawning the entity (avoids short flicker)
* rename registry#getShopkeeperByBlock() to getShopkeeperBySignBlock or similar?
* properly separate loading/unloading from activation/deactivation in debug messages/method names/etc
* More editor options for mob shopkeepers
* Allow equipping (and unequipping again) items to mobs
* Mobs riding other mobs?
* Enderman: carrying block
* Phantom: size
* Puffer fish: puff up state.
* Shulker: color
* Snowman: derp
* Tropical fish: color, pattern, pattern color
* Vex: charged state?
* Add individual config options for the different editor options?
* Allow changing the editor option button items
# 1.14:
* Allow changing the sign text color?
* Set villager trades and test if they display trade-able items when the player holds corresponding items
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.
* Store shopkeeper data (save.yml) in smaller chunks? Maybe 1 file per world?
* Makes only sense for very large numbers of shops, with many trades -> TODO benchmark