Fix oredict for stairs, doors, and fence gates - #104
Conversation
|
Do the logs have logWood? I remember one of the extra trees woods didn't complete the logWood task for one of the starting quests. |
Yep, the logs does have logWood. |
| } | ||
|
|
||
| public static ItemStack getStair(IPlankType plankType) { | ||
| return TileEntityMetadata.getItemStack(ExtraTrees.blockStairs, getPlankTypeIndex(plankType) - 32); |
There was a problem hiding this comment.
The - 32 offset is only correct for ExtraTreePlanks. PlankType.setup() registers Vanilla at ordinal(), ExtraTrees at ordinal() + 32, Forestry at ordinal() + 128 and ExtraBiomes at ordinal() + 192, and BlockETStairs.getIcon does the inverse meta + 32, so this helper silently returns a wrong metadata for every plank family other than ExtraTreePlanks.
Also worth noting that getPlankTypeIndex clamps with Math.max(index, 0), so an unregistered type falls through to -32 instead of failing. Narrowing the parameter to PlankType.ExtraTreePlanks would turn misuse into a compile error.
| for (IPlankType forestryPlanks : PlankType.ForestryPlanks.VALUES) { | ||
| OreDictionary.registerOre("doorWood", WoodManager.getDoor(forestryPlanks, DoorType.STANDARD)); | ||
| OreDictionary.registerOre("fenceGateWood", WoodManager.getGate(forestryPlanks)); | ||
| OreDictionary.registerOre("stairWood", WoodManager.getStair((forestryPlanks))); |
There was a problem hiding this comment.
ExtraTrees stairs only exist for ExtraTreePlanks: BlockETStairs.getSubBlocks iterates ExtraTreePlanks.VALUES, and the stair recipe further down (line 123) is ExtraTreePlanks only. Forestry indices are 128..156, so this registers stairWood entries with metadata 96..124, which are not real items.
Both stair render paths index ExtraTreePlanks.VALUES (length 35) by raw item damage: ItemETStairs.getIconFromDamage and StairItemRenderer. Rendering one of those stacks, for example when browsing the stairWood entry in NEI, throws ArrayIndexOutOfBoundsException.
| for (IPlankType vanillaPlanks : PlankType.VanillaPlanks.VALUES) { | ||
| OreDictionary.registerOre("doorWood", WoodManager.getDoor(vanillaPlanks, DoorType.STANDARD)); | ||
| OreDictionary.registerOre("fenceGateWood", WoodManager.getGate(vanillaPlanks)); | ||
| OreDictionary.registerOre("stairWood", WoodManager.getStair((vanillaPlanks))); |
There was a problem hiding this comment.
Vanilla indices are 0..5, so getStair returns -32..-27 here. TileEntityMetadata.getItemStack rejects the negative value and stores it in the NBT meta tag instead, leaving item damage 0. The result is six copies of Fir stairs carrying a bogus meta tag, all added to stairWood.
| for (IPlankType plank2 : PlankType.ExtraTreePlanks.VALUES) { | ||
| OreDictionary.registerOre("plankWood", plank2.getStack()); | ||
| OreDictionary.registerOre("doorWood", WoodManager.getDoor(plank2, DoorType.STANDARD)); | ||
| OreDictionary.registerOre("fenceGateWood", WoodManager.getGate(plank2)); | ||
| OreDictionary.registerOre("stairWood", WoodManager.getStair((plank2))); | ||
| } | ||
|
|
||
| for (IPlankType forestryPlanks : PlankType.ForestryPlanks.VALUES) { | ||
| OreDictionary.registerOre("doorWood", WoodManager.getDoor(forestryPlanks, DoorType.STANDARD)); | ||
| OreDictionary.registerOre("fenceGateWood", WoodManager.getGate(forestryPlanks)); | ||
| OreDictionary.registerOre("stairWood", WoodManager.getStair((forestryPlanks))); | ||
| } | ||
|
|
||
| for (IPlankType vanillaPlanks : PlankType.VanillaPlanks.VALUES) { | ||
| OreDictionary.registerOre("doorWood", WoodManager.getDoor(vanillaPlanks, DoorType.STANDARD)); | ||
| OreDictionary.registerOre("fenceGateWood", WoodManager.getGate(vanillaPlanks)); | ||
| OreDictionary.registerOre("stairWood", WoodManager.getStair((vanillaPlanks))); | ||
| } |
There was a problem hiding this comment.
The three loops cover ExtraTrees, Forestry and Vanilla, but BlockETDoor.getSubBlocks and BlockGate.getSubBlocks also include ExtraBiomesPlank when that mod is loaded, so those doors and gates still end up without oredict.
WoodManager.getAllPlankTypes() returns exactly these three sets plus ExtraBiomes when active. Using it for the door and gate registration would cover that case and keep the block in sync with getSubBlocks.
| GameRegistry.addSmelting(ExtraTrees.blockLog, new ItemStack(Items.coal, 1, 1), 0.15f); | ||
| for (IPlankType plank2 : PlankType.ExtraTreePlanks.VALUES) { | ||
| OreDictionary.registerOre("plankWood", plank2.getStack()); | ||
| OreDictionary.registerOre("doorWood", WoodManager.getDoor(plank2, DoorType.STANDARD)); |
There was a problem hiding this comment.
Only DoorType.STANDARD is registered, while SOLID, DOUBLE and FULL are craftable too (see the recipes in postInit). Was that deliberate? A recipe accepting doorWood has no obvious reason to reject the solid variant.
|
|
||
| for (IPlankType vanillaPlanks : PlankType.VanillaPlanks.VALUES) { | ||
| OreDictionary.registerOre("doorWood", WoodManager.getDoor(vanillaPlanks, DoorType.STANDARD)); | ||
| OreDictionary.registerOre("fenceGateWood", WoodManager.getGate(vanillaPlanks)); |
There was a problem hiding this comment.
getGate(VanillaPlanks.OAK) returns new ItemStack(Blocks.fence_gate), so this re-registers the vanilla fence gate under fenceGateWood. Harmless, but redundant.
3 participants
Summary
Fixes GTNewHorizons/GT-New-Horizons-Modpack#25846
Added doorWood to all Forestry and Extra Trees planks variant of doors, Added stairWood to all available variants of planks stair, Added fenceGateWood to all available variants of planks fence gate.
Checklist