V0idWa1k3r

No. Read the docs on the object holders. The field must be final. Don't touch it. Just declare it as null and never put anything into it manually. Forge will do everything for you. Just register new instances of your blocks/items in the registry event like I do here.

Just don't use it. This is for initial sync when the window is opened but you will sync all your data on the first tick anyway. Just get and set your variables directly. get/setField are wrappers for variable access anyway. For example instead of getField(0) you would use tile.progress and instead of setField(0, value) you would use tile.progress = value. I have an example in one of my projects here.

Check one, then check the other. player.getHeldItemMainhand().getItem() == Items.itemA && player.getHeldItemOffhand().getItem() == Items.itemB

EntityPlayer#getItemStackFromSlot. Or EntityPlayer#getHeldItem(EnumHand). Or alternatively EntityPlayer#getHeldItemMainhand and EntityPlayer#getHeldItemOffhand. Any of these will do the trick. Edit: Problematic code issue #12.

Caused by: java.io.FileNotFoundException: lanterns:blockstates/orz1_off.json Is your blockstates file named orz1_off.json? Make sure it is lowercase - all asset names must be entirely lowercase(I see that your blockstates file references the model with upper-case letters in it's name - that won't work)

Do you know java? Your IDE clearly tells you that this methods requires an EntityEquipmentSlot as a parameter, not an integer.

InventoryPlayer#armorItemInSlot is client-side only. Use EntityPlayer#getItemStackFromSlot

No OpenGL context found in the current thread. You can only call opengl related functions from the render thread. In this case DynamicTexture probably invokes something related to opengl. Also Code-style issue #1.

Place the breakpoint in your capability attach event and see if it is being attached at all. If it is put a breakpoint in your capability getter and see why it returns null.

What is this package? What does it even mean? Why are you now registering your capabilities in init? Capabilities should be available as soon as possible, not delayed untill init. You are still using direct calls to GL11. The more players on the server the faster this will tick down and thereby the faster the mana will regen... for one player out of them all. Store this value in the capability. Why did you just straight up delete your clone event? You need that to persist capability data. Apart from that your capability registration seems correct. Does the issue still persist?

The mana capability is null. Your code is full of issues that you must fix: You are reaching across logical sides in a lot of places like here(PlayerTickEvent is common, Minecraft is client only). Why is this class named ClientTickEvent? There is nothing client about it, it's common code. Also it is probably a bad idea to create a new Random object twice each tick per player. You are using numerical IDs which is a really bad idea since they can and will unpredictably change. Forge already has a built-in update checker. This is just extra work you don't have to do. It also does the check on the main thread which means that if the page is unavailable for some reason or takes a really long time to respond the client will stall potentially forever(or at least untill the timeout happens). Why is this in your client package? Presumably the mana regeneration is server-only or at the very least common code, is it not? You are using GL11 directly and by doing that corrupting the state of the GlStateManager. You must use GlStateManager, not GL11. As far as I know RenderTickEvent is fired every frame regardless of whether there is a player or not. You must be checking for the player in your event handler. The only reason it doesn't crash now is because of this line and that is not the propper check. If some mod nullifies the currentScreen before the world is started your code will crash. Why on earth are you only adding your capability on the client? This is the root cause of your problem. Presumably you need this capability on the server aswell yes? Otherwise it serves no purpose. Or are you going to send packets based on trusting the client? Oh it is also worth pointing out that currently every entity in the game apart from the only one that needs it has your mana capability. I don't think that this is whay you wanted. Especially considering that right in the same file on the next few lines you are copying the capability disregarding whether it's the client asking you to clone it or the server. Code-style issues #1 and #3 And those are just the issues I found at a quick glance at the repo. I'm sure there are many more.

That is correct. Mod loading order only determines the order in which mods are passed the FML lifecycle events. If mod A requires mod B and mod B requires mod C then the loading order would be the following: Pre-Init: C, B, A -> Init: C, B, A -> Post-Init: C, B, A

net.minecraftforge.client.event,FOVUpdateEvent allows you to set a new FOV using FOVUpdateEvent#setNewfov. Alternatively there exists net.minecraftforge.client.event.EntityViewRenderEvent.FOVModifier which allows you to set a modifier for the player's FOV instead of altering it directly via FOVModifier#setFOV. You can read about events and handling them here.

stack.getItem() == Items.IRON_INGOT. No need to ask the registry for a lookup. There pretty much never is a need to do so. For vanilla all items are stored in the Items class and for mods use ObjectHolders.

I don't recommend using index-based field getters. Indices can change if a particularly bad mod creates a field in the class using asm. Names can't.

This event is the FML lifecycle event. All FML lifecycle events are called on both the physical client and the server since they are common. What you are seeing is the event called at the physical client since you are launching the client and not the dedicated server. By the time most FML lifecycle events fire there is no logical server for them to be fired at. Read this for futher documentation. As far as I can tell any common code that is executed before the server is started will do. I personaly do it in the pre-init phase.

You could always use reflection. Make sure to use ReflectionHelper.getPrivateValue and provide both the deobf name of the field as well as the SRG name.

Basically I needed the chunk loading distance. On the client that equals render distance. Same goes for the integrated server. The dedicated server however is different and stores this value separately. I needed a handler for the case where the server is not integrated and this is where I used the ServerProxy. Maybe there was a better way of doing this but that's the solution I thought of.

I needed a server proxy to access a server's property collection(the one parsed from the server.properties file) once. Generally if you need something from the DedicatedServer you need a ServerProxy.

Your registry handler class is annoteted with EventBusSubscriber but your event handlers are not static. If you want to use automatic EventBusSubscriber your event handlers must be static. Otherwise use EventBus#register.

Code-style issue #1. You pass a location of your ClientProxy to be com.TMod.skyc.client.ClientProxy but it actually is com.TMod.TMod.client.ClientProxy

Why are you referencing the player in the constructor of your item? You understand that there is no possoible way player isn't null when your constructor is called, right? https://github.com/WarpReality/Lost-Powers/blob/master/src/main/java/com/warpedreality/lostpowers/tools/ItemVoidMultitool.java#L17 Class minecraft is client-only. Generic solution - use proxies. Solution for you - stop using Minecraft there. It dosen't even do anything. Also: Problematic code, issues #10 and #14

I personally am more interested in forge changes although these changes are pretty big too. Like I've heard that Lex wants to drop support for forgeblockstates and while that is understandable due to vanilla blockstates becoming a lot smarter with their predicates it is still sad for me as I've personaly been using forge blockstates everywhere. And submodels are a useful feature too. Or for example that according to this quote "SidedProxy annotation will probably not be maintained. Replaced with using SidedExecutor." It sounds very interesting to me but I imagine it would be quite difficult for modmakers to drop using proxies and start using something they are not used to instead. But going back to 1.13 generic changes there is now a tegs system that looks really promising. I wonder if it could in theory replace OreDictionary if handled properly. Couldn't you still kinda do that with a PlayerEvent.BreakSpeed? While it's not the same you could achieve identical functionality.

What? Items are singletons. EntityPlayer#getHeldItemMainhand returns an ItemStack. Items.SHEARS is an Item. ItemStack != Item. Use ItemStack#getItem EDIT: Animefan8888 was a second faster I guess

Those are for shaped recipes, OP is using a shapeless one. Shapeless recipes specify their ingredients as a json array named ingredients. Additionally if the item has subtypes the "data" key must also be provided(data is metadata)