V0idWa1k3r

From what I can tell annotation-based configs are created and injected when the mod is constructed. So even as early as pre-init should be fine. I've just debugged it and can confirm that the configuration indeed exists at preinit.

You can get a Configuration for your mod by using ConfigManager.getConfiguration. If you haven't specified the name in your @Config annotation then it will be equal to your modid. That configuration will contain all categories/properties you've specified in your annotation-based config and you can do whatever you want with it just as you would with a normal Configuration.

Object#toString will return a fully qualified class name appended by @ and the object's hashcode in hex. Item doesn't override that method so you get this. In any case don't use metadata for buckets, use capabilities to store the fluid. As for the model - forge uses a custom model for it's buckets - ModelDynBucket. It is needed because any mod can add any fluid it wants and the forge bucket must be able to contain it and display the propper fluid textures. You can utilize forge's bucket model in json - the parent model becomes forge:forgebucket, and the textures it expects are: base: The bucket's empty texture fluid: The dummy fluid texture. I think this is basically the mask for the fluid's actual texture to apply to, and anything outside of the mask is discarded. You can use the dummy fluid texture provided by forge - forge:items/bucket_fluid if your bucket is of the same shape as vanilla's, otherwise you need to create it yourself. cover: The bucket's texture that has fluid in it, but the fluid's pixels are transparent. If you are using forge's blockstates you can also pass some custom data: fluid: the name of the fluid to put in the bucket when baking. If this is not specified water is used as a default fluid. flipGas: whether or not to flip your texture upside-down when the fluid is a gas. applyTint: whether to tint the fluid's textures based on the fluid's colour. Actually you can read the javadoc yourself - ModelDynBucket#process. If you need an example of using the dynamic bucket model with custom buckets - here is one. Note that the example uses forge's blockstates to define the bucket's model, not a model json. And yeah, these parameter names make no sense. I can kinda see naming strings as str_something, although that is actually what's called a Hungarian notation(kinda, but close enough for me to classify this as one) and has absolutely no place in modern programming whatsoever(and I think you are the first person I've ever seen to apply it to java code, congratulations), but why is Item also named like that? Or an int? This makes zero sense.

Well, updateScreen happens once each tick, drawScreen happens each frame. There are 20 ticks a second and any number of frames per second. Depends on how you do it. If you have the position value changed each tick, but calculate the interpolation based on partialTicks each frame then yes, it will be perfectly smooth. Otherwise no, it will have issues with too low or too high frame rates.

You are thinking about it the wrong way. Have a counter field that gets decremented in the tick event. When it reaches zero type your key and set it to the delay you want.

You can't just return 1 when the method wants you to return a T where T is an instance of your capability. This is basic java. You need to return a wrapper around your capability that only allows access to certain slots.

That's what I meant by "or something". I don't think it really matters, LootTables are not a IForgeRegistryEntry and are managed separately. Currently it doesn't matter when they are added to the set. If you want - yes, you can absolutely register them in pre/init. If they ever become a IForgeRegistryEntry though I will be telling people to use the appropriate registry event :P.

Just put them in the run/mods folder if you just need them for testing. If you actually want mod integration then you need to add them as libraries through your build.gradle file or put them in the libs folder and add them as a library in your IDE.

This is the cause of your issue. When loot tables are reloaded then all loot tables from the LootTableList are iterated using foreach. This method adds a loot table to the list. Obviously, you can't modify a collection while it is being iterated using foreach, hence the CME. Do this method soewhere else, like in a static initializer or something.

Are you sure? What's this line then?

Well you could type into the console with a robot, sure, I guess. There is no console on an integrated server though, only the dedicated. Chat messages are typed on a client, then sent to a server. I meant the logical server.

Use it as a library. You can use a proxy-like system where you have 2 classes that share a common interface that provides the contracts for the methods. If mod A is loaded then you instantinate the AProxy class that references mod's A code. If it isn't then you load NoAProxy that provides noop implementations. You can use reflection to instantinate the proxy, this way it is guaranteed that your proxy class will not load unless mod A is present.

Well, yes, if the fields are static then they are not instance-based and thus you can't simply create another instance and be content. You need a different approach. I kinda see your point but this is ultimately more work than the one config idea. Keeping two configs means that you now need to write the ugly: int hardness = player.isConnectedToAServer() ? ServerConfig.hardness : ClientConfig.hardness; everywhere(pseudo-code obviously).

