Closed Dweblenod closed 1 year ago
I am not currently accepting new content for 1.18, all new content needs to target 1.19.
That aside, failure triggers are valuable, but it might be better to understand what you're looking to get out of them before an implementation is decided upon. Obviously a method like generateLoot
from reward is not the ideal API for a failure-condition (as items are not dispensed).
So I ask what are your goals from having a failure condition element? We would want to start by adding a few types of builtin failure conditions (explosions or something like that) so users do not have to fall back to commands.
Hadnt gotten the opportunity to test it in a server setting first. GatewayEntity/GatewayRenderer crash the game client side due to null gateway
The addition of failure components was primarily to accommodate punishments for losses, particularly I thought it would help for datapacks like one I intended to make where the gateways generate near players in a raid/invasion style mechanic on timed intervals.
With that, I like the idea of including explosions as a condition, and can recommend an option for killing players and one for applying a potion effect(potion effects could also make for a good reward). I definitely agree that the loot generating basis of the functions is not necessarily fit for these kinds of uses
Manually added in 3.1.0
Using code from Reward, created circumstances in gateways json files for if the timer runs out. Its an optional section, and only shows up in tooltips or upon failure if it was added to the file(with none of the default gate pearls being given said section)
This was unprompted so its understandable if you don't want to consider these changes!