search

Blood-Asp / GT5-Unofficial

Decompiled and modified version of GT5.07.07
160 stars 97 forks source link

[5.09.32-pre4] Stone bound ores generates in GT Black Granite and Marble. #1453

Open leagris opened 6 years ago

leagris commented 6 years ago

Stone bound ores generates in Black Granite and GT Marble. No network packet issue since updating block does not fix. Still remains stone bound.

MauveCloud commented 3 years ago

I think this is essentially the same as #1245 Also, I might have at least figured out why it happens: looking at https://github.com/Blood-Asp/GT5-Unofficial/blob/45373ba84714303a92002bad159490dbf25f81d6/src/main/java/gregtech/common/blocks/GT_TileEntity_Ores.java#L149-L178 it seems that when a section of black granite, GT marble, etc. generates into a vein (instead of the other way around), it tries to replace the substrates, but if I'm reading that code correctly, it sets the substrate by checking for plain stone, netherrack, granite, marble, etc. However, by the time that method is called from GT_Worldgen_Stone, the block will be GregTech_API.sBlockOres1, and none of the conditions tested will be true.

Edit: I was reading the code wrong, the conditions for checking the substrate were appropriate after all - the real issue here is the blockType==null check. As far as I can tell, that member variable only gets set if getBlockType is called on the TileEntity, which presumably only happens during rendering, since it's a client-side function. No other class in GregTech does anything with blockType, and once I changed the methods to no longer rely on it (in my local copy of the source code), preliminary testing looks good.

Edit 2: Small clarification/self-nitpick: TileEntity.getBlockType is not client-side by annotation, but the deobfuscated code generated by ForgeGradle for it includes a comment claiming it is client-only.