The robot class in java exists to simulate mouse/keyboard input. The server doesn't care. It doesn't even listen to any input.

Particle textures are determined at BlockModelShapes#getTexture. If you inspect the method you will find out that it has hardcoded special cases for any vanilla block that has a TESR. Thus the only approach for you is to have a IBakedModel associated with your block. You don't actually need to have any quads in the model as long as you return the correct texture in IBakedModel#getParticleTexture and your block doesn't return INVISIBLE in Block#getRenderType(unfortunately returning invisible makes the particles have no texture) you will be fine. And yes, your model may specify a particle texture without specifying any quads and that is acheivable through json alone.

You must have done something wrong. I just used this utility and was infact able to make a remapped OF jar that works absolutely correctly. Show your command line input for running the deobfuscator, please.

Well, optifine uses notch names. That complicates things. Try this, might still work. The last paragraph of the readme is the important part here. I don't know if it still works now, but it worked for OF for 1.11.2(I've browsed OF's issue tracker to confirm, here is the relevant issue - the OP had it working after following the instructions)

Well, yes, but it doesn't really make sense to modify the registry before any recipe has been loaded. And yes, vanilla recipes also get loaded basically at that event(it loads vanilla recipes first, then fires the event). And yes, the recipe registry happens after pre-init but before init, just as any other registry. See Loader#initializeMods. And while you could in theory modify the registry in the init or post-init after it has been initialized it won't work with any mod that grabs a reference for recipes, like JEI for example. It won't even work with the recipe book actually since it builds the recipe table after the registry event but before the init. So the registry being modifiable doesn't really mean you can do whatever you want with it whenever you want without consequences or incompatibilities. Besides the registry event just seems like the most logical place to modify the registry.

Well, you can see how vanilla did their furnace at TileEntityFurnace. Just don't use IInventory like it does, use capabilities. I have yet to see a minecraft modding tutorial video that would at least be "ok". Most of them are pretty bad. Actually every single one I've seen so far was pretty bad. So don't expect to find anything good on youtube for a while, although I've heard that @Animefan8888 is planning on making a series on his channel once 1.13 forge comes out.

This is the wrong time to be removing recipes. You need to remove them at the appropriate registry event. Yes, recipes are a IForgeRegistryEntry. Also don't do this Item item = r.getRecipeOutput().getItem(); if (item == Items.SHIELD) { recipeRegistry.register(RecipeEdit.get(r)); } check whether the recipe you need removed is the one by comparing it's registry name. Why does it even have the output itemstack if it outputs an empty stack when asked? And it doesn't even matter since it doesn't fit any crafting grid. Also it doesn't override the recipe you desire to override since it's registry name will never equal the recipe you are overriding.

IntelliJ Idea, Eclipse

Well there are official forge docs. You can also look at repositories of mods by other people, like here, here and here for example. Your IDE, of course.

You need to use the language file to set the names for your items. The tile.whatever.name is the language key. The value you assign to it will be what's displayed in the game. IHasModel is stupid. All items need models, no exceptions and nothing about model registration requires access to private/protected things of the item. Register your models in the ModelRegistryEvent directly.

Apart from that, yeah, learn java first. There are plenty of online courses/books. Don't. That is the worst choice anywone who wants to do minecraft modding can make. As an example as to why recipes must be made using json, not java. And even if you use java for some god forsaken reason do it in the appropriate registry event, but not in the PreInit.

public static boolean isPlayer(Entity entity) { Minecraft.getMinecraft().getIntegratedServer() return entity instanceof EntityPlayer; } Uhh... fitst of all this code doesn't even compile. Secondly there is exactly zero need to get a server to determine whether the entity is a player. Even in this snippet you've provided getting the server does absolutely nothing. instanceof in java8+ is one of the fastest operations the JVM can perform. It is kinda useless for the MinecraftServer class itself but different implementations of that class may override the method to do something else. If you want the DedicatedServer you can use FMLServerHandler#getServer, that one is pretty much guaranteed to return a DedicatedServer. However remember that DedicatedServer class only exists on the physical server, so if you access it in any way you need to do it in your server proxy. In a lot of cases a simple MinecraftServer will suffice and you can get that through FMLCommonHander#getMinecraftServerInstance which will return either an IntegratedServer(client) or a DedicatedServer(server). Again though, you do not need a server instance for your issue. Object.this has nothing to do with what you are talking about, it's just a way to access the parent instance of inner non-static class instances.