V0idWa1k3r

What are you trying to do, exactly? Move the lightning? You will need to use the tick event to detect the lightning in the weather effects list and move it. Potentially you might also need to update the lightning's position on the clients with a custom packet, I am not sure whether the game keeps the lightning's position in sync or not.

Use the debugger, looks like the NBT data being deserialized doesn't have any tag by the inventory key. Did you add the inventory later after adding the TE to your world? In order to avoid these kind of errors don't use the raw getTag method, use the getter that corresponds to the type of the object you want to get. In your case NBTTagCompound#getCompoundTag. These getters will never return null. Now for the non-related issues: CommonProxy makes no sense. Proxies exist to separate sided-only code. If your code is common it goes anywhere else but your proxy. It makes even less sense in your case since you are using it as the event handler for whatever reason. And handling FML lifecycle events there. Handle the FML lifecycle events in your main mod class, and handle the other forge events in a separate handler. Don't use this overload that is marked as deprecated. Use the one that takes a ResourceLocation as it's second parameter. What on earth is a gui proxy? BaseBlock is anantipattern. There is already a BlockBase, it's called Block. Also: IHasModel is stupid. All items need models, no exception, and nothing about model registration requires access to private/protected data of the block/item. Register your models in the ModelRegistryEvent directly. And yes, this is just another variant of IHasModel, you just have a class instead of an interface. Don't ever use static initializers. Instantinate your things in the appropriate RegistryEvent directly. See above point. https://github.com/Sudwood/Cencial/blob/master/java/com/sudwood/cencial/blocks/BlockBasicPlinth.java#L98 You don't need all this awkward TE manipulations. Just override TileEntity#shouldRefresh.

No. The game will only display/handle your hitbox when you are directly looking at the block in question. While block hitboxes are raytraced it doesn't apply to hitboxes bigger than 1x1.5x1. If you need blocks bigger than that you will have to fill in the space with "phantom" blocks. Don't do stringly-typed code. Minecraft already has a class for directions, it's EnumFacing. Also you can't store variables in blocks like that. Blocks are singletons, there is only ever one instance per registry entry. If you need to store additional data per block then you need to use either blockstates or TileEntities. Don't compare strings like that, use equals. This only works because java has string pools and those can be disabled(I think) This doesn't even compile. What are you actually trying to do? have the bounding box be dependent on the block's rotation? You can get the IBlockState passed to you in the Block#getBoundingBox and compare against the value of the rotation property of that blockstate.

If only forge had a utility that allowed you to execute sided-only code based on what physical side you are on...

You can equip a sword aswell. And you can change the AI on the go if needed too, similar to how a skeleton adapts to having a sword instead of a bow in vanilla. But whatever, fine. You need to despawn your current entity using Entity#setDead, then create a new one of the type that you want(the other entity), place it in the same location as your first one(Entity#setPosition, Entity.posX/Y/Z) and do whatever else you want to do with it(if anything). Finally you only need to spawn it with World#spawnEntity. Make sure you check that you are only performing all of that on a server first.

Why not just make the entity wear the chestplate instead, like all vanilla entities do? There is no need to replace the entity with an another one here. This will never be true, that's not how OOP works. These are 2 different non-primitive objects thus they will never be equal to one another in a direct == comparason.

It can drop whatever you want, but you are telling the game to look for a lottable at minecraft:loot_tables/bone_drop, which is incorrect. Well, you are a programmer. You should be able to easily fix syntax errors. I can't tell what the issue is since you have neither provided enough code to determine the issue nor the error report.

This would register the loottable with the name of minecraft:bone_drop. I don't think your modid is minecraft. Also when are you calling this? Apart from that(and apart from the fact that you've blatanly copied my code - you even left the field names the same which makes no sense in your mod) sure, looks fine to me.

Also why did you quote @Animefan8888 who also told you not to use LivingDeathEvent?

There is a section in the official docs that explains how to add custom drops to a vanilla loottable. If you need an example you can have them here(json, registration, injection)

