Animefan8888

If you look at the TridentRenderer you'll notice that the same field name actually points to a texture(png) file that the renderer uses.

Yes? Should look something like this. clientSetupEvent(FMLClientSetupEvent event) RenderingRegistry.registerEntityRenderingHandler(YourEntity.class, manager -> new SpriteRenderer<YourEntity>(manager, Minecraft.getInstance().getItemRenderer());

What does this file look like? What does this function do?

You'd put it anywhere. Static variables only exist once. No it would only compute it where you told it to compute it. I would need more information on what would affect the values to determine where it should be computed.

No dont do this. You only need to register it once. Not every time a player logs in. Check if the entity player is the client player? Assuming I understand this correctly. player == Minecraft#player

Then you dont ever need to save it. You could just compute it at startup. And store it in a static variable. And if it is customizable/world dependent sync it from the server to the client.

If you can list more APIs that have been removed would be a good place to start. You've gotta use the new Features system there are quite a few posts on here already about ore generation and structure generation. From what I know not much about TEs has changed just the way they are registered. They finally have a registry event where you register a TileEntityType. GUIs are now called Screens and they need to be registered with the ScreenManager class. Containers also have a registry now where you register types ContainerType. Not sure what you are having a problem with here besides the ToolMaterial and ArmorMaterial changes. There are now interfaces that are used instead of EnumHelper. For tools in particular create an enum that implements IItemTier(I think that's the name). I dont know what has changed here. What problems are you having? No need for most of it, the flattening removed the need to register models. They are all registered automatically now based on the registry name. Yes here.

Instead of using 2 as the flag in setBlockState use 3

Don't use his tutorials they tend to use improper methods to get stuff done. Your public static final String modid has capital letters in it. Make it lower case. Modid's have to be lower case.

First that's not where the RenderingRegistry goes. Second are you sure you are spawning your Spear Entity? What about your Renderer what does that look like? Is it using your model or is it using the Trident's model?

It uses the SpriteRenderer class which you can use too.

If you're just saving an array list that stores two values you should store a ListNBT or a TagListNBT. I'm not sure what it was changed to recently. But that tag list needs to store a CompoundNBT in which you will call CompoundNBT#putDouble(ID, double) and CompoundNBT#putString(ID, string)

No they do not. In order to do this I recommend using your own custom arrow instead of the regular one. Just replace the original one spawned with your custom one when the conditions are met.

Dont create registry values outside of a registry. Have you registered a renderer for your entity? For the Item? Why do you check this over and over. Its unnecessary. Just check it once and check all of your blocks like this (block == Block1 || block == Block2) With the parentheses. You should return your Item here not the egg item.

You'll need a custom IRecipe and either a IRecipeFactory(1.12) or an IRecipeSerializer(1.14)

That's caused by you using the EntityType.EGG instead of your EntityType

Post the error again it could be slightly different. Also maybe change this.blockState.getBaseState() in your blocks constructor to getDefaultState()

Lighting needs a block update. Give the blocks a block update when you place them. You'll have to put them down last they are probably receiving neighbor placement updates. Place things that rely on surfaces last. Or make sure the surfaces are placed first.

Don't know what your asking here. I only referred to registry events. IE Register<Block> No. You just need to do something like this @ObjectHolder("modid") class Registry public static final Block SOME_BLOCK = null; registerBlocks event.getRegistry().register(new Block(...).setRegistryName("modid:some_block")) Boom done.Then you can reference the value you created in the registry event by using the SOME_BLOCK field.

Because it's easier to just loop through a Set/List of Item/Block(technically still an Item) and register them directly in the ModelRegistryEvent with a for loop. It's much simpler and you only have to write it once instead of every new class. Inside their registry event. Use the @ObjectHolder annotation it retrieves objects after the registry event has fired. And applies the value to the field.

No stop using this. Don't statically initialize your Block or Item or any registry values. This isn't quite enough information to diagnose the problem. Post the whole error.

You need a javaw.exe at the end. Cool. People on here have lives too. And they don't have to answer you. So sometimes you need to be patient.

Don' change the values on the client based on what the client says is true. The client can and will lie. Always and only change the data on the server and then sync it to the client via the use of packets. It's actually the other way around. I can't remember the explanation I've heard for it's name though. But basically always check for !world.isRemote or Entity#isServerWorld; which both do the same thing.

That's not true it's built in to the instanceof check. And getSource() will never return null.

You need to call tickRandomly on your Properties or override ticksRandomly(BlockState) in your Block file.