V0idWa1k3r

AttachCapabilitiesEvent fires on both the server and the client. This means that the client also has the capability, just not the latest data. On the client you always have access to the client player - Minecraft.getMinecraft().player. That player will have your capability. All that's left is to set the data in that capability. I assume you do know how to create and use a setter.

In the code the OP posted he has one though He is just using a deprecated version. Which is his issue as far as I can tell.

I don't see anything obviously wrong with your TE and Block(apart from what me and Diesieben mentioned). Use the debugger to find out what's going on. Alternatively if you could setup a github repository of your mod I could debug it locally.

@Override public NBTTagCompound writeToNBT(NBTTagCompound compound) { super.writeToNBT(compound); compound.setInteger("cooldown", cooldown); if(compound.hasKey("CustomName", 8)) { compound.setString("CustomName", this.customName); } return compound; } This will never be true. This public void updateTick(World worldIn, BlockPos pos, IBlockState state, Random rand){ if (!worldIn.isRemote){ if(worldIn.getTileEntity(pos) instanceof TileEntityTrebuchet) { ((TileEntityTrebuchet)worldIn.getTileEntity(pos)).setCooldown(0); } } } doesn't do what you think it does. It fires each tick, sure... for one random block in all of loaded chunks. Implement ITickable in your TileEntity and do the stuff with the cooldown there. What makes you think no tile entity is created? Have you placed a breakpoing in any of your methods that get the tile entity and inspected the TE local?

Separating them into 2 blocks creates a lot of confusion since your will have 2 meaningless blocks (BlockThingOne and BlockThingTwo). That said this way is pretty good if you want to save on block ids. Creating a unique block for each variant is a more intuitiva approach. This is also how variants function in 1.13. So this approach will allow you to update your mod to 1.13 easier and is more intuitive but it's less conservative on block ids. Alternatively you can store all your variants in a single block by using a TileEntity. Since TEs can be non-tickable now this approach is also viable.

This would be your issue. You are only spawning your arrow on the client. You need to do the opposite. Also you can't do this Blocks are singletons thus every block in the world that shares this class shares all the variables of that class. You must use a TileEntity if you want to store the data per-block.

Do you mean that you want the player's model replaced? Then handle the RenderPlayerEvent.Pre, render your model instead and cancel the event so the original model doesn't render.

Are you sure you've imported the right PlayerEvent class? There are 3 classes with that name, 2 of which are provided by forge. You need the net.minecraftforge.event.entity.player.PlayerEvent, not the net.minecraftforge.fml.common.gameevent.PlayerEvent

For the most part, as long as you are using the suggested ways of doing things (read: capabilities and registry events). You will have to fix a few things here and there but it should be fairly straightforward, there aren't many changes between 1.10.2 and 1.12.2 codebase-wise.

ItemStack became non-nullable (and got the EMPTY constant as well as the count methods) in 1.11 afaik. Any particular reason you are modding for 1.10.2? You should update to the latest (1.12.2) version.

You can't do this client-side only if(button.id == this.btnNewtype.id) this.nt.setHumantype(EHumantypes.NEWTYPE); if(button.id == this.btnOldtype.id) this.nt.setHumantype(EHumantypes.OLDTYPE); This only sets your data on the client(and that data won't be persistent as one might guess). You need to send a packet to the server and set the data there. https://github.com/SpaceboyRoss01/MSGundamMod/blob/master/src/main/java/com/spaceboyross/gundam/capabilities/providers/NewtypeProvider.java The generic type for ICapabilitySerializable is either NBTBase or any of it's children. If you are using NBTTagCompound to begin with you should just use it as your generic type rather than casting all over the place. And why are you introducing a HANDLER generic type You do not need it as far as I am concerned. This makes absolutely zero sense. A capability of NBTBase? The generic constraint there is your capability interface, not the type it is serialized into. I have no idea how it is even working and not crashing you completely. This line is useless. It just creates a final field that is assigned to null. If you want your capability to be injected there you need to add the annotation. root.setInteger("humantype",instance.getHumantype() == EHumantypes.OLDTYPE ? 0 : (instance.getHumantype() == EHumantypes.CYBER_NEWTYPE ? 1 : 2)); => root.setInteger("humantype",instance.getHumantype().ordinal())); instance.setHumantype((new EHumantypes[] { EHumantypes.OLDTYPE, EHumantypes.CYBER_NEWTYPE, EHumantypes.NEWTYPE })[root.getInteger("humantype")]); => instance.setHumantype(EHumantype.values()[root.getInteger("humantype")]); You also must copy the data from the old capability to the new capability upon PlayerEvent.Clone, otherwise your capability data will reset to defaults every time the player is cloned(respawns for example) ResourceLocations should be all lower-case. In 1.13 the "should" turns into "must" as an exception will be thrown on non-lower-case ResourceLocations. TL;DR: I think that your problem is not serialization but a) The fact that you only ever set the values on the client b) That your capability provider is broken.

