Jump to content

wehttam664

Members
  • Posts

    25
  • Joined

  • Last visited

Everything posted by wehttam664

  1. If I use the simulated InventoryCrafting, "where they already are" is the first nine slots (no matter where the grid they used to be), leading to the issue I described.
  2. I originally tried this, but the issue because immediately apparent after the crafting completed. There's no real way to distinguish where on the grid the "remaining items" should be placed, and they usually just get placed in the first 9 slots (with is not the upper left 3x3, but rather the first row of five then four from the second row). The "remaining items" do work off the given inventory size and faking it a 3x3 causes it to behave incorrectly. Trying to avoid this, as copying recipes out of the vanilla manager tends to leave several mod recipes behind, since Forge loads mods that do not depend on one-another in a pretty random (and inconsistent) order and I miss recipes loaded after my mod. I'm starting to like the idea of patching this class more and more, but I'm not entirely sure how to do so.
  3. It appears the image's alpha is being raised to 1 above a certain threshold. Taking a look at the pumpkin blur code in net.minecraft.client.gui.GuiIngame, the major difference in yours versus the pumpkin (which appears to have functional alpha transparencies from the image), is that "depth" and "alpha" are being disabled, and the depth mask flag is set to false before drawing the image. It also appears to be using the blend function differently. Here's what I'm referring to: protected void renderPumpkinOverlay(ScaledResolution scaledRes) { // this stuff is what's different. GlStateManager.disableDepth(); GlStateManager.depthMask(false); GlStateManager.tryBlendFuncSeparate(GlStateManager.SourceFactor.SRC_ALPHA, GlStateManager.DestFactor.ONE_MINUS_SRC_ALPHA, GlStateManager.SourceFactor.ONE, GlStateManager.DestFactor.ZERO); GlStateManager.color(1.0F, 1.0F, 1.0F, 1.0F); GlStateManager.disableAlpha(); // the draw code looks like yours. this.mc.getTextureManager().bindTexture(PUMPKIN_BLUR_TEX_PATH); Tessellator tessellator = Tessellator.getInstance(); // .. tessellator.draw(); // re-enable the things you disabled. GlStateManager.depthMask(true); GlStateManager.enableDepth(); GlStateManager.enableAlpha(); GlStateManager.color(1.0F, 1.0F, 1.0F, 1.0F); } Try adding in those calls and see if that makes a difference. I know the pumpkin blur does something similar but on a smaller scale, so this may solve the issue.
  4. Long story short, I've got a 5x5 crafting grid that I want to be able to handle 3x3 recipes, much like how 3x3 grids can take 2x2s. The 3x3 recipes work, but only in the upper left 3x3 of the grid, and it seems to completely ignore any items in the remainder of the 5x5, even if those items are a valid shapeless recipe, which work perfectly fine. Upon further investigation, it seems that ShapedRecipes is the only class at fault. ShapelessRecipes, ShapedOreRecipes, and ShapelessOreRecipes all behave exactly as I want them to, so I investigated and source and discovered the actual issue in the matches(InventoryCrafting, World) method. It seems that the shaped recipes class has hard-coded a 3 into the code, while the other three recipes all utilize the width and height of the given inventory. The code in question, ShapedRecipes:58: public boolean matches(InventoryCrafting inv, World worldIn) { for (int i = 0; i <= 3 - this.recipeWidth; ++i) { for (int j = 0; j <= 3 - this.recipeHeight; ++j) { // those 3's are the issue, I assume // all the other implementations use inv.getWidth() and inv.getHeight() // ... I'd like to solve this issue without going through the mess of CoreMods and ASM (primarily because I have no idea how to do that), but I don't mind doing it if I have to. Is there a solution to this?
  5. I'm trying to work with custom OBJ models for a block, but I cannot seem to get the model to render. There is absolutely no tutorials for doing this in 1.9, so I have to do a large amount of playing around by myself. I have found that I no longer need (nor can use?) a TESR, and can simply just use a ICustomModelLoader and OBJModel. I have this as my loadModel method: @Override public IModel loadModel(ResourceLocation modelLocation) throws Exception { OBJModel.MaterialLibrary materialLibrary = new OBJModel.MaterialLibrary(); materialLibrary.parseMaterials(resourceManager, "textures/blocks/crystal_seelum_block.mtl", new ResourceLocation(AuroraProjectBase.modId + ":blocks")); return new OBJModel(materialLibrary, new ModelResourceLocation(AuroraProjectBase.modId + ":block/crystal_seelum_block.obj")); } After cleaning all the lines that upset the parser from the .mtl, it appears to load without errors, but the block is invisible in-game. What am I missing here?
  6. You could technically just check entities near the block and apply a velocity vector to them whose magnitude varies with distance.
  7. I'm trying to use an IBakedModel for my block since Forge block states don't quite do what I need and it works fine in the world, but I'm not really sure how I would go about rendering it in the inventory. What do I have to do to the blockstate JSON and/or in the getQuads() method to make this work?
  8. Upon playing around a bit, I found that PropertyEnum.create(String, Class<T>) will work fine when called inside createBlockState() or in a static context, but not in object context. Basically: final static PropertyEnum<FrameType> frameTypeProperty = PropertyEnum.create("type", FrameType.class); // Works final PropertyEnum<FrameType> frameTypeProperty = PropertyEnum.create("type", FrameType.class); // Doesn't work. Any thoughts, or should I go bug report this?
  9. Now, I'm not really sure why, but for some reason PropertyEnum.create(String, Class<T>) is returning null. This is what I have: final PropertyEnum<FrameType> frameTypeProperty = PropertyEnum.create("type", FrameType.class); // ... @Override protected BlockStateContainer createBlockState() { System.out.println(frameTypeProperty); return new BlockStateContainer(this, frameTypeProperty); } The console has null printed to it then the game crashes on an NPE in BlockStateContainer:99. Why is it null?
  10. Somehow I am surprised I did not see that one line up from mcDefaultResourcePack. Sometimes it takes a second pair of eyes, I guess. Thank you, I'll play around with that.
  11. I'm trying to do a number of things with the game's Languages and I found that resource packs are fully capable of doing what it is I need to do. However, I need to ensure this pack is activated at start and cannot be deactivated, much like the DefaultResourcePack loaded by Minecraft. I chased the loading of such down to ResourcePackRepository and spotted the setRepositores(List<Entry>) method, but the entry it accepts is not publicly accessible. func_188565_b() appears to get an Entry from the last call to setResourcePackInstance(File), but that method accepts a file. While I'm not above reflection, I'd like to avoid it if possible. Is there a way to inject a permanent resource pack?
  12. For a few different reasons, I wanted to try adding another language to the game that Forge can find the associated lang files in mods. I noticed the constructor for Language is public, but I don't know where to put the resulting object. At the moment I'm reflecting the LanguageManager, and, as with most reflection, it feels dirty and unsafe. Is there an actual way to do this?
  13. I'm not really sure why, but for some reason my block is having its texture culled when it really shouldn't. I'm using forge blockstates for a block that uses minecraft:farmland as a model under a certain condition, replacing the #top and #dirt textures. Noteably, the model is being culled on all non-top faces despite a block not being present next to them. While normal farmland is not affected by this, my block is. I confirmed it was a culling issue after copying the model and removing the `cullface` key, wherein the model rendered fine. What's going on here?
  14. This is the Vanilla implementation of ItemSeeds#getPlant: public IBlockState getPlant(IBlockAccess world, BlockPos pos) { return this.crops.getDefaultState(); } Where this.crops is assigned from the first parameter of the constructor. In your case, it is somehow null. Ensure your crop variable is not null when your seed's constructor is called or override the method to return your own state.
  15. The TileEntity class already has methods for this. For server-bound, try getDescriptionPacket and for client-bound use onDataPacket. Example Implementation: @Override public Packet<?> getDescriptionPacket() { NBTTagCompound tagCompound = new NBTTagCompound(); writeToNBT(tagCompound); return new SPacketUpdateTileEntity(pos, 1, tagCompound); } @Override public void onDataPacket(NetworkManager net, SPacketUpdateTileEntity pkt) { // TODO update stuffs from packet. super.onDataPacket(net, pkt); }
  16. As a result of being unable to use Forge blockstates for all variants of my model (3*(2^21) combinations later...), I've now gone to use an implementation of IBakedModel as demonstrated in TheGreyGhost's mbe05 example. While I realize I could make a model for each rotation, is there a way to rotate an IModel before or during the baking process? I'd like to rotate it or its quads as opposed to 20-something different models, so is there a way to do this?
  17. I've looked through that. Each sub-model needs its own property since each individual model can either be there or not independent of the others. I've decided to go with a custom IBakedModel implementation for those parts since I figured out how to get the TileEntity into the bake method. That works better and doesn't cause load times to skyrocket.
  18. Turned out the block was already updating on neighbor change, assuming the neighboring TileEntity changed as well, which it wasn't for some reason. I solved the issue after discovering this and making sure the tile entity is removed on break.
  19. I'm currently trying to work with the forge block states to create a block model, but it has become evidently clear by the game's startup time I need to do it a better way. I'm trying to render a number of different pieces with the system: 8 corners, 4 pillars, 8 bars, and a core can all be there or not plus the core has an int property ranging from 0-2. This totals the number of possible combinations (and thus the number of models loaded by the bakery) to 3*(2^21), which is just under 6.3 million possible combinations. This is obviously not acceptable. Is there a better way to do this?
  20. I have a block that only seems to update its block state when placed, but the state is dependent on the blocks around it. I need the block to update its block state (i.e. call getActualState) when a neighboring block changes (plus once when the block is loaded). I need it to be in the vanilla block state for use with models, so I can't used the IExtendedBlockState class. The block has a TileEntity if that is of help. Any way to do this?
  21. That will work a whole lot better, thank you. Question now is can models be parented to these forge blockstate variants, or do I have to do a lot redundant typing?
  22. I need that many combinations. 2 from the possibility of a side having a panel on or off. 6 from each of the six sides. 16 possible panels (including no panel). I may have done the math wrong, but it's still a ridiculous number of combinations for the block. No matter the number of combinations, I do need this solved...
  23. I'm relatively new with using custom BakedQuads, but, rather than make 2^6^16 combinations of block states for rendering, I figured it was an easier method. I cannot, however, get them to render the correct way. No matter what I do to the numbers, the texture is displayed facing downward. I have a the following inside of IBakedModel#getQuads override. TextureAtlasSprite texture = ItemPanel.getTextureOf(panelUp); int color = Color.WHITE.getRGB(); quads.add(new BakedQuad(Ints.concat( vertexToInts(1/16f , 15/16f, 1/16f , color, texture, 0 , 0 ), vertexToInts(15/16f, 15/16f, 1/16f , color, texture, 16, 0 ), vertexToInts(15/16f, 15/16f, 15/16f, color, texture, 16, 16), vertexToInts(1/16f , 15/16f, 15/16f, color, texture, 0 ,16) ), 0, EnumFacing.UP, texture, false, format)); vertexToInts: public static int[] vertexToInts(float x, float y, float z, int color, TextureAtlasSprite texture, float u, float v) { return new int[] { Float.floatToRawIntBits(x), Float.floatToRawIntBits(y), Float.floatToRawIntBits(z), color, Float.floatToRawIntBits(texture.getInterpolatedU(u)), Float.floatToRawIntBits(texture.getInterpolatedV(v)), 0 }; } All other quads come from baked model components and render fine. Why is this texture facing down? It seems the EnumFacing parameter in BakedQuad.<init> does nothing (I tried other values), so what am I doing wrong? EDIT: This issue also happens with EAST- and NORTH-sided panels facing WEST and SOUTH respectively.
  24. If you're extending BlockTorch and just doing setCreativeTab(null) isn't working, try overriding getCreativeTabToDisplayOn and returning null instead. @Override public CreativeTabs getCreativeTabToDisplayOn() { return null; } Not the best way to do it, but it works.
×
×
  • Create New...

Important Information

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