V0idWa1k3r

I see 2 possible exit conditions to this loop: 1. recipeComponents is not a string, the loop exits normally. 2. i => recipeComponents.length(the last element of the recipeComponents array is a string), the loop throws an ArrayIndexOutOfBounds exception and the exception is passed along potentially crashing the game. That could be your issue. Why is there a String[] to String[] cast? Isn't it a tad bit redundant?

Are you sure that the client has correct energy data for your tile? Try debugging the value of the local in your getLightValue method. I can't reproduce the issue with a similar code.

Is outdated. Use Block::createTileEntity and Block::hasTileEntity. Blocks are singletons. Tile entities are not. You can't change the value like that as the change will be reflected on all lamps in the world. You can override Block::getLightValue(IBlockState, IBlockAccess, BlockPos) and return the appropriate light level there based on the tile you get at the coordinates. You will also have to call World::checkLight to redraw the light levels around your lamp as you change them as they are not updated automatically for you.

This is a bug that had already been reported. Forge just has a lot of other things to work on at the moment. There however is already a PR to fix this issue so it should be fixed in the near future.

Well, let's look at your tileentity class then shall we? It is common and also shared by both blocks. In it's update method we see this: Oh, I wonder where is the block field at? And it is static. Every time you place a new TileEntity you refresh this field for all your tileentities as it is static. The next tick all tileentities convert the blocks that they are bound to to the block that this field stores which conviniently is the block you've last placed. Also it is probably not a good idea to call this each tick. Granted you are calling this on a server which does nothing by the way, but if you would call this on the client you would cause a lot of lag by the renderer having to redraw your block every tick.

Are you registering your item models here? That is absolutely not how you should do it. 1. Use ModelLoader, not ItemModelMesher. 2. Model registration must be done during pre-init, not post-init. And not init, for that matter. Pre-init and pre-init only. That is if you are chosing to not use forge's registry events... 3. You must use proxies to access client from common classes. Your mod class is a common class, you can't call client-only methods from it, even if you do the side check first. Client-only methods and classes simply do not exist on the server so a check like the one you are performing will not save you. 4. Why are you using some getName() method to generate a resourcelocation of your items? Why can't you just use Item::getRegistryName as the first argument to your ModelResourceLocation? (see N6 for more clarification) 5. Your ItemGraphitePickaxe literally registers itself with the name "name". Not the name you've passed in it's constructor, but a literal "name" string. Same goes for it's unlocalized name. 6. You are also horribly misusing forge's registry system. You should not use GameRegistry.registerItem. Instead you should use Item::setRegistryName for your items and registering them via forge's registry events. Or at least with GameRegistry::register. Not registerItem, just register. 7. Register your recipes at one loading stage. At least just for consistency, of all the reasons there are. Why are some of your recipes registered in preinit and others in init? Bonus points for using Shaped/ShapelessOreRecipe instead of regular Shaped/Shapeless. Why are your java files and the crash report attachments of all the things? People do not want to download random files to their computers, there are plenty of online text hosting services out there. Use github to host your code and gists to link text files. Or at least pastebin or something like it. Edit: Oh, I just missed something. Your preinit method is using FMLInitializationEvent, not FMLPreInitializationEvent, and it is not annotated with EventHandler so it is not called. All your items are null, hence the crash.

Well if you put it like that sure, the client can load TE's data from an NBT but I ment from-disk loading getUpdatePacket and onDataPacket methods have existed for a while, but I can't tell you by how much. By default they do not do anything(onDataPacket is an empty method and getUpdatePacket returns null). They are needed for... erm, I would call it "on-demand tile entity changes". Basically if you look at PlayerChunkMapEntry::update method you will see that this packet gets sent in 2 cases(really it is more like 1 case with a sub-case ): 1. There has been a single change for the ChunkMapEntry involving a tileentity 2. There have been less than ForgeModContainer.clumpingThreshold(64) amount of block changes for the entry. Then every tile that got changed sends this packet. On the other hand, when the chunk data is fully sent to the client(a player loads a chunk) or there are a lot of changes within the chunk entry(>= 64) all tile data gets 'clumped' into a single NBT which is sent. That NBT is composed of TileEntity::getUpdateTag for each tile that gets synced that way. By default TileEntity::getUpdateTag writes tile's X/Y/Z, ID, extra data and all capabilities into the tag and handleUpdateTag simply invokes TileEntity::readFromNBT, thus deserializing all that data. As far as I can tell those are the only conditions for those two methods to be used, as getUpdateTag is only ever called while initializing a new SPacketChunkData packet. The changes are recorded to the chunk entry when the blockChanged method gets called and that gets called from ServerWorldEventHandler::notifyBlockUpdate which is a IWorldEventListener for the server. notifyBlockUpdate gets called when World::notifyBlockUpdate is called, respectively. That for example is called at World::addTileEntity, and under certain conditions when you invoke World::setBlockState. So long story short that keeps chunk data(blocks+tiles) in sync. You pretty much want to override both methods, although due to default implementation getUpdateTag and handleUpdateTag are optional and you might not need to override those. getUpdateTag/handleUpdateTag are for initial sync and big changes. getUpdatePacket/onDataPacket are for "on-demand" sync. You can still let vanilla handle everything. Just make getUpdatePacket return a packet that is your NBT data serialized and onDataPacket simply deserialize the data. After that you can still use World::notifyBlockUpdate/whatever you were using. I've had issues with that method being unreliable sometimes but I was unable to reliably debug it so i'd say that it should be safe to use it. A small disclamer: All that I have written above is something that I was able to trace with the debugger/code inspections, it might not actually be exactly the way things work. I also can't say anything about 1.10.x or lower as I've only started modding at 1.11 (all knowledge I have of previous versions is theoretical) and I do not know if those methods were changed at some point in the past.

