V0idWa1k3r

Also Which version of the game are you using?

Apart from messing with GL matrix this does nothing in your implementation.

renderByItem. The one that takes in partialTicks aswell as the ItemStack but both work. You are not actually rendering the item in the code you've provided.

Yes, everything is correct. What are you concerned about?

Why are you extending ItemRenderer? You need to use a TEISR, not ItemRenderer.

Well, you could store the player's position somewhere within the dragon/AI in addition to the angle variable. When the AI to circle around kicks in calculate the current angle between these vectors [dragonPos - playerPos], [unitZ](<- I am not sure which direction the game consideres forward, I think it's unitZ though). You can calculate an angle between two vectors using arccos((vec1 DOT vec2) / (vec1.length * vec2.length)) if I am not mistaken. Then you can start circling, You know the angle the dragon started at so now you can just add to it each tick. The amount you add should be manually tweaked based on your dragon's speed. Now you have a new angle, which is your previous angle + X. You can then use this angle to calculate the position the dragon needs to be at: [x = playerX + r * cos(a), y = playerY + NUM, z = playerZ + r * sin(a) Where r is the distance from the dragon to the player you want to acheive(radius of your circle) and NUM is the height of the dragon relative to the player. Then just tell the dragon to move there.

Ah, I see. I got confused by the way @FireIsH0t asked his question. The app messed up, use something different that was actually made for propper model making, like blender(it's free).

...Why? UVs are bound within a [0-1] range for a reason. Considering that the game collects all textures onto a single sprite sheet - no.

Define "limited in the size". You can use the scale transform to make the model bigger. Provide a dummy IBakedModel then. That method was deprecated a while ago. Use the methods that the Item class provides. So far you have not explained what you need a TEISR for. Please elaborate, the functionality you want might be acheivable with basic json.

ReflectionHelper.findField takes in a class and an array of field names. That array contains all names to look up the field by. That would be the MCP and the SRG names.

Your issue is the fact that you were operating with different data all this time. You were iterating over the entries in the map, but needed to iterate over actual data attached to the chunks. Because the data was different(as in the VoidEnergy instances were different) there were all kinds of issues. Don't store the data in the map, in fact ditch the map alltogether. Have a list, or an array, or something containing all ChunkPositions of loaded chunks. Also store this in the world capability since there are multiple world instances(dimensions). Your packet will also need a dimension ID. Iterate over those positions and get the actual data attached to the chunk. Then do whatever it is you need to do with it. Also probably don't send it each tick.

field_XXXXX. The line will also start with the letters FD(FielD) For example, the ones you are interested in: FD: net/minecraft/entity/projectile/EntityTippedArrow/potion net/minecraft/entity/projectile/EntityTippedArrow/field_184560_g FD: net/minecraft/entity/projectile/EntityTippedArrow/customPotionEffects net/minecraft/entity/projectile/EntityTippedArrow/field_184561_h

No, it's not and you can see that yourself: It's called func_XXXXX. Why would a field be named func? It's owner class is net/minecraft/entity/EntityAreaEffectCloud. AreaEffectCloud != EntityTippedArrow

Then you likely didn't provide the SRG name. Minecraft is obfuscated. It means that the field/class/method names in the compiled game differ from those in the source code. Use ReflectionHelper - it gives you methods which take multiple names for the thing you are searching for. Provide both the MCP(deobfuscated) name and SRG(obfuscated-ish). It's actually a bit more complex(there are three levels of names, Notch, SRG, MCP), you can ask for more if you'd like to know more. You can get the SRG names from mcpbot or from %user_folder%\.gradle\caches\minecraft\de\oceanlabs\mcp\mcp_snapshot\%snapshot_data%\%game_version%\srgs It's because technically all arrows apart from spectral ones are TippedArrows.

Could you please update your github repository so I can debug this locally?

https://bugs.mojang.com/browse/MC-107941 You are doing everything you could do completely wrong. First of all Entity#readEntityFromNBT deserializes the entity in question from the NBT provided. The NBT won't change, since the entity is reading from it, not writing into it. Finally you don't need to mess with NBT at all. Check if the arrow is an instance of EntityTippedArrow(hint: you are already doing it), cast it to one and obtain the potion effect from said arrow. Use reflection if you have to.

Define "best way". There is only one way to spawn an entity. If you want to know how to shoot an arrow into a certain direction see how vanilla does it in ItemBow

Depends. If you do not care whether the execution finishes or not then you can do it in your TE. However if you do care then you need to do it in a different way since a TE can get unloaded. Something like this(pseudo-code): class Gui { ... void onButtonPress(GuiButton btn) { Network.sendMessageToServer(new MessageDoThings()); } ... } class MessageDoThingsHandler implements IMessageHandler<MessageDoThings, IMessage> { ... IMessage handleMessage(MessageDoThings message, IContext context) { EntityPlayerMP sender = cotext.getSender(); World world = sender.world; IWorldCap worldCap = world.getCapability(YOUR_CAP, null); worldCap.addAction(new DoThings(YOUR_TIMER)); } } class WorldCap implements IWorldCap { List<IWorldAction> actions = Lists.newArrayList(); @Override void addAction(IWorldAction action) { this.actions.add(action); } @Override void onTick() { for (int i = this.actions.size() - 1; i >= 0; --i) { IWorldAction act = this.actions.get(i); if (!act.run()) { this.actions.remove(act); } } } } interface IWorldAction { boolean run(); } class DoThings implements IWorldAction { final int timer = 0; DoThings(int i) { this.timer = i; } @Override boolean run() { if (this.timer % 20 == 0) { this.doThings(); } return this.timer-- == 0; } void doThings() { ... } } @EventBusSubscriber class WorldHandler { @SubscribeEvent static void onWorldTick(WorldTickEvent event) { if (event.phase != Phase.END) { event.world.getCapability(YOUR_CAP, null).onTick(); } } }

Look at DynamicTexture, that is minecraft's way of having textures outside of assets. For an example of usage see GuiListWorldSelectionEntry#loadServerIcon

I don't fully understand you here. Do you want to render the last screenshot or a file from a mod's jar? Because these two things are completely different, screenshots are stored in the screenshots folder, not in a jar.

Don't ever use static initializers for registry entries. Instantinate your stuff in the appropriate registry event. BasicItem is an antipatteri. There is already a BasicItem, it's called Item. IHasModel is stupid. All items need models, no exceptions, and nothing about model registration requires access to private/protected data. Register your models directly in the ModelRegistryEvent. This makes no sense for two reasons. Reason number one is that Info.proxyCommon points towards an interface which can't be instantinated in the first place, which will crash the server. Reason number two is that your common proxy can't be your server proxy, since a server proxy either provides noop implementations for client-only methods or references classes/methods/fields that would crash the client. Uh, are you really calling static methods in your interfaces here? First of all this loads the IProxyC class, which will crash the server. Second of all why are you even doing this? Are you aware of how static methods work and the fact that they can't really be overridden? Do you know basic java? Speaking about your proxies, this is me nitpicking but why are they called IProxy[C/S]? the I prefix in java usually indicates that it is an interface which is not the case. Don't have your proxy be an event bus subscriber. Have a dedicated class for that stuff. https://github.com/nov4e/NovaMineResources/blob/master/main/java/com/nov4e/novamine/Registry.java#L100 Don't do this. Remove registry entries in the appropriate registry events. In general if you are accessing a registry like that chances are you are doing something wrong. https://github.com/nov4e/NovaMineResources/blob/master/main/java/com/nov4e/novamine/Registry.java#L107 Don't do this. The recipe output may vary, or even be empty. Remove recipes based on their registry names, those are consistent. This actually ties in directly into this issue: In this case https://github.com/nov4e/NovaMineResources/blob/master/main/java/com/nov4e/novamine/features/tooltips/VanillaTooltips.java#L14 Don't do this. You might be only playing in english but there are plenty of people who might want to play with your mod but don't know english or simply want to read the text in their native language. Don't ever add straight-up english text if you can avoid it, use the localization feature of the game.

There isn't an event specific to player finishing eating the food but you can listen to LivingEntityUseItemEvent.Finish. That won't work for mods that add food that can be eaten instantly by simply right-clicking it, though I know of none such mods.

You could have your own version of ContainerWorkbench that does the check and replace the default one with yours when the container is opened. It won't work for any of the modded crafting tables though. I suppose you could make an issue/submit a pull request at forge's github about that but I don't know how likely it is that forge would accept it, since you are the only one doing this. I guess you could also contact Mojang directly and ask them to add the ability to have recipes support more than one item from a stack per craft. They might be willing to do this since they are already doing the whole data-driven recipes for map makers thing, but good luck contacting them in the first place.

This should never be the case since you are adding the capability to each and every chunk. And if this is the case - something is seriously messed up and you should just crash the game. Use the debugger to see When the update packet is sent to the client, if it is sent at all What are the contents of said packet What data arrives at the client What the client does with that data

Well, that happens because in vanilla there is no reason to. All recipes in minecraft take one item at a time, not many, and as such the system just isn't built with requiring more than one item in a stack at a time. This isn't a "major flaw", this is you using the system in a way it was never meant to be used. Your best solution is to have your own implementation of ContainerWorkbench that does the check every time a stack size is changed aswell. Of course that means that you need your own workbench.