V0idWa1k3r

There is no setupDecompWorkspace in 1.13 I don't know if eclipse has gradle support built-in, if it doesn't install the appropriate plugin and simply import the MDK as a gradle project, gradle will do the rest for you.

You can't do this in your packet. You must reconstruct the data in your handler, you can't store it like that.

net.minecraft.item.crafting.IRecipeSerializer

UVs are just texture coordinates. You can bind whatever teture you'd like, the coordinates tell OpenGL where to get the colour from

Binding a texture is an action that is model-independent. Regardless of what and how you are rendering the binding of texture will always be the same.

Likely whatever GLU is doing to create the sphere either doesn't include UV coordinates at all or they are setup incorrectly. The correct answer here is to not use GLU. I don't believe it is even included in lwjgl3 anyway(and 1.13 will use lwjgl3) so yeah. The easies option to render a sphere then to me would be to create and render a wavefront(obj) model instead.

SAPPHIREORE != oreSapphire. ObjectHolders aren't magical, they match the field name(or the value passed in the annotation) to the registry name. Also registry names must be entirely lowercase.

Use one of the subclasses of TickEvent. The one you use depends on your circumstances and your mod. It can be whatever you need it to be. In most cases it would be an int. If you are going with the second approach it would be a long

Set a counter field to the amount of ticks you want to wait in your triggering event, decrement the counter in a tick event, once it reaches zero do your action. You may or may not need to store the context you need(block position, triggering player, etc) in fields too. You could also store the time(in ticks) at which you want the code to execute and instead of decrementing the counter compare the current time against the stored one.

I highly doubt that, considering the 1.13 tutorials that people are making now still continue with those outdated practices like static initializers that should've been gone by now and with the new loading system are causing a ton of issue. So yeah, the issues I saw: https://github.com/Mekelaina/Duelcraft/blob/master/src/main/java/com/mekelaina/duelcraft/blocks/BlockBase.java Block/Item/WhateverBase is an antipattern that abuses inheritance. Don't use it, you don't need it. There is already a BlockBase, it's called Block. If you want to set common data of your block don't abuse inheritance, use a helper method. https://github.com/Mekelaina/Duelcraft/blob/master/src/main/java/com/mekelaina/duelcraft/util/interfaces/IHasModel.java IHasModel is a bad practice, drop it. Not only do you not need it at all, you actually end up writing almost 3 times as much code using it compared to the amount of code you would write without it. I have no idea why everybody got so attached to this stupid thing. Oh well, at least 1.13 practically killed it with automatic item model registration. https://github.com/Mekelaina/Duelcraft/blob/master/src/main/java/com/mekelaina/duelcraft/proxy/CommonProxy.java A common proxy makes no sense. Proxies exist to separate sided-only operations, if your code is common it goes anywhere else but your proxy. Even besides that I would say that if you need to use a proxy for an operation common executing code is not possible at all. https://github.com/Mekelaina/Duelcraft/blob/master/src/main/java/com/mekelaina/duelcraft/proxy/CommonProxy.java#L18 This makes no sense. On a server that would just return you the english translation. On the client you can use I18n directly. https://github.com/Mekelaina/Duelcraft/blob/master/src/main/java/com/mekelaina/duelcraft/proxy/ClientProxy.java#L23 Don't make your proxies into event handlers, that invalidates the whole purpose of a proxy - a class that would only be loaded on the respecive physical side. https://github.com/Mekelaina/Duelcraft/blob/master/src/main/java/com/mekelaina/duelcraft/Duelcraft.java#L76 A CommonProxy is bad enough, but having it as your ServerProxy makes even less sense. Server proxy executes the code that would crash on the client with ClassNotFoundException. This is the opposite of common code. https://github.com/Mekelaina/Duelcraft/blob/master/src/main/java/com/mekelaina/duelcraft/init/ModBlocks.java Don't use static initializers for your Registry entries ever since you can't control the loading order of those classes. It WILL mess everything up at some point. Registry entries must be instantinated in the appropriate registry event. https://github.com/Mekelaina/Duelcraft/blob/master/src/main/java/com/mekelaina/duelcraft/blocks/tileentities/BlockTileEntity.java#L14 I don't understand the point of this class at all. Just override Block#hasTileEntity and Block#createTileEntity in your block classes. https://github.com/Mekelaina/Duelcraft/blob/master/src/main/java/com/mekelaina/duelcraft/blocks/tileentities/TileEntityPillar.java#L58 Don't "request a sync" from the client ever. The server knows perfectly well when to sync and what to sync, the client shouldn't have a say in this at all ever or it will be abused by malicious clients. Override TileEntity#getUpdatePacket, TileEntity#getUpdateTag, TileEntity#onDataPacket and TileEntity#handleUpdateTag instead. https://github.com/Mekelaina/Duelcraft/blob/master/src/main/java/com/mekelaina/duelcraft/util/handlers/RegistryHandler.java#L37 This is too early to add new entries to the ore dictionary, and if you would look at the output log of your game as it starts up forge tells you that with a bunch of errors already.