? What version are you on? This method has not been static since Mojang changed their threading stuff a while ago... Please clarify what exactly is protected. The method? The folder?

After you are done rendering your stuff you need to rebind the texture that was previously used. Forge won't rebind the texture after each even it posts in GuiIngameForge, it leaves it to modders(and that is the way it should be). The numbers are still drawn as FontRenderer binds the font texture every time it needs to draw anything.

Java's try-with-resources is only available for Java7+ and you are building against Java6. Either update your build.gradle file to build against Java7+ or do not use the feature. To change the java version you are building against find the following in your build.gradle sourceCompatibility = targetCompatibility = '1.6' // Need this here so eclipse task generates correctly. compileJava { sourceCompatibility = targetCompatibility = '1.6' } and change 1.6 to whatever version you want to be building against(1.7 or 1.8)

I do not know how you handle your command, but you might need to explicidly sync your tile with the client. It can be done by either using forge's custom packet system, or by manualy sending tile's update packet to a client. There is a World::notifyBlockUpdate method that is supposed to do that for you but I fould it to not be reliable enough for some reason. Additionally looking at your tile's code I see that you are overriding But not TileEntity::onDataPacket. When your update packet arrives on the client it calls that method. By default that method does nothing. You need to override it and read your data from the packet which is method's second argument.

Is outdated, Use Block::hasTileEntity and Block::createTileEntity. 1. Yes. 2. Vanilla has a great example of a tile entity that retains it's data when broken. See BlockShulkerBox. 3. If you so chose to you can store all the data of the tile in your item's capability. Capabilities are just means of storing/accessing data easily. Chosing to use them or not in this case is up to you. In general you would want to create a custom ItemStack as a drop that contains your tile's data in it's NBT/Capability. Upon the placement of that item you would either set the data in a newly created tile on your own using a custom ItemBlock or let vanilla handle it by saving your tile data into a NBTTagCompound and storing that tag in your ItemStack that gets dropped with a BlockEntityTag as a key(yet again, see BlockShulkerBox for more clarification)

TileEntity loading from NBT only happens on server, the client doesn't load anything from any files. The client can only read the data server sends to it. If your tile depends on some data being present on both server and client you need to sync it by overriding getUpdatePacket and getUpdateTag(optional, you only need to do so if you want non-capability related stuff to be synced) to send the data and onDataPacket and handleUpdateTag(most likely you don't need to override this one unless you want to do something more than just reading NBT of the tile) to recieve the data. there is no such method as getActiveState. Did you mean getActualState? If you want to get tile's common data from that one on the client you will need to sync the data first.

returns an Item. Not an ItemStack. It works properly, it just doesn't do what you think it does. Block::getDrops returns a list of ItemStacks to be dropped upon block breaking. Look at how blocks are dropped as items at Block::dropBlockAsItemWithChance. Could you please explain a bit better what do you mean by that? Placed as poured from a bucket by the player? As the bucket is an item you can use forge's RightClickItem event.

Yes, why? To begin with you are getting a list of every entity in the world, but you only care about the players. There is a playerEntities field in a world that contains all the players. You do not need to iterate every singe entity in the world. Additionaly your current code will only work for players in the overworld. If a player is in the nether, for example, you will not iterate over them. You can get a list of all players on a server through PlayerList::getPlayers and you can obtain an instance of PlayerList from a server with MinecraftServer::getPlayerList. Those method/class names look pretty self-explanatory to me... Well tell them that that is very inefficient especially because there are already methods of doing so without iterating every entity in the world and every world of a server. I do not know what factions is but using a Timer like that is not thread safe. If you are comfortable with multi-threading it might work but considering that this task is only ever executed once an hour I would just use forge's TickEvents. I do not see a need for another thread for a really infrequient task that barely does anything(if you use the PlayerList, that is). 1 hour is 72000 ticks.

In your render factory (the RenderRock.Factory subclass), in it's method return a new instance of RenderSnowball(new RenderSnowball). It's constructor takes 3 parameters. 1. a RenderManager. You already have one(it is the only parameter of the createRenderFor method) 2. an Item. That is the item you want the texture of to render. In your case it is your Rock item if you have one. I do not know where do you keep your item references so I can't give you a code snippet to use. 3. a RenderItem. You can obtain one using Minecraft.getMinecraft().getRenderItem(). If you want your item to render as a snowball but with a different texture you might aswell use snowball's renderer instead of writing your own.

