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.