desht

The simple number of different packets in your mod has zero impact on performance. What does impact performance is ensuring you don't send packets unnecessarily, and that you encode information in the packet efficiently - don't send more data than is needed to convey the message (extreme & simplistic example: don't use a double to send a boolean value). Only send packets when you know the other side needs the information. Encode any data needed properly, e.g. don't use NBT for network data, use the smallest data type that fully describes the information you're sending. In your case, a simple packet sent when a player does a "left click air" action is no big deal. It doesn't even need any extra data encoded in it - whenever the server receives such a packet it has all the information it needs: "player X just did a left click air".

Get over your fear of sending packets. The server is never aware of a "left-click empty" event - that's even mentioned in the javadoc for the PlayerInteractEvent.LeftClickEmpty event. Your only option if you want to inform the server is to listen for that event on the client and send a packet.

@Blue_Atlas a bigger problem here is that ItemStack doesn't have a hashCode() or equals() implementation, making it unsuitable as the key for a Map; adding itemstack1 to the map, and then looking up by a different itemstack2 object will fail, even if itemstack1 and itemstack2 have exactly the same item/metadata/NBT. To do this correctly, you need to either use a wrapper class which correctly implements hashCode() and equals(), or take a look at the TCustomHashMap from Trove, which is included with Minecraft (todo: check if 1.13.2 still includes Trove).

I'm going to assume you're referring to TileEntityItemStackRenderer, since TileEntitySpecialRenderer has nothing to do with items (it's purely for tile entities). Assuming you're using a TileEntityItemStackRenderer, it's because your item has some special animation requirements, and you're not using the Forge animation system. Even in that case, your item will need a static model for rendering in a GUI, on the ground, in an item frame, etc. So no - there is no case for IHasModel, under any circumstances. It does not make your code simpler, it just adds unnecessary cruft. Please don't use it, and please, please, don't suggest that its use is in any way OK. As for your assertion that using a "CommonProxy" avoids cluttering the main file - seriously? If you're that concerned about clutter, put those "common" methods in their own class. But not in a proxy class whose sole point is to separate the implementation of client-only and server-only code.

If you need help porting, first have a read through https://gist.github.com/williewillus/353c872bcf1a6ace9921189f6100d09a. If you have specific questions regarding methods that don't exist anymore (i.e. equivalents for methods that used to be in FMLClientHandler/FMLCommonHandler), ask them. Right now your questions are a bit too vague to get useful answers.

Villager professions are in the registry, so set up an event handler for RegistryEvent.Register<VillagerProfession>. In your handler, create a new VillagerProfession object and register that via the event. To add trades, create a VillagerCareer object and use its addTrade() method. EntityVillager has a few static inner classes for convenience when setting up trade lists (e.g. ListItemForEmeralds).

According to https://gist.github.com/williewillus/353c872bcf1a6ace9921189f6100d09a#rendering-changes, "normal" is no longer a valid variant, and "" should be used instead. (That entire document is worth reading carefully, multiple times)

Think I've actually got this working by adding error-prone as a dependency: dependencies { minecraft "net.minecraftforge:forge:${config.mc_version}-${config.forge_version}" provided "com.google.errorprone:error_prone_annotations:2.1.0" } Looking back, I had that in 1.12.2 as well, but commented it out. Not sure why I need it, since it seems non-standard, but Minecraft starts up with that in place, at least. Of course, it crashes with an NPE very quickly but that's my incomplete porting and within my power to fix

runClient -s output posted here: https://pastebin.com/JJNi1JKW I've cloned the github repo into a new clean directory, run ./gradlew genIntellijRuns, and ./gradlew runClient - same result. Running the Hotspot JVM 1.8.0_201 on Linux Mint 17.3 if it's relevant. $ java -version java version "1.8.0_201" Java(TM) SE Runtime Environment (build 1.8.0_201-b09) Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)

Took me a few days, but I've managed to port 1.12.2 mod to 1.13.2, at least to the point where it compiles. However, getting it to actually run is another matter... I'm using Intellij and I've run the genIntellijRuns task (which completed without error), but when trying to run the runClient task, I'm getting this: > Configure project : New Dep: net.minecraftforge:forge:1.13.2-25.0.48_mapped_snapshot_20190214-1.13.1 > Task :compileJava FAILED error: cannot access CanIgnoreReturnValue class file for com.google.errorprone.annotations.CanIgnoreReturnValue not found Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. 1 error FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':compileJava'. > Compilation failed; see the compiler error output for details. * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights. * Get more help at https://help.gradle.org Deprecated Gradle features were used in this build, making it incompatible with Gradle 5.0. Use '--warning-mode all' to show the individual deprecation warnings. See https://docs.gradle.org/4.9/userguide/command_line_interface.html#sec:command_line_warnings Anyone else seen this? Github repo is at https://github.com/desht/ModularRouters/tree/MC 1.13-master for reference.

NetworkHooks#openGui() should take three arguments, and you're only passing two. The third argument is a PacketBuffer, where you send any extra data you need on the client side, including in your case the tile entity position. E.g.: NetworkHooks.openGui((EntityPlayerMP) player, yourContainerProvider, buf -> buf.writeBlock(tePos)); Edit: third parameter is now a Consumer<PacketBuffer> as @loordgekpointed out. That changed in the last 24 hours, time to update

I've read https://mcforge.readthedocs.io/en/1.13.x/utilities/tags/ and looked at the Tag and TagCollection source via my IDE, but maybe I'm missing something; is there a way to find out what tag groups a given Item belongs to? The use-case being the need to compare two different items and see if they have any tag groups in common, for item filtering purposes (basically, a replacement for oredict-filtering).

You have an instance of Tessellator already, and it has this handy draw() method...

You don't need to implement your own GUI, no. Forge provides ServerChatEvent and ClientChatEvent events, depending on where you want to intercept the message. Sounds like ClientChatEvent is what you need here.

Actually Additions adds bat drops, and it's visible (not open) source on github, so you could see how they do it. The mod's licence specifically permits copying small sections of its code, so you should be fine there.

You can't. What is it you're trying to achieve?

As @diesieben07said, look at any vanilla entity. See also this thread:

Because EntityPlayer inherits from EntityLivingBase, not EntityLiving.

World#notifyNeighborsOfStateChange()

You should really cache that Field object (at mod startup time - preinit is fine), especially if that code gets run frequently. Reflection isn't the fastest thing in the world.

Generally, you'd do this by having different item handlers depending on the face, and return the appropriate one from getCapability(). As an example, a simple processing tile entity with one input and one output slot would have two item handlers (most likely a subclass of ItemStackHandler with isItemValid() overridden if necessary to filter what's allowed in there).

And another reason to hate MCreator: it generates code using ItemModelMesher, which is outdated and very bad practice (use Item#setCustomModelResourceLocation).

Other than that, "pm" is a terrible name for a mod: it's far too short (although "PracticeMod" sounds like you don't plan to release this). And IHasModel is an antipattern - a useless waste of time and an example of cargo cult programming. Ditch it. Every item has a model.

Just for future reference, OreDictionary#initVanillaEntries() sets up all the vanilla oredict mappings (and it's "logWood", by the way).

Good question. I suspect that section of the docs is outdated. It used to be the case that blocks & items were explicitly registered from preInit, but that's since been superseded by the registry events. My guess is that part of the docs was written before that. In any case, moving your ore dict registration from preInit to init should solve your problem (you can verify this with your IDE debugger - if you breakpoint your current code, you should see that ModBlocks.MY_PLANKS is null).