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)

Literally just pulled and compiled from GitHub.

Describe the issue (IMPORTANT)

Deepslate Lit Redstone Ore which had an ItemBlock before, now no longer has an ItemBlock making it impossible to access using the GameRegistry because the GameRegistry decides to crash whenever you try to access it.

Mod list (OPTIONAL)

java.lang.NullPointerException
at net.minecraft.item.ItemStack.func_77976_d(ItemStack.java:187)
at cpw.mods.fml.common.registry.GameRegistry.findItemStack(GameRegistry.java:371)

Additional Context (OPTIONAL)

Mods are not supposed to NOT register ItemBlocks to their Blocks, that is actually against the Rules for anything that isn't Vanilla, because Mods can special case around vanilla but should not be expected to special case around other Mods.

If you want to hide something from NEI use NEI's function to hide ItemStacks for that one, and not "lack of ItemBlock".

How exactly are you accessing it? GameRegistry.findBlock works

It's more than hiding it from NEI. There's likely other cases where it might show items, I don't want that clutter anymore. It's not my fault findItemStack assumes a block has an item.
Why are you exactly creating an item stack with an unobtainable item anyways? Find item does not crash

It probably does get item from block on the block, and then just creates an item stack with it, without actually checking if that item's available

findItemStack crashes though, I dont think you should do something that literally crashes the damn GameRegistry when someone does something that normally SHOULD WORK

If you want to hide something from NEI use NEI's function to hide ItemStacks for that one, and not "lack of ItemBlock".

Or to say it more simply, you made a backwards incompatible change with older versions of GregTech 6, because you cant load GT6 anymore with your latest EFR until I fix it on my end

In vanilla, lit redstone ore is very obtainable, which is why i have to register it to the Oredictionary just to make sure it can be used for Ore Processing, so I did the same for your Deepslate Redstone Ore too.

Lit redstone ore is not obtainsble, it has no itemblock

Very sure it does have an ItemBlock because i couldnt oredict register it if that wasnt the case.

And now I remember why I need an ItemBlock for it because certain Tools use Recipes on the Blocks they harvest, and Redstone Ore is a complicated bitch about it because it turns lit whenever you leftclick it, meaning BOTH redstone ore blocks need to have a recipe, and if the thing misses an ItemBlock crashes are bound to happen.

lit redstone ore does not have an ItemBlock

GameRegistry.findItemStack("minecraft", "lit_redstone_ore", 1); produces the same crash
(Ignore the bee in the background)

You sure you're doing the same thing to regular lit redstone ore? Because I caused a crash the same way with the vanilla lit redstone ore.

Yes, I do. I believe this version of WAILA actually requires it. I remember not being able to start my game with just WAILA. NEI is present.

I do access Blocks.lit_redstone_ore directly and just make new ItemStack of it, but I also DO pass it to the OreDict which WOULD crash if there was no ItemBlock for it. I wonder if it just gives you the ItemBlock for regular redstone ore then, meaning nothing is registered as the lit one.

Edit: Do you have NEI in that instance you took the screenshot from? NEI actually does fix a lot of missing ItemBlocks

I wonder what the actual eff happens because there should be an actual error thrown SOMEWHERE on my end which there is not...

aaaaaand congrats to myself for hacking shit together like this in the harvest event!

	Block aBlock = (aEvent.block == Blocks.lit_redstone_ore ? Blocks.redstone_ore : aEvent.block);

Yeah, that's actually weird. By all means, you should cause a crash if you are trying to create stacks with vanilla lit redstone ore. I am surprised what you are doing is not crashing the game. Under no circumstances is it obtainable, it doesn't have an itemblock and even if it did, there would be no ways to obtain it legitimately.

Both mine and vanilla override createStackedBlock to return the unlit versions of the block, and they drop the unlit version when silked. I wonder if your recipe thing should check that instead? That way it'd return the same thing; the unlit block and pass it into the recipe, regardless of if it's actually lit.

Not sure how it works on your end, just theory crafting based on my imagination

