Et Futurum Requiem

Et Futurum Requiem

105k Downloads

Hates MiddleEarth Tweaks.

MagmaSlime123 opened this issue · 11 comments

commented

Initial Questions

  • I have searched this issue tracker and there is nothing similar already, and this is not on the list of known issues. Posting on a closed issue saying the bug still exists will prompt us to investigate and reopen it once we confirm your report.
  • I have verified that this issue occurs in a SUPPORTED environment, meaning I can reproduce this WITHOUT OptiFine, and without Bukkit+Forge server software like KCauldron, Thermos, Crucible, Mohist etc

Mod Version

2.6.1.

Describe the Issue

Title.

Conflicting Mods

See Javanosa/MiddleEarth-Tweaks#3 for info.

Crash Report

See above issue.

Other Details

Dev told me via DMs to report this to you, as its caused by EFR, and not their mod.

image

commented

https://github.com/Roadhog360/Et-Futurum-Requiem/blob/master/src%2Fmain%2Fjava%2Fganymedes01%2Fetfuturum%2Fblocks%2FBaseSlab.java#L177-L180

This code can't throw NPE. Nothing is ever null at this point. I noticed this is happening in preInit, they may be asking for hardnesses before my blocks are even initializrd and if they are, then it's not on my end and they have to be sure they're running this after my blocks initialize. Even then I fail to see how that's on my end. All of the proper checks are in place.

commented

image
image

commented

Ohhh they're calling the hardness function without a dummy world and just hoping no mods crash? Sorry but no, not my issue, being not null is an expected result, use a dummy world. I preemtively avoid issues exactly like this when building my blocks registry; had this code crashed it'd be my fault not the other mods.

Here is how I safely check other blocks' hardnesses outside of a world. If you can't be arsed then just try/catch with a default value or something. Honestly surprised no other mods gave him issues.

https://github.com/Roadhog360/Et-Futurum-Requiem/blob/master/src%2Fmain%2Fjava%2Fganymedes01%2Fetfuturum%2Fcore%2Futils%2FDummyWorld.java
https://github.com/Roadhog360/Et-Futurum-Requiem/blob/master/src%2Fmain%2Fjava%2Fganymedes01%2Fetfuturum%2Fblocks%2Frawore%2FBaseRawOreBlock.java

commented

Thats very much overkill. Im doing slabBlock.getBlockHardness(null, 0, 0, 0) as im expecting a static value to set for my automatic vertical slab registrations. I have no way to get a world object at the block registration time. I did this way as its statically used among all the vanilla code and code of most other mods. So if you could return a static value if world is null that would be a solution.

commented

Try/catch is not overkill. Haphazardly passing null into a function is not something I'm inclined to work around.

Workaround ≠ solution

I'm sure plenty of other mods have meta-sensitive hardness, in fact plenty of my other blocks do.

commented

With try catch or a dummy world it would always return a wrong blockhardness so that would need an extra class for your slab... As i said you are the first mod where I see this.

commented

And with a default value I'd always be returning the wrong value anyways since the slabs have many different hardnesses, and even more when you count the meta-specific values.

Try getHardness catch with the direct hardness field. Or you can provide your own default value because it's no more likely to be correct than mine would be.

commented

Well sad as i cant update my mod 😪

commented

With try catch or a dummy world it would always return a wrong blockhardness so that would need an extra class for your slab... As i said you are the first mod where I see this.

Wait what do you mean? with a dummy world it would always return the right hardness...

Anyways I'm definitely not the only mod using the worldIn object in the hardness call lol. Why even do this on preInit? Why not just pass the base slab's getHardness to the vertical slab's?

commented

Yes

commented

Here is an example of a block that copies lots of properties from another.

https://github.com/Roadhog360/Et-Futurum-Requiem/blob/master/src%2Fmain%2Fjava%2Fganymedes01%2Fetfuturum%2Fblocks%2Fores%2FBaseDeepslateOre.java

It doesn't pass in the getHardness due to being in preparation for passing in different combinations of metadatas to copy that may not be relative to the base block but I still hope it helps as it copies many other properties directly in a similar manner of passing in the base function.