Skip to content
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
Closed

NullPointerException Crash #260

FireBall1725 opened this issue Oct 6, 2014 · 5 comments
Assignees
Labels
bug
Milestone

Comments

@FireBall1725
Copy link
Member

@FireBall1725 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
BugFix for #260
@thatsIch
Copy link
Member

@thatsIch thatsIch commented Oct 6, 2014

Needs further investigation

@thatsIch thatsIch added the bug label Oct 6, 2014
@Cisien
Copy link
Contributor

@Cisien 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
Copy link
Member

@thatsIch thatsIch commented Oct 8, 2014

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

@yueh
Copy link
Member

@yueh 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
Copy link
Member

@thatsIch 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
HotFix, potentially fixes #260 through catching a null node
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.