ChampionAsh5357

FMLPaths.GAMEDIR.get().resolve(FMLConfig.defaultConfigPath()); should allow you to get the default config path. This returns a Path object.

For future endeavors, you might want to get the BlockState of whatever block you are trying to use. From there, instead of using ItemRenderer, you should use BlockRendererDispatcher and figure out which method best suits what you are trying to do. I'm not necessarily sure if this will work, but it never hurts to try.

I would recommend going into net.minecraftforge.common.ForgeModConfig and the net.minecraftforge.fml.config package in the source and looking at how they setup and register it. Then all you need to do is register the config in your main mod file's constructor using ModLoadingContext#registerConfig. The best I can do for a visual example is my classes for the Config and Main Mod File.

I am currently trying to create a concept where an item can be combined with another item in some sort of recipe serializer to create it so that one item is rendered like the other. The way I was approaching this was to just attach an nbt which holds an item registry name and then it gets the item when being rendered. The issue is that there is no easy way to override ItemRenderer#getItemModelWithOverrides to set this value. There are registry events but in all cases it would take removing that stack and rendering a different item in multiple different places which is just highly tedious. So, is there a way to hook into this method to have it check for the nbt first before trying to render the item? Any input is appreciated for methodology.

If you have registered your configuration file, it should be in run/config/whatyounamedit.toml The default name would be modid-side.toml If you do not know where your run folder is, it should be in the same directory as your src folder that you are currently working on. Note you do have to run the game once to generate the configuration file.

this.blit(screen_xpos, screen_ypos, texture_xpos, texture_ypos, texture_xsize, texture_ysize); The first two render the x and y position on your screen. The second two get the top left corner of the texture to use. The final two get the size of that texture.

If you look at the class, you can tell that blit draws the binded texture to the screen. It would make sense that the first blit renders the entire screen since it is the gui and background layer to be rendered. This would mean that all other blits are used the render the overlays (arrow, bubbles, blaze input). Deconstructing that further, the integer l seems to clamp down a value divided by 20 between 0 and 18. It also has a integer of k which, if you search what it equals to, is the fuel or blaze input. This means that the blit that is handled by integer l is the blaze input. This means that the last two blits handles either the arrow or the bubbles. Since the second blit of the last two clearly handles the bubbles (it says bubblelengths), then the first blit of the last two must handle the arrow overlay.

You should try to create a standard block model for the torch rather than using the one provided in Minecraft. Minecraft does a very strange thing with the torch by creating two extra cubes to render the sides of the torch without uv distortion. I'm not sure why they use this, probably someone more knowledgeable about how Minecraft was programmed could answer that. However, this sort of poses an issue when rendering. The torch by default is rendered as a cutout while the stained glass is rendered as translucent. This means that either the glass will be treated as a cutout (no variable opacity/alpha) or the torch will be treated as translucent (texture might incorrectly render at some places since it is still 16x2 or 2x16 on the cubes). The best way to fix this is just to adjust the torch element so that it is just a single block rather than 3 cubes that render the sides. If you have done that, the code should look somewhat like this for the torch faces: "north": {"uv": [7, 6, 9, 16], "texture": "#torch"}, "east": {"uv": [7, 6, 9, 16], "texture": "#torch"}, "south": {"uv": [7, 6, 9, 16], "texture": "#torch"}, "west": {"uv": [7, 6, 9, 16], "texture": "#torch"}, "up": {"uv": [7, 6, 9, 8], "texture": "#torch"}, "down": {"uv": [7, 13, 9, 15], "texture": "#torch"} This should remove the need for your block to be rendered as a cutout making it valid on any render layer.

Well the error says that the entity is already tracked. So at some point in your code, you ended up generating two entities with the exact same id. The only way to get two entities of the exact same id in the world is to spawn the same entity twice. How do you spawn an entity twice? Well you spawn an entity even though the game code already spawns that same entity for you. A good place to start is looking where you add an entity into the world and then ask yourself, "Is Minecraft already doing this for me?" On a side note, keep your client and common side separate. You might accidentally call client side only code from your common which will prevent your mod from running on servers.

Please recognize what version of Minecraft you are using before asking about a class. Some classes have been removed, others have been redone, and finally (in your case) some classes have been renamed. The easiest thing to do would've been to open up a source version with IBlockState (e.g. 1.12.2) and then looked at your current version (1.15.2) and then finding what has changed. In this case, a quick look would have told you IBlockState was renamed to BlockState. Second, the Block class methods are usually deprecated since they only check for that specific block. The BlockState class has the same methods without deprecation since they can check for multiple states of that block. Implementing and overriding deprecated methods are usually okay since most are reused in the BlockState. However, when we are calling those methods we should stick to using the BlockState function calls over the Block function calls. Deprecated methods usually are obsolete for similar reasons. Finally, the error message is probably because you most likely did not generate the specific files required for the workspace you are using. Although, you should use the latest versions since they do have some necessary updates that might fix some bugs you run into later on.