I recommend using software that allows you to change your transforms visually instead of doing trial and error manually. Blockbench is the one I use for example. It can even import already existing json models.

Damage values are stored in metadata. ModelLoader.setCustomModelResourceLocation takes an integer as it's second parameter. That parameter represents the metadata of the item.

Do you see this line if (result == net.minecraftforge.fml.common.eventhandler.Event.Result.DENY) { this.idleTime = 0; } If the result is deny then the idle time is set to 0 preventing the entity from despawning. From the code you've pasted: if (this.idleTime > 600 && this.rand.nextInt(800) == 0 && d3 > 1024.0D && this.canDespawn()) { this.setDead(); } The entity will only despawn if idleTime is greater than 600 and denying the event sets it to 0.

As you've said yourself the client doesn't know of potion effects applied to an entity. You will need to send them to the client yourself. Probably you would compare the current effects to the effects active last tick and send the data to the client when there is a new effect added/old effect removed/effect changed.

net.minecraft.client.gui.GuiOverlayDebug Although you should probably specify the game version you are modding for. This class might have been recently added.

When the data changes on the server send the packet with the new data to the client When the client recieves the data get the client's capability and set the data in that capability to the data you've recieved. When the time comes to use the data the client conveniently already knows the latest up-to-date information. Just use the capability as you would normally do - it already has the latest data in it.

Where are you getting this idea from? If anything non-forge registries registration methods will be deprecated. Using registry events and registries is the propper way to do things, it won't be deprecated. It is a coherent place for things to be registered. Forge itself is event-based and it only makes sense that the registration would be too. It is convenient. It is a specific place for you to register your stuff. No guessing "is this loaded yet or no", no more "what order do I register things in". Registry events solve all those issues. It is the most lazy way. Instead of first declaring your things somewhere, then instantinating them and then registering them you do all of it in one place - the registry event. You create and register your things right there and then. In theory it allows hot-swapping mods on the fly. Since with registry events forge can make "snapshots" of the registry it now knows what was added to the registry, when, from where and what mod is responsible. If forge ever implements "hot-swapping" it would then be trivial to remove/add things from/to the registries during runtime rather than initial startup. It is the correct way of doing so. When you want to say handle an entity dying you don't write a coremod. You use an event. Same here - you should use the event because it's the right thing to do.

As @jabelar said you need to use packets. Send the data needed(what you want present on the client) when it is needed(upon initial login and when it changes). Don't send the packet when the data is needed, send it when it is changed. This ensures that the client always has up to date data.

This approach screams "static initializers" and static initializers are bad. Just instantinate your blocks/items/whatever directly in the registry event. Not in a static initializer, not in FML events. You are also doing extra unnecessary work, think about it. Thirst you instantinate your stuff somewhere, then you add them to the set in the constructor, then you loop through the set in the event. That's at the very least 3 lines of code per block. Now think of the recommended approach. You instantinate your stuff directly in the registry event as an argument passed to register. That's one line of code per thing. With the recommended approach you are doing only 33% of the work. Also CommonProxy makes no sense. Proxies are for separating sided only code. Common code goes whereever but your proxy.

Handle net.minecraftforge.event.terraingen.DecorateBiomeEvent.Decorate, check that it's EventType is LAKE_WATER, check that the biome is yours and set the result to deny. Alternatively it seems that the field generateLakes was renamed to generateFalls.

I am sorry but what are you talking about? No other ticks will fall into the default behaviour, minecraft simply tries to despawn entities once every 32 ticks and this is where forge hooks into. If this isn't true no despawning code will be executed at all. And no forge event will fire either because there is no need to. If you want your mob to stick around for a certain amount of time you can attach a capability to that entity and store your time there.

As I've said As soon as I changed getX to readX and writeIntLE/getIntLE to writeInt/readInt a thing was spawned. The reason is that this buf.getDouble(1),buf.getDouble(2),buf.getDouble(3) is not how you read data from a packet and it was reading a 0 for all your positions.

We can't help you without your code. Although from the error trace I suspect that you haven't registered your IGuiHandler. Also any particular reason you are using 1.10.2? You should be using 1.12.2.

Then you are doing something wrong. readInt/writeInt should work just fine. What exception are you getting and what number are you trying to write into the buffer(and how)? There is no reason to use Forge's methods here. You know which side the packet is recieved on. The same goes for the code you've linked as far as I am concerned. Well you are a programmer. You should be able to fix whatever errors your IDE throws at you. I'll try debugging your code locally.