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

NullPointerException Crash #260

Closed
FireBall1725 opened this Issue Oct 6, 2014 · 5 comments

Comments

Projects
None yet
4 participants
@FireBall1725
Member

FireBall1725 commented Oct 6, 2014

appeng.parts.misc.PartStorageBus.checkInterfaceVsStorageBus(PartStorageBus.java:360) ~[PartStorageBus.class:?]

Looks like something is messed up with the achievement code

@FireBall1725 FireBall1725 self-assigned this Oct 6, 2014

@FireBall1725 FireBall1725 added this to the rv2 milestone Oct 6, 2014

thatsIch pushed a commit that referenced this issue Oct 6, 2014

@thatsIch

This comment has been minimized.

Show comment
Hide comment
@thatsIch

thatsIch Oct 6, 2014

Member

Needs further investigation

Member

thatsIch commented Oct 6, 2014

Needs further investigation

@thatsIch thatsIch added the type-bug label Oct 6, 2014

@Cisien

This comment has been minimized.

Show comment
Hide comment
@Cisien

Cisien Oct 8, 2014

Contributor

@jztech101 ran into an NPE on the line above the commented one. Not really sure what's causing it though. I have a feeling it has to do with rv1 stuff that we need to migrate to the correct spellings (the renamed/fixed enum names getting written to NBT as their .toString() value.)

Contributor

Cisien commented Oct 8, 2014

@jztech101 ran into an NPE on the line above the commented one. Not really sure what's causing it though. I have a feeling it has to do with rv1 stuff that we need to migrate to the correct spellings (the renamed/fixed enum names getting written to NBT as their .toString() value.)

@thatsIch

This comment has been minimized.

Show comment
Hide comment
@thatsIch

thatsIch Oct 8, 2014

Member

Not sure if its really advised to use a enum name to serialize something.

Member

thatsIch commented Oct 8, 2014

Not sure if its really advised to use a enum name to serialize something.

@yueh

This comment has been minimized.

Show comment
Hide comment
@yueh

yueh Oct 8, 2014

Member

3 options come to my mind:

  1. by name =>
    Issues when changing names
  2. by ordinal =>
    Issues when changing order
  3. by custom value => similar to 1, but with an additional overhead that EXTRACTABLE_ONLY is stored as EXTACTABLE_ONLY
Member

yueh commented Oct 8, 2014

3 options come to my mind:

  1. by name =>
    Issues when changing names
  2. by ordinal =>
    Issues when changing order
  3. by custom value => similar to 1, but with an additional overhead that EXTRACTABLE_ONLY is stored as EXTACTABLE_ONLY
@thatsIch

This comment has been minimized.

Show comment
Hide comment
@thatsIch

thatsIch Oct 9, 2014

Member

I think I have a better option. At the moment it determines the expected setting by the NBT tag itself within the item. In itself it is not bad but as you see, any renaming to it leads to crashing code. The system should be more like config system from Forge.

It tries to fetch a specific tag from the config and if not present set the value with a default value. That way it can never occur, that it crashes without our reach. This will also allow us to remove that rv1 -> rv2 hack to catch those circumstances. In addition to that we can check and remove all non-existent tags stored to that item. Not really needed imo in the long run, but can prevent cluttering of the NBT tags.

Member

thatsIch commented Oct 9, 2014

I think I have a better option. At the moment it determines the expected setting by the NBT tag itself within the item. In itself it is not bad but as you see, any renaming to it leads to crashing code. The system should be more like config system from Forge.

It tries to fetch a specific tag from the config and if not present set the value with a default value. That way it can never occur, that it crashes without our reach. This will also allow us to remove that rv1 -> rv2 hack to catch those circumstances. In addition to that we can check and remove all non-existent tags stored to that item. Not really needed imo in the long run, but can prevent cluttering of the NBT tags.

@thatsIch thatsIch closed this in 0f54148 Nov 15, 2014

thatsIch pushed a commit that referenced this issue Nov 15, 2014

thatsIch
Merge pull request #435 from thatsIch/hotfix-260
HotFix, potentially fixes #260 through catching a null node
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment