Jay Avery

Using capabilities is using TEs, it's just using them in a particular way that's a bit more effort to set up, but more tailored for compatibility. A TE is just a class, and instances can store fields like anything else. Using capabilities doesn't mean not using TEs, it means storing the information in your TEs in a particular form that makes it easy to be accessed and used in certain ways.

If you're passing the message itself as a parameter, then you can access the message's entityid field locally in the method - by passing it separately you're basically passing the same information to the method twice. Post the error.

Yes, Forge is - it will only call the method on the client. But like draco said, the JVM isn't clever enough to know the method won't get called, so it crashes as soon as it finds a reference to a nonexistent class. You won't have any problems when you run code like that on the physical client because all the referenced classes are present - it's only the server that will crash. @SideOnly isn't forbidden, it's just that it needs to be used correctly. People get mixed up about the difference between logical and physical sides - @SideOnly applies to physical sides.

The main benefit of capabilities is compatibility, with vanilla things and with other mods which might connect to or extend your functionality. If you don't want compatibility at all, then you can just not bother to use a capability.

java.lang.NullPointerException at com.ninja3659.explorationexpansion.client.model.ModelBeelzebook.AwakeAnimation(ModelBeelzebook.java:193) ~[ModelBeelzebook.class:?] Something is null where it shouldn't be. I'm guessing line 193 is probably this one, right? NeemPacketHandler.INSTANCE.sendToServer(new PacketGetAwaken(entity.getentityAwake(), "com.ninja3659.explorationexpansion.client.model.ModelBeelzebook", "awake", entity.getEntityId())); Where do you call the registerMessages method of your PacketHandler?

final on a field means nothing about overriding, because overriding applies to methods only. A final field just means it can't be changed after it's been initialised. In ItemSeeds, the crops field is initialised using the Block passed to the constructor, so you can set it to whatever you want when making your own seed item. Maybe explain your actual situation, because this sounds like a potential XY problem.

Exactly which line is #60?

Are your model registration methods definitely being called?

Post the latest log, which should contain model loading errors.

You can also specify the item model and texture/s in the blockstates file itself. Forge looks for a variant called "inventory" in the blockstates file and uses that for the ItemBlock model. Since your model and textures are already defined in your defaults section, you should just need to add an empty variant ("inventory": [{}]) and it will automatically use the same model as your block (assuming that's what you want it to do). If you want it to be different to the defaults, you can define a different model and textures inside the variant like you would with any other.

Registering blocks and items is crucially important to a functional mod. Regardless of whether it seems to be working, failing to register things is a fatal problem which you should prioritise over anything else. If you block's model or textures are not working properly, post the blockstates file and model file(s).

This method does not register a block. It creates an itemblock and then calls another method which registers a model for the itemblock, without registering it either.

I knew that because they happened when I gave the block Material.WATER, I just wanted to know exactly where they happened to see if there was any way to change or cancel them with events. Thanks, that event is half of my solution. I don't see a method by that name in Entity, but I think I tracked down water particles to Entity#resetHeight, which gets called from Entity#handleWaterMovement. In any case, nothing I can cancel or interfere with - I guess I'll just put up with water bubbles.

I've made a custom fluid which extends BlockFluidClassic and has Material.WATER, because I want the player to swim and drown in it (which is working fine). But that also means that: There's a blue overlay when the player is underwater Blue splash and bubble particles spawn when swimming I can't seem to pin down where these effects happen, or whether there's a way to cancel/override them. Can anyone suggest a way to change these effects, or simply point me to the code that controls them so I can investigate?

Just generate the number locally inside the getContainerItem method. The local variable will be discared once the method returns, and a new one will be created each time the method is called.

I don't know exactly - I think it's something to do with the way they are written to/from bytes which is kind of linear, so if things get offset by one packet not being registered right then the problem appears to come from somewhere else. The reason I recognised it in this case is just because I've had this crash a couple of times and tracked it down to unregistered packets!

getBoundingBox needs to be a full block, and getCollisionBoundingBox needs to be less than a full block. Look at vanilla BlockSoulSand. Another way of doing this is to leave the bounding boxes alone and override onEntityWalk - look at vanilla BlockMagma. That method is only called when an entity is standing on top of a full block, not if they collide from other directions.

It looks like you haven't registered your QuizStartingMessage, that may be the problem.

I made a very simple @Config class with just a few booleans: When I delete the config file, it creates it with the properties and comments in the class, and when I change values in the file then the fields in the class change as expected - so it's definitely working in some sense. But the "config" button in the mods list is greyed out. There aren't any crashes or error messages that I can find, but I could post the whole log if that's useful. I do subscribe to OnConfigChangedEvent in my mod class, but it doesn't get called because there is no GUI to save the config from. What am I missing? All my code is on github.

Okay, in that case I'm confused. I've made a simple @Config class, it correctly reads the config file, but the "config" button in the mods list is still greyed out. Does the @Config class need to be registered or anything?

Is this the case in 1.11, or is it only in 1.12+?

Is there a way to hide some subtypes of vanilla items from creative tabs, but not others? For example, I'd like to hide polished granite, but leave regular granite there. setCreativeTab applies to all subtypes and I can't find any events that seem to be involved.

Also post the latest log, it should contain texture/model errors.

That means you're logging an air block, not a water block.

Another update. I noticed that the client-side container was being replaced after the server-side one, and wondered if that was a problem. So I added a check to the PlayerTickEvent (where I replace the containers), and only set the client-side one there, then send a packet to tell the server to replace its own container so it happens afterwards. This seems to have eliminated the inventory-doubling problem without recreating the syncing problems I originally had. So, this seems to be solved, but I'm not happy about it because I still don't really understand what the problem was in the first place. If anyone can enlighten me, or even make a suggestion, I'd really appreciate it.