desht

Block/item registration happens after preInit, and before init. So oredict registration should happen in init (i.e. in response to a FMLInitializationEvent). You haven't posted your block registration code, but I sincerely hope you're doing it in a RegistryEvent.Register<Block> event handler?

If you take a look at the source, in particular tracing back from the chat event constructor, you'll find NetHandlerPlayServer#processChatMessage(). In there, you'll see how the message is normally sent to all players on the server: server.getPlayerList().sendMessage(...). But if you just want to modify a message, do what @diesieben07said above!

Whoever told you that didn't know what they were talking about. Proxies exist because the Minecraft client and server, while sharing a lot of common code, also do things that other does not, e.g. the client knows about models, textures, GUI's, and the server neither knows nor cares about such things - try to register a model on the server, and it'll crash. So you should be doing client-side specific code from your side-specific proxy implementation. On the other hand, tile entity registration is identical on both sides, so proxies are completely unnecessary there. Have a read of https://mcforge.readthedocs.io/en/latest/concepts/sides/ and when you're done, go back and read it again. It's really important to understand this fundamental Forge concept.

Yes, there's a problem - you posted a screenshot of your IDE instead of your crash log.

Tile entity registration needs to be done on both client and server, so why are you even using a proxy?? While we're at it, "CommonProxy" is an anti-pattern you should get rid of. The whole point of proxies is to implement different behaviour on the client and server; if the same code needs to be executed, then it shouldn't be in a proxy at all. The correct way to do this is to create an IProxy interface, and two implementations: a ClientProxy for the client and ServerProxy for the server. Pass those classnames to your @SidedProxy annotation, and define your proxy object with type IProxy. As for your tile entities, just register them from your FMLPreInitializationEvent handler.

No, those overrides should be sufficient. What does your model JSON look like? Also, you should be using CUTOUT_MIPPED for your block render layer (getBlockLayer()). TRANSLUCENT is for blocks like glass or ice.

Try overriding isOpaqueCube() and isFullCube() to return false.

