Choonster

From your previous thread:

MovingObjectPosition was renamed to RayTraceResult . Most renames in 1.9+ are documented in this issue tracker.

Ah, I see what's happening now. In the deobfuscated environment, IBossCustom#getHealth is implemented by EntityLivingBase#getHealth in EntityBossElgra ; but in the obfuscated environment, EntityLivingBase#getHealth has an SRG name like func_0001_a so there's no longer a getHealth method to implement IBossCustom#getHealth . If you want a completely custom boss overlay, either rename the IBossCustom methods so they're not implemented by vanilla methods or replace your current boss system with a copy of vanilla's BossInfo system, modify it to your needs and use it like EntityWither does. If you want to use the vanilla overlay, just use BossInfo like EntityWither does.

That should work. Post your code, particularly the EntityBossElgra and BossCustomStatus classes.

It looks like you may be running a deobfuscated build of the mod in the obfuscated client. Make sure you build your mod with the build Gradle task, which reobfuscates the mod after building it.

If you run Minecraft in debug mode, you can edit your code and then tell your IDE to compile the project; this will reload the edited classes in any running client/server instances. Note that it's not possible to reload classes if you've added/removed classes, methods or fields; you'll need to relaunch the instances in this case.

ProxyInjector is the class responsible for injecting the instance of your proxy class into the field you've annotated with @SidedProxy . In this case, it's throwing a ClassNotFoundException because the class you specified in the annotation ( quizer9o8.com.mineralz.proxy.ClientProxy ) doesn't exist.

IForgeRegistryEntry.Impl#setRegistryName(java.lang.String) will automatically prefix the specified name with your mod ID.

ModelLoader.setCustomModelResourceLocation must be called in preInit, not init.

If you want a block like the cake, try looking at the cake's code.

Minecraft ran out of memory. Give it more memory by increasing the value of the -Xmx argument in your launcher (1G = 1 GB of memory).

Mekanism is trying to use a class from BuildCraft's API that doesn't exist. Update both mods to their latest versions. Where did you get that copy of BuildCraft from? It doesn't look like it was downloaded from the official site.

Post the FML log.

Always specify the Minecraft version you're using in the title. Judging by your code you're using 1.7.10, which is very outdated and no longer officially supported. Update to 1.10.2. There are a few issues here. You never set PlayerHurt to true , so the condition in your PlayerTickEvent handler is never met. You can't store per-player data in event handlers, there can be any number of players on a server all doing thing simultaneously. Why are you sending the packet a tick after the player is hurt instead of sending it straight away? You're mixing up sides here. LivingHurtEvent is only fired on the server side, it's never fired on the client side. You send a packet to the server that calls World#spawnParticle , but this does nothing on the server. You need to listen for damage on the server and then send packets to the clients of nearby players to spawn the particles. You don't need your own packet, you can use WorldServer#func_147487_a ( WorldServer#spawnParticle in 1.10.2) to send a packet telling clients to spawn particles.

Post the FML log (logs/fml-client-latest.log in your game directory).

Post the full output of the command.

PlayerEvent.StartTracking is probably a better event to use here. This will be fired when a player starts tracking the entity, after the entity's spawn packet has been sent to the client; so the entity will likely exist by the time your packet is received. The entity will only exist on the clients of players close enough to it. If they're too far away or in another dimension, their clients won't know anything about it.

The capability is for arbitrary mobs in the world, not players. The entity ID is required to determine which mob to update the data for.

PacketEnemyLevel does absolutely nothing when it's received by the client, so the client-side IEnemyLevel instance is never updated. You need to send the entity ID and the level in the packet, then retrieve the Entity with that ID from the client World and update its IEnemyLevel instance.

If the check is fairly infrequent (e.g. once a second), use World#scheduleUpdate to schedule an update tick from overrides of Block#onBlockAdded and Block#updateTick . Perform the check in the override of Block#updateTick . If the check is fairly frequent (e.g. once a tick), use a TileEntity that implements ITickable . In either case, you'll have the block's World and BlockPos so you can check the block under it.

Always specify the Minecraft version you're using in the thread title. You first need to decide when this check takes place, what triggers it and what counts as an ore block. You can then use World#getBlockState to get the IBlockState at the specified BlockPos .

Models are resources that get overridden by resource packs, just like textures. If you don't want a resource pack overriding a vanilla model to affect your own model, copy the vanilla model into your own assets and use the copy as the parent. This doesn't prevent a resource pack from overriding your copy of the model.

It looks like you tried to use a deobfuscated build of the mod in the obfuscated client. Make sure you build your mod using the build Gradle task, which reobfuscates the mod after building it.

You could answer this question yourself by looking at the code that formerly used ICrafting and seeing what it uses now. You could also search this issue tracker (which documents most renames in 1.9+) for ICrafting to find this issue documenting its renaming. For fields, methods and parameters (but not types like classes, interfaces and enums), you can also use MCPBot to view their name history.

CheeseArrow#makeTippedArrow doesn't override a super method because there is no method with that name in ItemArrow . Override ItemArrow#createArrow instead. Always annotate override methods with @Override so you get a compilation error if the method doesn't actually override a super method. Using rendering-related classes like Display in common code will crash the dedicated server since it doesn't use those libraries. Rendering-related code must only run on the client side. Changing the window title is a bit obnoxious, the user doesn't need to be constantly reminded that they're using your mod. Don't access static fields (e.g. DeGeweldigeMod.DGMInstance ) through instances (e.g. this ). There's no reason to use the @Instance field within your @Mod class; the methods are already being called on that instance, so use this .