Leaderboard

Yes. There are vanilla blocks that utilize similar things, like wool and carpet.

I finally did it, I managed to get it work, thanks everyone for the help! Marking this as solved. Thanks everyone again!!!!

Minecraft.getMinecraft().player (dont know if this changed in 1.14 but probably not) this will always give you the client player

You've imported the wrong Supplier you need java.util.function.Supplier

if event,getEntity instanceof MobEntity // Cast event.getEntity to MobEntity and access goalSelector

Define near the player like within x and z distance? Yes I would use the PlayerTickEvent for this. Then check the surrounding chunks in those distances to see if they are loaded then apply the transfer of the values based on a Random number generator.

you can get the player from the context Supplier<NetworkEvent.Context> ctx https://github.com/MinecraftForge/MinecraftForge/blob/1.14.x/src/main/java/net/minecraftforge/fml/network/NetworkEvent.java#L194

We will be making an announcement about it when we can. The current state is that it means almost nothing for us. As the license doesn't allow for us to actually USE this information. We are waiting to hear back from Mojang's legal team {This is all stuff they could of answered before the public announcement by asking us, but whatever} Keep an eye on Github/Twitter and we'll keep you updated.

As anyone who's started porting to 1.14.2 is probably aware by now, container and GUI creation has changed... quite a bit. To summarise what I've gathered so far: Containers (more accurately: container types) are now registry objects and must be registered in a RegistryEvent.Register<ContainerType<?>> event handler. Container objects themselves must provide a constructor of the form MyContainer(int windowId, PlayerInventory inv, PacketBuffer extraData). This will be used to instantiate the client-side container. Your container's constructor must call the super Container constructor with your registered container type and the windowId parameter (this int parameter is not used in any other way - just pass it along to the superclass constructor and forget about it) You can use the extraData parameter to pass... extra data! to your container. This PacketBuffer parameter is built server-side when you call NetworkHooks.openGui(); see below. Typically, your container will have (at least) two constructors; the factory constructor described above which is used for client-side construction, and a constructor taking whatever parameters you need to pass to set up your server-side container object. Container-based GUI's are now associated with a container type with the ScreenManager.registerFactory() method, which takes a registered ContainerType and a ScreenManager.IFactory to construct your GUI object. Call that in your client-side init code. ExtensionPoint.GUIFACTORY is gone, no longer needed, as is the old IGuiHandler system. ScreenManager does all that work now. While there must be a one-to-one mapping from ContainerType to each GUI, also remember that you can happily re-use the same container class for multiple container types if you need to; just pass the container type as a parameter to your constructor and up along to the Container constructor. All container-based GUI's must provide a constructor taking(T, PlayerInventory, ITextComponent), where the generic T is the type of your container object. Container-based GUI objects are now generified (is that a word?) on the container's class, e.g. public class MyGui extends ContainerScreen<MyContainer> IInteractionObject is gone; instead your tile entity should implement INamedContainerProvider: the createMenu() method is where you create and return your server-side container object. (I believe getDisplayName() is only used to initialize the title field of your GUI object). To open a container-based GUI on the tile entity (server-side), call NetworkHooks.OpenGui(player, myTileEntity, pos) or player.openContainer(myTileEntity) That would typically be called from Block#onBlockActivated() If you want to create a container-based GUI for an item, create a class implementing INamedContainerProvider (a static inner class of the item makes sense, or perhaps an anonymous implementation), implementing createMenu() and getDisplayName() to create and return the container object as above. That would typically be called as something like NetworkHooks.OpenGui(player, new MyItemContainerProvider(stack), pos) or player.openContainer(new MyItemContainerProvider(stack)) from Item#onItemRightClick() or Item#onItemUse() player.openContainer() can be used if you have no need to pass any extra data to the client, e.g. your GUI is just displaying container slots, like a chest. But if your client GUI needs access to the client-side tile entity, use NetworkHooks.openGui() and pass at least the tile entity's blockpos so the client container can get the GUI object. Syncing any necessary TE data to the client-side TE needs to be done separately by whatever means you choose. Note that NetworkHooks.openGui() has a couple of variants to allow extra data to be passed to the client-side container object: a simple pos argument if you just need to pass the blockpos of your TE, or a more flexible Consumer<PacketBuffer> if you have more complex data to pass to the client. The simple pos variant just calls the full-blooded Consumer<PacketBuffer> variant in any case. It's this packet buffer that is received by the client-side container constructor.

No, this will be irrelevant for the update cycle. Forge, and other projects have had access to this information for years. As I have stated many times, the concept that Forge is slow to update is a dirty lie spread by people who just want to disparage our good name. 1.13 is a SPECIAL CASE that took a while as a explicit decision. As we took the time to re-write the entire toolchain/codebase. NORMAL updates take less then 24 hours to do. And we will be continuing that tradition now that our rewrite is finished. MCP will still exist, as there are a lot of things that MCP allows us to have that these mappings do not. Documentation, parameter names, better names, better code from injected data/managed data. This is NOT as useful as people are thinking. And with the legal issues it's actually detrimental to the community as a whole. As the only people who benefit from this, are the ones who do not respect Mojang's copyright. There already are projects that just straight up use the mappings, deobf/ship Mojang's named classfiles/decompiled code. Those projects will get popular because there are members of this community who are not respectable. There probably will be a major fanbase harassing everyone about using the names. But, Forge WILL respect Mojang's copyright, so as is we can't publicly use these names.