Support trade rebalance experiment #3311
Conversation
apple502j
requested review from
modmuss50,
Juuxel,
Technici4n,
deirn and
a team
apple502j
added
enhancement
| @@ -66,4 +113,111 @@ public static void refreshOffers() { | |||
|
|
|||
| private TradeOfferHelper() { | |||
| } | |||
|
|
|||
| @FunctionalInterface | |||
| public interface VillagerOffersAdder { | |||
There was a problem hiding this comment.
The boolean parameter is a no-go for me.
There was a problem hiding this comment.
Agreed. Mojang can add multiple offer rebalance packs and mods can add multiple rebalance options; it's better for them to query the data pack status instead, so maybe pass an object that can provide such data pack/experiment enabled information.
There was a problem hiding this comment.
Mojang offering 2 trade rebalance packs is just a speculation - we should not over-complicate the API; and since this API does not allow mods to modify existing trades, I doubt there would be many mods that does that to warrant expansion of this API.
There was a problem hiding this comment.
Then Mojang can remove the trade rebalance pack, by integrating into mainline or dropping it, at any time. What would this boolean serve by then?
What I am looking for is another parameter which mods can query if ANY experimental pack, from mojang or mods, are added. Say a mod want to add a villager trade for bundle if bundle pack is enabled; then this parameter should be some sort of view/manager that allows the mod to query this information and thus decide.
There was a problem hiding this comment.
@liach The boolean-taking version would be deprecated and replaced with the existing, non-taking version. However, a deprecation is expected for any design we could take (apart from just outright not supporting the experiment).
The reason such parameter isn't added is simple: it is not possible. This method is called statically on game load before a world is even loaded, and calling the method pow(2, experiments.length) times (and storing the result, then applying on world load) is unreasonable. Requiring that this be called during world load is inconsistent with the existing API, and there is no convincing reason to do this.
I also question the "modded experiment" part of the comment. Fabric API does not provide an API to register an experiment yet, so there is no reason to support modded experiments.
Finally, a mod that wants to conditionally add bundles in the offer do not need a special parameter. All you need is a custom TradeOffer.Factory, which creates an offer only if the experiment is added. (This method can return null since this update.)
There was a problem hiding this comment.
Looked at the code, this is indeed some bad design from mojang. I think a better solution would be to patch MerchantEntity.fillRecipes implementations to fire 2 events where mods can modify the resulting TradeOffers.Factory list; you can pass the profession, level, and the server world in the regular villager event (and just the world in the wandering trader event), which should be sufficient for mods to make decisions mostly.
There was a problem hiding this comment.
Again, I did not want to make it too different from existing one; I also don't know why this is needed apart from some hypothetical scenarios.
...uilder-api-v1/src/main/java/net/fabricmc/fabric/impl/object/builder/TradeOfferInternals.java
Outdated
Show resolved
Hide resolved
...uilder-api-v1/src/main/java/net/fabricmc/fabric/impl/object/builder/TradeOfferInternals.java
Outdated
Show resolved
Hide resolved
...uilder-api-v1/src/main/java/net/fabricmc/fabric/impl/object/builder/TradeOfferInternals.java
Show resolved
Hide resolved
…ct-builder/trade-experiment
Continuation from #3306, with much cleaner design and code.