V0idWa1k3r

Most of the things are still the same IF you were following modding conventions. I don't agree, actually. Everything is now done using event subscribers. So instead of having EventHandlers in your mod class you now have just normal events, like FMLCommonSetupEvent. You subscribe to them just as you would to most other events. The thing to be aware of is that there are 2 event buses now - the mods specific one and the generic forge bus. Things like registry events happen on the mod bus while generic events happen on the forge bus. Not much has really changed. Subscribe to the appropriate registry event, instantinate your things there and you are done. Nothing about creating items or blocks has changed apart from some parameters like hardness now being final - but that's what the Block.Properties or Item.Properties you pass to the constructor are for. Item models are also automatically registered for you now, just as blockstates, so you don't have to register them yourself anymore. Unlocalized names are now the "prefix(block or item).registryname" and the language files are now simple json files. As for the mod's .toml file the example mod provides a pretty good explanation in my opinion.

Entity is not a RegistryEntry thus it can't be used as a parameter for the registry event. use EntityType. Well obviously you don't just copy-paste my explanatory-example line. Replace the placeholder variable names with what you actually need.

It's a registry event. You are already using these for your blocks and items, and there is one for entities too. If you are talking about events then no, you don't. Since the flattening each egg is now it's own item. So you just register a new instance of ItemSpawnEgg in your item registry event. They do need the EntityType in their constructor though so I guess you'll have to instantinate them in the item registry event too, but register in their registry event. Just store them in a field(don't instantinate them in that field though). The other two parameters are the colours of the egg.

These are methods, you override them just as you would with any other method. //In your registry event event.getRegistry().register(EntityType.Builder.create(YourEntityClass.class, YourEntityClass::new).tracker(range, frequency, sendvelocity).build("modid:name"));

This issue is known to the dev team: https://github.com/MinecraftForge/MinecraftForge/issues/5469

Block.blockState is now Block.stateContainer. As stated in my previous reply this is done through a builder now. CreativeTabs is now called ItemGroup. As stated in my previous reply EntityRegistry is gone. I don't know where you were importing FACING from but you can get all vanilla blockstate properties from the BlockStateProperties class. Instead of a single IBlockAccess there are now a lot of various interfaces that the world implements. I don't know which methods of yours needed the IBlockAccess so I can't tell for sure what it needs now but I suspect it needs a IBlockReader. As far as I can tell from your code that points into your main mod class so you've removed that field yourself. As stated above this is done through a builder now. Also that syntax was never needed in the first place. PropertyDirection is now DirectionProperty. Again, that points towards your main mod class, you've removed the field yourself but left the reference. As stated above this is done through a builder now. Instead of a single IBlockAccess there are now a lot of various interfaces that the world implements. I don't know which methods of yours needed the IBlockAccess so I can't tell for sure what it needs now but I suspect it needs a IBlockReader. As stated in my previous reply this is now done through Block#fillStateContainer Since metadata is now gone those helper methods to convert to and from metadata are gone too. IBlockState#getValue is now IBlockState#get. Block#isOpaqueCube is now controlled through it's VoxelShape returned by Block#getRenderShape and simply checks if the given shape is a full cube. It will also return false if Block#isSolid returns false. Since hardness is now final the setters are gone, use Block.Properties passed to the constructor to control it. Same here. And same here too. Unlocalized names are now gone. Instead they are controlled by Block#getTranslationKey which uses the registry name (block.REGISTRY_NAME). This is done for you automatically, you don't need to set anything. IBlockState#withProperty is now IBlockState#with. I don't know what you were using this for but be wary of an ongoing issue: https://github.com/MinecraftForge/MinecraftForge/issues/5470

What do you mean? There is an integrated server in the singleplayer world too, any command registered will work in singleplayer just as well as in multiplayer. Please elaborate on your question. Do you need to create client-side only commands or do you wish to know how to register commands in general?

Don't expect your 1.12.2 code to work in 1.13 without issues, there have been major changes. For example let's look at your block class: All of these are now set through the Block.Properties passed to the constructor. As they are now final their setters are gone. These are now controlled by the new VoxelShape class and thus the methods you need are Block#getShape and Block#getCollisionShape. To create custom simple VoxelShape instances use Block.makeCuboidShape. BlockStateContainer isn't constructed manually anymore. Override Block#fillStateContainer and append your properties to the builder. Metadata doesn't exist in 1.13 thus these are completely pointless. EntityRegistry is thankfully finally gone and replaced by the registry events(to be fair it was replaced in 1.12 too). Construct and register EntityType instances in the appropriate registry events. For now models for items are registered automatically so the stupid IHasModel can finally rest in pieces. You don't need to register your models manually anymore. As for the more complex models the api isn't done yet I suspect. Don't. Instantinate your stuff in the appropriate registry events, not in a static initializer. These are block properties like hardness, sound, etc. See how vanilla constructs them in the Block class. Give me a bit of time and I will post a detailed response to your error list.

If you are using idea just import the mdk as a gradle project, gradle will handle everything for you after which you canrun genIntellijRuns. If you are using eclipse run the eclipse task although I believe you might be able to just import it as a gradle project aswell.

You are already using the correct event, you just need to implement this logic.

Don't. IHasModel is stupid cargo-cult programming. All items need models, no exceptions, and nothing about model registration requires you to access private/protected data. Register your models directly in the ModelRegistryEvent. This screams static initializers. Don't ever use static initializers since then you lose control over loading order and can introduce all sorts of bugs. Same here. Instantinate your stuff in the appropriate registry event. This will always be false. If the block at the given position receives a tick then the chunk is loaded. Why do you have these all over the place? They don't do anything in your code. This will always be false because IBlockState will never be equal to a Block. A block at the position passed will be your lily pad, it can't be water. This will always be true since the argument passed is of an Entity type. You don't need this comparason at all. ...why? Well you are kinda close to the solution yourself, you just need to offset the position given to you in the method. And fix all those other issues.

You have posted a function that doesn't tell me anything. I don't know where it is defined and what your proxy's registerItemRenderer does. Although this alone leads me to suspect you are using IHasModel in which case - don't.

Please provide more information. How are you registering the models for your items? Are you using forge's blockstates for them?

You can do similar things to what raytracing blocks does, just for entity hitboxes. As in study the code for raytracing blocks and write similar code for entities. There really shouldn't be much difference since the code is working with AABBoxes in both cases. However entity hitboxes won't work if you want to detect specific body parts. In that case you can see my suggestion here:

I assume you mean whether the MCP names are applied or not, since your mod will never run in a vanilla minecraft environment(unless you are doing jar mods/coremods but we don't talk about that) You can simply use reflection to check for an existance of any field in vanilla minecraft's code with it's mcp name. If it exists then your environment is the dev environment. If there is no such field then it isn't.

That's how block rendering works, it needs a blockstate file. The blockstate file resolves the blockstate of a block to a model. Define "registering as full blocks". They are full blocks. If you mean the adjacent blocks having the sides touching the frames be transparent you need to override Block#isOpaqueCube and return false. As for the missing model block post your startup log, it should contain an error related to it.

https://github.com/Esrome/science-mod/blob/master/1.12.2/src/main/java/esrome/scienceMod/blocks/containers/ContainerSteamGenerator.java#L54 You don't need al this get/setField IInventory nonesense. Just access your fields directly. https://github.com/Esrome/science-mod/blob/master/1.12.2/src/main/java/esrome/scienceMod/blocks/containers/ContainerSteamGenerator.java#L74 I think you have a typo here. You also need to send the initial state of the fields in Continer#addListener. Unrelated but still issues that need fixing: https://github.com/Esrome/science-mod/blob/master/1.12.2/src/main/java/esrome/scienceMod/blocks/BlockBase.java You don't need this, there is already a BlockBase, it's called Block. By using this you are prohibiting yourself from extending other Block subclasses and minecraft uses quite a lot of instanceof checks. Use utility methods instead. https://github.com/Esrome/science-mod/blob/master/1.12.2/src/main/java/esrome/scienceMod/energy/ElectricityStorage.java Why can't you just use EnergyStorage if all your overridden methods default to super implementation anyway? https://github.com/Esrome/science-mod/blob/master/1.12.2/src/main/java/esrome/scienceMod/util/IHasModel.java IHasModel is stupid cargo-cult programming. All items need models, no exceptions, and nothing about model registration requires access to private/protected data. Just register your models directly in the ModelRegistryEvent. https://github.com/Esrome/science-mod/blob/master/1.12.2/src/main/java/esrome/scienceMod/proxy/ClientProxy.java#L9 This makes zero sense. Your client proxy can't extend your server proxy. Proxies exist to separate sided-only code. A server proxy either provides noop implementations for client-only methods or runs code that would crash the client. Extending it like this will crash your client if you at one time will use the server proxy to do something server relater. https://github.com/Esrome/science-mod/blob/master/1.12.2/src/main/java/esrome/scienceMod/init/ModBlocks.java#L20 Don't ever instantinate your stuff in static initializers. Static initializers remove your ability to control loading order and may cause all sorts of issues. Instantinate your stuff directly in the appropriate registry events.

You could generate the sphere's mesh on startup and render it. That would require you to write an algorythm that does that though. Another option is to create your sphere in any kind of 3d model editor, export it to something that's easy to parse like wavefront, parse it into a collection of vertices and render that.

If you are already translating to x,y,z then there is no need to draw the vertices from x,y,z since they are already at x,y,z.

GlStateManager just manages the various state parameters of opengl like blend, culling, light, etc. The drawing is not done through GlStateManager. To draw vertices you need to understand that a vertex is just a collection of data in a certain arrangement that defines the properties of a point. Several points make a polygon of a kind(a quad for example). To draw vertices you first need to start drawing using BufferBuilder#begin. The first parameter is the type of polygons you will be drawing. You can get the constants directly from GL11. The second parameter is the format of your vertices - the order in which the data is arranged. You can get the formats from DefaultVertexFormats and their names are pretty descriptive apart from BLOCK(pos vec3, color vec4b, uv vec2, lightmap vec2s) and ITEM(pos vec3, color vec4b, uv vec2, normal vec3). Then you can start defining your vertices. They must match the format and the amount must match the amount per polygon * number of polygons(note that you can draw multiple polygons in one draw call). To define a vertex use the methods in BufferBuilder. For example, if you want to draw a simple quad it would need 4 vertices and would look like this(example with the POSITION_TEX format) bb.begin(GL11.GL_QUADS, DefaultVertexFormats.POSITION_TEX); bb.pos(xs, ys, z).tex(us, vs).endVertex(); bb.pos(xs, ye, z).tex(us, ve).endVertex(); bb.pos(xe, ye, z).tex(ue, ve).endVertex(); bb.pos(xe, ys, z).tex(ue, ve).endVertex(); Tessellator.getInstance().draw(); The order in which you define your vertices also matters, because opengl will not render everything that doesn't match the order to save on rendering time - that's culling(if it is enabled). Minecraft usually defines vertices counter-clockwise but you can change that using GlStateManager. Just don't forget to reset it back after you are done.

You can't just instantinate your potion twice and call it good. The potion type needs a reference to an existing potion. To get a reference you can use @ObjectHolder. I don't know how you are applying your potion but if it is through a bottle then this is your issue. Why do you need this helper? World.isRemote is enough and shorter. The reason I am wary of this is you might have implemented it incorrectly and are mixing the client and the server which would be the cause of your problem(although I don't know how you are adding the potion itself). Fix these two, they are big culprits and if that didn't help proceed with the debugging: Place a breakpoint in EntityPlayerMP#onNewPotionEffect to see if it is triggered for your potion and one in NetHandlerPlayClient#handleEntityEffect to see if the client is receiving the packet for your potion effect.

If it's your own capability then you can just instantinate it directly. Use the getDefaultInstance to grab a default instance for a modded capability that you need. In general if you can instantinate it - you probably should. I would also recommend reading about capabilities on the official docs, they might answer some of your questions. Feel free to ask if you don't understand something.

You don't need to get an instance of the capability like this for the IItemHandler since forge provides one for free at CapabilityItemHandler.ITEM_HANDLER_CAPABILITY. You can though, obtaining capability references using CapabilityInject is the way to do this. Don't do this for inventories. This method is acceptable for capabilities provided by other mods if you just need the default instance but an inventory capability holds a certain amount of slots, which you declare in it's constructor. Just instantinate ItemStackHandler. This is a forum, not a chat room, please be patient.

In your getSubItems you must check that the tab you are adding the item to is the tab it is supposed to belong to. Otherwise it gets added to every single creative tab, including the delete slot.