With the way you have it setup - no, it isn't possible to apply UV changes by editing vertex data. It is still possible with a custom shader if you are willing to go that way(although I wouldn't recommend that). The best way would be to bind different textures based on the frame.

You've never called a super implementation of GuiContainer#initGui from the override in your GUI thus the player's open container never updates to reflect yours thus the packet that arrives on the client carries the new slot indices but the client still thinks it has the regular inventory open thus causing the issue. It also causes a bunch of other issues that I am surprized you haven't told us about. You are also using a ton of bad practices that you must drop, like CommonProxy and static initializers. They WILL cause issues later on. Also you probably shouldn't include all those files in your repository while you have not implemented them yet. It took me the good part of an hour to download and setup your repository because of 8000+ useless resources you've got.

mcmeta files are for defining animations within the texture atlas, it doesn't do anything for textures not belonging to a texture atlas, aka normal textures. So the short answer is no, it isn't possible. The long answer would be you can make the object appear to have animated textures by binding a different texture based on some kind of counter, like a current frame field. Depending on the way you render the sphere you could also change the UV values to shift to the next frame

https://github.com/DanielHeEGG/RapidOxidation/blob/master/src/main/java/com/daniel_egg/rapidoxidation/proxy/ClientProxy.java#L20 You are registering your renderer for minecraft's EntityFireball, not yours ProjectileFireball

No, 1.8 is not supported, neither is 1.7. We only support 1.10 and higher at this point in time.

You need to give the slots that belong to your TE's inventory said TE's inventory, not the player's inventory.

Predicate is just a functional interface that takes a given argument and returns true or false. You can learn more about finctional interfaces and lambdas here So in your case something like e -> e != thrower && e != this would work just fine. Also don't bump, this is not a chat room. Your post is within the top 10 recent posts, there is no reason to bump it.

Why are the indices of both of your slots the same? This should never be the case. As for the issue - look at the object you are passing to this method: Obviously the added slots will correspond to the player's inventory since it is the inventory you are passing.

A shader is a program that executes on your GPU. It gets some data as an input and it outputs some data. That's all there is to them. When opengl renders stuff it goes through various passes, during which it may interact with the currently active shader program. An interaction in this case would be opengl passing some data to the program and collecting the results. Write one, bind it before rendering and you are done. Of course shaders are fairly complex and difficult to discribe like that. There are many resources online that introduce you to shaders. Just keep in mind that minecraft isn't exactly shader friendly, as in it's rendering engine is a huge mess of pre 3.0 and post 3.0 GL code. https://learnopengl.com/Getting-started/Shaders is a good one I am personally aware of, but apart from that just google "opengl shaders tutorial" and I am sure you can find a lot of information out there.

The item/inventory will sync itself to the client automatically in this case. Make sure not to spam the server with packets though.

What you've bolded in your error message means that the issue happens when the game fills the slots based on the packet it received from the server. It is still the same issue - the inventory specified doesn't have the slot with that index. So I'll repeat myself again - use the debugger. The code you've provided shouldn't cause this issue, maning something's wrong somewhere else. You could also provide your mod as a github repository so I can debug it for you.

I don't think you want to do this since this inventory will be discarded once the container is closed. You could use the debugger to at least find out what inventory those slots belong to since as it stands I can't find an index greater than 35

it got renamed to getInstance

Well, yes, it is a static initializer. All I can recommend to you is to learn java. Making minecraft mods requires an understanding of the language the mods are written in, you can't really make a mod without knowledge of the programming language you are using. I mean I could say "you have created the constructor yourself, pass in the values that make sense" but even if you fix this issue with our help you will encounter new issues at every step going forward if you don't know the basics of java.

Custom potion effect creation hadn't changed for a while so 1.12 methods should still apply as long as the tutorials are not using stuff like static initializers.