V0idWa1k3r

Override it by overriding the entry in the datapack. Bascially have a datapack with the modid of minecraft provided by your mod that overrides that one specific advancement. Pull Request

That only applies if you are using IDEA though, I don't know enough about eclipse to help you with it but check whether forge had been imported.

You need to add a corresponding armor rendering layer to your renderer. See RenderZombie for an example.

I just told you. Use reflection to access the list, iterate it, find your particle in it(likely based on it's position) and change the colour fields. I wouldn't recommend this way though. Sure, you can do that, that's one of the ways I've suggested.

The issue here is that SlotItemHandler references IItemHandler#extractItem to check whether the item can be extracted and since you are using one custom IItemHandler that will always return something based on the slot id it returns false and you can't extract items from the slot. You need to return a wrapper based on the side your capability is accessed from. If it is accessed from a null side chances are it's your container or something else that should always have access to all slots regardless. Pipes will never pass null.

https://github.com/BurntRouter/ATimeMod2/blob/dev/src/main/java/com/router/atimemod2/init/ModEntities.java#L22 I have seen many ways to access registries in my time on these forums, but this one is the best worst one yet I think. Don't do that. Registry entries must be instantinated in appropriate registry events and registered there. What you are doing here will never work. Also Why? Why would your registry event handler extend a registry entry?

Don't do anything you are doing with your items/blocks/entities/registry entries. They must be instantinated in the appropriate registry event, and registered using the registry instance passed in that event. If you are ever accessing registries like that you are doing everything wrong. And yeah, your issue is using static fields. In your ClientProxy the itemrenderer is stored in a static field, or rather it is obtained by a static field. By the time that executes it is null, so you are passing null to the renderer thus making it crash with an NPE. Don't obtain references in static fields like that, don't use static initializers, don't access registries like that, use appropriate events.

I can confirm that the code of the testmod just doesn't match here. Look at the commit history of the CapabilityPigSpawner. Especially this commit https://github.com/Choonster-Minecraft-Mods/TestMod3/commit/b191f331519093a5d6986f01508812fb95cd59bb#diff-8b7fdc96f9790467595ac30419c94981 It happened at Mar 1, but the ItemPigSpawner was only updated Feb 27, so it still references the old code from said file. Especially look at this change https://github.com/Choonster-Minecraft-Mods/TestMod3/commit/b191f331519093a5d6986f01508812fb95cd59bb#diff-8b7fdc96f9790467595ac30419c94981L112 This change changed the return value of the method to be a LazyOptional from the actual instance. So yeah, the item sources just weren't updated to compile with the changes, you can't make a cast like that in java, this is not a programming language where you can define custom implicit/explicit casts. Just get the value from the lazy optional and operate on that, it should be an instance of your interface or whatever you specify in the getter method.

Override Block#getHarvestLevel. Override their entries in the blocks registry by registering a new block with the same registry name as the old one. This works with many registries, not just blocks. However do consider using events before doing this. Overriding blocks won't really work well if multiple mods are overriding the same block. Maybe an event can do what you want. https://minecraft.gamepedia.com/Advancements#JSON_Format Forge doesn't change the way datapacks register advancements or much about them really. You would do the same things you would when making a datapack. Can't actually answer #4 since i've never really worked with the recipe book, but I don't think many players care since pretty much everybody uses JEI anyway. In theory it should assign a recipe to a tab based on the creative tab of the resulting item. It is possible, but not with that mindset. It is a very invasive way that creates a ton of compatibility issues and is not going to be supported here. Use forge events or if something can't be acheived by an event/registry override/inserting other object into a field consider making a PR instead.

https://gist.github.com/mcenderdragon/6c7af2daf6f72b0cadf0c63169a87583

So if I understand you correctly you want to enable the slots on the left if there is an item in the pink slot in the middle? See ContainerHorseInventory and GuiScreenHorseInventory for an example. It basically overrides Slot#isEnabled to check for whether the slot should be active and the GUI itself is modular with the slots not being drawn if they are not enabled.

I would say that you want to log as little as possible. Maybe if you have not quite a fatal issue you should log it but that's about it. Please don't be *that* mod that logs every block and item it registers, or even worse a mod that spams absolutely useless info into the log like TConstruct does. Yes, that would be correct. Yep So far your guesses are correct. Yes, but make sure to understand that it would still run in singleplayer, this is for the logical server starting.

You would either need to create your own particle class or use WorldRenderer#addParticleUnchecked(it's private so you need reflection) that gets you the reference to the added particle so you can manually change it's colour fields. That is assuming 1.13.2. In 1.12 the method you need is RenderGlobal#spawnParticle0. You could also use ParticleManager#spawnEffectParticle(1.12) or ParticleManager#addParticle(1.13) but you would need to replicate some checks WorldRenderer does. You could also iterate the particle list(it is also private), find your particle there and change it's colour fields.

Now you never call the pre-init method in your proxy, thus the OBJLoader doesn't know that it is supposed to process your mod. You did have it called previously, why you removed that lime of code I don't know. You do need the .obj extension at the definition of your model so the OBJLoader itself knows that you are looking for a wavefront model. Also stop using common proxy, it makes no sense. And don't have your common proxy as your server proxy, that makes even less sense. And well, it took me a while to figure this issue out, but your blockstates file isn't a forge blockstates file. forge_maker != forge_marker. Now those issues done and all your obj model is still broken. UVs MUST be within a [0-1] bounds. This one isn't.

Constants are just custom ingredients you can use in your recipes that are defined within the _constants file. They have as much to do with the OreDictionary/tags as your recipes - they can use them but that's about it.

Well, if you would update your github repository I could debug it and tell you the next issue.

Don't rely on OpenGL as the end-all solution. Yes, there is something in OpenGL(not in GL11 though) that can help you, but it isn't going to acheive the result you desire. What you can do is simply render the player's model, but disable every part of it apart from the head and it's children(ModelRenderer.isHidden).

https://stackoverflow.com/questions/23931546/java-getter-and-setter-faster-than-direct-access Basically if you look at the resulting code after a few iterations of it's execution it should be identical in most cases.

Pretty much all getters are internally optimized by the JVM.

I don't see how using 32,767 increases the recipe amount by x3. Use a new constant with multiple ingredients. And yeah, you can auto-generate recipes just fine using pretty much anything. I personally used C# for a very simple script that generates recipes with varying ingredients, but you can do the same in any programming(or scripting) language, you don't even need JSON support(although it is preferrable)

You don't need that anymore. Look at SimpleChannel#registerMessage It just takes in a bunch of functions/consumers now that take in an instance of your packet and do stuff with it, so basically any class can be an IMessage now, you don't need the interface since it is all done via functional interfaces. Again, look at the link I've provided, it has a clear usage example.

https://gist.github.com/williewillus/353c872bcf1a6ace9921189f6100d09a#nitty-gritty-random-things-ctrlf-section Specifically this section

Your .obj model is broken, the uv coordinates must be within a [0-1] range, you have some outside(in this case the X is negative).

Your repository is not set up correctly, the root directory of your repository must be the root directory of your project. I have no idea how you are doing anything in the first place since your code doesn't even compile since you have multiple syntax errors, like defining root level classes in files that do not correspond to the file names, wrong package definitions, missing imports, missing fields, etc. Please fix all of that, it is literally impossible to compile and debug.