More informative mishaps #951
Conversation
| override fun errorMessage(ctx: CastingEnvironment, errorCtx: Context) = | ||
| error( | ||
| override fun errorMessage(ctx: CastingEnvironment, errorCtx: Context): Component? { | ||
| val typeStr = HexIotaTypes.REGISTRY.getKey(perpetrator.getType())?.getPath(); |
There was a problem hiding this comment.
Not a huge fan of this; what if two mods add iota types with the same path?
There was a problem hiding this comment.
It's currently set up this way because the hexcasting.mishap.invalid_value.class.<type> lang keys already exist (for use in the old version of MishapInvalidIota) with exactly the string that's needed for this part of the message, and are already used by basically every addon. The alternative would be to make a completely new set of lang keys for this based on the full ResourceLocation, but that would A) require writing out effectively the exact same strings twice for every iota type and B) require every addon to update their lang to do so as well in order to support this version of the base mod.
I agree that it's not a perfect solution, but I can't really think of a better one that doesn't introduce other issues as described above. If you have one in mind though, please let me know!
On another note, two addons that use the same path will likely run into issues regardless of this change, since using the MishapInvalidIota.ofType() method requires defining a hexcasting.mishap.invalid_value.class.<type> lang key for your iota type, and those will conflict with each other anyway unless one of them uses a type name in the lang that isn't the same as the identifier path.
2 participants
Uh oh!
There was an error while loading. Please reload this page.