Jump to content

weckar

Forge Modder
  • Posts

    62
  • Joined

  • Last visited

Everything posted by weckar

  1. Uhm, okay. I got that last bit. Makes sense. Rendering != Logic. I've been looking for tutorials, but they all go into much more complicated things, while all I want to do is render a block! They also all directly seem to call out the opengl library without much explanation of what any of the calls actually mean. ...Maybe I'm trying to do too much... Apologies if I'm trying anyone's patience too much.
  2. But I thought TESR was still called on update? This code would otherwise work on a TESR extension? EDIT: After moving the code over to a TESR extension AND registering (I confirm through the log that the code runs), it is still invisible.... Current code block: public class RenderBox extends TileEntitySpecialRenderer{ private RenderBlocks renderer = new RenderBlocks(); @Override public void renderTileEntityAt(TileEntity tileentity, double x, double y, double z, float f) { LogHelper.info("RENDERING BOX!"); renderer.blockAccess = tileentity.getWorldObj(); renderer.renderBlockAllFaces(Blocks.glass, (int)x, (int)y, (int)z); } }
  3. So, as an experiment I thought I'd try to make the most basic possible rendering Tile Entity. It took a bit to get error free (for whatever reason blockAccess was never set in the RenderBlocks no matter what I gave to the constructor), but even now that it is it doesn't actually seem to render anything... For info: TEBase most only consists of a method to split the updateEntity method into a server and client version. public class TEBox extends TEBase{ private RenderBlocks renderer = new RenderBlocks(); @Override void updateClient(World world, int x, int y, int z) { renderer.blockAccess = world; renderer.renderBlockAllFaces(Blocks.glass, x, y, z); } } Is there anyone who can see anything blatantly wrong here, or otherwise correct my course to what I should be doing instead?
  4. Here's a question: Does your fluid also have this effect on vanilla blocks, or only your own blocks? The usual cause for this problem is not overriding isOpaqueBlock, but I see you did do that. If the issue were in not drawing all the sides of the fluid instead of another block I would have suggested looking at canRenderInPass(1), but I don't really think that would help here. More information on specifics of the problem - maybe a screenshot or two or example cases? - could really help you help us help us all.
  5. Upon a first read I don't see anything wrong with the code, so a crash log could probably help us out. I do have to ask why you are casting the tile entity when both classes possess the same method that you are giving identical calls? Or will these sections be differentiated more later?
  6. You could register the current health at the point where the regen should be disabled. From there on, override that value whenever it goes down, and override the health with that value whenever it goes up. Not a perfect solution, but it should cover most cases.
  7. If you need to do this in a method where you already have the player entity and the world as parameters, it is rather easy. I forget the exact method called (away from IDE), but if your IDE has a code suggestion feature check the world object for a method that contains the word 'sky'. There should be a method that checks whether a certain object can see the sky based on blocks above it. Put in the coordinates of your player, and this should tell you whether there is anything above it.
  8. Possible. Centralized registration does allow for easier referencing later, I find. It's a balancing act, to be sure...
  9. I prefer to keep things encapsulated where they belong as much as possible. Thanks for the idea though.
  10. THAT.... is an awfully good point. A post-registration init method instead of the constructor. I feel silly now... Thanks!
  11. You mean through GameRegistry.registerBlock? I do that... Unless I'm also supposed to register it elsewhere?
  12. Hi there, I was just trying to make a wood variant, and wanted to have it be burnable. By the new standards, I went and used Blocks.fire.setFireInfo. Unfortunately, rather than making an instance of FireInfo, it tries to use the getIdFromBlock array approach (which is even indicated as deprecated, but there is no check to skip to the newer implementation). Because of this, I get an ArrayIndexOutOfBounds as the getIdFromBlock of course returns -1. Am I just overlooking some detail here? All help is appreciated.
×
×
  • Create New...

Important Information

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