Rikka0_0

Checkout my example: https://github.com/rikka0w0/librikka/blob/382f6f79847ae666c22b9c2d6cd591207dfb4303/src/main/java/rikka/librikka/Utils.java#L51

Rendering order is important. Can you render your blocks in the Solid or Cutout layer?

In order to let the client communicate with the server, you need to create your own packet. Have a look at my mod: https://github.com/RoyalAliceAcademyOfSciences/SimElectricity/blob/master/src/main/java/simelectricity/essential/utils/network/MessageContainerSync.java And register your custom packet during onCommonSetup(FMLCommonSetupEvent event) event: https://github.com/RoyalAliceAcademyOfSciences/SimElectricity/blob/master/src/main/java/simelectricity/essential/Essential.java If a class contains calls to the Minecraft class, it will crash on the dedicated server. Client-only classes are not available on a dedicated server. In this case, use a DistExecutor (used to be called proxy): public static CommonProxy proxy = DistExecutor.runForDist(()->()->new ClientProxy(), ()->()->new CommonProxy()); https://github.com/RoyalAliceAcademyOfSciences/SimElectricity/blob/master/src/main/java/simelectricity/essential/ClientProxy.java In your case, you should create a ClientProxy class and make a function to return the value of Minecraft.getInstance().objectMouseOver. One last thing, I think you should perform the raytrace on the server side instead of the client side.

You should have a look at its implementation in the super class when you override a method. In most case, you need to call the super method.

A lot of server to client data synchronization needs the list of all players who is using the GUI. In previous versions, this can be done by reading "listeners" field in my own implementation of "detectAndSendChanges". However, this field becomes private in 1.15.2. Does that mean we have to track the listeners by our self, or is there a more elegant way of doing this? Thanks! Forge Version 31.1.47

Thanks! My BlockStateProvider is now working! I will post a link to the repo once I finish cleaning up the code.

Thanks! As far I as know, this is the only possible way. Also, can anyone confirm that forge blockstate loader has been permanently removed? I put "forge_marker" : 1 but Forge seems to ignore it.

I was convinced One more question, it is possible to specify the model loader in the blockstate file?

How to invoke the DataGenerator? I launched the game, the GatherDataEvent is not fired by MinecraftForge. https://wiki.mcjty.eu/modding/index.php?title=Tut15_Ep15

We may still need StataMappers or its replacement! I'm dealing with blockstates including subtypes(int), facing(Direction) and status(Boolean). Removing subtypes is straightforward. Facing and status controls the appearance of the block. I decided to only keep facing and status in the blockstate, however I encoutered some problems. In 1.12.2, my mod uses StataMapper extensively to avoid writing tons of json files (BlockState json) files and then redirect the loading of variants to my own loader. In 1.15.2, the StataMapper has been removed and the hardcoded logic in ModelBakery::loadBlockstate(ResourceLocation) suggests that it only accepts JSON files! Which means I have to write a JSON Blockstate file for each block, flattening makes things worse as it increases the number of JSON files required. I have three solutions, the first is to write a json blockstate file for each block, it points to a json model file, which then tell forge to use my own IModelLoader to load the model. Although it takes a lot of time, but it is still feasible. The second is to add back the StateMapper, by the MinecraftForge Officials, it will take some effort but I definitely think it is worthwhile. I will be really appreciate if StateMapper is back! The last one is to use IForgeTileEntity::getModelData, but some of my blocks don't have a tileEntity.

ModelLoader.setCustomModelResourceLocation no longer exists in 1.15.1. I have around 30 simple items to register and I would like to avoid writing 30 json files. Looks like Minecraft.getInstance().getItemRenderer().getItemModelMesher().register() is the only way. Or is there a more elegant solution? Thanks

Thanks for this information！ Are they building the GUI or it is still in the to-do list?

I'm having exactly the same problem! Fresh forge install (30.0.41) on Minecraft 1.15.1, dev env is Idea 2017, running on Java8. Some other threads suggest that the config gui feature may have not been implemented yet I'm digging through the code and trying to find the answer. Why they abandon the nice 1.12.2 config system and rewrite a broken and incompatible new one?

Has the GUI config button been implemented? (Jan 22, 2020) On Minecraft 1.15.2 Forge 30.0.41, all config buttons are disabled, including the forge one. When will this feature be available? Should I start migrating to 1.15.2 or stay at 1.12.2?

