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

Hates MiddleEarth Tweaks. #545

Closed
2 tasks done
MagmaBro123 opened this issue Nov 1, 2024 · 11 comments
Closed
2 tasks done

Hates MiddleEarth Tweaks. #545

MagmaBro123 opened this issue Nov 1, 2024 · 11 comments
Assignees

Comments

@MagmaBro123
Copy link

MagmaBro123 commented Nov 1, 2024

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

@Roadhog360
Copy link
Owner

Roadhog360 commented Nov 1, 2024

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.

@MagmaBro123
Copy link
Author

MagmaBro123 commented Nov 1, 2024

image
image

@Roadhog360
Copy link
Owner

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

@Roadhog360 Roadhog360 closed this as not planned Won't fix, can't repro, duplicate, stale Nov 1, 2024
@Javanosa
Copy link

Javanosa commented Nov 1, 2024

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.

@Roadhog360
Copy link
Owner

Roadhog360 commented Nov 1, 2024

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.

@Javanosa
Copy link

Javanosa commented Nov 1, 2024

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.

@Roadhog360
Copy link
Owner

Roadhog360 commented Nov 1, 2024

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.

@Javanosa
Copy link

Javanosa commented Nov 1, 2024

Well sad as i cant update my mod 😪

@Roadhog360
Copy link
Owner

Roadhog360 commented Nov 1, 2024

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?

@Javanosa
Copy link

Javanosa commented Nov 1, 2024

Yes

@Roadhog360
Copy link
Owner

Roadhog360 commented Nov 1, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants