redria7

You are probably having trouble with teleporting back and forth, forever. Every player should have an integer variable called something like portalCoolDown or something similar. When you teleport your player, set that to 100 or something to begin with, then whenever you have your collision method for your block, where you initially teleport the player, check to make sure the cooldown is equal to 0 before you teleport. If the cooldown is greater than 0, then they cannot teleport and it gives the player time to exit the teleporter. Also, you will want to look into where your player lands when they teleport and where the portal is built. If they land in the teleporter like you do with the nether, it makes it easier to accidentally teleport back when you don't want to.

....Interesting. Thank you. Create a class that implements ISimpleBlockRenderingHandler. The method renderWorldBlock is given the renderer. The link I posted has more than you need, but it does help a lot with setting up your first custom block renderer and you can learn a lot from it.

I meant the second bug. That's why I quoted you mentioning the second bug. Put a piece of coal and 8 iron in a vanilla furnace and wait till 4 pieces have been smelted. The fire will have burned down halfway. Exit the world, then log back in, and you will notice the fire is full again, and will drop rapidly when it reaches the last item to be smelted.

Should do, but if they want it to sort of have a mixed texture... look up the randomite mod he mentioned and look at how that texture blends into the stone background. That has to use alphas to work. It is a little bit more complex, but not too bad.

This bug is present in vanilla furnaces too last time I checked. If anyone knows a fix, I could use it too, but I've kind of given up on it myself.

Ack! I'm trying to get out of this thread! haha. I was saying yeah to flame. I should have quoted. I'm not sure how to go about doing entities really. Sorry. Good luck.

Yeah.

I, uh, may have obsidian tools. BUT That is one of the things I did when I was learning how to mod. And I made it interesting. Kind of. I have lots of other stuff that is part of my pack. And I plan on calling it a mini mod pack because I'll have several independent mod sections that can be turned on and off through config if someone cares enough. Anyway, I'll let this thread continue. I've hijacked it long enough.

I'm pretty confident in what I've done, but I also want that reveal moment. Where I have everything finished and I get to just show everything at once. So, you know, a couple spotlighters can say "oh wow" and no one else notices and life continues as normal... I don't think there is really anything to fear: I think most people go into modding because they have a specific idea in mind to start with, but I play my little games.

http://www.minecraftforge.net/wiki/Multiple_Pass_Render_Blocks Start there.

Sorry, tile entity is my thought for this on how it would work easiest. By pointing out that that's exactly what you were doing already I was (not very clearly) pointing out that that method was already being done, so using a different method would probably be a good idea. I respect the fact that you are willing to help someone doing something similar to what you are doing when you haven't released yet. I plan on going open source the moment I release, but I am trying to hide my more fun features until I release just in case someone else likes the idea and releases first. I'm a little selfish that way.

Tile entity my friend. A tile entity with a gui where you can alter size and... do exactly what flame is doing! Or try the entity. Mobs, players, TE's, all of these are entities. Items on the ground are entities. Creating one wouldn't be impossible. Maybe make something similar to a spawn egg, except instead of spawning a mob, it spawns an entity that has a set size and shape and covers a large area, with no collision etc. Then your mayor can give each person one egg from creative mode, and the players can throw the egg at a location and it locks that location to them.

You want... a texture pack that changes the texture of other people's mods? Or is it your own ores that have default textures? Or the vanilla ores? Looking up the randomite mod, it looks like you want it for your own. You probably need a custom renderer. The first thing you need to have your custom renderer is get the icon for regular stone. This will let you have that textured stone background. From there you have several choices. 1: Draw in textures in sections. You know exactly where your ore is going to show up in the block. Say you are just going to have a 4x4 square in the middle of the block. You are going to go in and draw in each side of the block individually, and on each side you would draw in a rectangle containing most of the bottom half of the stone texture, up to the bottom of where your ore shows up. Then you draw in 2 rectangles the height of your texture extending from the sides of the texture to the sides of the block. Then finally another big rectangle extending from the top of your ore to the top of the block. This draws in a regular stone block with a gap in the center. Then you just need to draw in your ore texture in the center of the block and it will look like you want. 2: Draw the texture in layers. I think this is how your example did it. Draw the stone block like normal. This gives you a base to work with, and takes much less effort than drawing each side. This will happen in pass 0, the solid block pass. Then your custom renderer and block will have to be set up to render in both passes. Your ore texture will be just the ore spots, with maybe a little bit of distortion around the edges if you want it like your example, with that distortion being slightly transparent. In the alpha pass or rendering, you will draw in the entire texture of your ore. This will theoretically overlay the normal texture and give you what you want. If you run into problems with z-fighting, where your texture flickers in and out of the stone texture, just expand your block bounds when drawing your ore texture ever so very slightly, so it is barely bigger than the stone block.