I also have this kind of problem. I do null check in my getActualBlock state. I think possible reason can be, sometimes the IBlockState passed into getActualBlock() can be implemented by a ChunkCache, and the TileEntity doesn't exist in it yet.

Currently I'm working on a mod which includes a lot of complex block models, and some of them may be greater than a normal cube size, so I decided to use code to generate BakedQuads. Those blocks just look fine when they are placed into the world or held inside the inventory, but once they are dropped into the world (become EntityItem) and held in hand, weird things start to happen. As shown in the attached picture, the EntityItem model is too dark and lighting is not working properly. Can anyone suggest what could go wrong? Thanks in advance! PS: If I return true in isGui3D() in the IBakedModel, the inventory model becomes dark too (sad QAQ!!!

I just did a clean up to my mod, according to the quote I switched from ITileEntityProvider to hasTileEntity() and createTileEntity(World, IBlockState). I'm curious about why ITileEntityProvider becomes deprecated? QwQ

In 1.7.10 there was no ITickable. /w\

It does nothing in the TileEntity ticking.

One of my friend points out a possible solution: at the end of the model baking phase, the huge baked model is splitted into smaller models, (each small model occupies a volume of a block) and then assign these smaller models to blocks. (I already have some invisible blocks to make collision boxes working properly). I'm thinking about doing this, so I don't have to modify my .obj model file. Back to 1.7.10. I used to have a lot of TESRs to render my power poles, if I have lots of them, the fps can drop by about 15. (At that time my graphic card was HD3000). After migrating the rendering stuff to ISimpleBlockRenderHandler(ISBRH), the fps no longer drop that much. So I conclude that TESR degrade the performance.

TESR is resource consuming QAQ I try not to use TESR to render stationary stuff. And break down the whole model into submodels...I dont think thats an elegant solution.... If I can insert a line of code inside a vanilla class, that is going to help a lot, and perhaps help to solve similar problems like this one. I might end up with writing a coremod or submit a Forge PR QAQ Also, I noticed that there's something new called FastTESR, is possible to render a bakedmodel in a FastTESR? and how is the performance?(compare to ordinary block model rendering and TESR)

true, for entities/tileentities, it is easy to do. The reason why im not using TESR is the performance loss, my model is stationary. No animated parts. I had a look at the vanilla rendering code, Minecraft does not render RenderChunks(16x16x16 instead of 16x256x16!) which are considered to be invisible to the player. RenderGlobal#renderContainer holds a list of visible chunks, only these chunks will be rendered. Seems that its impossible to attach any other RenderChunk to the list. RenderGlobal#renderContainer is private and there's also no way to get an instance of a RenderChunk from BlockPos. Vanilla clear the list before collecting visible chunks and after rendering them. If forge can have a hook inserted just before this.renderBlockLayer(blockLayerIn), its going to be tremendously helpful!!

My mod has some multi-block structures. In a structure, most blocks are invisible and used as placeholders, only one block has a visible model (huge one, much bigger than 1x1x1). In most case, it just works fine, however the structure becomes invisible when I look at it from some perspective. I believe the game thinks that this block can not be seen by the player, so the entire structure is not being rendered. Is there any way to force the game to render a block? (Of course I can split my huge model into smaller ones, but it is going to take a lot of time and effort, and not elegant QAQ!!!) TTTThanks in advance

Be aware that onLoad() can be call from both server and client side, I guess your energy system simulation logic is server-only, so if you attempt to access the energy system from client side, you will get a NullPointerException. From what I know, getTileEntity attempts to create an TileEntity if there's no existing one at the given location. OnLoad() is called after the tileEntity is loaded. So calling getTileEntity() in OnLoad() can result in a recursive situation, and eventually cause stack overflow /w\ Call Hierarchy Your code looks like updating the appearance of blocks, I guess a better way to do this is to override getActualState(), in your block class /w\ getActualState handles blockstates which aren't depended on metadata. Some other useful stuff: Minecraft Forge event: ChunkWatchEvent.Watch

IBlockState includes information other than block type and metadata, such as states which isn't mapped to metadata and extended states. This is my concern. but anyway, i decided to compare IBlockState instances directly. Up to now everything works fine /w\