Trading Upgrade

[AtomSponge]

An upgrade for Robots and/or Drones, which comes with two tiers:

1. Allows Robots/Drones to view all offers of a Villager
2. An extended version of the first tier, which additionally allows trading with the Villager (providing that the Robot/Drone has an Inventory Upgrade installed)

Basic idea by @ZeekDaGeek, I just thought of the different tiers

[Sbotkin]

I think your version first tier is pretty pointless. How about making it view and trade, but only second tier?

[fnuecke]

I admit I also don't see a use-case for the T1 version, but the general idea is interesting. Making it T2 sounds about right to me.

[ZeekDaGeek]

Possibly for balance. If you would prefer people on your server to find a good villager, leech it and bring it to a user for trading, which would require a users involvement and interaction then disable T2 upgrade.

Also it's a pretty powerful upgrade for just 1 point on drone.

Otherwise only ever craft the T2 upgrade and pretend the T1 doesn't exist.

[fnuecke]

I think it'd be fine to have this as T2, considering it kind of balances itself a bit by the fact that to actually find a villager on its own it'd need a second upgrade (like Computronics' radar).

[Inari-Whitebear]

Hm, wondering how this would work. Would it just be e.g. trading component

• trading.listOffers() -- returns table, listing trading offers (with info on items, if the villager wants to do that trade, etc)
• trading.trade(tradeID) -- tradeID taken from the list of offers, returns false if the trade failed (e.g. the drone/robot didnt have the right items, invalid ID, villager doesn't want to trade that)

and operating on the closest villager in a small range?

[fnuecke]

My idea would have been something along these lines:

• trading.getTrades() returns a table of userdata objects, each of which represents a trade offered by a villager in range (i.e. the list contains all trades offered by all villagers in range, the upgrade doesn't really need to differentiate between individual villagers IMHO).
• trade.getInput() returns the stack representation of what the villager wants.
• trade.getOutput() returns the stack representation of what the villager offers.
• trade.trade() tries to perform the trade, using the stack in the agent's selected inventory slot.

The methods on the userdata objects would fail once the respective villager is out of range or the trade becomes invalid.

[Inari-Whitebear]

Hm, yeah, makes sense ^^ Will take a shot at it~

[fnuecke]

Cool! If you have any questions, lemme know.

[ZeekDaGeek]

trade.trade(int slot1, int slot2) may be required. Villager trades sometimes involve 2 different items in order to complete, such as emeralds and book resulting in an enchanted book.

[fnuecke]

Ohh, right, I completely forgot they have two input slots. Hrm, in that case getInput() would return a tuple, I guess (i.e. local in1, in2 = trade.getInput()), and trade... maybe the agent's inventory could automatically be searched for matching items? I'm not sure if, say, the OreDictionary applies when trading, so that the additional control via specifying the slots is needed?

[Inari-Whitebear]

I went with the automatic way. The only issue with that I found is that if the trader wants for example a diamond sword and gives you an enchanted one back (usually you still have to give something as a second item) and you want to do that multiple times. Minecraft Villagers don't care if the diamond sword you hand them is already enchanted... so depending on inventory layout it could happen that you trade in an already enchanted one for an enchanted one.... 3 ways to go about that I guess:

• Leave it up to the player to program it accordingly (moving items about in inventory)
• Maybe could skip the item as possible input for a trade when it is the same as the output produced from the trade, but there are reasons you might want to trade the diamond sword in multiple times. For example to unlock more trades without needing as many diamond swords.
• Require the player to specify the 2 slots in the inventory when calling .trade(), this would probably simplify the trade method code a bit too

[fnuecke]

I adjusted that check to take into account NBT now, i.e. it must be an exact match. Makes sense for trades potentially added by mods, using mod items with NBT in them, anyway, I think.