If you looked at the BowItem code, you would see that it looks for items within the ARROWS tag. So yes, you would need to add your item to the arrow tag. Adding an item to a vanilla tag is just as simple as navigating to data.minecraft.tags.items.tagname.json and creating a json file which holds the registry name of your item. Just make sure you have the replace value set as false since you do not want to override anything. Also, for future reference, if you don't know how to do something related to json files in Minecraft, you can google it. There is documentation all over the internet about how to do it. Some good examples is the Forge Documentation and the Minecraft Wiki which tells you literally how to create a json file for tags. If you need a visual reference, the data folder in Minecraft holds all the tags (which in your workspace should be under client-extra.jar) so you can just open one of those json files and just copy it replacing its items with yours.

My guess is that you haven't created a static instance of the ItemGroup, rather opting to create a new instance every time you set in in game. I would recommend creating static final instance of the ItemGroup in your main mod class and then adding your items to that group using the instance. If you're not completely sure what I mean by that, do public static final ItemGroupName VARIABLE = new ItemGroupName(); and then call Mod.VARIABLE when setting the ItemGroup of your items. That should hopefully fix your problem.

Fluid movement is explicitly checked for anything in the water tag. One way to fix this would be to append your fluid static/moving block to the water.json tag, however, then your fluid would act like water as well. Another way to do it would be to update the tick event for the player and change the movement there, however, that could also lead to some movement bugs within the water.

Currently I am building a recipe serializer system which incorporates aspects of blocks such as their current state in the world. I am currently stumped on trying to reconstruct a state given the block name and properties. References like BlockStateProperty do allow me to check the input state to make sure they are equal, but there is none which I could find that allows me to fully construct one. The issue is with setting the property values since I cannot be sure of its type. So I am wondering if there is a way to construct a state using a json file. From there, the write and read methods of the PacketBuffer are easy to implement since properties are stored as strings and elements anyways.

You definitely didn’t remove the other instances of setRegistryName.

Did you remove the other instance?

Reverse what you did. I said attach the setRegistryName you declare in the event and just add it to the end of each EntityType variable (e.g. public static EntityType<Vampire> vampireentity = EntityType.Builder.<Vampire>create(Vampire::new, EntityClassification.MISC).setShouldReceiveVelocityUpdates(true).setCustomClientFactory(Vampire::new).setUpdateInterval(1).setTrackingRange(128).size(1F, 1F).build("element:vampire").setRegistryName(“element”, “vampire”); ). Then just remove the healentity.setRegistryName("element", "heal"); you wrote in the registry event. If that doesn’t work, I’m not entirely sure what the problem would be.

The same way you have here you just append to the end of your EntityType instance. So it would be build(id).setRegistryName(registryName).

instead of where you have it now.

My best guess is that you should probably set the registry name on your EntityType instance since you are not using dependency injection for registering.

Entities are registered through EntityType<T extends Entity> using EntityType.Builder#create and then finalizing with EntityType.Builder#build. Each EntityType needs an instance of the entity constructor holding the EntityType and World as parameters along with the EntityClassification. From there, you can modify the standard entity information such as its size, update interval, tracking range, etc. If you want a spawn egg for your entity, you have to create an item that use the SpawnEggItem class or create your own.

Currently the HarvestDropsEvent hook has been removed since the original method it hooked onto no longer exists. Until it gets re-implemented, is there any other way to override all block drops? I am currently using a potion to modify block drops when active so just creating a json file will most likely not be helpful. I was originally looking at Block#getDrops, but I have no idea how to override it for all blocks without adding the Forge hook.

You need to set the render layer using RenderTypeLookup#setRenderLayer within your FMLClientSetupEvent to make blocks transparent. It takes in two parameters: the block and the RenderType. The RenderTypes are as follows: Solid - field_228615_R_ Cutout Mipped - field_228616_S_ Cutout - field_228617_T_ Translucent - field_228618_U_ Translucent (No Crumbling) - field_228619_V_ Leash - field_228620_W_ Water Mask - field_228621_X_ Glint - field_228622_Y_ Entity Glint - field_228623_Z_ Lightning - field_228624_aa_ What you are looking for is either cutout mipped or cutout so use either RenderType#field_228616_S_ or RenderType#field_228617_T_ to accomplish this.

After changing my code to match Minecraft's style, there seems to be no support for liquid containers other than water. If that's the case, how would you get other liquids to render inside the block? It seems like this system was only made for one instance and no other case.

You know I feel like such an idiot sometimes. But then comes the problem of having multiple fluids inside the block. Do I need to create a state for each fluid? If so, then would it require to have a state for the flowing version and the source version? What would come about for modded fluids then as well? I don't really see a way to have a state for each fluid in the game dynamically.