jabelar

How did you register the event handling class? If you used the EventHandler annotation then you need to make the method static. In any case you need to have it properly registered as well.

It is not a method, it is a field. isJumping is a boolean field inherited from EntityLivingBase.

It means that something is wrong with the way your mod JAR is packaged. I'm not sure specifically but since it mentions MetaDataCollection it seems like it might be related to your mcmod.info file. Perhaps that file has a mistake in it?

Wait, first of all what do you mean by it rendering inaccurately? It should be rendering accurately. Do you mean moving inaccurately? The reason why this is important question is: do you think that it is the partial ticks part causing trouble or the actual position at the time of each render? The partial ticks is the way Minecraft tries to "tween" the motion between two ticks since motion can only update on ticks (20 times per second) but screen gets re-rendered over 60 times per second (some people now run at 120 or even higher). So i think you need to figure out which part is causing trouble before you just start using doubles or higher precision math. I am quite certain this isn't a precision problem per se. Secondly, the benefit of something moving quickly is that it should be harder to notice irregularities in its motion. So I'm surprised you're noticing something. One thing I'm wondering is: did you set your entity for fast tracking? Projectiles are set for fast tracking so that server syncs more often. If something is really fast then I think you can consider a different approach to rendering. Why not simply show sort of a "flight path" where the whole arc of the flight is rendered briefly like a bit of a "trail"? Or you can leave a couple previous positions rendered (with increasing fading transparency) to create sort of a motion blur effect. Anyway, first figure out if it is the partial ticks or the motion/position updates causing the problem. Make sure you're fast tracking as well. Then use a rendering trick to hide any remaining imperfections.

You can use Eclipse to give you a list of all the methods in the ItemStack class by right-clicking on ItemStack and choosing "Type Hierarchy". You can then scroll through and see all the available methods (and fields) and it is good to get familiar with them anyway but you should see some related to getting the item, as well as other methods for comparing ItemStacks.

I believe the RenderFish class does this. You'll see that it takes in the EntityFishHook instance as a parameter and then uses the EntityFishHook#getAngler() method to get the player instance that is fishing and then does a bunch of rendering based on all that. So to do a similar thing you have to first realize that the fishing rod item creates a projectile entity called EntityFishingHook. So for your tool you also need something similar to represent the end of whatever you're casting. Then you need to make a class like RenderFish which extends Render<EntityFishHook> but instead of EntityFishHook you'd use whatever projectile you created. Then I would mostly copy the code from RenderFish which I believe should draw the line between the entity and the player holding your tool.

I just reread your original post and realize you're trying to use another mod's items. If it was your own item you can convert the integers to bytes and back since you can control the NBT. Does an integer value actually fail? It's possible that the NBT creation code can handle casting to byte. Have you contacted the industrialcraft authors? Maybe they know a solution, or if not they will probably appreciate being aware of the bug and maybe could fix their mod to accommodate integers.

While it does seem like a bug, can't you just work around it by converting through an integer? Read into an integer and then cast into a byte (you can validate the value first if you want and throw error if the int value doesn't fit into a byte).

So what's happening with the motion. Is it doing nothing? Is it doing something but not what you expect? Also, is the isRidden and the rider all working properly? Like it knows that there is a rider on it?

Did you look at how the regular fish hook works? What have you tried so far?

Okay, now trace the rest. Is the motion and rotation of the entity changing as expected then? In addition to adding console statements to you custom methods, I often also add some to an event like LivingUpdateEvent. Check for your entity type and print out things like position and motion, plus information about whether it thinks it is isRidden and who the rider is.

Okay, now start tracing your code. Are you sure the travel method is even being called for your entity?

Okay good, so in Eclipse highlight each parameter name, right-click and choose Refactor | Rename and call them something like strafeIn, vertMotionIn, forwardMotionIn.

No offense but it is kinda weird to be aiming to "replace the world renderer" and then asking questions about what the renderer even does...seems a bit ambitious versus your understanding. What are you trying to accomplish specifically? There are a lot of render events to hook into, plus as mentioned it is possible to use combination of public instance fields and reflection to actually replace things (could just replace the RenderGlobal I guess). But it is a "big hammer" to apply.

@Spaceboy Ross You're at a very important point in your programming/modding learning and my main advice is "slow down and understand". You're jumping around across a number of advanced modding topics while missing some fundamental skills related to Java programming as well as setting up your mod. Cutting and pasting and guessing at changing values is not a good way to develop your ability and will lead to weirder and weirder bugs in your code. Now you certainly SHOULD use vanilla code as a reference, even copying portions of it, but you also MUST understand what the code is doing. So if you have a parameter name that is something like p_191986_1_ in the vanilla code you should rename it according to what it actually does. Your code will become much more readable, and your ability to modify it properly will improve. If you don't understand Java well enough to know that you can rename the parameters then you really need to practice getting stronger in Java as well. For parameters passed into a method, the name of the method and the TYPE and order of the parameters must match the call, but the name can be anything you want (and should be meaningful). In order to figure out what the parameters really mean (so you can name them correctly) you should look at the Call Hierarchy (right-click on method name in Eclipse and it will give you that option) to see where other code that uses the method is. You can look at that and it is usually pretty obvious then what the fields represent. Then, regarding debugging you have not followed my suggestion regarding adding lots of console print statements through your code. You should be able to identify what is wrong with almost any code within 10 minutes if you print out the right info to trace the execution. In your case you keep saying "it doesn't work" but that isn't helpful. You need to figure out if your method isn't being called at all versus whether it is being called and executing differently than you expect. I don't personally use debug mode much (I find console statements work for most cases) but if you're going to do that then you need to learn how to do that properly -- setting breakpoints, ensuring the thread settings are correct (so other threads don't time out), and learn the various ways to step through (or into) the code. There are lots of tutorials for that. The reason why we're all jumping in on this thread is because you're showing a lot of potential and obviously have a passion for modding, but you're missing some important lessons you need to learn in order to really progress. So, simply (a) figure out what the code is supposed to do (b) trace the execution.

