V0idWa1k3r

IBakedModel is a model you register for a blockstate. You can't really make a model "structurally aware" (well, you can but you shouldn't), but you can make a blockstate aware with getExtendedState. Then you would return a model that corresponds to a structure type that the blockstate dictates.

Just remove your data that corresponds the chunk coordinates from a map. That's all. When a chunk is unloaded it is saved first so you are free to remove the data. Upon placement of your block you get the data that corresponds to a chunk the block is placed in and do something with that data(increment the pollution for example). Upon your block being broken you do the same but you decrement the pollution. You do not need to write data to a chunk from a block, you already write the data(that is obtained from an underlying map) to a chunk every time the chunk is saved.

Yeah, Draco already mentioned that, I've read the annotations on events incorrectly, my bad. Just set the result to DENY

No, you store the data in a map, modify the data in the map when needed and in your save event handling you save the data from the map that corresponds to the chunk saved. They are the key for the map. Those a coordinates of the chunk you use to access and store the data in your map.

There are a lot of entity-related events. There is a whole LivingSpawnEvent class with subclasses for you to explore. You can simply create mobs to 'increase their number'. There is the WorldEntitySpawner::findChunksForSpawning method that essentially spawns mobs but it affects the whole world rather than e specific chunk.

There is a SaplingGrowTreeEvent for saplings(cancelable has a result). There is a CropGrowEvent and it's subclasses for crop growth(Pre is cancelable has a result(Thanks to @Draco18s for correcting me)). Note that if a mod author does not call those events on their crops or trees there is nothing you can do(*cough* Pam's Harvestraft *cough*)

Forge has chunk-data-related events. ChunkDataEvent.Save and ChunkDataEvent.Load. Both give you the NBT of the chunk. Handle the load event, load your data, pack it into your preferred way of storing data, put it into something like a map, sync it if needed and you are done. Handle the Save event and save your data. Handle the ChunkEvent.Unload to remove data from your map. Access the map through any means you like. Not the cleanest sollution as map accessis somewhat expensive but unfortunately you can't attach a capability to a chunk as chunks are not instances of ICapabilityProvider. At least not yet.

Block::harvestBlock applies all vanilla enchantments, adds stats to the player's stat tracker and drops appropriate items. It will not set the block to air for you so you have to do it manualy. It does not fire forge's events that are related to block destruction(it will however fire the HarvestDropsEvent) so you might want to fire some of those manualy too. Just don't trigger a recursion where you handle the even you are firing - that would only result in a crash. Note that if you want to completely simulate the harvesting of the block including all events, drops and whatnot you can simply invoke PlayerInteractionManager::tryHarvestBlock. Just be aware that it is going to fire all forge events related to block harvesting. Most likely including the one you are handling so you will have to avoid infinite recursion.

Yes, you can add it to vanilla leaves. Blocks.LEAVES.setHarvestLevel("axe", 1) is valid code.

Uh, anywhere that gets triggered? Block::setHarvestLevel is public afterall, so you can invoke it on any block you want, including ones from Blocks class.

A block model is not supposed to take more than 1 block. It creates issues of all kind. Even Mojang had to go through a lot of inconvinience to make fences working, and that is mostly workarounds. You could use a custom IBakedModel if you do not care about collision boxes. You should just have your block have multiple other blocks surrounding it that act as 'parts of the bigger model'. As for your first question - it is a bit difficult to understand what exactly you are trying to achieve but you can use a Block::getExtendedState to have as many states of a block as you want. You will need to store something that dictates the current to-be-chosen state somewhere, most likely in your tileentity.

This might be a somewhat complicated way to do so but you can use a custom IPerspectiveAwareModel implementation. The IPerspectiveAwareModel::handlePerspective method returns a Pair of a model and a matrix of transforms to apply so you can in theory return a different model based on the TransformType you are getting. Edit: as for displaying the number of arrows you will need to render that manually in a handler of RenderGameOverlayEvent of a Hotbar type.

Uh, your prevState variable is local to the method meaning that it really isn't a 'previous state' as it will never persistently store anything - it gets dumped from the stack as soon as your code finishes running. Did you mean to make it a field and not a local? Do you really need a helper method for a chestStack.getItem() call? In an event? And keys is a field, not a local? And it is not being cleared? You do realise that you will essentially add those 4 fields into your list every time the mouseinputevent is fired(which as far as I can tell is done each tick the player and the world are not null)? And that things like ArrayList support duplicates?

