Jump to content

coolAlias

Members
  • Posts

    2805
  • Joined

  • Last visited

Everything posted by coolAlias

  1. Bow rendering is handled specially by Minecraft, so if you want your bow to render in the same fashion, you need to create a custom render class that copies what Minecraft does. Look at the item rendering class and search for bow, then create an IItemRenderer for your item.
  2. I'm pretty sure mobs haven't changed that much from 1.7 to 1.8, so you could probably adapt those 1.7 tutorials without too much difficulty. Have you tried that, yet?
  3. What? How could you possibly screw with the vanilla coding? It's super simple: 1. EntityTameable already handles the owner for you, so you don't need to do anything there. 2. Player's username is a STRING 3. NBT natively supports reading and writing Strings: nbt.writeString("nickname", player's username); 4. Want it on the client for rendering? DataWatcher ALSO supports String by default, just add it and be done. Sorry, but this topic has gone on way too long for something so blatantly simple. It looks like there is a lot of other stuff going on in your Entity, so perhaps you'd be better off by creating a SIMPLE entity that does nothing but handle the nickname stuff. Then you can get just that working without worrying about anything else, figure out exactly what you need, and go from there.
  4. We've already explained that several times... please read every response again. Everything you need has been explained, both here and in the vanilla code. And why are you still fixated on the UUID? That's taken care of by EntityTameable, aren't you trying to save / load a String for the nickname?
  5. His point is that there are too yaw values - one for the player's body, and one for the player's head; the look vector is based on the head yaw, so your particles will be spawning relative to the back of the player's head, rather than the back of their body. Thus, if the player is looking a different direction than their body is facing, your particles will likely be in the wrong spot.
  6. Excellent point by TGG there
  7. @Ernio EntityTameable stores the Yggdrasil converted UUID in DataWatcher which should then be usable just fine to retrieve the owner Entity whether on the client or the server. Otherwise, why would they bother storing it in DataWatcher if it only worked on the server? It is sound to cache the owner entity once you have retrieved it, though, and you will need to store both the UUID and nickname, which we have discussed to death already in this thread.
  8. That's just flat out wrong. Did you not look at EntityTameable's code at all? It shows EXACTLY how to convert the UUID to String format so you can place it in DataWatcher or read/write as NBT. The second question is a result of not understanding basic principles: the whole point of UUID is that it is UNIQUE, and the UUID for each player can always be used to retrieve that player instance from the world (if they are in the game).
  9. Use a Logger, e.g. public static final Logger logger = LogManager.getLogger(your_mod_id); // somewhere in your code: logger.info("Here's a message"); // prints: [13:27:48] [server thread/INFO] [your_mod_id] Here's a message It is possible to further format / customize the output, but that is more work than it's worth, in my opinion.
  10. .. That's what I just said... but you have a custom field, 'this.owner', which IS NOT the same as what is returned by EntityTameable#getOwner, and that is what I was asking about. Anyway, it should be clear by now what you need to do; if not, I highly suggest you take some time to properly learn Java so that simple things like incorrect type parameters to a method (e.g. UUID instead of String) are no longer cause for concern.
  11. EntityTameable#getOwner returns an Entity; is 'this.owner' an Entity, or an EntityPlayer? If it is an EntityPlayer, then yes, that code should work just fine for saving the nickname to NBT.
  12. Multiplying each vector coordinate by -1 is identical to subtracting the vector coordinate: Vec3 vec = player.getLookVec(); double dx = player.posX + (vec.xCoord * -1); // is the same as: double dx = player.posX - vec.xCoord;
  13. Yes it does, it is a method of EntityPlayer. Unless your entity will be tameable by other types of mobs, then the only type of owner you will have is an EntityPlayer. Check the instance type and cast to EntityPlayer if you can, otherwise store getCustomNameTag() or whatever else you feel like.
  14. So you're saying to do float deltaZ = MathHelper.cos((float)(-yaw * 180.0/Math.PI - Math.PI)*2.0F); float deltaX = MathHelper.sin((float)(-yaw * 180.0/Math.PI - Math.PI)*2.0F); to spawn the particles at make the spawn 2 blocks behind the player once put into the x and y? If so, that doesnt make any sence as to how that would work. No, he's saying get the player's look vector and multiply each coordinate by -2, then add those values to the player's position / height values and spawn your particles there. They will appear exactly two blocks behind the player. Vec3 vec = player.getLookVec(); double dx = player.posX - (vec.xCoord * 2); double dy = player.posY + player.getEyeHeight(); // you probably don't actually want to subtract the vec.yCoord, unless the position depends on the player's pitch double dz = player.posZ - (vec.zCoord * 2); spawnParticle(dx, dy, dz); // not actual method signature
  15. Sorry, that was from 1.7.10, but if you were to use your IDE, you would quickly find a solution: look in the class outline for EntityPlayer and you should almost immediately see that there is getDisplayNameString().
  16. You can actually override onUpdate and onLivingUpdate, and that will stop it from acting like a living entity. Not entirely, as there are plenty of places that check 'if (entity instanceof EntityLivingBase)' before operating some logic which may not really apply to the vehicle; not to mention that overriding those two methods is generally pretty messy. Still, that is a possibility. I would only use it as a last resort, though.
  17. Neither: use EntityPlayer#getDisplayName() if you are storing the nickname. And sorry, I did not re-read the entire thread; based on the last few comments asking about how to store the owner UUID, it seemed like you were not extending EntityTameable.
  18. I know it's not a crash. Read my reply again. ownerID is a UUID, which you cannot store as a DataWatcher element - you must convert it to a String. Please READ the EntityTameable code. It shows you exactly how to do what you are trying to do. Better yet, just extend EntityTameable and you don't have to do anything for the owner to work correctly. Then you just have to worry about storing the nickname, which is exactly the same as storing the other String.
  19. Okay, this kind of reply where you state a problem but do not show the code you tried that resulted in the problem is part of the reason this thread is so long. Whenever you have an issue with your code, SHOW the code right away when you describe the problem, even if you think it is redundant, rather than waiting for someone to ask for it. All I can tell you without seeing the code is exactly what the error message says: if you are using DataWatcher to store a String, then you have to store a String, not anything else. If you have a UUID, you need to convert it to a String, which you would see if you looked at EntityTameable (always look at the vanilla code for examples when you are doing something that has already been done).
  20. Did you at least try searching for how to synchronize fields in an Entity before asking? Chances are that whatever question you have has already been asked and answered. Anyway, three main methods: 1. DataWatcher (google it - there is a good tutorial on the Forge wiki) - you'll probably want to use this one 2. IEntityAdditionalSpawnData - useful for unchanging fields; not suitable for your situation 3. Custom packet - very flexible and something you should learn about if you don't know already; tutorials abound
  21. A simple way to move to the left or right is to take the player's look vector, then subtract the vec.zCoord (* some factor) from the player's posX, and add the vec.xCoord (* some factor) to the player's posZ - that will give you a position directly to the right of the player. Reverse the arithmetic to get a position to the left. Vec3 vec3 = player.getLookVec(); float f = 0.15F; // this is usually roughly one block width, depending on context; play with it double dx = player.posX - (vec3.zCoord * f); double dz = player.posZ + (vec3.xCoord * f); // now use dx and dz for your entity's position or whatever else
  22. Basically, you copy the standard EntityThrowable constructor code, and add or subtract from the player's rotationYaw whatever amount you desire before you calculate the rest of the variables for the heading. Pretty simple, really
  23. Solution: Move the registration to a method in your ClientProxy, and call that method from your main class: @Mod.EventHandler public void load(FMLInitializationEvent event) { proxy.registerHandlers(); // server proxy does nothing; client proxy registers key handler }
  24. Extend EntityLivingBase instead, or simply add your own hit points field and manage it yourself when the entity is struck. The first is easier, but has the downside of your vehicle then acting like an actual living being when it shouldn't. The second is more work, and will require that you spend some time thinking about your design and being comfortable with Java.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.