X-Ray Scanner not working if NotEnoughIDs mod is used together with ELN

[JalapenoPepper]

• [ x] Bug report

Issue description

When you use a mod called NotEnoughIDs, to extend hardcoded block and item registration ID's up from 4096 to 65535( because MC 1.7.10 natively can't handle so much blocks and items from various mods), ELN X-Ray scanner will display nothing, even if it pointed straight on an vanilla ore block( Gold, Redstone, etc.)


If the mod is removed from mods folder, X-ray scanner will work fine, even on the same save/world

Steps to reproduce

Install MC 1.7.10 with MC Forge 1614
Add ElectricalAge-1.14.2.jar or ElectricalAge-1.17.0.jar to mods folder
Add NotEnoughIDs-1.4.3.4.jar (Curseforge , His github)
Launch the game and generate world
Take a charged X-Ray scanner in active slot and try to point with it on earth or ore blocks - you'll see nothing, as if the scanner was pointed to the air.

Electrical Age version

1.14.2 to 1.17.0

Also, if you try to use NotEnoughIDs-1.4.3.5, the game will crash:

Description: Unexpected error
java.lang.ArrayIndexOutOfBoundsException: 1750
	at mods.eln.item.electricalitem.PortableOreScannerItem$RenderStorage.generate(PortableOreScannerItem.kt:459)
	at mods.eln.item.electricalitem.PortableOreScannerItem.renderItem(PortableOreScannerItem.kt:243)
	at mods.eln.generic.SharedItem.renderItem(SharedItem.java:75)
	at net.minecraftforge.client.ForgeHooksClient.renderEquippedItem(ForgeHooksClient.java:220)
	at net.minecraft.client.renderer.ItemRenderer.renderItem(ItemRenderer.java:80)
	at net.minecraft.client.renderer.ItemRenderer.func_78440_a(ItemRenderer.java:499)
	at net.minecraft.client.renderer.EntityRenderer.func_78476_b(EntityRenderer.java:736)
        at net.minecraft.client.renderer.EntityRenderer.func_78471_a(EntityRenderer.java:1361)
	at net.minecraft.client.renderer.EntityRenderer.func_78480_b(EntityRenderer.java:1015)
	at net.minecraft.client.Minecraft.func_71411_J(Minecraft.java:1001)
	at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:898)
	at net.minecraft.client.main.Main.main(SourceFile:148)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at net.minecraft.launchwrapper.Launch.launch(Launch.java:135)
	at net.minecraft.launchwrapper.Launch.main(Launch.java:28)

A detailed walkthrough of the error, its code path and all known details is as follows:
---------------------------------------------------------------------------------------
-- Head --
Stacktrace:
	at mods.eln.item.electricalitem.PortableOreScannerItem$RenderStorage.generate(PortableOreScannerItem.kt:459)
	at mods.eln.item.electricalitem.PortableOreScannerItem.renderItem(PortableOreScannerItem.kt:243)
	at mods.eln.generic.SharedItem.renderItem(SharedItem.java:75)
	at net.minecraftforge.client.ForgeHooksClient.renderEquippedItem(ForgeHooksClient.java:220)
	at net.minecraft.client.renderer.ItemRenderer.renderItem(ItemRenderer.java:80)
	at net.minecraft.client.renderer.ItemRenderer.func_78440_a(ItemRenderer.java:499)
	at net.minecraft.client.renderer.EntityRenderer.func_78476_b(EntityRenderer.java:736)
	at net.minecraft.client.renderer.EntityRenderer.func_78471_a(EntityRenderer.java:1361)

[jrddunbr]

Yeah, it looks like that line of code casts to an unsigned byte. That's not going to work, and I don't think we're updating that.

This version of the mod is no longer going to be supported with major code changes, so you're not going to get support at this point; we're working on (hopefully!) MC 1.15.2 as our next version.

As an aside, it's relatively uncommon that you have that many blocks/items in the game. In games where that is the case, Electrical Age is probably not the best choice for a large pack, since if you run a server with more than 5 people and really capitalize on using Eln, you will need a beefy server to handle the load. We've run official servers in the past, and they required high clocking i7's and i9's to perform well with 10+ people on them with large megawatt scale grids.

[JalapenoPepper]

So, no 1.12.2 version, right?( That's really sad,because other many good and interesting mods are not going to be updated to 1.12+ versions, aside from ELN. And yes, I'm using a private server( Intel Xeon E5603, and unfortunately it lags) with my friends, 120 mods in total Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

…

On Tuesday, 21 July 2020 г., 17:28, Jared Dunbar ***@***.***> wrote: Yeah, it looks like that line of code casts to an unsigned byte. That's not going to work, and I don't think we're updating that. This version of the mod is no longer going to be supported with major code changes, so you're not going to get support at this point; we're working on (hopefully!) MC 1.15.2 as our next version. As an aside, it's relatively uncommon that you have that many blocks/items in the game. In games where that is the case, Electrical Age is probably not the best choice for a large pack, since if you run a server with more than 5 people and really capitalize on using Eln, you will need a beefy server to handle the load. We've run official servers in the past, and they required high clocking i7's and i9's to perform well with 10+ people on them with large megawatt scale grids. — You are receiving this because you authored the thread. Reply to this email directly, [view it on GitHub](#954 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AOXGF4TJRRXC6T64VPCPTJ3R4WQXPANCNFSM4OJMBHHQ).

[jrddunbr]

Yeah, well if Forge would support the previous popular versions they made, then we would use 1.12, and even update 1.7.10! But they don't want to support 1.12 anymore, so we have to develop for new versions. Life sucks man, but I am not going to be a masochist and write code for a platform that isn't supported. This project is big enough as it is. Much as I may dislike it, we need to build on the work that Forge has done and use versions they support. If you can get them to support 1.12 dev in a modern development environment, then sure, we'll build a version for it. And there's certainly no reason that someone else couldn't do it once we've got ourselves to 1.16. Either way, we're redoing the entire codebase from the ground up, and we're not re-utilizing the old code in the new version for many good reasons.