SkBee icon indicating copy to clipboard operation
SkBee copied to clipboard

[SUGGESTION] Merchant syntax rework

Open Fusezion opened this issue 2 years ago • 2 comments

Suggestion

Rework and break every nook and cranny of merchant syntax into an easier to read and modify system. I am fully planning to have this rework break merchant syntax to provide an easier and more user friendly experience than looking through docs to compare syntax

Currently the syntax to manage recipes, create and add is too centered around the initial creation *maximizing the total possible constructors given for MerchantRecipe. Currently using syntax would look like

on load:
    set {_example} to merchant named "billy bob joan"
    set {_recipe} to merchant recipe with result stone with max uses 10
    set ingredients of merchant recipe {_recipe} to diamond and iron ingot
    add {_recipe} to merchant recipes of {_example}

that's 3 whole lines to create, add ingredients and add to recipes that's honestly not bad however it can be improved but firstly let's show an example using all possible options for merchant recipe with result...

on load:
    set {_example} to merchant named "Fusezion's Mother"
    set {_recipe1} to merchant recipe with result stone with max uses 10 with uses 10 with experience reward with villager experience 1000 with price multiplier 1.1 with demand 2 with special price 1
    set ingredients of merchant recipe {_recipe1} to 10 diamond blocks and 15 snowballs
    add {_recipe1} to merchant recipes of {_example}

While above it might of sounded like I disliked it being 3 lines long I'm aware there's no real way to counteract it without it looking like I just spent 15 minutes snorting some pixy stix dust. as such my prefer rework is as shown below where we don't focus on maximum constructors but rather minimum

# going from this
[new] merchant recipe with result %itemtype% with max uses %number% [with uses %number%] [(|with experience reward)] [with villager experience %number%] [with price multiplier %number%] [with demand %number%] [with special price %number%]
# to this
merchant reicpe (for|with result) %itemstack% (and|with) (%integer% max uses|max uses [of] %-integer%) (using|with ingredient[s]) %itemstacks%

syntax is prone to change as %integer% max uses|max uses [of] %-integer% one or the other needs decided The ingredients should be defined in the initial creation with all the little extra side details managed via their own expressions

set experience reward of merchant recipe[s] %merchant recipes% to %boolean% # maybe an effect?
set [:max] uses of merchant recipe[s] %merchant recipes% to %integer%
set villager experience [reward] of merchant recipe[s] %merchant recipes% to %integer%
set price multiplier of merchant recipe[s] %merchant recipes% to %number%
set demand of merchant recipe[s] %merchant recipes% to %integer%
set special price of merchant recipe[s] %merchant recipes% to %integer%

as a result the new version would be

on load:
    set {_example} to merchant named "bobby"
    add (merchant recipe with result stone and 10 max uses with ingredients diamond and emerald) to merchant recipes of {_example}

Alternatives

I've been unable to think of any other alternatives I could add to this that not only prevented breaking changes but allowed for the freedom users needed.

Additional Information

While 2.7 is at the point where no one knows when it'll release I needed a reminder for this outside of only #418. Merchants are mostly a separate section outside of recipes and shouldn't be limited to only that.

I have this targeting 2.7 due to api changes like registerDefault for property expressions, this will allow me to add support for structures/sections a lot easier and add easier/faster creation as below

create [a] [new] merchant (with name|named) %string%:
    add trade for merchant recipe for stone with 10 max uses using cobblestone and coal
    add merchant recipe for stone with 10 max uses using cobblestone and charcoal to trades
    # unsure which pattern I like more

on load:
    create [a] [new] merchant (with name|named) %string%:
        add trade for merchant recipe for stone with 10 max uses using cobblestone and coal
        add merchant recipe for stone with 10 max uses using cobblestone and charcoal to trades

as you can see it's basically 1-1 copy and nothing outside of needing to register a StructMerchant and EffSecMerchant all I need to do is basically add a dummy event similar to BoundCreateEvent to store the possible event values

NOTE: as bukkit doesn't have a Bukkit#getMerchant() and Bukkit#createMerchant() won't act as a getter it stands they'll have to use a line of code like set {merchant} to merchant. I'd probably rather add a map as (string, merchant) to allow a custom getMerchant method it wouldn't be needed and probably just useless code. That will be left to the development period of this rework to see how it goes and if that should be done over the above.

Fusezion avatar Aug 03 '23 07:08 Fusezion

I do not like the idea of a structure, since you aren't able to use variables and some expressions, and you also have no control over when the recipe is created. I do like the idea of a section though. It cleans things up.

That said, since its in a section you could do an effect to add trades without the need to use an expression for the ADD effect. simply you could do

on load:
    create [a] [new] merchant (with name|named) %string%:
        add merchant recipe for stone with 10 max uses using cobblestone and charcoal

ShaneBeee avatar Aug 03 '23 15:08 ShaneBeee

Yeah using an effect was probably gonna be the route I used just for general cleanliness trade was mostly there for explaining but I do like your syntax more.

Not doing structure is fine, not really an important piece compared to a section or smth

Fusezion avatar Aug 03 '23 16:08 Fusezion

closing due to inactivity, please re-open if you see fit

ShaneBeee avatar May 20 '24 19:05 ShaneBeee