It seems that you can simply return a new instance of RenderSnowball then. Look at it's constructor. You already have your RenderManager in your factory, the Item is your item(the rock) and you can obtain an instance of RenderItem at Minecraft::getRenderItem

Why? There are no reasons to stay on the outdated versions. Especially now, with the community actively wanting to set 1.12 as the "mainstream" version. There are modpacks for it already for crying out loud, we don't even have a stable forge yet... No one is going to use your mod if it is that outdated. Well, you've registered your renderer. Are you maybe going to do something in there? You know, by default an implementation of Render is not going to do anything. You need to provide it with code that it will use to render something. You currently have only defined the textures used for rendering, but you are not telling the game how to render your entity. Maybe you could use an implementation of RenderSnowball that renders your rock instead of the snowball? Please explain what you want your entity to look like.

What are you trying to cast to EntityPlayer? You do not yet have a local/field named player. Additionaly you can't have 2 locals with the same name. Moreover if the entity you are casting is not an instanceof EntityPlayer you will crash with a ClassCastException. There is an instanceof check in the language, use it. Comparing a local after casting to a local before casting is redundant. It is the same object, the == check will always be true. Those are java basics. getEntityWorld only returns the overworld. There is a list that holds all players already, it is called something like playerEntitiesList. I have no idea what are you trying to do with that timer but that will not work. If you want to store data related to a player use capabilities. If you want to do something regularly use forge's TickEvent subevents.

If you read the javadocs of the LivingEntityUseItemEvent.Finish you will see the following lines: Fired after an item has fully finished being used. The item has been notified that it was used, and the item/result stacks reflect after that state. Note the item/result stacks reflect after that state. part. If you have used the potion the item is indeed an empty stack - as that is what happens to a potion as you drink it. You can make a workaround by subscribing to either Start or Tick subevents, storing the reference to the stack being used somewhere(presumably in a map, just make sure to not leak memory with your keys), removing that reference on the Stop subevent and using that reference as the item being used originally at your Finish subevent handling. Do not forget to clear that map when needed. That is not a perfect solution and if someone suggests a better one you should use theirs.

Setting the tileentity like that updates the position of that tileentity. So your next call is already using the new pos - the one you've just set your tile to, the position local to be precise. So it sets the block in front of the original position to air as that is the position it is currenty at. You should not really "move" a tileentity like that. Either carefully invalidate/validate it manualy as you do or simply create a new one and copy all the data over

VisualVM is the default jvm profiling tool that is usually shipped with your JDK. It is pretty good and should suffice in most cases. I remember there being mods that did the same, opis and alike. I also remember seing something about alternatives for MC 1.10+. I'll look them up and edit this post with their names if I find any. Also this question is not related to modding directly, so I do not think that this is the right subforum for it? Edit: that alternative is called TickProfiler.

The debuger can't 'not show anything'. Even if your breakpoint isn't triggered it is already showing something, isn't it? It is showing that your code isn't being executed. Then you take if from there and try to see why exactly is it not being executed. If your whole IWorldGenerator is not being triggered(that is a breakpoint at the start of the generate method isn't triggered) then you are not registering your generator correctly. If that breakpoint is triggered something later down the lines isn't correct and the breakpoints allow you to figure out precisely what. If you are using logging to debug - well, you shouldn't. Learn how to do breakpoints, it is literally 1 click of your left mouse button. Logs were ment to give information to the end-user, not to debug. Try again with breakpoints(or if you already are tell exactly what part of your code is not being executed) and post the answer in that other topic of yours.

1. You continuing to post in this topic which is completely unrelated to your current issue. You already have a topic that is related to worldgen with templates. Post there. Posting here just makes it more difficult for others with the same issue to find a solution later as they are likely to skip this topic judging by it's name. if ((int) (Math.random() * RealmOfTheDragonsConfig.testhousechance) == 0) => if (rand.nextInt(RealmOfTheDragonsConfig.testhousechance) == 0) The whole getGroundFromAbove method can be replaced with world::getPrecipitationHeight and a while loop to 'drop down' to the ground in case precipitation height is a tree leaf or something. More efficient than iterating from 255 and all the way down. foundGround = blockAt == Blocks.DIRT || blockAt == Blocks.GRASS || blockAt == Blocks.SAND || blockAt == Blocks.SNOW || blockAt == Blocks.SNOW_LAYER; What if the biome's top block is neither? For example AbyssalCraft's biomes have custom mod-added blocks as top blocks of their biomes. You can also directly return from the while loop. The foundGround local is redundant. // if Y > 20 and all corners pass the test, it's okay to spawn the structure return posAboveGround.getY() > 63 && corner1 && corner2; if Y > 20 return posAboveGround.getY() > 63 One of these two statements is a lie isCornerValid method currently always returns true so there is no reason for it to exist in it's current implementation. Why have you hardcoded 63 everywhere as a minimum height? What if the world is lower than that? Apart from all that I do not see more obvious issues. Is your structure not spawning? What is happening then? Have you tried debuging it? What are the results of the debug?

Calling super first makes the button drawn first and then everything is drawn over it. Call super last and it will draw the buttons over the rest of the ui.