Are you wanting this to just always be there or are you specifically wanting it to happen when you have another block placed already? If you place a block in order to have the overlay, you could use a custom renderer on that placed block and draw your overlay from there. To make it cover the block that is there in the first place, you could set the block bounds to be just ever so slightly larger than a normal block, so it completely covers the normal block that is there already. If you want it to just exist there, I can't really help you.

Yeah, I caught that moments before you replied. Thanks though. I had it there and decided to comment it out since I didn't see it immediately contributing, then I finally looked at the sign tile entity and saw: /** * Overriden in a sign to provide the text. */ public Packet getDescriptionPacket() and realized my mistake.

I have run into a little bit of a snag with my tile entity. When I place it, I want it to recognize what location it is being placed at, specifically the coordinates, and store this information in variables within my tile entity class. That seems to be no problem since tile entities are eventually told their own coordinates. However, I then want to be able to tell it, through my gui, to pretend it is located somewhere else. It renders in the same spot, but those coordinate variables are changed. So it has the normal tile entity coordinates, and my new altered coordinates. Again, no problem. My problem comes with initialization of the client side world. When the client side world is created, my tile entity is initialized as if it has just been placed and the internal coordinates have not been changed, and this is never rectified. So every time I load the game, the server is loading the changed coordinates and the client is showing the original ones. I (think I) know the solution lies in packets, but I'm just not sure when and where to send a packet, or if that isn't the solution at all. To be specific, I have an initialization boolean that starts as false (not initialized) and when updateEntity is called the first time, the coordinates are stored and the boolean is set to true, stopping the coordinates from being reset when updateEntity is called again. This was the only way I could think of to initialize the block to contain its coordinates. A thought is that I could maybe send a packet from updateEntity from the server side to client to update it, but I'm not sure how to control the flow of packets so it isn't just spamming packets. Tldr: The client side world is loaded when the game starts and initializes my tile entity as a new entity, never recognizing changes that had been made before the world was saved and closed. It seems like a problem that other things should face, so there should be a solution... I'm just not seeing it. Edit: Disregard all this: I'm an idiot. I had getDescriptionPacket and onDataPacket already set up to handle this, then I commented them out thinking they weren't contributing as I was learning how packets worked. I uncommented them and it works. Yay me.

That. I have no explanation to help you with, but in making my own dimension, I wanted all of the vanilla overworld biomes to spawn in my dimension. The 2 world chunk managers I know of are WorldChunkManager and WorldChunkManagerHell. The Hell one does one biome, which you specify. The regular one does multiple. You will have to make your own world chunk manager and look in to how the regular one works.

Wait, really? I don't want to doubt someone who clearly knows more about this than I do, but my computer is severely lacking in, well, everything, and I want my mod to work optimally both for my sake and any other poor soul out there who has never run minecraft past tiny render distance without crashing. Can anyone else confirm?

Why is your render type 180? Either set it to 3 (the render type of a fire block) or return Block.fire.getRenderType() to make sure yours always renders the same as fire in case the number is ever changed.

It handles squares. Anything that is a square is good, because it looks up the size of the icon. So regardless of how big your icon is, it is designed to draw from the start to the end, not just 16 pixels. The only reason it can't handle a square is because it complains about non-squares... and I don't know how to get around that.

Sorry, I realized that I didn't specify: I need to have a gui for this tile entity.

I have a tile entity that won't be storing items. So it wouldn't need a container, right? Am I imagining the concept of the container incorrectly? Doesn't the tile entity itself store all the information and the container is just... I'm not even sure what the real purpose of the container is. Defining what items are accessible from what tile entity? The gui handler needs to pass a container (in getServerGuiElement) for a gui to be opened, so I must need a container class, but it would literally do nothing. Which confuses me.

I have absolutely no idea why nothing else would work. I went in and tried it and I just tried different things until I found something items failed at. Haha. But, be warned that this is probably not a good solution. I don't know a good solution, but this seems very sketchy to me. It seems to work, but I can't guarantee it continuing to work, so in spare time you may want to look into finding a different solution.

In your constructor for your gui add in: this.xSize = 182; this.ySize = 172; This allows you to reference xSize and ySize as they do in the vanilla furnace gui class.

Dirty hacks version. THIS WORKS. I went in and tried it myself because everything else people are suggesting somehow doesn't work. @Override public boolean isItemValid(ItemStack par1ItemStack) { if(par1ItemStack !=null) { if(par1ItemStack.itemID < Block.blocksList.length && Block.blocksList[par1ItemStack.itemID] != null && !Block.blocksList[par1ItemStack.itemID].getLocalizedName().equals("tile.ForgeFiller.name")) { return true; } } return false; }