Jump to content

TheGreyGhost

Members
  • Posts

    3280
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by TheGreyGhost

  1. Hi That's curious because in the 1.7.2 version I have, ChunkProviderHell initialises that array to be 32768 Block[] ablock = new Block[32768]; I gather that your two blocks are being allocated an ID > 4068, presumably < 32768. So why is the caller to your function providing a Blocks array of only 4068 instead of 32768? If you can figure that out you might get a step closer to the underlying problem. I do remember something about 1.6.4 you couldn't use ores with an ID greater than 255 in the generators. Perhaps this is something similar? Pure guesswork unfortunately... -TGG
  2. Hi This link might help http://greyminecraftcoder.blogspot.com.au/p/list-of-topics.html (The Item Rendering sections). -TGG
  3. Hi This class might be of interest to you https://github.com/TheGreyGhost/SpeedyTools/blob/Working/src/speedytools/common/Utilities/OpenGLdebugging.java I've used it in the past to check what the OpenGL settings are; it's not complete, but dumpAllIsEnabled() works and has showed up problems for me before- dump for a good render, dump for a bad render, and spot the difference. -TGG
  4. Hi DieSieben Are you sure about that? If I look through the code in BlockFire.onUpdate I see Block base = Block.blocksList[par1World.getBlockId(wx, wy - 1, wz)]; boolean blockBelowIsFireSource = (base != null && base.isFireSource(par1World, wx, wy - 1, wz, par1World.getBlockMetadata(wx, wy - 1, wz), UP)); if (!this.canPlaceBlockAt(par1World, wx, wy, wz)) { par1World.setBlockToAir(wx, wy, wz); } and public boolean canPlaceBlockAt(World par1World, int wx, int wy, int wz) { return par1World.doesBlockHaveSolidTopSurface(wx, wy - 1, wz) || this.canNeighborBurn(par1World, wx, wy, wz); } i.e. so long as the block below isFireSource() and has a doesBlockHaveSolidTopSurface, it should sustain a fire above it, even if the other burn properties are not used? @Thornack Odd. Try putting the breakpoint into BlockFire.updateTick() and then use your flint to light the top of the block. Then trace through to see why it doesn't call your Block's method. -TGG
  5. Hi The code from Block.isFireSource() certainly looks like it should do the trick /** * Currently only called by fire when it is on top of this block. * Returning true will prevent the fire from naturally dying during updating. * Also prevents firing from dying from rain. * * @param world The current world * @param x The blocks X position * @param y The blocks Y position * @param z The blocks Z position * @param metadata The blocks current metadata * @param side The face that the fire is coming from * @return True if this block sustains fire, meaning it will never go out. */ public boolean isFireSource(World world, int x, int y, int z, int metadata, ForgeDirection side) { if (blockID == Block.netherrack.blockID && side == UP) { return true; } if ((world.provider instanceof WorldProviderEnd) && blockID == Block.bedrock.blockID && side == UP) { return true; } return false; } Have you tried public class BlockCampfire extends BlockContainer { [..] @Override public boolean isFireSource(World world, int x, int y, int z, ForgeDirection side) { return (side == UP); } When you light a fire on top of the campfire block using flint and steel, it should call your isFireSource. @Spaceboot1: > but for some reason I can't override them in my modblock class. .. that means you must be doing something wrong because there's nothing special about those methods. Show your code? -TGG
  6. Hi Out of curiosity I had a look. It appears that the recipes are sorted in such a way to make sure that the most specific recipes gets matched first. Shaped before Shapeless, for example. The sorting algorithm is interesting, I suspect cpw wrote it like that because he wanted to try out a topological sorting algorithm for the fun of it -TGG
  7. Hi Looks to me like it currently does nothing, it appears to be intended for when you are calling a function which needs a Player, but you don't have one. "FakePlayers should be used for server side interaction with the world on a player's behalf, not for client rendering." "If there is no player available, the FakePlayer class can be used. To grab a fake entityplayer, you will need to call FakePlayer.get(world, "playername"). It is expected to pass a real player name in this method so protection mods can handle the event correctly." -TGG
  8. Hi Your render code should go into your TileEntitySpecialRenderer for your TileEntity: the renderTileEntityAt for your TESR should call a "whatIsMyDisplayedItem()" method on the TileEntity to retrieve the Item being displayed, then render the displayed item. Your block.onBlockActivated should retrieve the TileEntity at that location (World.getBlockTileEntity) and call your "changeDisplayedItem()" method on it. Later, when the TESR calls whatIsMyDisplayedItem(), it will then receive the new Item. Do you know how to register your TileEntity and TESR? Also, if you want the TileEntity to remember your displayed item after saving & reloading the world - the NBT functions readFromNBT and writeToNBT? -TGG
  9. Hi Based on RendererLivingEntity.doRenderLiving, it appears to be float f2 = this.interpolateRotation(par1EntityLivingBase.prevRenderYawOffset, par1EntityLivingBase.renderYawOffset, par9); float f3 = this.interpolateRotation(par1EntityLivingBase.prevRotationYawHead, par1EntityLivingBase.rotationYawHead, par9); [..] this.rotateCorpse(par1EntityLivingBase, f4, f2, par9); [..] this.renderModel(par1EntityLivingBase, f8, f7, f4, f3 - f2, f5, f6); Just a guess, haven't tried it myself. -TGG
  10. Hi Two things i) the error is because onBlockActivated is called on the server as well as the client. in onBlockActivated, use par2World.isRemote() to tell the difference. ii) putting the render code into onBlockActivated is not going to do what you want. your render code will get called every time the block (TileEntity) is rendered. onBlockActivated is only called once. your onBlockActivated needs to update your TileEntity with the new item, so that when the renderer for TileEntity is called, it displays the item you clicked. I suggest you get the rendering working first and worry about the onBlockActivated later. -TGG
  11. Hi To be honest, I don't think you need to do all of that manually since vanilla does it for you, and handles all the special cases too (eg items which are 3D, items which have multiple render passes (eg potions) etc.) Step (1) create an EntityItem from your item EntityItem entityitem = new EntityItem(world, xPosition, yPosition, zPosition, itemStack); Store it somewhere (in your TileEntity), don't spawn it Step (2) in your TileEntitySpecialRenderer for the TileEntity, render the EntityItem renderItem.doRender(itemStack, xPos, yPos, zPos, 0, partialTick); where renderItem is a RenderItem() you have created and stored previously, and partialTick should be available from your TESR method, otherwise set it to 0. Step (3) in your tileEntity.updateEntity(), animate the item entityItem.age++; There are several tutorials around on how to create TileEntity and TileEntitySpecialRenderer, if you're not sure how to do that. You may need to set up some of the lighting configurations / OpenGL settings before the call to the doRender, but we can cross that bridge when we come to it -TGG
  12. Hi I don't see any obvious problem there. Perhaps you have accidentally made your three icon files the same? Have you given your block a name? I would suggest you put a breakpoint into getIcon to see whether it gets called with different side values and returns the correct icon. This should give you a clue to eliminate a bunch of possible causes. Alternatively @Override public IIcon getIcon(int side, int metadata) { IIcon retval = side == 1 || side == 0 ? this.topIcon : (side == 4 ? this.bottomIcon : this.blockIcon); System.out.println("Side: " + side + " = " + retval); return retval; } As a general rule it's a good idea to put @Override before methods you are trying to override from a base class, can help pick up subtle mistakes. -TGG
  13. Hi GuiIngameModOptions might give you somewhere to start, it uses a scrolling list and has meaningful field & method names -TGG
  14. Hi From a rendering point of view, vanilla does this already when you drop items- creates an EntityItem. You could use a TileEntitySpecialRenderer for the block which holds its own EntityItem (so that the player can't pick it up) and renders it. -TGG
  15. I would say - it looks fine. If it works, leave it like that. I think it works because the order of object creation is now correct, i.e. the BiomeGenBase are initialised before you use them. If you really want to move them, you need to make sure that they are not null when you use them. You could consider an initialisation-on-first-use method if you're having trouble, i.e. check if it is null (never used before) and if so, initialise them. But honestly, unless you're making a complicated mod I wouldn't bother. -TGG
  16. Hi I suggest - delete one or two at a time, try to run it, if you get an error, add it back. -TGG PS @f1rSt1kChannel - I did....
  17. Hi When bits of my models disappear like this, it has usually been because back face culling has been turned on and some of my faces have been pointing the wrong way. If you walk to the other side of your model (or inside ), can you see the faces from the other side? If so, there's probably something wrong in your model or your export, so the faces are pointing the wrong way (some information on that here: http://greyminecraftcoder.blogspot.com.au/2013/08/the-tessellator.html http://www.opengl.org/wiki/Face_Culling ) If this is the problem, there are two ways to fix it - fix the model, or - turn off back face culling. Since your shape is solid, you'll normally never see the inside, so this won't matter. GL11.glPushAttrib(GL11.GL_ENABLE_BIT); // save the settings GL11.glDisable(GL11.GL_CULL_FACE); // do your render stuff GL11.glPopAttrib(); // restore the settings -TGG
  18. Oh yeah, you're right, I missed that, sorry {facepalm} I can't be of much help then; perhaps you could step through WaveFrontObject.loadObjModel and see why it gets upset. It is looking for a pattern that matches this private static Pattern groupObjectPattern = Pattern.compile("([go]( [\\w\\d]+) *\\n)|([go]( [\\w\\d]+) *$)"); http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html The wavefront files I'm familiar with just have one word after the g. You could try deleting the word Model, or replace it with a single character, and seeing if it works. -TGG
  19. Hi My guess is that it's probably this issue, if your wavefront object has numbers in it without a decimal point, it doesn't like it. https://github.com/MinecraftForge/MinecraftForge/pull/1043 and http://www.minecraftforge.net/forum/index.php/topic,15954.msg80870.html#msg80870 -TGG
  20. I've assumed that he/she has (wisely) decided to refactor RenderArcanaThrowable since posting the code -TGG
  21. Hi So my train of thought on this 1) One of the variables on this line is null and a method is being called on it IIcon icon = this.item.getIconFromDamage(this.meta); --> There is only one possibility (item) since this can't be null. 2) Why is this.item null? It is being set in the constructor public RenderArcanaThrowable(Item par1Item, int par2) { this.field_94151_a = par1Item; this.field_94150_f = par2; } 3) The constructor is being called here RenderingRegistry.registerEntityRenderingHandler(EntityDanmaku.class, new RenderArcanaThrowable(ArcanaModBase.danmaku, 1)); so it appears that ArcanaModBase.danmaku is null 4) Why is that null? danmaku = (ItemDanmaku)Item.itemRegistry.getObject("danmaku"); Perhaps this call is failing, perhaps it is being called after the registryEntityRenderingHandler, or perhaps it is not the same variable as ArcanaModBase.danmaku At this point I would either use a breakpoint (if you know how to do that) or alternatively insert a System.out.println("danmaku is null:" + (danmaku == null)); // or parItem1 == null or this.item == null as appropriate into a couple of your methods, i.e. in the constructor, just after getObject("danmaku"), etc Once you've narrowed that down, you can keep troubleshooting in the same way until you get to the root cause. If you get stuck again, let us know? -TGG
  22. Hi The problem appears to be that you've put your call to the handler outside of any method. And a lot of your code is in the class constructor but it should be in preInit, postInit. This link might help http://greyminecraftcoder.blogspot.com.au/2013/11/how-forge-starts-up-your-code.html If you're just new to Java, this thread might be of interest http://www.minecraftforge.net/forum/index.php/topic,16784.msg84954.html#msg84954 and http://www.minecraftforge.net/forum/index.php/topic,19694.msg99530.html#msg99530 -TGG
  23. Hi You could use the tessellator directly, to draw your liquid level. It's a cube, I presume? Eg see here http://greyminecraftcoder.blogspot.com.au/2013/08/the-tessellator.html Just change (eg) the top z coordinates to draw the amount of liquid you need. There are also various OpenGL commands that let you add clipping planes when you draw, never done that myself but it doesn't look too hard. This guide to OpenGL is pretty useful http://www.glprogramming.com/red/ -TGG
  24. Ah, yeah so it is. I have them swapped in my helper function for some reason, sorry about that. I'm guessing then that your block is always being placed with metadata 0. Have you registered the Blocks correctly? i.e. are you using ItemBlockWithMetadata, not just ItemBlock? (or alternatively - your own Item extend ItemBlock overriding getMetadata() )? -TGG
×
×
  • Create New...

Important Information

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