V0idWa1k3r

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)

Depends on what you want to do. It is generally recommended to use json recipes whenever possible since you get: No ~1000line-long classes that register various recipes but instead each recipe is neatly in it's own file. Easy to edit anytime you want without having to spend minutes trying to search for that one line that defines the recipe Any pack maker can easily alter your recipe with a datapack(1.13). No specific recipe-altering mods required. The _constants file. In it you can easily define a constant that corresponds to an item. Or to multiple items. Or to an oredict enty. Or to both. Here is an example of me using one constant to handle differently named oredict entries. While you kinda can do the same with hardcoded recipes it's not as intuitive and easy as just writing a couple of files in your json. If something goes wrong with a json recipe the game will kindly provide a log of what went wrong. If something goes wrong with a hardcoded recipe - it just will be missing from the game with no indication as to why. You will need all your recipes to be json recipes for 1.13 anyway. However for some complex recipes you will need to use "hardcoded" IRecipe implementation. An example of that would be leather armor dyeing or firework making. There is however a point to be made that even custom IRecipe implementations can still be registered with json as I do here and here. If you are using json recipes simply create a recipes folder in your assets/modid folder. All json recipes will then go there. Here is a minecraftwiki page with a description of the format and here is the examples I used myself provided by Lex. If you are using in-code registration subscribe to RegistryEvent.Register<IRecipe> and use event.getRegistry().register to register your recipes. Do not forget to give them a registry name!

You can't directly transform the metadata from a blockstate to a metadata of an ItemStack. For example the metadata of a sideways spruce log would be 5. An itemstack of a log block with a metadata of 5 would be something completely invalid since log metadata for items only goes as high as 3 - as you can see this approach doesn't work since metadata of items and metadata of associated blocks can represent completely different things since as I've said metadata of blocks is only used for serialization. The most accurate solution to getting an ItemStack from a block I can think of is Block#getPickBlock. While it is not 100% accurate(depends on the implementation especially for modded blocks) it is the ItemStack that is associated with middle-clicking that block and in most cases it will be the ItemStack representation of that block with that particular state in the world.

What are you trying to achieve? The only way I can think of is to invoke Block#getMetaFromState. But you shouldn't be using metadata from blockstates directly as it is pretty much only used for serialization purposes.

Why is your texture an .obj file? No. When a model is looked up in the game the blocks/models/ path is added automatically. With your path the game tries to look for the model at momcraft:blocks/models/blocks/models/magic_node.obj which is incorrect. Just specify your path as momcraft:magic_node.obj similar to how I do here.

It makes no sense. Proxies are objects which are injected into the field based on the physical side the game is on. The entire point of a proxy is to separate sided-only code. Your "common" code can go anywhere else. A common proxy is using proxies in the only way they are not supposed to be used.

No. That is hardcoded at EntityFallingBlock#fall and there are currently no forge hooks into it as far as I can tell.

There is a reason models are limited to 2 blocks tall max and you shouldn't even do that. Models should be a 1x1x1 cube. If you need a big model either use a TESR or multiple blocks each with different parts of the bigger model. The collision boxes won't work properly if they are greater than 1x1.5x1 and even the 1.5x on the y axis is a hack in vanilla. Solution - use multiple blocks for big collision boxes.