Crash with Super Ores
abused opened this issue ยท 2 comments
So witch Chisels n bits installed im getting a crash https://pastebin.com/9qjFVM8Q with my mod super ores. The error leads BaseOresBlock.java:51 which would be
@Override public int damageDropped(IBlockState state) { if(this.getDefaultState().getBlock() == ModBlocks.OsmiumOre && OreDictionary.doesOreNameExist("oreOsmium")) { return OreDictionary.getOres("oreOsmium").get(0).getItemDamage(); }else if(this.getDefaultState().getBlock() == ModBlocks.YelloriteOre && OreDictionary.doesOreNameExist("oreYellorite")) { return OreDictionary.getOres("oreYellorite").get(0).getItemDamage(); }else if(this.getDefaultState().getBlock() == ModBlocks.ArditeOre && OreDictionary.doesOreNameExist("oreArdite")) { return OreDictionary.getOres("oreArdite").get(0).getItemDamage(); }else if(this.getDefaultState().getBlock() == ModBlocks.CobaltOre && OreDictionary.doesOreNameExist("oreCobalt")) { return OreDictionary.getOres("oreCobalt").get(0).getItemDamage(); }else { return this.item.getMetadata(); } }
or specifically
return OreDictionary.getOres("oreOsmium").get(0).getItemDamage();
i don't see the problem on my end as it seems to be working fine without C&B so i thought it would be from your end
- MC Version: 1.12.2
- C&B Version: 14.0
- Do You have Optifine: no
If your issue is with OreDictionary.getOres("oreOsmium").get(0) that means there are no blocks registered with that dictionary name. ( since the length of the list is zero.
If your mod is registering those, I assume its registering them later then the search tree is being generated?
I could catch the crash but that would mean marking your block unsupported by C&B, I think you would be better of testing the number of ores in the array before accessing the first one in the list, so if there are zero it would crash.
I don't really have any say when I need to calculate the name of my bits, since MC decides that, so the only options I have are to catch the exception from your mod or black list your block by id so that I don't even try to support it.
I wish there was something else I could do, but my hands are pretty much tied to either of those, I think your in a much better place to resolve the issue by just doing some array length tests.
On another note,
I have to say tho, that That code looks fairly dangerous, and it seems like your block is expecting the ore dictionary to return your own item damage values when it might just as easily return another mods blocks, or some other mod might remove your blocks from the ore dictionary and then replace them with its own. Well I suppose you checking that its the right block... but....
Your block should probably be returning damage values based on some fixed state -> damage value table mappings.