ChampionAsh5357

Probably true, you most likely didn't sync the data from the server to the client so the client remembers the items that were originally there without the update. If you have a container, it should be the same process as anything else to add the container to the gui. Telling us something is wrong without showing a reference is also not helpful since we have to guess on what to fix based on prior posts.

This is not a capability, the nbt data is only useful when saving or loading a world in this case. What you've done is literally nothing since the data will never be read.

Would you happen to be able to show your code? This is a very general statement. You should only need to store the UUID of the player.

If you are using a vanilla item yes. If you are creating your own item override onItemUse or just make it a BlockItem.

I think the correct implementation is something like this: public static final FillerBlockType VAR_NAME = FillerBlockType.create("VAR_NAME", constructor_variables...); The enumName refers to your own variable that you are creating.

If I remember correctly, the enumName is the name of the variable you are defining the enum value for (e.g. NATURAL_STONE, NETHERRACK). If it's not that, it probably is the name of the enum class.

There's an event for that: PlayerInteractEvent#RightClickBlock.

PlayerInteractEvent#EntityInteract with some clever usage of a capability on the creeper probably would work.

One of your ITextCompoments is incorrectly reading information. Maybe its an uninitialized string object within your tile entity. Maybe its the fact you have I18n on a variable in your container even though its client side only. You could easily put a breakpoint at all of your ITextComponent instances and find the location where it errors. I'm not sure where the exact error is, but your code seriously needs an overhaul to the current standard including no IInventory, TranslationTextComponent, etc.

A good thing to look at is the log since it does check if there is an error while parsing a blockstate in a certain space. Based on a quick glance, you seem to have a random structure block with no metadata in your nbt making it completely pointless. I didn't see anything wrong with the code itself, but I also have very limited knowledge on nbt loading of structure pieces. I still need to create some tests of my own.

When adding a structure, you must do two things. First, you must add the feature to every biome as you did. Then, you have to add the structure to the structure map using Biome#addStructure. I think that's it since everything else seems correct.

Then yes, you would sync those values in a packet, except you're not changing the config variables. You're storing the result in wherever you are using the HUD. Basically, when turning on the hud, send a packet to the client from the server side containing the variables stored in the config. Then, store those values inside the HUD to be rendered. This way you are getting the variables from the server rather than the client. That's how I see it anyways.

You still need to sync the data between client and server when logging in.

I was saying that originally because I misunderstood your original intention. So, let's address it. If I understand this right, you want the dedicated server config to match the users own personal config file? I'm not sure why you would need to send a packet from server to client to recognize the change. My understanding of the config file is based in logical sides. There are two kinds of servers: IntegratedServer and DedicatedServer. The server uses the config file adjusted for common and server based code ignoring client (for obvious reasons). The need for updating the specific user is irrelevant since data such as what you are describing would be handled on the server side. If there is something that needs to require Minecraft to restart, then you would need to restart minecraft again to change them. You would need some instance of reflection to override that. Moreover, code would be handled by the server itself leaving only rendering details to be handled by the client making the whole point of a packet update seem quite useless especially since they're final values. I would recommend testing your mod using a server with a different configuration than the user and test it and see what results. If my understanding of config files is right, the server should reign over the user on a multiplayer world and only in a singleplayer world would the user's config be needed.

What's the point of having a configuration file if you want to change the variables within the code itself? Just create a temporary variable for testing purposes and change it to the config version once you have finished.

I would recommend reading up on logical sides. If you want to check whether the player respawning, you should use PlayerEvent#PlayerRespawnEvent unless you are doing something specific to the client side such as rendering.

Just because you put a method in-between two registers doesn't mean anything. You're trying to register the BlockItem before the Blocks have even had a chance to be registered. If you want to register an item block the way you're doing it, you have to wait for each block to be registered and then activate your method. Otherwise, use the same instance of the block used when registering in your item. One of the easiest examples of registering the block and item at the same time is like so: private static <T extends Block> RegistryObject<T> register(String id, T block, @Nullable Function<T, BlockItem> item) { if(item != null) CustomItems.ITEMS.register(id, () -> item.apply(block)); return BLOCKS.register(id, () -> block); }

If you have already created a block with a Container, you would know that using NetworkHooks#openGui is used to activate a container and its gui counterpart. Unless I'm mistaken, it should be the same process.

I mean that's what you use if you create an ItemEntity, set the position, and then spawn in the item.

I feel like that answers your question.

If you can find the folder where you extracted the forge contents into, you are going to open up a command window (Command Prompt, Powershell, Terminal, etc.) and then type 'git init'. From there, its the same setup as you would a normal git repo for whatever website you are uploading to.

Use a transparent texture? As for a git repository, initialize the git repo in the folder that holds the build.gradle file and then repeat the process when you create a repo as normal.

I feel like that's self-explanatory. Check to make sure you registered your block correctly.

Are you sure your constants are set correctly?

World#getHeight and IWorldReader#getBiome can help you with that. Here are also the six heightmap types and what they do: MOTION_BLOCKING: The highest block that blocks motion or contains a fluid. MOTION_BLOCKING_NO_LEAVES: The highest block that blocks motion or contains a fluid or is in the minecraft:leaves tag. OCEAN_FLOOR: The highest non-air block, solid block. OCEAN_FLOOR_WG: The highest block that is neither air nor contains a fluid, for worldgen. WORLD_SURFACE: The highest non-air block. WORLD_SURFACE_WG: The highest non-air block, for worldgen.