Buildinggadgets: [1.15.2]Client crash

Created on 4 Apr 2020  路  18Comments  路  Source: Direwolf20-MC/BuildingGadgets

After deleting this template, please provide the following information:

  • How to reproduce the issue:When I searched for '瀛樺偍' with JEI, the client crashed and the server remained intact.

Most helpful comment

Thanks

All 18 comments

Notice that we have no clue what these chinese, japanese, whatever symbols mean.
Furthermore: 1.15.2 latest is not a version number. Please provide the actual version number.

Nor have we a way to type the symbols in (without painfully trying to find the unicode numbers).
And yes we can propably copy them, but we'd need to know what language to change to in order to test the search...

This may not be your problem, but I don't know why there are Building Gadgets..
https://github.com/FifouBE/EconomyInc/issues/16

In addition, there is only one version of 1.15.2, which I thought you knew.

Whilst this might be correct, it may happen that we release another version and from that point on it is unclear which version was meant. Also it is easier to find out in the future what this was about, when one knows the version number.

I see what you mean.
I'm sorry, it's my fault

Also I believe that this can be closed temporarily, as the dev of FifouBE pointed out, that his block would still be a WIP. This can always be reopened if it appears unfixable on his end.

When I updated EconomyInc 1.6.7, it still crashed.
I tried to delete BuildingGadgets and the crash went away.
This is the latest crash report: https://gist.github.com/EnterFor/045cbc70f17f04a35f05d692c0500895

The same recurrence process,
The block is not placed,
The eye sees it and it crashes.

Which doesn't change the fact that they don't seem to hand our renderer our tile...
I'll take a look at what workaround I can see

To be honest: in this line is the class initialisation...
So as far as I can see, the only cast which matches the exception that happens here is when someone should pass our tile to the render Method. Therefore this is not our Problem: EconomyInc seems to do an unchecked cast here, which does not succeed propably because they are passing the wrong tile to our render Method.

Therefore this is not a BG Problem and can be closed

@MichaelHillcox

Thanks

Actually block bills does something else then I thought and I can see nothing obviously wrong with any of our or FifouBe's renderer code

My first guess towards this without looking at any code would be the collection method or how our render block is setup.

I updated my github, with the latest version 1.6.7. If you see anything wrong with the render code please let me know, I doubled checked and saw nothing wrong. My guess is on the inventory renderer that is not rendering and maybe causing the problem.

@MichaelHillcox it fails already when attempting to pass the Tile into our render Method. For some reason mc associates our renderer with this BlockBills tile entity, when it is rendered in an inventory. And I see nothing obviously wrong with our registration, which would lead to our type overwriting this other one. Which is why I believe the issue must be elsewhere, possibly even in Forge. But only debugging can prove that.

My guess is on the inventory renderer that is not rendering and maybe causing the problem.

@FifouBE what do you mean with that?

The method I use is returning true, which means that mc couldn't render properly the item in the inventory, so oit might me that who is causing the crash. I'm trying to contact EnterFor to see with a temporary fix of disabling the inventory render line, if it's resolve the crash with your rendering process.

Was this page helpful?
0 / 5 - 0 ratings