V0idWa1k3r

Then in that topic that relates to that one issue describe exactly what your issue is, what you have tried and what is your desired result. Bonus points for attaching relevant code, preferrably as a link to your git repository. Your question makes no sense. the generate method will generate your structure, but you have to call it from somewhere, presumably from your IWorldGenerator implementation

I believe I've already seen your other thread in which you've asked the same question. And you have already recieved the answer there.

In it's model's render method.

Is OP not asking about saving/loading as well as he is asking about performance in general and that also falls under that category? Was just trying to be clear about that aswell.

As long as your tiles do not implement ITickable they only affect the world load time. And that corresponds to the amount of data you put into your NBT. In your case it is a long(8 bytes) and an int(4 bytes) + vanilla TE data(position - 12 bytes, id - ? bytes(string - 2 bytes/char)) + some internal amount of bytes MC uses to "open and close" nbt tags, not sure how much that takes but I would be surprized if it takes more than 4-8 bytes. Long story short - it is mostly fine unless you push an insane amount of data into TE's NBT or make your tiles tickable. I am also using TEs for ores and I have not noticed any difference whatsoever between a world without them and a world with them. Apart from that - could you explain a bit better about textures and 'reloading every time the world starts'. I can't quite make a connection between using a TileEntity and textures reloading. If you are going to do something that involves TESR of any kind - no, you will gain no performance. TESRs are quite heavy, even FastTESRs especially when there are lots of blocks in the world that use them as their buffers are computed each frame while IBakedModels just add their quads into a buffer on demand and that buffer is drawn each frame. If you mean a 'bake-on-demand' custom IBakedModel that depends on tile data - sure, that is fine if you use caching.

Because you have to check for the block itself too. You know, different blocks have different states and different properties.

you have the IBlockState of the block in the event. That state contains properties. See BlockStone to see which ones(hint - it's the VARIANT property). You can get a value of that property from the blockstate you have... And then you would just compare that value to see if it is a regular stone block or diorite/whatever. Something like if (event.getState().getValue(BlockStone.VARIANT) == BlockStone.EnumType.STONE) Edit: Here is a documentation that explains blockstates.

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"));