If you want to use a GLSL shader... use a GLSL shader. There is nothing stopping you. The game uses OpenGL after all and all normal GL calls are available to you. Load your shader, compile it, link to a shader program, delete the shader, bind the program, upload your data, render and you are done. Yes, you are absolutely free to use modern OpenGL(by that I mean ~<=3.3) with buffers and stuff, MC somewhat uses them already and If I recall correctly the game even requires GL3.0+ support to launch. Yes it is going to be a pain to implement with vanilla provided Tessellator's VertexBuffer as the way it uploads data is... weird. Yes, you can allocate your own buffer, put stuff in, bind and render, just like you would do for normal gl rendering. If you want more specific details you should browse lwjgl's tutorials and wiki as MC uses lwjgl. Note that there is no guarantee that other mods will not mess stuff up(thinking about the shadersmod for example) so you should be as cautious as possible and not forget to reset all GL states and binds after you are done.

When is your registerRenders method called? You must call it during pre-init. I do not see you doing so in the code you've previously posted.

Caused by: java.io.FileNotFoundException: xmt:blockstates/blocktowncentre.json Uh, you either needed to rename the asset name or your registry name, not both Your registry name and asset name must match, as I've said.

Post your new log after you've made the changes.

Well, not with that directly, that is just the way to write method names (classname::methodname) I usually use. Maybe something like ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(block), 0, new ModelResourceLocation(block.getRegistryName(), "inventory"));

Which part of it? I am not sure at which stage you are registering your blocks/items as the method is called init, so I explicitly told you that you must at least register them at pre-init to avoid issues. You should really use forge's registry events(RegistryEvent.Register) - they are nicer and more understandable and guarantee that everything loads as needed. They are normal events that you can listen to using SubscribeEvent. You are currently registering the model for your itemblock using ItemModelMesher(Minecraft.getMinecraft().getRenderItem().getItemModelMesher()). Do not. It is buggy and forge has an alternative called ModelLoader. Just call ModelLoader::setCustomModelResourceLocation. Does the same thing but without bugs or issues

If you are using Intellij 14 or later you might want to look at this: Even if you are not you might want to look at that topic. It is quite helpful as it covers common steps and issues.

Do not use ItemModelMesher(Minecraft.getMinecraft().getRenderItem().getItemModelMesher().register). It is outdated, causes bugs and obscure issues. The tutorial you saw that told you to use it is outdated. Use ModelLoader. Blocks and items must be registered at least during pre-init. Models must be registered at least during pre-init. The best way would be to use forge's registry events to register your things. Caused by: java.io.FileNotFoundException: xmt:blockstates/blocktowncentre.json *looks at the screenshot posted* xmt -> blockstates -> towncentre.json Your blockstates file name does not match your registry name. Same goes for your itemblock as you are using the same registry name.

A lot of deprecations that currently exist don't necessarily mean that it will get deleted. Currently Mojang moves to blockstates system and those methods may move to there respectively(and they have, they just callback the methods in the Block currently). Or they may not move there. 1.11.2 - those methods are still there. neighborChanged is one such example. There is no non-deprecated alternative apart from one in IBlockState. It may get deleted. Or it may not. Same goes to the MapColor. You may create your own IBlockState implementation to be safe as methods there are not marked as deprecated. Conviniently, Material.WATER returns true at Material::isReplaceable(). You might want to handle that too by replacing the water block with your interaction block using the flowIntoBlock method?

What exactly are you trying to achieve? Most likely you can just create a standart json model, bind it in your blockstates file and let standart model rendering take things from there.

You should use custom IBakedModels for your items if you need something complex, and forge's animation api if you need your items animated. That method only exists to allow rendering of tile entities as items (vanilla examples - chests, mob skulls, banners, etc.). And as you've pointed out yourself it is clearly marked for deletion.

Ah, indeed, you are correct. WorldGenMinable only offsets the ores it generates based on the vein size but not the base point. Hmm, not sure how I got confused with that, my bad. In this case you would be fine with your previous code. Although you may just be experiencing too much worldgen in general - 75 tries per ore per chunk is quite a lot, considering that vanilla by default only has a maximum of 33 for it's very common andesite/diorite/granite... Well, to be fair that's not really a lot, but could still cause some issues, though unlikely