Choonster

-498 & -496? how does that work....? lol, supposed to show the same result though correct? On the server, the arrow hits the barrier block. On the client, it continues through that block space (because the client doesn't know there's a block there) and hits the ground underneath/behind it. If you stand directly in front of the invisible block and fire an arrow pointed at the ground, the x and z coordinates are the same for both sides and the y coordinate is 1 lower on the client compared to the server.

As Leviathan143 said, this is a client-server desync. I copied your command block setup, ran it to create the "phantom" blocks and then fired this arrow at one of the blocks. This was the chat output: You can see a video of this .

Forge's documentation has an explanation of the various sound-playing methods here. The SoundEvent is the object you use to play the sound, the ResourceLocation stored by it doesn't need to be saved anywhere.

It's actually TextureMap#getResourceLocation that adds the prefix and extension to your ResourceLocation before loading the texture. ResourceLocation is used for many things that aren't textures, so it wouldn't make much sense if it added the prefix and file extension automatically.

You probably don't need unlisted properties ( IUnlistedProperty ) and extended state ( ExtendedBlockState / Block#getExtendedState ) here, just regular properties ( IProperty ) and actual state ( Block#getActualState ). Regular properties have a fixed set of values and can be used to determine which model is rendered for the block. Unlisted properties can have any number of values (e.g. PropertyFloat will accept any float by default) and can't be used to determine which model is rendered for the block, but can be used by the model itself to determine how it's rendered (e.g. ModelFluid uses it to determine the height of each corner). I have a pair of blocks that store one value (colour) in the metadata and one or two more values (rotation and face rotation) in the TileEntity . You can see them here: [url=https://github.com/Choonster/TestMod3/blob/c49a3557e534a765fc0f10338cb617ecbc2df292/src/main/java/choonster/testmod3/block/BlockColoredRotatable.java]BlockColoredRotatable[/url] ( Block ), [url=https://github.com/Choonster/TestMod3/blob/c49a3557e534a765fc0f10338cb617ecbc2df292/src/main/java/choonster/testmod3/tileentity/TileEntityColoredRotatable.java]TileEntityColoredRotatable[/url] ( TileEntity ), colored_rotatable.json (blockstates file) [url=https://github.com/Choonster/TestMod3/blob/c49a3557e534a765fc0f10338cb617ecbc2df292/src/main/java/choonster/testmod3/block/BlockColoredMultiRotatable.java]BlockColoredMultiRotatable[/url] ( Block ), [url=https://github.com/Choonster/TestMod3/blob/c49a3557e534a765fc0f10338cb617ecbc2df292/src/main/java/choonster/testmod3/tileentity/TileEntityColoredMultiRotatable.java]TileEntityColoredMultiRotatable[/url] ( TileEntity ), colored_multi_rotatable.json (blockstates file) These are single blocks rather than a multi-block structure, but the principle is the same (they use TileEntity data to determine the model).

It sounds like this may only exist as a result of a bug rather than being a proper block. Do you have a way to reliably create it? If you look at it with the F3 debug info active, is the block's registry name/state shown?

Block#onEntityCollidedWithBlock is called on both the client and the server. Are you sure your override isn't being called on the server?

Entity#isServerWorld returns the inverse of World#isRemote by default, but EntityPlayerSP overrides it to return true . EntityLiving also overrides it to only return true if the entity's AI is enabled. If you want to check whether you're on the server, use World#isRemote directly.

Can you explain that a bit more? If you would want for the players health to not exceed 5 hearts for example I thought you only need to change it once when the player enters the world. You could apply the modifier once when the player enters the world, but that will be a static reduction and won't account for other modifiers being added or removed. If you want to change the modifier's amount, you need to handle removing it, re-calculating the reduction, making sure the max health doesn't reach 0 and re-applying it. I chose to do this with a capability.

But not every IBlockAccess is a World , it may be a ChunkCache or something else. You should check that it is a World before casting.

Is there a more simple way of doing it? It depends on what your needs are. When does the player's maximum health need to change? How often does it need to change? Are there existing systems (e.g. potions, equipment) that will apply the modifier when you need it?

You need to create a Render class that renders the model for the entity and then register an IRenderFactory for it with RenderingRegistry.registerEntityRenderingHandler(Class<T>, IRenderFactory<? super T>) . Look at vanilla for examples of Render classes.

You need to apply an attribute modifier to the player. When I did this in my mod, I created a capability to manage the modifier. You can see the API here and the implementation here.

It looks like you haven't registered the IceBall class with EntityRegistry.registerModEntity . Side note: Always annotate override methods with @Override so you get a compilation error if they don't actually override a super method. In future, please leave the original question in tact and ask new questions in separate replies or threads.

EntityRegistry.registerEgg must be called after EntityRegistry.registerModEntity . Alternatively, call the EntityRegistry.registerModEntity overload with the two additional int arguments and it will register the spawn egg for you.

Individual x/y/z block coordinates have been replaced by BlockPos objects. Block and metadata arguments have been replaced by IBlockState arguments. Use World#setBlockState to set a block in the world. Use Block#getDefaultState to get the default IBlockState of a Block and then chain IBlockState#withProperty calls to get an IBlockState with each IProperty set to the appropriate value. Use MovingObjectPosition#getBlockPos to get the BlockPos that was hit by the raytrace. Forge's documentation has an introduction to block states here.

The msg local variable is pointless, just use the message argument. The player variable should be moved inside the Runnable#run implementation to avoid potential thread safety issues. Other than that, what you have should work.

The Block#getSoundType overload I mentioned was added in Forge 1.10.2-12.18.1.2031. Update Forge to the latest or recommend version. Use IBlockState#getValue to get the value of a property.

Create your own. PlayerLoggedInEvent is fired after SPacketPlayerPosLook is sent from the server, so a packet sent from the event handler should be received by the client after the vanilla packet. Packet handlers are run on a separate thread, you must schedule a task to run on the main thread before you can safely interact with normal Minecraft classes. The Warning section of the documentation explains how to do this. This packet will be sent by the server and received by the client, so you can't use NetHandlerPlayServer or EntityPlayerMP in the handler. You need to open the GUI through the client player ( Minecraft#thePlayer ) instead. Sending the packet to a client will cause the client to open the GUI once it's been received.

Read the documentation.

Minecraft#currentScreen contains the current GuiScreen , but you shouldn't need to check this; just display the GUI when you receive the packet. That's why I told you to send a packet rather than calling EntityPlayer#openGUI .

A Block can only have one default state. Any setter methods in Block will set that value to be used for every state of the block. Instead of calling the setter methods in the constructor, you need to override the getter methods to return the appropriate value based on the state they receive as an argument. The methods you need to override are Block#getBlockHardness , Block#getExplosionResistance(World, BlockPos, Entity, Explosion) and Block#getSoundType(IBlockState, World, BlockPos, Entity) .

Ah, that makes sense. Minecraft#loadWorld spawns the client player in the world, firing EntityJoinWorldEvent and opening your GUI. The Minecraft#displayGuiScreen call after that replaces your GUI before you can see it, so it looks like it was never opened. This means that you'll need to show your GUI slightly later in the login process. I suggest subscribing to PlayerLoggedInEvent (fired on the server side) and checking if the player has built their character (i.e. finished with the character builder GUI). If they haven't, send a packet to the client to open the character builder GUI. This should be received after GuiDownloadTerrain has been hidden by the SPacketPlayerPosLook handler.

Rather than using a hardcoded metadata value, you should call EnumDyeColor#getDyeDamage on EnumDyeColor.WHITE to get the white dye (bone meal) metadata.