TheGreyGhost

Hi dude, I think you're posting on the wrong forum. This forum is for people who are programming mods. -TGG

Hi I've sent you a private message, have a look and send me back if it doesn't answer your question -TGG

Hi two guesses: (1) perhaps you're not setting up everything you need for the lines to be visible eg the vanilla uses this before drawing the selection box around blocks (see RenderGlobal.drawSelectionBox): GL11.glDisable(GL11.GL_ALPHA_TEST); GL11.glEnable(GL11.GL_BLEND); GL11.glBlendFunc(GL11.GL_SRC_ALPHA, GL11.GL_ONE_MINUS_SRC_ALPHA); GL11.glColor4f(0.0F, 0.0F, 0.0F, 0.4F); GL11.glLineWidth(2.0F); GL11.glDisable(GL11.GL_TEXTURE_2D); GL11.glDepthMask(false); (2) perhaps the origin of the rendering coordinates is not what you think it is. The TE renderer is called with an origin corresponding to the location of the block, so translating by the player position might not put the lines in the right place, so you can't see them. -TGG

Hi The answer is in the post - i.e. you probably can't do it directly for particles, but if you turn the top of your chimney into a TileEntity or an Entity, and create a custom renderer for it that draws smoke, you will be able to see it from further away. Probably as simple as creating the appropriate EntityFX objects, storing them in your chimney object, and calling their onUpdate and renderParticle methods when the corresponding chimney object methods are called. -TGG

Hi If you're just doing an exact copy of the EntityItemFrame, you could copy/adapt the rendering code in RenderItemFrame, you would need to register your own renderer for your CheatingItemFrame. Come to think of it, since you've derived your CheatingItemFrame from EntityItemFrame, you can probably just bind RenderItemFrame to it. Worth a shot. RenderingRegistry.registerEntityRenderingHandler(CheatingItemFrame.class, new RenderItemFrame()); -TGG

yeah that's true, and in 3/4 of the cases that works fine for what I need. I'm thinking of those cases where it's more effective to modify the code to log or to see what happens if I comment out part of the code. Especially for rendering, or for code that gets executed many times and I need to break if a particular condition becomes true. I'll give the extraction idea a crack, can't be that hard surely :-)