There are a few things being discussed here. First of all, a resource pack should be able to replace vanilla assets not just add to them. It is possible that sounds are behaving different/wrongly but I don't think it is expected. Secondly, the events are perfectly suited for this. As mentioned above, there is no noticeable performance impact for checking for a sound. Just check for the sound and if it is the one you want to replace, play yours instead. Here is a video with more details about adding sounds in modpacks - the first part is about custom sounds (played using commands), but later it talks about replacing existing ones.

Before talking about this specific problem, your code has another problem. You're calling the Minecraft class (where you set the view entity) from a common class. This will cause crashes on a dedicated server. Checking for isRemote isn't sufficient because the Minecraft class will not even be loaded so the code statement will not be understandable to the JVM. Instead, you should make a method in your proxy system called something like setViewEntity() and in the common code do nothing but in the client proxy version call your Minecraft code. Okay, now regarding your issue with steering. To debug problems people don't just read code, rather they *trace* (i.e. follow along with) the actual execution to observe what is actually happening. There is no need to guess. I personally do this by simply adding console statements (System.out.println()) throughout my code then watching the console to confirm how things are operating. For example, in your onInteract() method you should add console statements to confirm that the code path that sets the pilot is executing as expected. And in your control() method you should add statements that firstly confirm the method is being called at all and also confirm that the isRidden code path is the one being followed. And so on. If you do this, you'll quickly find out what is wrong. Either the methods aren't being called at all, or when they are some fields are not the values you expect and so the code doesn't follow the path you expect. So add statements, see if you can notice anything specific going wrong. If you can't figure it out, post the revised code along with the actual console output so we can help.

It's great that you're trying so many things, but it is important to go through a few steps before asking for help. For example don't just say "it doesn't work". What exactly doesn't work? Did you trace the code execution to see where it is failing? Does the code for the entity being ridden show that it "knows" that it is being ridden? Do you see the code related to movement properly switching to the ridden entity. Without knowing this we will just say "copy the code for riding a pig"... Basically, always trace your code to figure out where exactly it is failing, then if you can't figure out what is wrong, post the specific description along with the code.

It tells you what has been added and what has been deleted relative to the original file that is being patched.

Yeah, pretty sure you'd have to do everything that the RenderGlobal class does but you'd set the camera and related frustum to be at the other entity position and in the direction it is looking. You could pretty much copy the code but that might not actually be easy because there is probably a lot of private stuff and concurrent modification issues you'd have to work through. I know some people have implemented mirrors that use a similar idea in mods so maybe there is some tutorial or open source code that can give you ideas.

I believe those come from "unified diff" format. See https://www.gnu.org/software/diffutils/manual/html_node/Detailed-Unified.html#Detailed-Unified

Yeah, looks like you're already on the right track. Just wanted to add that Minecraft is just Java and so any file and folder processing you want to do you can do using standard Java methods to do so.

Ummm...bind a different texture and use GL11 scaling methods?

Actually, since you're starting this now and 1.13 is getting close I would suggest taking the same approach and making it fully "flat" -- separate block for every variant. The way 1.13 seems to be going is that properties like facing orientation will still be applied to blocks but all the different types of wood will be their own block. I am not sure the entire motivation but I'd bet it is because the combination of variants with other states simply runs out of room with the 4-bit per block position "metadata". So instead of doing a half-assed approach like having two log blocks each with multiple variants just go all the way and make every variant its own thing. For more on the 1.13 approach see: https://minecraft.gamepedia.com/1.13/Flattening It will make your transition to 1.13 a LOT easier if you go ahead and flatten now.

In modern computing having something that is checked occasionally isn't going to be a performance problem. Even every tick there are literally 10's of thousands (maybe more) checks going on. The only things that will really bog down a computer nowadays are things like large loops or recursions especially if they include expensive operations. But just doing a couple straight-forward checks for value and/or type on the occasion where the music attempts to start won't be a problem. When programming it is good to think about performance optimization but you should always start with trying to make your code well-structured logically. This helps prevent bugs and aids maintenance and collaboration. If you think there is a possible performance concern then profile your code and see what is really causing problems and focus on that. There is no point fretting over the little stuff when performance is going to be dominated by a couple big offenders.