#(BillGates) why dont trades accept maps

54 messages · Page 1 of 1 (latest)

little roost
#

no idea how to title this better

like, instead of having to write down trade[result=diamond;max_use=10;inputs=stick] which feels a LOT like writing raw objects, could just use map, like trade[<map[result=diamond;max_use=10;inputs=stick]>]

rapid urchinBOT
#

(BillGates) trades accept maps

rapid urchinBOT
#

Hi I'm AutoThreadBot! Don't mind me, I'll just be adding the helper team to this thread so they can see it. A human will get to you soon.
You can block this bot if you don't want to see these messages, I won't mind.
<@&525394568410038282>

little roost
#

my english is getting worse everyday, damn i need to get a break from the internet

#

oop, i forgot to ask the main question:

why don't tradetags accept maps?
is this a limitation, or is this a create feature request moment?

#

(BillGates) why dont trades accept maps

gilded dock
#

!tag with_property_map

quaint lakeBOT
#
Possible Confusion

Did you mean to search for propertyholderobject.property_map?

gilded dock
#

er

#

!tag with_map

quaint lakeBOT
# gilded dock !tag with_map
Cannot Specify Searched Tag

Multiple possible tags: <PropertyHolderObject.with_map[<property-map>]>, <DiscordButtonTag.with_map[<map>]>, <DiscordEmbedTag.with_map[<map>]>, <DiscordSelectionTag.with_map[<map>]>, <DiscordTextInputTag.with_map[<map>]>.

gilded dock
#

:(

#

!tag propertyholderobject.with_map

quaint lakeBOT
gilded dock
#

that one^

little roost
#

oh shit

little roost
#

wait, uh, i do that with the villager entity?

gilded dock
#

with the trade object

little roost
#

oh its an actual object, right that makes more sense

north nova
#

!objecttype trade

quaint lakeBOT
# north nova !objecttype trade
ObjectType: TradeTag

Merchant trades are the parts of a special merchant inventory that is typically viewed by right clicking
a villager entity. Any number of trades can fit in a single merchant inventory.

Trades are represented by TradeTags.

The properties that can be used to customize a merchant trade are:

result=<item>
inputs=<item>(|<item>)
uses=<number of uses>
max_uses=<maximum number of uses>
has_xp=true/false

For example, the following command opens a virtual merchant inventory with two merchant trades.
...

Prefix

trade

Base Type

ElementTag

Implements

PropertyHolderObject

Format

The identity format for trades is just the text 'trade'. All other data is specified through properties.

little roost
#

ok, i managed to do it for a single trade

#

how would i go about multiple trades?

# 
blocktrade_world:
    type: world
    data:
        1:
            max_uses: 10000
            inputs: iron_ingot
            result: end_stone
    debug: false
    events:
        on player right clicks blocktrade:
        - ratelimit <player> 1t
        - determine passively cancelled
        - opentrades <trade[trade].with_map[<script.data_key[data.1]>]>

this works

north nova
#

!c opentrades

quaint lakeBOT
# north nova !c opentrades
Command: OpenTrades
Group

player

Syntax

opentrades [<entity>/<trade>|...] (title:<title>) (players:<player>|...)

Short Description

Opens the specified villager entity's trading inventory or a list of trades.

Description

Forces a player to open a villager's trading inventory or a virtual trading inventory.
If an entity is specified, only one player can be specified.
Otherwise, if a list of trades is specified, more than one player can be specified.
If the title is not specified, no title will be applied to the virtual trading inventory.
If no player is specified, by default the attached player will be forced to trade.

north nova
#

it's a list of trades

little roost
#

do i gotta do each <trade[trade].with_mapblablabla individually?

north nova
#

i mean

#

you have access to code, you can use loops

little roost
#

yeah

#

imma try something

#

prob a bad idea, brb

# 
on player right clicks blocktrade:
        - ratelimit <player> 1t
        - determine passively cancelled
        - repeat <script.data_key[data].size>:
            - define trades:->:<trade[trade].with_map[<script.data_key[data.<[value]>]>]>
        - opentrades <[trades]>
#

basically still same idea from the hacky version, but now using with_map

#

it works, but not too sure if this is the correct way to do it

gilded dock
#

use a foreach

little roost
# 
on player right clicks blocktrade:
        - ratelimit <player> 1t
        - determine passively cancelled
        - foreach <script.data_key[data]> as:val:
            - define trades:->:<trade[trade].with_map[<[val]>]>
        - opentrades <[trades]>
#

yeah that feels way cleaner

#

mark as resolved? idk if theres room to improve

gilded dock
#

if you wanted to overdo it you can use parse_tag, would fit it all in one line, albeit a rather long line

#

mostly stylistic preference at that point

#

otherwise ye /resolved

little roost
#

hell yeah

#

thanks guys