Leaderboard

public static void registerBlocks(final RegistryEvent.Register<Block> event, Block BlockModAmethystOre) { you cannot have that Block BlockModAmethystOre parameter on the method, because then it no longer matches the registration event.

Your biomes o plenty is broken, remote it, or make sure it's the latest version. If it is, report the error to the author.

Okay, back to your original question. So both the server and client are totally separate threads. The only issue with mixing up sides is if you try to access classes that aren't supposed to be available (but might be if you're using integrated server) due to being on the other "side". So methods are only called in the client thread from the client thread. And methods are only called in the server thread from the server thread. However, there are some methods which are part of the logic on both sides and will both get called (separately but in parallel). This is for the reason I explained above -- some logic does need to execute on the client in order to smooth out the action between server updates. However, the client calls it itself. The client is just trying to copy what the server will do. It is actually kinda hard by just looking at the code to know where the code will run. There is very likely code that is not marked as SideOnly that still only runs on one side. And if the code has any checks for world#isRemote then it will execute differently depending on where it will run. Remember, the Side.CLIENT stuff is stripped out to optimize the server JAR size but there is no requirement to strip out everything. In many ways you just need to get a feel for which things are working in each place. One good way to get a feel for that is to make some test classes (block, entity, etc.) that have console statements in the methods of interest and watch what get's printed to the console. You'll see some that happen in one thread or the other, and some that happen in both. Sometimes things are obvious, like a renderer only being on client side. However, sometimes it gets confusing because the server implementation will use a same or similar method name to notify clients (rather than do the client thing) -- a good example is various sound playing methods where on the client they will directly play the sound, but on server they will send notifications to the clients (to tell them to play the sound). So don't feel too bad if you still get confused. But do try to understand the main concepts: 1) The dedicated server JAR does not have access to anything marked Side.CLIENT, although testing with integrated server will fool you (because it does have access). 2) Methods that are not marked as sided may run on one side or both, and if they run on both may use world#isRemote to have different behavior. P.S. Modders mostly run into problems with Side.CLIENT., not Side.SERVER There are also cases of Side.SERVER but those are mostly limited to networking, user authentication, and a few other MinecraftServer fields, so modders don't seem to run into problems with that much.

Sure, I'd be delighted to actually be on the helpful end around here for a change. // Get a RayTraceResult describing whatever the player's looking at (within 32 blocks). private static RayTraceResult PointingAt(boolean stopOnLiquid) { WorldClient world = Minecraft.getMinecraft().world; EntityPlayerSP player = Minecraft.getMinecraft().player; Vec3d posVec = new Vec3d(player.posX, player.posY + player.getEyeHeight(), player.posZ); Vec3d lookVec = player.getLookVec(); return world.rayTraceBlocks(posVec, posVec.add(lookVec.scale(32)), stopOnLiquid); }

To be honest, the division between the logic running on each side can be a bit murky. In this case the LivingAttackEvent may still have some use on the client side but it admittedly is less useful due to the much less information about the damage source. Overall though processing the event on the client side would only be useful for visual or audio effects, since any lasting game logic (such as modifying the actual attack) has to happen on the server.

The first paragraph is the way it actually works. I'm not suggesting something. I'm describing the Minecraft actual design. The mod has to be client-side because it isn't our server and so we have no ability to add a mod to it. This is for multi-player servers. Like if you wanted to join a MinePlex server. How would you possibly get them to put your mod on their server? That makes no sense.

