Aspect conflicts with other mods

[xJon]

Continuing the discussion over https://github.com/TheCodex6824/ThaumcraftFix/issues/8, I believe there is currently no good workaround to aspect conflicts caused by other mods' recipes, e.g. when using IC2 Classic. As I mentioned there, even when manually overriding the aspects of the basic items (i.e. Planks), some of the cascading items' aspects were still missing (i.e. Bowls). I don't believe manually setting the aspects of all items is a feasible workaround. I'm not sure what the best option is, but an opt-in feature to prioritise vanilla recipes for vanilla items was brought up.

[TheCodex6824]

I think part of this is due to how aspect registrations work - due to the same root cause as the snowball issue, if Thaumcraft discovers an item as a component of a recipe and then later someone registers complex aspects to it with wildcard metadata, the complex aspect is not reflected in the item itself, nor its crafted component.

As an example: chests are apparently supposed to have 15 vacuous (assigned to the wildcard metadata), but they end up not because shulker boxes are examined first before the 15 vacuous is assigned to the chest. Even if the chest had the vacuous assigned to metadata 0 so it appears, the aspect registry is not smart enough to know that it needs to reflect that 15 vacuous in the shulker box now.

I'm really temped to just redo the aspect registry to fix all of these problems, but I'd have to be careful not to break Thaumic JEI, Thaumic Speedup (the main one I'm worried about), and so on.

[xJon]

Regarding Thaumic Speedup, as far as I know it is already somewhat broken (you can see the open issues over https://github.com/LoliKingdom/Thaumic-Speedup/issues), hence I've excluded it from my modpacks.

I am aware of a fork (https://github.com/Wong-Innovations/Thaumic-Speedup) supposedly containing improvements but it is unreleased and seemingly abandoned as well.

[JoshieGemFinder]

One thing I noticed that is probably related is that the new AspectList(ItemStack) constructor calls AspectHelper.getObjectAspects() on the stack passed to it, creating the aspects for that stack, whereas how it's used (in ConfigAspects, at least) seems to be more of a "base aspect list" sort of thing (where aspects added to the stack in the future would still apply to the list assigned in the past, though you can apply extra aspects to this child stack) and this disparity is what causes the shulker box issue (the coloured shulker boxes are meant to treat the purple shulker box as a future base but instead create the purple shulker box aspect list too early). This issue also affects sandstone and stone bricks.

[TheCodex6824]

It seems like there needs to be some system to calculate recipe aspects in the correct order, so that dependencies between recipes are accounted for and the shulker box situation is avoided. This would involve changing the aspect registry so that instead of immediately resolving and registering complex aspects, it would just remember the extra aspects assigned. When all of the registrations are done, it could then go through all the recipes in the game in dependency order (so for the shulker box example, it would evaluate log -> planks -> chest -> shulker shell -> shulker box -> dye -> colored shulker boxes). I think that would work, but you'd have to watch out for recipe cycles.