Package org.spongepowered.api.item.merchant

Interface TradeOfferGenerator

  • All Superinterfaces:
    java.util.function.BiFunction<Entity,​java.util.Random,​TradeOffer>
    Functional Interface:
    This is a functional interface and can therefore be used as the assignment target for a lambda expression or method reference.
    @FunctionalInterface
public interface TradeOfferGenerator
extends java.util.function.BiFunction<Entity,​java.util.Random,​TradeOffer>
    Represents a generator to create TradeOffers with a bit of randomization based on ItemStackGenerators for populating ItemStacks and finally generating a TradeOffer.

    Can be directly implemented as a lambda as follows: 

     
 final TradeOfferGenerator generator = (merchant, random) -> TradeOffer.builder()
   .firstBuyingItem(ItemStack.of(ItemTypes.EMERALD, 64))
   .sellingItem(ItemStack.builder()
       .itemType(ItemTypes.DIAMOND_SWORD)
       .quantity(1)
       .add(Keys.APPLIED_ENCHANTMENTS, List.of(Enchantment.of(EnchantmentTypes.SHARPNESS, 1000)))
       .build()
   )
   .merchantExperienceGranted(5)
   .priceGrowthMultiplier(1.3f)
   .maxUses(20)
   .build()
 );
    The by-product of a direct implementation is that you would be needing to build out functions accepting the random instance to add dynamism to your generated TradeOffers. As such, a handy builder has been provided with builder() and the related methods exposed in ItemStackGenerator.

    The primary use of this, and why the Random must be provided as part of the BiFunction signature is that during multiple world instances, there's different Random instances instantiated, and more can be provided without the necessity to change the generator. One advantage to using a generator is the ability to provide some "randomization" or "chance" on the various aspects of the generated TradeOffer versus creating a static non-changing offer. Normally, the vanilla TradeOffers are using a similar generator with limited scopes of what the ItemStack can be customized as.