V0idWa1k3r

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.

Why are you using ByteBuf#getIntLE/writeIntLE? Why not writeInt/readInt? Why are you using ByteBuf#getX in the first place? You should be using ByteBuf#readX. The fact that this this.index = buf.getIntLE(this.index); even works is a miracle that only happens because index is 0 by default. FMLCommonHandler.instance().getWorldThread(ctx.netHandler) => ctx.getServerHandler().player.getServerWorld() Don't use FML internals when it's not necessary. I also have no idea what this MobileSuit ms = MSRegistry.getMobileSuitFromIndex(message.index); returns. I assume you've used the debugger and made sure this isn't the cause of your problem? mob.posX = message.pos.x+1.0; mob.posY = message.pos.y+1.0; mob.posZ = message.pos.z+1.0; => Entity#setLocationAndAngles. Or at the very least Entity#setPosition. How and where are you constructing/sending your packet? Are your fields set to the correct values? Also make sure that your packet is registered correctly. Step through your handle method in the debugger and see the values on the fields in your message. Something might be wrong there. Also make sure that the handle method is called in the first place. I don't even... What? What does your IDE have to do with this?

As I've said please stop using reflection here. It's not the use-case for reflection. Use a factory. Reflection wastes a lot of CPU cycles doing lookups for things. Modded minecraft is laggy as is, don't add more lag to it when you can avoid it. Packets are handled on a separate network thread. You must encapsulate whathever you are doing in a runnable and use IThreadListener#addScheduledTask. On the server your listener is the WorldServer instance. On the client it's Minecraft. Also don't blindly trust the client. Always assume that the client lies and perform additional checks in your handler. With your current code anyone could spam the server with artficial spawn packets and spawn thousands upon thousands of your entities whereever they want them to be. Also that is not the descriptor for IMessageHandler#onMessage. If you are calling this from your packet handler please post the whole code so it is easier to spot what's wrong.

This explanation doesn't even mean anything. How is it special? What does internally mean in this context? This is not within your API package so there is zero reason to use reflection. I've looked at your github and I still fail to see a reason to use reflection. If you want to create something dynamic that may or may not be overriden by something else use a factory, not reflection.

You can't spawn an entity on the client. You must do that on a server. Use packets to communicate the button press to a server. On a completely unrelated note: What on earth is this: Do you know how to instantinate things in java? Why are you using reflection? Also this is the worst way to handle exceptions. If something went wrong don't just print it and carry on. Minecraft crashes for a reason and so should you.

The event is client-side. You have access to the client's player. You have access to the player's open container. That has access to the slots.

This would be the preferred solution. a) Don't search it every tick but instead say every 10 ticks. b) Realise that the size of the vanilla player's inventory is only 44 slots and that will take virtually no time to iterate through and stop worrying. That said you might try to do something interesting with the MouseEvent. I wonder if Detecting the slot under the cursor Checking whether that slot can accept your item with your custom checks Cancelling the event if not will work. I suspect it will but I can't test it right now.

I guess it is possible by handling the PlayerContainerEvent.Open and then adding your custom slot to that container's slot list(Container#addSlotToContainer although you wouldn't be able to access that method directly since it is protected so you would need to either use reflection or replicate the functionality of that method). However all sorts of hell can and will break loose as soon as Container#transferStackInSlot is called. I couldn't even begin to imagine what would happen if the container attempted to handle the slot that it didn't know existed(read: wasn't programmed to handle). Probably the duping glitches would be the least of your worries. The containers are just not built to have slots added to them post-construction. Another alternative would be replacing the container with a different one alltogether... and creating a hard incompatibility with everything else that does the same. Having a separate Gui/Container pair is the most sane solution.