Yeah see my previous post for how i hacked it together and then FORGOT ABOUT IT ENTIRELY

Oh no worries. I've done horrible hacky stuff in the past either to quickly jump to a class because I was too lazy to scroll down to it, or just wrote some hacky code I made a mental note to fix later and then totally forgot about. if I dug around I cold probably find some ugly hacks I wrote in the past too. I think we're all guilty of doing horrible hacks at one point.

The thing is, the hack i wanted to do JUST NOW is the hack i already saw EXISTING before I even did it XD

You should probably call createStackedBlock, I'm probably not the only mod that decides not to register unobtainable ItemBlocks. createStackedBlock seems to be used to totally force the block to be recognized as something else. If you head over to my other example of itemless blocks, lit redstone lamp, it also uses this function to always create the unlit version as an ItemStack regardless of which one it is.

Another thing I just noticed, Deepslate Redstone Ore does NOT need an Iron Pickaxe while the vanilla Redstone Ore DOES need an Iron Pickaxe, you might wanna look up harvest levels in the Block.java lol

Full list of ItemBlocks with no item:
air (fucking obviously lmfao)
powered_repeater (item is ID "repeater")
unpowered_repeater (item is ID "repeater")
powered_comparator (item is ID "comparator")
unpowered_comparator (item is ID "comparator")
piston_head
piston_extension
lit_redstone_ore
lit_redstone_lamp
melon_stem
pumpkin_stem
redstone_wire (item is ID "redstone")
tripwire
standing_sign (item is ID "sign")
wall_sign (item is ID "sign")

Blocks that technically do not have an ItemBlock but have an item with the same ID as the block (meaning, they are registered as a separate item in Item.java, and not registered with their corresponding block in Block.java. Item.getItemFromBlock will return null for these, these are all on the Item.java block ignore list as well)
wooden_door
iron_door
bed
cauldron
brewing_stand
flower_pot
wheat (yeah I actually thought the block ID for this was "crops" till I looked this up)
reeds
cake
skull

Might've missed a few. Also as a side note, none of these exist regardless of NEI. NEI just hides some unobtainable ItemBlocks (namely double slabs) but does not actually return any that were removed. I've come to that conclusion after looking at the code that refuses to register the ItemBlocks. ObjectIntIdentityHashMap's iterator() function also contains a predicate that ignores null.
I can also check for any mods that have missing ItemBlocks later.

Here's the ones on my end that never had an ItemBlock from when they were created:
sweet_berry_bush
lava_cauldron
potion_cauldron

ItemBlocks that were removed since 2.5.0:
All standing/wall signs
frosted_ice
beetroot (the crops)
daylight_detector_inverted
lit_blast_furnace
lit_smoker

The last two I've considered returning considering the vanilla lit furnace has an ItemBlock.

All of these have 1 thing in common: Trying to create ItemStacks with these IDs will result in null stuff, and GameRegister.findItemStack will likely crash with all of them. Haven't tested but I can later if you want. However it likely will.
The line you showed crashing at the top of the StackTrace is getMaxStackSize(). It gets the item without checking if it is null, since ItemStacks expect to not have a null item when being created anyways. (They should probably throw an IllegalArgumentException in their constructor or something but when does Forge ever force sane things? People can put fucking spaces in a namespace ID for Christ's sake)

So I've double checked although I did similar research back when adding the three itemless blocks above, and determined that null itemblock == the same thing as vanilla does.

I've talked about this change with a pack dev (jss2a98aj) and none of the 95ish mods in his instance has any issues with this. Would you still consider this an issue?

Did you release it already? because I know GT6 currently crashes with it and its not released yet lol

Nope. It's still in beta and probably will be for like 2 weeks at the very smallest. Probably about a month at most.

The time frame I gave you is also I assuming I don't go into another burnout phase and stop working on EFR, which those last anywhere from 2 weeks to 3 months

Yeah just making sure that I release my fix in time. ^^

I'd also be totally willing to wait for you if I end up finishing faster than initially estimated.