Matryoshika

Well, not all blocks have tileentities. In those cases, World::getTileEntity will return null, so you'll need a null-check first, or you'll very likely crash. After that, you can use an instanceof instead of equals-check, and just reference your TileEntity's type eg if(world.getTileEntity(pos) instanceof TileEntityFurnace)

You can call BlockPos#getAllInBox which returns a collection of BlockPos. You need to give the method 2 opposite corners. You can get those by using BlockPos::add(+-x, +-y, +-z) You can then do a normal for-loop or lambda-for-each to iterate over each BlockPos.

World::isRemote returns true for Client Capabilities still exist on the client, it's just that no data is saved = null values (tile.air is an empty stack aka null)

Capability data is only saved on the server (meaning client doesn't know anything)

... The second parameter is the variant of which you want to use... Unless otherwise specified in the BlockState file, there is only "inventory" for items, but blocks also have "normal" (placed)... The Item's RegistryName (which comes from getRegistryName()) should already equal "ds:old_tome", IF you used setRegistryName("old_tome") in the item's constructor... You don't need to worry about that... On a tangent however, modid's are recommended to never be shortened or otherwise altered from the original "name". I don't know what "ds" stands for, but for example, what if I made a mod called "Deep Storage" and also used "ds" as my modid? The longer a modid is, the probability of another mod having the same name exponentially becomes smaller. You also need to actually have this code RUN during the ModelRegistryEvent... You can do this very simply by annotating your client-proxy with @Mod.EventBusSubscriber and moving your registerItemRenderer method to said client-proxy. Your registerItemRenderer() also needs to become registerItemRenderer(ModelRegistryEvent event), so that the method can be picked up by the scanner, and called when the ModelRegistryEvent is fired, which then will run the code.

You should use items/blocks getRegistryName() as the first parameter. First parameter should not contain any extensions (".json") nor any file-separators ("/"). All of that is automagically done "behind the curtains" for you.

Problematic Code #2

You are adding the player to the collection AFTER you check if he is in it... of course the player won't be inside of it before then Switch the if-statements 'round to add first, THEN check if the player is in it.

If the update changes IBlockStates, then by default, the TileEntity is removed. Does this issue still happen after overriding TileEntity::shouldRefresh to return oldState .getBlock() != newState.getBlock()?

Perhaps. What program do you use to create the OBJ models? I know that in Blender, with default settings, a normal sized block corresponds to a cube at x 0.5 y -0.5 z 0.5 at scale 0.5. While I know that you are not using a block, this should help you narrow down issues with size and/or translation The ObjLoader also only support faces with a maximum of 4 vertices. Be sure to have the checkbox for "triangulate faces" marked, though issues with that should be logged. This could also be an issue with the texture. Are you applying the texture to the material, or to an actual UV-map? The second option is the one I use. Try setting the render to "textured" at the bottom of the screen, to get a (bad) preview of the model with texture. Also be sure that the Normals for this item are OK. If the model is rendered inside-out, you wouldn't be able to see it.

If you look at Entity::rayTrace in your IDE, you can see that the method is annotated with @SideOnly(Side.CLIENT). This means this piece of code only exists on the client (it was moved to the client because it was never used on the server, by the deobfuscation process) You have to copy the logic inside of Entity::rayTrace and put it somewhere in your own code, and call that instead.

Ah, misread. They are, and the execution is the same as the example blockstate I linked. Here, the sole variant used for items is "inventory".

I'm not sure how you are not getting any issues. Minecraft needs the variants for this block, which by default are "normal" and in the case of corresponding itemblocks, "inventory". This is how I usually write my blockstates for OBJ models. Though you'll likely won't need the "transform" block, and the "defaults": "model" should correspond to "forge:default-block"

That is used to manually load a model (Equivalent of ModelLoaderRegistry#getModel) To have the ObjLoader scan your resources, one needs to call OBJLoader::addDomain(modid) during either the ModelRegistryEvent or preInit. The former is preferred.

You can use B3D or OBJ models for this, though you will require one model for each state (which will bloat your mods filesize) You can also create an ICustomModelLoader, which loads a custom (dummy) IModel, which loads an IBakedModel. This is where you can get access to the blockstate, and in IBakedModel::getQuads, create a list of BakedQuads, which determines how to render what. You're gonna have to get the default non-rotated model, get it's quads, rotate them, and return that. As for how you're going to rotate them, you can look in TRSRTransformation how vanilla handles 90 degree angles, or look up other sources. Due note, to optimize the second option, only rotate each state once. Once you've rotated, stick the List<BakedQuad> in another list, which is sorted according to the rotational property of the model (rotation 0 = 0 degrees, rotation 1 = 22.5 degrees etc) and in the mentioned IBakedModel::getQuads, check if you have the model for rotation X. If you do, get it from the list. If you don't, make it, and add to list.

Hello MrWisski, long time no see o/ Are you sure that BlockSoil:: initModel is actually called? Your ClientProxy#registerModels calls ModBlocks::initModels but does that reach BlockSoil::initModel? Are you sure that BlockStateContainer::getValidStates return the appropriate states, or does it only return a list containing the default state? If worse comes to worst, you can likely create your own ICustomModelLoader and create the baked models specifically for these ItemBlocks, but that's like lighting a candle with a flamethrower mounted on a tank.

When a player dies (and during dimension travel) the player instance is removed, and a new instance is made. This is likely why the "save-state" is null. You will need to transfer the data just like with Capabilities. Oh, and you should not store the EntityPlayer (or derivatives like EntityPlayerMP) directly. You should be using a WeakReference<EntityPlayerMP> instead. Storing an EntityPlayer can cause memory leaks. What if the player dies repeatedly? A new savestate would exist for each player instances, and the old player instances would not be garbagecollected because they're still being referenced. A WeakReference allows the garbagecollector to remove the player from memory in case of death/log outs etc. Alternatively use the UUID instead, and get the EntityPlayer from that.

If your quest-system makes use of the Capability System, you need to transfer the data to the "new" player, as mentioned in Forge's documentation. https://mcforge.readthedocs.io/en/latest/datastorage/capabilities/#persisting-across-player-deaths

Use world.isRemote to see on what logical side you are on.

You don't need to mess with individual if-statements. All of these crops extend BlockCrops Check if the block extends BlockCrops, then cast it. From there, call BlockCrops::isMaxAge(IBlockState), if so, call BlockCrops::withAge(0) to get a new IBlockState of the crop, with age of 0.

You're not "damaging" it here, you are actively removing one item from the stack. If this is a non-stacking item, well... 1-1=? Use ItemStack::setItemDamage(stack::getItemDamage() + x) to set damage. Furthermore, if this is your own item, you should Override Item::onItemUse instead of making an event-handler

Don't use Minecraft::getItemModelMesher. Prone to issues. Forge has since several versions now included the ModelLoader as a more reliable Model handler. This is how I manually load a (normal) IBakedModel. To load a .OBJ model, you need to call OBjLoader::loadModel instead of ModelLoaderRegistry::getModel.

Oh, and as far as I know, defining textures inside of the BlockState.json for a .obj model is not plausible, as that is handled by the .obj's accompanied .mtl file.

Before you register your models during preInit or during the ModelRegistry Event, you need to call OBJLoader.INSTANCE.addDomain(your-mod-id) This is to signal Forge that "hey, at least one of my models are going to be .obj, so have that loader checking my stuff as well". I also have a working BlockState.json for a .obj model here. Feel free to take a look.

To quote myself from a similar post calculateCelestialAngle is the method Minecraft uses to figure out time for the WorldProvider's associated dimension. If you override it, you can make it state whatever time you want.