hi all The new gradle setup for Forge has put the Forge and Minecraft sources into a library. Previously I used to edit the vanilla classes to add diagnostics etc when I was trying to figure out how the vanilla worked (or more often - why my own code didn't work). I'm hoping that I can still do this just by removing the forge jar from the library, extracting all the files into a test workspace, tweaking the build config (should be fun! have no idea about gradle), and editing them directly as in ye happy days of olde. Thoughts from people who know more about gradle and IDEA than me? -TGG

Hi you mean - items which are partially transparent (eg let 50% of the light through)? Yes it's possible. I haven't done it myself but I would suggest trying to use an IItemRenderer to add your custom rendering code for the item (turning on the appropriate alpha blending - something along the lines of GL11.glBlendFunc(GL11.GL_SRC_ALPHA, GL11.GL_ONE_MINUS_SRC_ALPHA); GL11.glEnable(GL11.GL_BLEND); The vanilla code has a few places which do this (although not for items?) A bit more info on IItemRenderers here (section on Item Rendering) http://greyminecraftcoder.blogspot.com.au/p/list-of-topics.html -TGG

Hi I'd suggest you stick with one Block per type of vine, with metadata for the growth stage. The reason I say that is because TileEntities take up a lot more memory and are significantly slower to render if you have a lot of them. They're also harder to program properly. If you're worried about keeping your code conceptually simple, you could create a base BlockMyVineBase and derive all your different types of vine from those. If you want to use the TileEntity approach, you can either render your block using a TileEntitySpecialRenderer, or alternatively (similar to your original idea), you can use an ISimpleBlockRenderingHandler, which is given the [x,y,z] when the rendering method is called. A bit more info here: http://greyminecraftcoder.blogspot.com.au/2013/07/block-rendering.html -TGG

Hi Perhaps you haven't registered the Entity properly (eg using EntityRegistry.registerModEntity)? -TGG

Hi A TileEntity will probably do what you need (with a TileEntitySpecialRenderer), alternatively an Entity spawned by your block as BrighamX suggested. These are both fairly advanced so if you're just a beginner you might find it easier to start with something a bit simpler first. Some vanilla examples are TileEntitySign (with TileEntitySignRenderer) for the TileEntity approach, and EntityHanging (for Picture frames, item frames) for the Entity approach. -TGG

Hi What do you mean bounding boxes? Do you mean the wire box that surrounds a block when you're looking at it? If so, I would suggest you register for the DrawBlockHighlightEvent, check whether the block under the cursor is your custom block, and if so render the multiple boxes yourself. (If it's not your block, revert to vanilla). If you don't know about events yet, try http://greyminecraftcoder.blogspot.com.au/2013/12/forge-techniques-events.html or http://www.minecraftforum.net/topic/1419836-131-forge-4x-events-howto/ -TGG

Hi My general advice would be "don't ignore warnings unless you understand why they're occurring and have a good reason for not fixing them". Are these errors in Forge or are they in your source code? Even though your code will run, a compiler warning will often give you a valuable clue that you have made a subtle mistake in your code and it's not going to work how you expect. resource leaks can be either trivial or very serious depending on what it is, notorious for causing subtle problems which don't show up until the code has been running for several hours or days. the casting warning might be a hint you that you are trying to pass the wrong type of variable to the function the assigning variable warning might be a clue that you have misspelled the variable or mixed it up with a different variable unreachable catch block error might mean that you have added a unnecessary catch block just for the fun of it :-), or it might be a clue that you've made an incorrect assumption about the types of errors that a function might throw. (If the warnings are in Forge code, not much you can do about that) -TGG

Hi ItemBlock line 42 is return Block.blocksList[this.blockID].getItemIconName() != null ? 1 : 0; The NPE means that blocksList[this.blockID] is null That means you haven't set up your blockID / ItemBlock IDs properly. It is trying to find the icon for your ItemBlock by looking at the corresponding block and it doesn't exist. -TGG

Hi I think it would be worthwhile to try and split the possible causes into two: (1) your FBO texture is wrong (your background is obviously correct but maybe the yellow rect isn't) vs (2) your renderBlock code isn't properly mapping the entire FBO texture to the rect that you're drawing. If you can somehow manually inspect the FBO texture that would be the most direct way, but perhaps you could also test it by drawing the yellow rect over the entire FBO, to see if your rendered rect changes to yellow (i.e. the entire rect is being textured with just one texel). Perhaps there's something subtle going on with alpha or depth values? Can't really be of much help unfortunately, I haven't got much idea about OpenGL. -TGG

Hi I couldn't navigate your code but it looks to me like you're running out of memory because the vanilla code keeps trying to find a place to spawn the player, but for some reason it can't find anywhere that doesn't collide with one of the blocks. This is odd because it keeps increasing the y value and normally it should pop out into free space, unless you're in a world with no sky. Each time it tries, it creates an AABB and if it keeps trying long enough, it runs out of heap space to store them all. Are you doing something strange with your shopStop block boundaries, minX, maxX, that sort of thing? Or have you replaced all the "air" blocks in your world with something that has a collision box? If it were me, I would add a breakpoint to here EntityPlayerMP constructor:: while (!par2World.getCollidingBoundingBoxes(this, this.boundingBox).isEmpty()) { this.setPosition(this.posX, this.posY + 1.0D, this.posZ); } and trace through getCollidingBoundingBoxes to see why it always finds a colliding box even though the y position is repeatedly incremented. -TGG

Hi Is there some way you can "inspect" your FBO to make sure it contains the correct texture? Apart from that - Although I don't know much about OpenGL, I'm suspicious of this bit in renderBlock glBegin(GL_QUADS); glVertex3f(1f, 0f, 0f); glVertex3f(0f, 0f, 0f); glVertex3f(0f, 1f, 0f); glVertex3f(1f, 1f, 0f); glEnd(); How does OpenGL know that you want to map your entire FBO texture to the size of the quad? i.e. when using the Tessellator you need to tell it both [x,y,z] and [u,v]. http://greyminecraftcoder.blogspot.com.au/2013/08/the-tessellator.html -TGG

Hi I reckon CJ's suggestion for looks promising, perhaps in conjunction with GuiOpenEvent to change the Gui and/or container to your own. Disclaimer: I haven't actually tried this before and the last time I tried to decipher the container handling + GUI code it got pretty cryptic so it might be challenging. Alternatively, your idea about the container's crafters list sounds like it could also be a solution - perhaps the presence of at least one trained mage allows others to craft too - i.e. does it matter which player looking at the crafting table does the actual click & drag to "complete" the crafting? -TGG

hi perhaps you could provide us with a direct link to the class(es) or paste them here... save us from having to look for them (and might increase your chance of a useful answer :-) ) -TGG

