New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

System not recognizing TE based items with ability to hold power as usable for autocrafting. #3315

Closed
mike7998 opened this Issue Jan 7, 2018 · 7 comments

Comments

Projects
None yet
6 participants
@mike7998

mike7998 commented Jan 7, 2018

The ME system does not recognize a lower tier flux capacitor, or simply jetpacks jetpack as an available item for autocrafting. The crafting preview shows them as unavailable, even though I had multiple of the previous tier of items in the system. attatched are screenshots that I hope help.

  • Minecraft Version: 1.12.2
  • AE2 Version: rv5-stable-4
  • Forge Version: 14.23.1.2582

2018-01-06_21 03 11
2018-01-06_21 03 22
2018-01-06_21 03 38
2018-01-06_21 03 52

@jkroepke

This comment has been minimized.

jkroepke commented Jan 8, 2018

Same for Mekanism machines / gas tanks if the receipts requires more then one tank.

@fscan

This comment has been minimized.

Member

fscan commented Jan 8, 2018

Try creating the pattern with "OreDict Substitution" enabled.

@yueh

This comment has been minimized.

Member

yueh commented Jan 8, 2018

These are actually two bugs.

One of them is fixable by us and affects the TE capacitors. At least for crafting them from scratch. Using capacitors with different settings/charge is not really possible.

The other one is pretty much unfixable on our side. The way SimplyJetpacks creates the output for a crafting results in a completely different item than you are able to define for a pattern. At least not without causing many side issues once other mods actually require precisely the same itemstack, otherwise they might end up in completely wrong results. E.g. a low tier item is suddenly a valid replacement for a high tier one.

@yueh yueh added the type-bug label Jan 8, 2018

@yueh yueh added this to the rv5.stable - 1.12 milestone Jan 8, 2018

@jkroepke

This comment has been minimized.

jkroepke commented Jan 8, 2018

Maybe it is possible to add an option ignore NBT tags like the oredict option for patterns.

@bookerthegeek

This comment has been minimized.

Collaborator

bookerthegeek commented Jan 8, 2018

@jkroepke that will cause more issues then it solves.

yueh added a commit that referenced this issue Jan 9, 2018

Fixes #3315: Slightly more permissive checks for autocrafting
Also fixes a bug in the fallback for looking up patterns to only use
ItemStack.EMPTY.
@Tomson124

This comment has been minimized.

Tomson124 commented Jan 13, 2018

I just had a look at the issue, too, also on my side... And I have to say, I don't know what to change, so it would work with your mod's autocrafting. As I am fairly new to java and especially modding, I am glad if you could give me some advice to fix this :)

@yueh

This comment has been minimized.

Member

yueh commented Jan 14, 2018

I cannot recall every detail and being a fork makes it a bit tedious to follow all code due to the missing search.

But in general it's caused because the recipes are very inconsistent with their NBT data. E.g. the first jetpack produces a NBT tag of {sjData:{Energy:0}}, but the recipe for the second requires {sjData:{Energy:0,JetpackParticleType:0}} but produces {sjData:{Energy:0,JetpackParticleType:0},Energy:0}
Each of them is a totally different item from an external point of view.

Ignoring certain tags is simply not an option and would also be pretty stupid. E.g. ignoring sjData might work, but then the separate Energy tag for the tier 2 one already contradicts it. Also sjData actually indicates completely different items via JetpackParticleType. So a player could request a certain particle effect, but due to it being ignored, they'll end up with a completely different one.

Also it is extremely short sighted. It doesn't fix it, just pushed it back and hope it does not appear again on the next day/release/etc. Basically it forces us to chase every mod we would handle in a special way and have to verify every single release or worse even commit against breaking changes, because the NBT data now has a new tag making it incompatible. Or something like data fixers make it pretty trival to rename sjData and just merge it into the top level tags. We'd to basically test a specific mod version, ensures it works under any condition and hard depend on this exact release until we review it again.
Just a constant uphill battle trying to avoid something, which should really be fixed with something better. E.g. things like labels in 1.13 or better item comparisons provided by forge.

@yueh yueh closed this in 8c5842a Jan 14, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment