DistinctiveItem/isSimilar + Backpack canStack

[Sefiraat]

Description

SlimefunItemStacks that share an ID are currently automatically stacked when running through cargo. Items that vary by lore or another meta aspect are being 'merged' with items that happen to match on ID but are, otherwise, distinct. See issue #3379. This likely only effects backpacks within core Slimefun but also effects any similar SlimefunItems using similar distinctions - DankPacks and Tinkers parts (I'm so self centred!) being an example.

Proposed changes

New ItemAttribute called DistinctiveItem to act as an identifier for items that match this criterion.
Distinctive item has a method that allows an implementation to say how two same-ID items can be distinguished.
SlimefunBackpack has been amended to implement this interface.
SlimefunUtils#isItemSimilar now checks if the stack's SlimefunItem is a DistinctiveItem and, if so, return the result of the canStack method.

Discussion with Walshy shows this is making an extra call to get the ID from the Meta that was already made in the previous getItemData that may mean this PR needs more work.

Related Issues (if applicable)

Resolves #3379

Checklist

• I have fully tested the proposed changes and promise that they will not break everything into chaos.
• I have also tested the proposed changes in combination with various popular addons and can confirm my changes do not break them.
• I followed the existing code standards and didn't mess up the formatting.
• I did my best to add documentation to any public classes or methods I added.
• I have added Nonnull and Nullable annotations to my methods to indicate their behaviour for null values
• I added sufficient Unit Tests to cover my code.

[char3210]

make sure to check for this in line 280 as well, and it should store the results of getItemData (should not call hasEqualItemData)

[char3210]

should be its

[Sefiraat]

Ah, quite right - thanks 👍

[Sefiraat]

make sure to check for this in line 280 as well, and it should store the results of getItemData (should not call hasEqualItemData)

Line 280 is under discussion, and as the PR states, getItemData is in question also. On that note I should have made this draft

[Sefiraat]

So, near as I can tell, the 5th branch (line 280) is never called by items moving through cargo though it will be reached when directly calling isItemSimilar. Given that meta is required to check distinction this will could add a lot of overhead to any other machine using this. Given the above, do we still want to check distinction outside of cargo - given that we do not currently and it, in itself, hasn't shown issues. Input welcome for how to add this in.

Also - changes in commit 92b45ad tested under the same conditions with expected and wanted results.

[char3210]

if that's the case then i would say it's fine as is

[Sefiraat]

See #3417