Deepslate/tuff causes random blocks to generate when deepslate ores are turned off

[DrParadox7]

Please check any boxes that apply to you and your issue

• I use a translator application to post this issue.

• This is a crash. Please upload, Pastebin, Gist or copypaste the whole crash report along with this issue.

• This is a mod incompatibility. If I do this in vanilla Forge with only Et Futurum Requiem installed, it works normally.

Version number of Et-Futurum-Requiem (IMPORTANT)

2.5.0

Describe the issue (IMPORTANT)

I have received reports that Tuff veins are adding in random modded blocks into its veins:

Upon isolating the problem this occurs even with Et Futurum alone so mod incompatibility is to be ruled out:

To replicate it, simply drink a potion of night vision and use spectator mode at the depths of the world.

Mod list (OPTIONAL)

Here's the mod list for the paranoid bunch:

crash-2023-09-29_03.00.50-client.txt

[GregoriusT]

I would like to know how the heck this happens to you because i have the exact same bug in GT6 and i have no idea how the Block IDs mess up this badly!

This specifically happens to me in random Chunks, as opposed to everywhere.

[Roadhog360]

Oversight with the deepslate ore registry, the deepslate registry still gets them when deepslate ores are not enable. And someone designed the setBlock function to just place random shit from the block registry instead of failing the setBlock!?

[GregoriusT]

Yeah somehow setBlock sometimes actually fails to set the Block you pass as parameter, and instead just gets some random Block ID. That is how it happens in GT6, and I have no Idea how to frikkin fix that...

[Roadhog360]

As explained above, it's because EFR is placing blocks that aren't actually registered.

[GregoriusT]

Welp, guess that was not how random chunks cause that Issue then, that's just how it happens in 100% of the cases...

[Roadhog360]

I might push a fix to BugTorch to make it so any unregistered or null block placement will just fail the setBlock. I'll still fix it within EFR but it'd be useful in case other mods have the same issue. And a failsafe for me making this mistake again.

[GregoriusT]

That might be a bad idea because it would make setBlock calls even more laggy, since you need to look up an ID just to check if the ID you are gonna look up is correct.

[Roadhog360]

Probably could use a map to cache if it failed or succeeded. And null instantly returns false before even trying to do anything

[GregoriusT]

using a map to cache the result of another map does not sound like it would actually do anything, does it? and yeah null check is fine ofc