V0idWa1k3r

Getting a registry object by ID requires a map lookup every time you do so. Getting an effect from a field requires... getting it from a field. The performance is way better if you use the later. It also generates a more readable code. Imagine yourself looking at this code 6 months later. Will you remember what this 19 is there for? What if IDs change? You will have to spend time figuring it out and that is not productive.

https://github.com/xt9/DeepMobLearner/blob/master/src/main/java/xt9/deepmoblearning/common/items/ItemDeepLearner.java#L24 No, you must open a container on both the server and the client. Opening it on the client only leads to all kinds of bugs including the one you are experiencing. How would a container be opened on client only if the server needs to know about inventory changes? Remove the isRemote check and everything will work fine.

To add a bucket to your fluid you would call FluidRegistry::addBucketForFluid. As you are doing. Is something not working correctly? It will be added to a creative tab that all buckets are at(I believe it is the Miscellaneous tab) if you call that method. Do not name the bucket, name the fuild(Fluid::setUnlocalizedName) and localize that, the bucket will be localized from there. Forge uses capabilities to store fluids in the bucket and so will you. Create an itemstack of a bucket, access it's capabilities and add your fluid into it using the capability. After that just return that stack as a result of your recipe. You can't call client side code from a common class or you will crash the server. You are adding a bucket twice. Granted it should not matter as bucketFluids is a set and set can't usually contain equal elements within but that is still redundant. Potion.getPotionById(19)? What is 19? Where is this magical number coming from? Why are you even using Potion::getPotionById? You have the MobEffects class at net.minecraft.init that contains all potion instances.

I do not think vanilla has an example of that kind. I can provide you with an example though. It shows you how to make metadata independent properties that are obtained from data in tileentity. Making powered a property should not be much different from that.

Apart from that I do not see anything that would reset the fuel values. I see that you are changing blockstates in your tileentity without a check if you are on a server and not a client so it could be causing your issue. Why do you have 2 different blocks for your auto miner? Powered and not can be a property that is obtained from say your tileentity in getActualState. You will need to make sure it is synced though.

Yeah, that can work, sure. There are potential issues with implementations of BlockAutoMiner, if you have multiple of them that is. That is not a typo in game's code. That is a typo in MCP mappings. You can submit a bug report on their repo if you feel like it.

That is weird. Last time I checked setUnlocalizedName had no SideOnly annotation so it should work fine on both server and client. In any case if you need to call methods that only exist on client use proxies.

When you change a blockstate of a block it's tileentity gets recreated unless you explicitly tell it to not do so. You can do so at TileEntity::shouldRefresh. Note that you should not blindly return false as this check will fire even if the block itself is completely different.

I do not see any reason why it shouldn't

Read the message of this commit. As Lex said - please be patient.

That is because you need to sync the values between client and server. Either use custom packets, vanilla methods (SPacketUpdateTileEntity, getUpdateTag and such) or sync your data in the GUI directly if you only need it to be visible in the GUI(see GuiFurnace for an example and give me a minute to try and find a thread with a similar issue so I can link it here) Edit: here it is

You have the hand the player clicks your block with as an argument. That argument is called hand. Do not reinvent the wheel. That method already exists at TileEntityFurnace and it is public and static. Offhand - 40. Mainhand - player.inventory.currentItem. => playerIn.getHeldItem(hand).shrink(1); As for your issue itself try debugging it. Set some breakpoints up, see which method fails the checks, try figuring out why. Edit: Okay, just want to clarify something as my response may seem weird at the point of me talking about the hand argument as you clearly see it existing. To clarify - the issue here is me failing to see any reason as to why are you ignoring the offhand completely and only do things for the main hand. I also tested your code with hand and method references corrected and I do not have the issue.

Wrong subforum. That is a very interesting way of inversing conditions. Are you aware that you can put your condition in parentheses and put a ! before them? This field makes no sense whatsover. TileEntities already have a world field in them(it, conviniently, is also called world). Not only is this redundant it will also crash the server as Minecraft is a client-side only class. You do not need this field. If the tileentity gets ticked(update method is called) it's world can't be null unless explicidly nullified which is not the case for vanilla or any mod that I know of. If tile's world is null and it ticks that is a severe issue on the part of the mod that nullified the world and it is their bug. Even discarding all that this check is pointless as you access tile's world object a few lines above meaning that even if it's world would be null it would crash before getting to this check. RNG => world.rand. No need to create new Random object each tick. Why do you even need this field? You only ever access it to obtain a property instance. Those should be static. And final. You should not need an instance to obtain it. The tiles are updated on both client and server. You might want to adapt your logic to that aswell since you are currently setting blockstates regardless of if it is client or server, which you should not ever do. Blockstates changes should be done on server only.

Use v3 resources. You are currently using v2 which is outdated. Create a pack.mcmeta file in your resources folder and in it define pack_format property as 3. You should also define a description property. Example structure of your pack.mcmeta file can be found in forge's example mod that is shipped with MDK or here. Then rename en_US.lang to en_us.lang(convert it's name to lowercase) and you should be good to go. V3 works just fine in 1.12 for me.

Background and foreground are called from this method regardless, background is just called first, then foreground.

GuiScreen::drawScreen. Just do not forget to call super.drawScreen() after you are done to render all the buttons and text fields

Use capabilities.

What do you need a tutorial for? Creating a resourcelocation? Obtaining a template instance from that location? Calling 1 method to generate the structure from a template? You start of by creating your structure in game. Then you save it with structure blocks. Then you grab the resulting nbt file and place it in your structures folder in your assets. Then in your world generator you load that structure into memory by calling TemplateManager::getTemplate. Then you call Template::addBlocksToWorld and you are done. Want an example? Grab one at net.minecraft.world.gen.structure.ComponentScatteredFeaturePieces.Igloo. If you want an example with IWorldGenerator - here is one. It is not perfect but is fine as an example.

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.