Hi From looking at the code it's not actually the spawner that stops spawning when the light level is too high, it's the mob itself MobSpawnerBaseLogic::updateSpawner() if (entityliving == null || entityliving.getCanSpawnHere()) { this.func_98265_a(entity); this.getSpawnerWorld().playAuxSFX(2004, this.getSpawnerX(), this.getSpawnerY(), this.getSpawnerZ(), 0); and in entityliving.getCanSpawnHere which is overridden to EntityMob.getCanSpawnHere: public boolean getCanSpawnHere() { return this.worldObj.difficultySetting > 0 && this.isValidLightLevel() && super.getCanSpawnHere(); } which calls EntityMob.isValidLightLevel() and this stops the mob spawning if there's too much light. So I doubt it's possible to override that directly. But I think it should be possible for you to get there indirectly: eg add a tickhandler on the server side, and every (say) 20 ticks, check for any mob spawners within 16 units of the player (they are tile entities so they're relatively easy to find), and if so spawn the entities yourself according to the mob spawner logic. I reckon it should be possible to have that run on the server only without needing any modifications to the client. -TGG

FYI I just checked the forge download site and although it looks like the beta is available... 1.7.2-Latest 10.12.0.967 1.7.2 12/26/2013 04:26:07 PM ... I'm not sure how that can be possible since MCP doesn't look like it's been released yet? And no official word from LexManos? Does this mean it's not actually what I think it is? Haven't actually tried out the src yet, need to figure out how to use Gradle first. -TGG

keen, glad you solved it. -TTG

Hi If you cancel the action on the client side, I think the answer is no, the vanilla won't call the server. However you could perhaps send the appropriate Packet15 to the server yourself from the client onItemUseFirst, without all the other unwanted methods that the vanilla calls? The Packet15 will then trigger onItemUseFirst on the server, just like vanilla? -TGG

Hi After a quick look through the vanilla code I don't think there is anything you could do directly, but you might be able to get to the same place indirectly. If you hijack the vanilla enchanting table using the GuiOpenEvent to replace the enchanting table GUI with one of your own which derives from GuiEnchantment, you could override mouseClicked to call a customContainerEnchantment which restricts the enchantments that can be applied. If Draco reads this he might have more specific help, he's done a stack of stuff with enchantment. -TGG

Hi What do you mean "change the slots to line up again"? how are you doing that? Hmmm I would be doubtful that this would help, to be honest. what did you use before? Do you notice a pattern of when the items move, compared with when they don't? Does it flick back and forth randomly, or at regular intervals, while you've got the GUI open? Or does it only change when you close and reopen? If you try to drag items out of the slot, does the item get selected when you click on the item, or on the slot (if you click the part of the slot which isn't covered by the item)? As you might have guessed I'm fishing for clues because I don't actually know what's happening. If you can narrow it down to the difference between a rendering problem vs an actual coordinates problem (hence the test with the item clicking / dragging), it might help a lot. -TGG