Don't do that, please. You're registering your TE with a plain string and not even prefixing it with your mod ID. That method is even deprecated in recent Forge builds. Correct way is: GameRegistry.registerTileEntity(YourTileEntity.class, new ResourceLocation("your_mod_id", "your_tile_entity_name)); You'll know pretty quickly if you registered it when you attempt to place any blocks of that tile entity. If you can place them, your TE is registered However, if the registerTileEntity() call didn't throw an exception or log a warning in your log file, it should be safe to assume it succeeded.

I'd also question why you're running code every single tick just to add a marker to your item's NBT. Why not just check stack.hasTagCompound() in your onFoodEaten() method? (I appreciate the code you're running isn't terribly expensive in CPU terms, but it's good practice not to run unnecessary tick-based code).

Reading/writing NBT is a separate concern from sync'ing data to the client. If your banner items need to persist across world/server restarts, then yes - you need to serialize them to NBT. But that has nothing to do with sync'ing the banner items so the client can see them. As for getters/setters, it's valid to have such accessors simply forward to getDataManager.get() or .set(). That also has nothing to do with NBT serialization, though.

DataManager is the standard (vanilla) way for entities to sync server-side data to the client-side entity. Modded entities can use it too, and it's not too difficult. As an example of an entity that sync's an ItemStack, see the vanilla EntityItemFrame and its ITEM field. In summary: Declare a static final DataParameter<T> field in your entity (T would be ItemStack in this case) Override entityInit() to register that field with getDataManager().register(field, defaultValue) To sync the data, use getDataManager.set(field, value). It will automatically sync to the client on the next tick On the client side, use getDataManager.get(field). You can optionally also override notifyDataManagerChange(DataParameter<?>), which is called both client- and server-side (so check world.isRemote) when any data parameter is changed. This could be used to cache values, for example, or carry out some computation you wouldn't want to do every tick.

Well, you could send a custom packet from the server to tell the client what happened. But - directed at @Eiachh - this feels a bit like an XY problem. Why do you need this level of information on the client in the first place, and what are you trying to achieve?

If you look in the vanilla assets for e.g. the oak sapling, there are actually separate models for the block and item forms of the sapling. models/block/oak_sapling.json uses a parent of block/cross, but models/item/oak_sapling.json uses a parent of item/generated.

Not having seen all your code, your symptoms (rubber banding) sound rather like you're updating the entity's motion on the server, but not the client. The server's position thus gets out of sync with the client's idea of the position, and you see the "teleport" effect when the server finally sync's up. Any changes to an entity's position should be done simultaneously on both server and client. Are you only calling your reflect() method on the server?

Actually, it is possible, and a working example is the PneumaticCraft Programmable Controller: https://github.com/TeamPneumatic/pnc-repressurized/blob/master/src/main/java/me/desht/pneumaticcraft/common/tileentity/TileEntityProgrammableController.java#L153 The drone entity is only created and spawned client-side, and it does work. Obviously the entity has no AI, so the only movement is whatever the client sets the entity's position to (in this case, the server gives the client a target position, and the client-side entity simply moves toward that position). This works fine as an indicator for the position that the Programmable Controller tile entity is currently operating at.

Would need to see your code, but custom SoundEvent objects should be registered via a registry event, similar to custom Block or Item objects. As an example: https://github.com/TeamPneumatic/pnc-repressurized/blob/master/src/main/java/me/desht/pneumaticcraft/lib/Sounds.java (the RL() method in there is just a convenience method to get a ResourceLocation with the mod's domain). See also https://mcforge.readthedocs.io/en/latest/effects/sounds/. Note that SoundType and SoundEvent are not the same thing, but you seem to be conflating them a bit here.

Often, when in doubt, the best bet is to consult the source and see how vanilla does it. In this case, take a look atItemDye#onItemUse(). Looking at the code there, it appears that applyBonemeal() (the overload that V0idWa1k3r mentioned) gets called both on server and client. Indeed, a perusal of ItemDye#applyBonemeal() shows some checks for server/client, so it's clearly intended to be called on both sides.

If code needs to be executed on both, then it shouldn't be in a proxy at all.

EnumFacing order is DUNSWE (which I'm pretty sure is the same as ForgeDirection from 1.7.10). But EnumFacing and/or BlockPos provide all the methods you might need to get rid of that ugly (and wrong) bit of code. Assuming the side int is in the expected DUNSWE order: BlockPos newPos = new BlockPos(x, y, z).offset(EnumFacing.byIndex(side)); // then use newPos.getX() etc.

It might be worth taking a look at Patchouli, Vazkii's new mod. You'll get a guidebook similar to the Lexica Botania with no coding required (although there is an API for more advanced requirements). Other documentation mods exist (IGW and GuideAPI spring to mod), but Patchouli is probably the most polished one out there at this time. If you want to code your own, it's basically just a lot of client-sided GUI work.

Include the TE's blockpos (x,y,z) in the packet you send. You can get the world from the player (ctx.getServerHandler().player).

Yeah, that should work, but those parameter names, really?

Yeah, I don't think there's much to be done except wait...

Not just you, if it's any consolation. Seems to be some problem with files.minecraftforge.net at the moment. I also noticed this and posted about it here:

I noticed this this morning when a Jenkins build failed on me: Download http://files.minecraftforge.net/maven/net/minecraftforge/forge/1.12.2-14.23.5.2772/forge-1.12.2-14.23.5.2772-userdev.jar FAILURE: Build failed with an exception. * What went wrong: Could not resolve all dependencies for configuration ':forgeGradleUserDevPackage'. > Could not download forge-userdev.jar (net.minecraftforge:forge:1.12.2-14.23.5.2772) > Could not close resource 'http://files.minecraftforge.net/maven/net/minecraftforge/forge/1.12.2-14.23.5.2772/forge-1.12.2-14.23.5.2772-userdev.jar'. > Premature end of Content-Length delimited message body (expected: 5199526; received: 86587 Trying with wget also reports an error, but wget auto-retries and manages to get the JAR ok. Unfortunately, gradle (as run from Jenkins above, and also from the local command-line) gives up and fails the build immediately. This seems to be pretty reproducable and happens both on my local machine and a remote Jenkins build server. Something up with files.minecraftforge.net?