Leviathan143

Yes. If you are fluent in Java or another similar language, post more specifics, actual code you're using would be good. Otherwise, you're being too ambitious and you should try something simpler. This task is not suitable for someone new to Java.

It doesn't need to. The logical server is part of the physical server process. The same goes for the client, the logical client is part of the physical client process. You seem confused about sides, I recommend you read this, even if you've read it already. It gives a pretty thorough explanation of logical and physical sides.

Can you rephrase that please? It's not clear what you're asking.

The effects of the static modifier are restricted to a single JVM. The server and each client all run separate instances of Minecraft in separate JVMs. There is no synchronisation of instances or member values between separate JVMs by default. If any exists it is because it has been explicitly and deliberately programmed by Mojang, Forge or you. Neither Mojang or Forge autosynchronise static member values. Separate JVMs do not talk to each other at all, in any way, ever, unless explicitly and deliberately told to do so and how to do so.

Why? It looks like you're trying to add a right-click action to your block. That is not the way to do it.

switch statements only work on primitive types, Strings, enums & the wrapper objects for primitive types(These are special cased). Since Block does not fall into any of those categories, you can't switch on a field/method return of type Block. What are you actually trying to do here? Blocks have a method that is called when they are right-clicked.

@Tmtravlr Your first issue sounds like it could be addressed by a PR I'm working on, MinecraftForge#4443. I'd appreciate it if you would give some input on it.

*Some of the test mods have a constant which is false by default. Unless this constant is changed to true, they still load but do absolutely nothing. I recommend you do this with your test mod, as it makes things cleaner, makes load times shorter and reduces the likelihood of test mods interfering with each other.

The qualified names you're giving as the proxy locations don't match the qualified names of the proxy classes. For example, you tell Forge your client proxy is com.absithiumgamer.learningmod.proxy.ClientProxy, but it is really Com.absithiumgamer.learningmod.proxy.ClientProxy. On another note, your package names do not follow java convention. Java naming conventions say that package names should be lowercase, you start your package names with an uppercase letter. Your class names are fine, they are PascalCase, as they should be.

Two things. One, "NEED HELP" is a terrible thread title. It tells me nothing about your problem, you wouldn't be posting here if you didn't need help. A thread title should give some idea of the problem. Two, you have not supplied the relevant code, making it less likely that someone can help you. As for your problem, it looks like your proxy isn't where you've told Forge it is.

Your property won't work because the fish hook doesn't include the looted entity in the LootContext it uses to generate fishing loot. It doesn't include the player either, so you can't check the biome of either entity. I'm working on a Forge PR to include the player, looted entity, damage source & player luck in all the loot contexts that they are applicable to and available to. There are also two other issues with your property. Firstly, a separate property for every class is completely unnecessary, you have complete control over the serialisation and deserialisation of your property. If you need info for your property, just figure out how to express it in string form, then you can specify it in the .json and deserialise it into whatever format you need. Secondly, you shouldn't be using the minecraft domain as your property is not part of vanilla Minecraft. Use your mod's mod ID as the domain.

Your pseudocode is on the right track. To get the string id of the entity, you can pass it into EntityList.getEntityString(). You should also be using Object#equals() to check string equality, rather than ==. == checks identity, it returns true if the two objects are the same object, i.e they are located at the same memory address. Object#equals() returns true if the two objects can be considered equivalent, the definition of equivalence depends on the object. For a String, two Strings are equal if they have the same characters at the same positions.

Your question is analogous to asking 'Is there any benefit to using java.util.List over using java.util.Map for indexed data storage?` as NBTTagCompound and NBTTagList are internally backed by a Map and a List respectively. The answer to the question is yes. java.util.List is designed for indexed data storage, java.util.Map is not. Consequently, using java.util.Map for indexed data storage is a terrible idea as it was not designed with that purpose in mind. If you have a problem, use a class that is meant to solve that problem rather than abusing another to do the job. The latter may be functional, but the former is both functional and more efficient. So please use NBTTagList, not NBTTagCompound for your purpose.

It's not working because you are passing chunk coordinates into a method that takes world coordinates. You want Entity#posX, Entity#posY & Entity#posZ.

Silly511 is setting up a Forge development workspace in order to submit a PR to Forge, not a Forge mod development workspace. The setup process for the former is quite different from the latter.

I've run into this issue before, I don't remember exactly what the problem was. However I do remember that I fixed it by deleting my Forge workspace and then following cpw's Forge dev env setup video; cpw uses IntelliJ IDEA but the video is still applicable to Eclipse as long as you change the IDEA specific gradle tasks to Eclipse specific gradle tasks.

A better approach would be to iterate over IChatComponent#getSiblings() until the chat component you want to change the style of is found. You can get the style of a chat component with IChatComponent#getChatStyle() and then the colour with ChatStyle#getColor(). From there you can change the ChatStyle retrieved with IChatComponent#getChatStyle() however you like using the methods it provides.

If you aren't on the latest Forge version already, I'd recommend updating. The json system had a lot of issues when the first beta of Forge 1.12 released and still has a few. You might find that updating will fix your issue.

Learning as you go is a very bad idea. I know, I did it, it was not enjoyable. Go learn Java properly. Start with Hello World and build up from there. You will find this much easier once you've done that. Oracle has some excellent tutorials here and here.

Local variables cannot be static. You need to use a member variable instead. Reflection is expensive, so you want to reflect efficiently. Method, Field, Class, etc objects obtained via reflection only need to be obtained once for a class and its children. So you should only obtain them once and then store them. Also, you should be using ReflectionHelper to get the Field objects. It allows you to deal with obfuscation much more easily as all its methods take an array of names for the field/class/whatever, if it can't find the thing under one name it tries the next one. You may be interested in knowing about the try statement's finally block.

You might like to know that you can replace TrappedShulkerStateMapper with an anonymous class. This allows you to avoid having to create a new class that you will only ever instantiate and use once. Since you are using 1.12 where Java 8 is required, you can also use a lambda expression instead. A lambda would be even shorter than the anonymous class. Which to use, or the choice to not use either at all is up to you. I just thought I'd inform you of some of Java's features that could make this easier.

Override Block#getRenderType() to return EnumBlockRenderType.ENTITYBLOCK_ANIMATED. You will notice that the method is marked @Deprecated, this is fine. It's just Mojang's way of saying that these methods should not be called(Call the equivalents in IBlockState instead), however it is still fine to override them.

You mean how long the entity has existed?

The keys look to be the variant names. To clarify, they are the strings you put before a variant to specify the conditions that should cause that variant to be used. Examples of variant names include "facing=up", "snowy=true", "facing=top, part=top", etc. I figured this out by creating exit breakpoints on both of the constructors of ModelBlockDefinition. Then I launched in debug mode; when execution suspended due to one of the breakpoints, I hovered over mapVariants in the source and looked at the string representation of it in the lower popup. I'm using Eclipse, but IDEA should have something similar.

There's nothing wrong here. Gradle does not generate the eclipse folder, it's only found in the MDK. The eclipse folder is completely unnecessary and in my opinion it is not a good way to manage a project. It only allows for one project in an Eclipse workspace and requires downloading/copying the MDK to create a new project. I would recommend using a multiproject workspace instead. Lex has made a video tutorial on this, it can be found here. He recommends using setupDevWorkspace, however I would strongly recommend setupDecompWorkspace as it allows you to look at the decompiled MC source. Additionally, I would not recommend targeting 1.8, target 1.9.4 at the very least, preferably 1.10.2 or 1.11.2. 1.8 had a lot of issues due the the massive changes to the rendering system, these issues were mostly remedied by Forge for MC 1.9.4.