So the way it works is that when the server processes an attack it updates the client with an SPacketEntityStatus packet. Unfortunately, it is implemented in a very minimalistic way, presumably for performance reasons. So there is a single byte value sent for the status. The codes are handled on the client side by the Entity#handleStatusUpdate() method. Since only a byte is transferred, only a few special types of damage are called out based on the need for client effects. For example, DamageSource.FIRE, DROWN and ENCHANT_THORNS_HIT have distinct codes and all other types of damage are considered DamageSource.GENERIC (and this is instantiated on the client side so no additional information like the attacking entity is included). So without a server-side mod it is very difficult to figure things out on the client side. I don't think it is entirely impossible to figure it out or at least make a good guess. For example, you could probably try to detect colliding entities and look at where they are in their attack sequence and such. But it would be a lot of work and probably not perfectly accurate in cases where lots of things are simultaneously happening. What could be done is that you could create a pull request on MinecraftForge to add a packet type where actual damage source is transferred and processed separately from entity status updates. Since damage is a relatively rare event I think having a more verbose packet would not hurt. If you figured out a solid way to implement it and that got accepted then future versions of Forge would support client-only damage interpretation. Since it is admittedly a useful thing to know for modding, it might get accepted.

@Differentiation, you're missing how mods are used. It is possible for people to make mods that only get applied to one side. For example, if I wanted to have my client render everything in pink for some reason there is no reason for the server to apply the mod. In the @Mod annotation you can indicate that it doesn't need to be on both side. Or on the server side you might want to change the way saving is handled, which the client wouldn't need to know about. The ability to make client-only mods is important because you wouldn't want to make a server administrator have to apply every mod that every player might want on their client. Now in most cases what you can do on one side is extremely limited, so yes in many cases (including the one discussed in this thread) both the server and client need to be involved.

Well, I meant it is conceptually more difficult as well as inconsistent with the other registries. You want to register an entity, but you need to wrap that in an entity entry. That would be okay except you can't simply construct that but rather you need to build it through a builder class then chain the methods -- and don't forget to actually call the build() method which is different than create()! Basically, you can see the OP in this thread ran into all the problems conceptually -- initially thought they could register entities directly, finally figured out that they needed a builder for entries but then forgot to do the build(). I guess I'd like it better if it was consistent across all the registries. I think the problem is that Forge is moving to more high-end programmer style -- lots of factories, functional interfaces, builders, and such. These are all really good programming style things and of course the "proper" way to do things. However, I believe it greatly reduces the accessibility to the general modder who is just dabbling. Also, the point with an API is that it is supposed to be a "contract" that is only modified under extreme situations. The amount of work it takes now to port a mod is literally weeks per mod. Forge ideally would be an API that stands the test of time (with all the changes happening invisibly under the hood). This is why there are so many people stuck modding back on 1.7.10 -- they simply can't keep up either conceptually or effort-wise. Basically, I think Forge is doing great stuff but is getting way ahead of the actual modding community both in terms of skill level required as well as simply keeping up porting mods. Heck this morning I upgraded my 1.12.1 mod to 1.12.2 and had to spend some serious time to clear out the errors. That is a problem when a modder like me who tries to keep up and has intermediate Java level has to scratch their head just to keep their previously working mod working. It is really fracturing the modding community -- if you don't believe me go to Minecraft Forums modification development forum and you'll see that only about 1 in 10 questions is about anything after 1.8! I guess I'm hoping that all these big changes get solid soon and then stay stable for a few years. Otherwise it is really disheartening to see all your learning and work get obsolete so quickly.

This is exactly the type of thread I envisioned when I was complaining on the pull request about the complexity of the new registration system... we went from needing a single, easy-to-understand line of code to register an entity to complex set of entries, builders and such. I'm still at a bit of a loss to understand the advantage of the new system. diesieben07 do you understand the advantage / reason that this sort of complexity is needed? I suppose it has something to do with the fact that entities need to be instantiated where other things that are registered (items, blocks, recipes) are singletons?

Hey there! Im a kind of new in modding and this all But i have an Idea for my mod but don't know how i can realize So: My wish is to make a tool (maybe a hammer), and with this tool you can hit an block with right-click and than its an stair, a second hit will make a slab out it and the 3th will transform it in a normal cube again. Anyone has an idea how i can do this? I hope thats possible cause than i dont have to implement stairs and slab for all blocks hope i get helb :* thx -madaro