CommonProxy makes no sense. Proxies exist to separate sided-only code. If your code is common it goes anywhere else but your proxy. Hmm... didn't I tell you that already? Why yes, I did. This makes even less sense. A server proxy either supplies noop implementations for client-only methods or invokes server-side only code that would crash the client. Your common proxy can't be your server proxy because if it were it would crash the client. IHasModel is stupid. All items need models, no exceptions and nothing about model registration requires access to private/protected information of the item. Just register your models in the model regitry event directly. I told you this one earlier too. Don't ever use static initializers, instantinate your stuff directly in the appropriate registry event. And yet again, you were told to do this aswell. Same for the items. ItemBase is an antipattern. There is already an ItemBase - it's called Item. Same goes for BlockBase This is not how you specify max/min bounds logically. It only works in this case because min is 1(drops 1 - 3). If min was 2 it would drop 2-4. As for the issue - look at your random logic here: So, generate at minY + [0-deltaY]. Okay, what's deltaY? Unless min > max which makes no sense deltaY will always be negative. You can't pass a value less than 1 to a random method. In your case deltaY is -48.

Just learn how to use loottables, it's not that hard. Not only are data-driven methods prefferred over code-based ones, a lot of mods rely on loottables, like JEI Mob drops addon. You also won't have any issues as a side bonus.

This has very little to do with capabilities. Again, in TileEntity#getCapability method you need to return a wrapper around your capability that doesn't allow inserting/extracting items based on the side. You can have one wrapper that does it all, or you can have one wrapper per side, it doesn't matter. Look at the javadocs of IItemHandler to see what you need to return in insert/extractItem to provide a "noop" implementation. Edit: well, sure, here is a small pseudo-code example:

Well, GUI button presses only occur on the client while the clock's logic occurs on the server. The server has no idea that the data was changed. You need to use packets to notify the server.

Well, you need to make sure that NBT data is synced to the client upon world load. The TileEntity#getUpdatePacket, TileEntity#getUpdateTag, TileEntity#onDataPacket and TileEntity#handleUpdateTag are the methods you need. You also need to make sure that your block actually constructs it's blockstate based on the data in the TE - use Block#getActualState for that.

That's what I was talking about. Look what the WorldServer actually does: int j = this.calculateSkylightSubtracted(1.0F); if (j != this.getSkylightSubtracted()) { this.setSkylightSubtracted(j); } it checks whether the cached value isn't equal to the actual value and if it isn't it sets the field to the new value. That's all it does. Everything else uses the value stored in that field. If you modify the field you give the modified value to everything that uses it. There is an issue though - WorldServer#updateBlocks is called after that but before forge's tick event. Which means that any block ticking(not a TileEntity! Just the Block#randomTick method being invoked) still has the old value. I don't know how critical that is. Everything else apart from blocks is ticked after the forge's event though. They happen on the same thread. There is very little multithreading in the game so you don't need to worry about that. I don't think the client is even aware of this value changing actually. It looks like the only time this value is changed is in WorldServer and I don't see it being synced anywhere. I guess the client doesn't need it at all. In java enums are just a fancy way to define a collection of objects. So reflection works much the same way as it would with any other object. The only difficulty might be the fact that values in enums are usually marked as final, but there is a dirty hack to get around that. Consider the following example: Field id = EnumDifficulty.class.getDeclaredField("difficultyId"); id.setAccessible(true); Field modifiers = Field.class.getDeclaredField("modifiers"); modifiers.setAccessible(true); modifiers.set(id, id.getModifiers() & ~Modifier.FINAL); id.setInt(EnumDifficulty.EASY, 10000); System.out.println(EnumDifficulty.EASY.getDifficultyId()); This outputs 10000, even though the initial value was 1.

