Jump to content

Yoyoness_

Members
  • Posts

    8
  • Joined

  • Last visited

Converted

  • Gender
    Male

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Yoyoness_'s Achievements

Tree Puncher

Tree Puncher (2/8)

0

Reputation

  1. But the issue is that the Gui class getting the wrong value from the TileEntity's fields when the field information is sent to the listeners from the Container class (the portion of code that is commented out). I'm just wondering why this is happening. I've attached a picture of what the values are when that code is commented out, so I know that's the issue.
  2. Alright, noted on the first point, but the issue isn't the fact that Java is doing integer division. Like I said, it works properly when that section of code is commented out. currCookTime is being multiplied by the amount of pixels before it is divided by totalCookTime, so it will return the proper value if given the proper values. The issue lies elsewhere.
  3. So whenever the code I have commented out below is not commented out, the progress bar of the furnace will be completely filled while it's smelting, no matter what the progress is. However removing this code makes the progress bar work properly. //This method is located in the ContainerNetherForge class @Override public void detectAndSendChanges() { super.detectAndSendChanges(); for (int i = 0; i < this.listeners.size(); i++) { IContainerListener listener = (IContainerListener)this.listeners.get(i); // if (this.cookTime != this.tileEntity.getField(0)) // listener.sendWindowProperty(this, 0, this.tileEntity.getField(0)); // if (this.totalCookTime != this.tileEntity.getField(1)) // listener.sendWindowProperty(this, 1, this.tileEntity.getField(1)); this.cookTime = this.tileEntity.getField(0); this.totalCookTime = this.tileEntity.getField(1); } } I checked to see if the values being sent to the listener were correct, and they were. In fact, all the values in both the TileEntity and Container classes remain correct, at least on client side. The furnace operates properly, the problem is only the animation. The issue is in this method. The calls to getField aren't returning the values they should be (and yes, the field IDs are correct, I checked at least 10 times). I provided a screenshot of the console to show the values that are being passed to the method. //This method is located in the GuiNetherForge class private int getCookProgressScaled(int pixels) { int currCookTime = this.tileEntity.getField(0); int totalCookTime = this.tileEntity.getField(1); System.out.println("Current cook time: "+this.tileEntity.getField(0)); System.out.println("Total cook time: "+this.tileEntity.getField(1)); if (totalCookTime != 0 && currCookTime != 0) { return currCookTime*pixels/totalCookTime; } else { return 0; } } As you can see from the values in the picture, the issue is that getCookProgressScaled(24) (which is being called in another method) will always return 24 or more. The issue is solely the values being passed to currCookTime and totalCookTime. I have no idea how listeners work, this is just how the vanilla furnace uses them. If anyone has more knowledge about listeners and why this might be happening, please let me know. - Yoyo
  4. Actually I figured it out. I have an ore that has an animated texture (I copied the lava_still.png.mcmeta, renamed it, and used a different texture), and when I generate that ore, I get massive lag. It's probably because I have it generating from y-coords 0-255 in the world with a maximum of 64 veins in each chunk for testing purposes. All of my other ores generate at the same levels, but they don't have animated textures.
  5. I was planning to put them in an ores list, but even so I tried a switch statement already and had the same issue.
  6. So I was generating ores in my world by iterating through all the blocks in my mod (there are only 5 for now, I'll make this work more efficiently in the future when there are more blocks), checking to see if they are ores, and then generating them if they are. The idea behind this is that I can add an ore to the blocks of the mod without having to go into my OreGen class and manually set how I want each ore to generate, I just need to make the ore itself. When generating 1 ore in any given dimension it works fine; the dimension loads in a few seconds, but if I generate 2 or more ores in any given dimension, the dimension takes 5+ minutes to generate, and loading new chunks takes much longer than usual once you are in the game. Does anyone with more advanced knowledge of how worldgen works know why this could be happening? Below is the code for my OreGen class: /** * Date: 02-19-2019 * Time: 5:29:29 PM * Author: Yoyoness_ */ package yoyoness_.yoyosaddons.worldgen; import java.util.Random; import com.google.common.base.Predicate; import net.minecraft.block.Block; import net.minecraft.block.state.IBlockState; import net.minecraft.block.state.pattern.BlockMatcher; import net.minecraft.init.Blocks; import net.minecraft.util.math.BlockPos; import net.minecraft.world.World; import net.minecraft.world.chunk.IChunkProvider; import net.minecraft.world.gen.IChunkGenerator; import net.minecraft.world.gen.feature.WorldGenMinable; import net.minecraftforge.fml.common.IWorldGenerator; import yoyoness_.yoyosaddons.init.ModBlocks; import yoyoness_.yoyosaddons.init.objects.blocks.BlockOre; public class OreGen implements IWorldGenerator { @Override public void generate(Random random, int chunkX, int chunkZ, World world, IChunkGenerator chunkGenerator, IChunkProvider chunkProvider) { BlockOre ore; if (world.provider.getDimension() == -1) { for (Block block : ModBlocks.BLOCKS) { if (block instanceof BlockOre && ((BlockOre)block).getDimension() == -1) { ore = (BlockOre)block; if (ore.getMinYGen() < 0 || ore.getMaxYGen() > 255 || ore.getMinYGen() > ore.getMaxYGen()) { throw new IllegalArgumentException(ore.getUnlocalizedName() + " generates at invalid y-coordinates. Must generate between y-coordinates 0-255 inclusive, with the minimum coordinate lower than the maximum."); } runGenerator(ore.getDefaultState(), BlockMatcher.forBlock(Blocks.NETHERRACK), world, random, chunkX*16, chunkZ*16, ore.getMinYGen(), ore.getMaxYGen(), random.nextInt(ore.getMaxVeinSize())+ore.getMinVeinSize(), ore.getMaxVeins()); } } } if (world.provider.getDimension() == 0) { for (Block block : ModBlocks.BLOCKS) { if (block instanceof BlockOre && ((BlockOre)block).getDimension() == 0) { ore = (BlockOre)block; if (ore.getMinYGen() < 0 || ore.getMaxYGen() > 255 || ore.getMinYGen() > ore.getMaxYGen()) { throw new IllegalArgumentException(ore.getUnlocalizedName() + " generates at invalid y-coordinates. Must generate between y-coordinates 0-255 inclusive, with the minimum coordinate lower than the maximum."); } runGenerator(ore.getDefaultState(), BlockMatcher.forBlock(Blocks.STONE), world, random, chunkX*16, chunkZ*16, ore.getMinYGen(), ore.getMaxYGen(), random.nextInt(ore.getMaxVeinSize())+ore.getMinVeinSize(), ore.getMaxVeins()); } } } if (world.provider.getDimension() == 1) { for (Block block : ModBlocks.BLOCKS) { if (block instanceof BlockOre && ((BlockOre)block).getDimension() == 1) { ore = (BlockOre)block; if (ore.getMinYGen() < 0 || ore.getMaxYGen() > 255 || ore.getMinYGen() > ore.getMaxYGen()) { throw new IllegalArgumentException(ore.getUnlocalizedName() + " generates at invalid y-coordinates. Must generate between y-coordinates 0-255 inclusive, with the minimum coordinate lower than the maximum."); } if (Math.sqrt(Math.pow(chunkX*16, 2) + Math.pow(chunkZ*16, 2)) >= 1000.0) { runGenerator(ore.getDefaultState(), BlockMatcher.forBlock(Blocks.END_STONE), world, random, chunkX*16, chunkZ*16, ore.getMinYGen(), ore.getMaxYGen(), random.nextInt(ore.getMaxVeinSize())+ore.getMinVeinSize(), ore.getMaxVeins()); } } } } } private void runGenerator(IBlockState ore, Predicate<IBlockState> blockToReplace, World world, Random random, int x, int z, int minY, int maxY, int size, int maxBlocks) { WorldGenMinable generator; int deltaY = maxY - minY; for (int i = 0; i < maxBlocks; i++) { BlockPos pos = new BlockPos(x + random.nextInt(16), minY + random.nextInt(deltaY), z + random.nextInt(16)); generator = new WorldGenMinable(ore, size, blockToReplace); generator.generate(world, random, pos); } } } Note: The data for how an ore should generate is stored in each instance of a BlockOre itself, that's why there are many calls to accessor methods from ore. I'm new to modding, so if there's a better place to store this data, please let me know. - Yoyo
  7. I'm brand new to modding, so I was recently creating my first custom recipes. I was using JSON files for shaped and shapeless crafting recipes, but I had to use the addSmelting method to make a smelting recipe. While making a smelting recipe, I found out about the methods for adding shaped and shapeless recipes. So my question is, should I use JSON files or the methods to add recipes? I have no qualms with either, but I would like to know which option is better for longevity's sake and why. Also, will smelting recipes eventually be able to be created through JSON files in later versions of Forge, because having the smelting recipes separate from the rest of the recipes is somewhat annoying. Thanks, Yoyo
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.