Alpvax

Is this what you actually meant to do? Just register the command you have created, instead of redirecting it to itself. Yup, you are registering it on the server, so any packets you send need to be from the server to the client (HINT: you have the correct client to send to passed into your 'run' function). Perform your logic directly in the 'run' function of your command, and if you need it on the client, send a packet to just update the client with the new value (don't do any calculation on the client, do it on the server and send the result).

Then you need to create a custom IRecipe type, which checks whether or not the player has the advancement as part of the recipe. Last time I looked, the only way to get the crafting player was by reflection (although that was a while ago).

Oh dear, I can see multiple issues with your code: What on earth are you trying to achieve with this? This will never work. If you are on the server (i.e. trying to send a message to the client), you CANNOT use Minecraft.getInstance(). Also, I'm pretty sure most (if not all, I haven't looked in a while) commands run on the server, so you shouldn't need to send packets (unless you need to update the client(s)). Please show where PointsCommand::register is called (just to check that it is being registered on the server).

That is a really bad idea. If your mod does nothing, there's no point having it installed. If your mod does something, it should show up in the mod list. Otherwise, if there is a strange interaction between your mod and another one, it becomes very hard to find the problem (because the users don't know they have your mod installed).

Try looking at the ender dragon code. I havent looked in a long time (so it could well have changed) but it used to be made up of multiple parts.

Use the dependencies in mods.toml. If they aren't satisfied, the mod won't load and the user will be shown an error

Show where you are sending your packet (the command). If you send the packet to the client, it will be handled on the client, so the server won't get updated.

Vanilla has this feature: /gamerule doLimitedCrafting See http://minecraft.gamepedia.com/Recipe_book#Obtaining

You still haven't taken into account user resource packs (i.e. those which are not in a mod jar). You would have to re-hash every time someone changed a resource pack, including in-game.

I seem to remember one of the mdk versions shipping with the vanilla code (and all the blocks) but the newer versions have that all stripped. What remains is helper functions to create standard blocks, fences, stairs etc. It is easy to strip from your mod if you really want to, as it is all called by events. Just exclude that class file from the build task, but how much space does a single class file take up (for me, including all my blockstates, models, recipes, tags etc., it's < 40kb uncompressed, and I've got a load of junk in mine that I was experimenting with)? For example, it is far easier to create a new fence model by creating the "fence_post" and "fence_side" models (just binding a texture to the parent models, can be done easily with a function call each) and calling a single method, passing those ResourceLocations in, than it is to manually create the multipart model file.

It was added by Mojang for their use, and has been extended to be usable by forge mods. It means that you don't have to manually create json files for all your basic blocks which are identical apart from texture. No, you can leave it there. During normal running, the event isn't fired, so the code isn't used (and probably isn't even loaded if it is in a separate file).

Hmmm... I wonder what would happen if someone wanted to change the textures with a resource pack? Which can be done in-game, and now instead of just loading and stitching the textures, it has to hash and save. And then the player decides they didn't like that resource pack after all...

What exactly are you trying to do? I use that method to conditionally highlight sub segments of my block (by returning a different voxelshape).

Unfortunately, so much has changed since 1.7 that you're better off rewriting the mod from scratch (create a new workspace so you can copy the old functionality).

Oh, re-reading the code, I think you need to override canStickTo to only return true if the other block is itself or non sticky. To be honest, I'm surprised that slime doesn't push your block.

So you have an instance of the player (the one using the table). Use that player to get the server: player.world.getServer();

Your way will crash on a server. Where are you calling this from? What are you trying to achieve?

If it's your own block, you can override Block#getShape: @Override public VoxelShape getShape(BlockState state, IBlockReader worldIn, BlockPos pos, ISelectionContext context) { if(context instanceof EntitySelectionContext) { Entity e = context.getEntity(); if (e != null) { // Perform your logic } } return super.getShape(state, worldIn, pos, context); }

I think you need to leave the default implementation of canStickTo, just override isStickyBlock

Registry events (and lifecycle events, config events etc.) are fired on the mod bus (anything to do with your mod). Game events (player interaction, damage, crafting etc.) are fired on the forge bus. If you aren't sure, it usually tells you which bus to use in the javadoc for the event.

Look at https://minecraft.gamepedia.com/Model#Block_states. Specifically the "multipart: Used instead of variants to combine models based on block state attributes" part. It allows you to declare individual states and models for each. Fences show how it is used.

Just checked, you're listening to the wrong event bus. You want the Forge bus, not the Mod one. (bus = Mod.EventBusSubscriber.Bus.FORGE)

If you are subscribing the events to the class, the methods have to be static (there is no instance to access the methods on).

For starters this: .setRegistryName("[NAMESPACE HERE]","steve_head") won't work, everything has to be lowercase (and the namespace should be your modid). Secondly, What is the error? Show us your log file.

Look at the blue banner at the top of the page: "New LTS System, 1.14 and moving forward" 1.12 is no longer supported on this forum. Update to a newer version.