Well, you are completely free to override the values that enum holds though... you know, via reflection. Apart from that while I don't truly understand what you are trying to do I can see that this method Is only called to change the value of World#skylightSubtracted. And if that's a field then you can modify it in a tick event after the world has ticked(hint - use the phase to check that it is run after the rest of vanilla's code). You know, modify using reflection that is.

There was also the 1.2.x -> 1.3 transition when Mojang "merged" the client and the server code. There was no "common" code in 1.2.x, period. If you wanted your mod to work for multiplayer you had to write a separate version. I think there even was a separate API for multiplayer mods - Risugami's ModLoaderMP(although it might have became obsolete earlier)

Well first of all your mcmod.info is broken Next, your obj models are broken faces in .obj models must have either 3 or 4 vertices per face, not more. You have more. Don't ever use static initializers. Instantinate your stuff directly in the appropriate registry event. Also ItemBase is an antipattern, there is already an ItemBase, it's called Item. IHasModel is stupid. All items need models, no exception and nothing about model registration needs access to private/protected data from the Item. Register your models in the ModelRegistryEvent directly. CommonProxy makes no sense. Proxies exist to separate sided-only code. If your code is common then it goes into your main mod file or anywhere else but the proxy. This makes even less sense. A CommonProxy can't be your server proxy. Server proxy either provides methods that will crash the client when invoked or noop implementation for client-only methods. If a Commonproxy were to do that it would crash the client. As for the issue - look at the javadocs of @EventBusSubscriber You need to provide the modid property value to your annotation. Also don't upload your code like that. Use github or something similar. Oh, also that is not how you use an API. Don't ever distribute any api in your mod but your own. Use the API as a library with your IDE or gradle.

Any reason you are doing this? Biomes are singletons, you can compare them by instances, there is no need to compare the classes. int x = (chunkX * 16) + random.nextInt(15); int z = (chunkZ * 16) + random.nextInt(15); This may cause runaway chunk generation, read and understand. As for your actual issue: The name for the template you are loading is static, thus is the same for all instances of WorldGenStructure - so as a result all your structures generate with the same template.

You are mixing vanilla blockstate format with forge's. Use either one but not both. BlockBase is an antipattern. There is already a BlockBase, it's called Block. Well, why should it? You've specified the property fine, (de)serializing it fine, sure. But you are not doing anything with it. You are not setting it anywhere, nor handling it in Block#getStateForPlacement or anywhere else. Unless you are using vanilla's setBlock to set the property it will always be facing north. As for your log:

I think that entity attributes are synced between the server and the client automatically(see NetHandlerPlayClient#handleEntityProperties). The snipped above would be executed on both sides. You can trace the call hierarchy of any method using your IDE to see where it is called from. For example EntityJoinWorldEvent here is fired in World#spawnEntity. And World#spawnEntity is called from both WorldServer and WorldClient. So what I am trying to say is - use your IDE to answer questions like this. Either trace the call hierarchy or just place a breakpoint and see which side it is triggered on. If anything is marked as @SideOnly at any point - that is a strong indicator to keep things side specific. Apart from that all logic should run on the server, the client should do as little as possible. The client's job is to render things and accept input. Mostly everything else should be handled on the server.

Don't compare strings like that. Use equals. I am unable to replicate the crash in test environment. And the code provided on github shouldn't crash. I see that you've changed it recently. Is the issue still relevant? As a side note - don't set the loot in the chest manually, use loottables.

Considering that it is another mod most you can do is report the crash report to the mod author. You could also change the player's dimension though MCEdit. Or alternatively you can use any NBT editor and edit the player's NBT data: Open the world.dat file with any NBT editor of your choice. Navigate to Data -> Player -> Dimension Change it to the dimension you need, like 0 for overworld. Navigate to Data -> Player -> Pos Change the values in that array to match the values of Data -> SpawnX/Y/Z to transfer the player to the spawn. Save the file. For multiplayer do the same, but instead of opening world.dat open playerdata/%UUID_OF_YOUR_PLAYER%. You can lookup the player's UUID online.

Why? If the "most terrible thing" occured then you should crash the game. Actually you should crash the game in most cirumstances. What's your reason for avoiding crashes? Apart from some edge-cases with IO/Network by writing code that works and has checks to prevent crashes. Like if you are afraid that a value is null then you check that it isn't null before proceeding, etc.