jabelar

It does support NBT data. The getSubTypes() method returns an ItemStack of items with different metadata. That metadata might have been generated by NBT, but the result is the same and that is what I'm passing back and forth. Remember that there is a difference between the NBT used to make variants and item NBT used for further player customization. This whole scheme is about giving player's fresh items, not copying specific items that are customized by the player. The server already has the default NBT. You just need to pass the metadata mapping and the server can re-create the same item stack.

That does seem weird. I haven't used Techne in a while -- I found it was easy enough to figure out models based on cubes by coding directly -- but I seem to remember that scaling the texture could cause some trickiness. Do you get the same problem when use default texture size?

To rule out coding as the cause, have you tried downloading someone else's mod repository and seeing if it behaves the same? The only other thing I can think of is maybe your Java version or the JVM arguments are causing trouble. I run forge on both good and crappy computers (like my 5-year old work laptop) and have never noticed this.

I couldn't let the topic go and kept working on it. I think I have success -- I can create a list from a byte buffer (which could be payload of a packet from client) that contains one of every item variant. Here is what the output of the resulting List toString() looks like: You can see for example that the spawn eggs (called monster placers) start at metadata value of 50 like they're supposed to, etc. Here is the code I run to create the byte buffer (you need to run each method in a row on client side). You need to put this code in the client proxy because it calls the client-side only methods: And here is the code that can receive the byte buffer on the server side and create the list: Note that the code probably needs some exception handling in case the byte buffer doesn't come in in the expected format. The expected format is: 1) int for item ID 2) byte for number of subtypes 3) if the subtypes is more than 1, then each of the metadata values as integers. Since the third part can be variable, you need to use loops to create and retrieve the values based on the number of subtypes.

I agree it is a fun project. It got me interested when I confirmed your point that server doesn't really have full concept of the sub-types. But every Item sub-type can be represented ultimately by the metadata. It's just that the server doesn't know the full list of possible metadata values. I think ultimately you could create an List of ItemStacks on the server if you wanted to, you just have to do the work of transferring the actual metadata values from client to server. You can do that in a number of ways, and I think you have some ideas on how to do that. It would take a bit of thought, but seems quite doable. Good luck!

The NBT shouldn't be a big issue, I don't think. The getSubItems() method will get a List of ItemStacks based on whatever the mod author wanted, but the result is the same -- a list of ItemStacks with Item and metadata value. My code above will still properly count the number of subtypes. Then when you tell the client you're interested in the 5th sub-type, you can just look that up by taking that element from the list. Otherwise, you're on the right track -- I can tell you understand the basic idea: you just need client to give information to server about the number of subtypes, and the Item itself can be referenced by ID. The server doesn't actually need to know the metadata value, it just needs to know the sub-types' index in the List that is returned by the client-side getSubItems(). So you shouldn't need to send that much data.

One note to watch out for. The example I give has the client indicate the number of different subtypes there are. In almost every case, the metadata values all start at 0 and go up with no gaps. However, I realized that in vanilla items, that spawn eggs (id = 383) actually start at 50. So my code will correctly say there are 27 spawn eggs but you won't know what the starting metadata value is. For vanilla you could just handle that special case, but other mods could have any scheme they wanted. So to be really safe you probably have to send more information. I see two options: 1) if you just want to use this for random item generation, then the server could use messages to get the mapping to actual metadata after it chooses the item. In other words, if server knew there was 27 spawn eggs and it chose spawn egg 14, then it could send a message to the client asking what the actual metadata value should be. 2) You could create the initial list with a bit of extra information. For example, you could have something in the payload that flags any item that doesn't have regular pattern of metadata. Like the payload data could be a boolean (for whether it is normal), the item id, and the number of subtypes, then if it isn't normal you would provide the additional info (like start at 50).

Like mentioned, the IDs must match as that is how the server communicates. If you don't trust that, I suppose you could use unlocalized name strings which should also provide a unique way to look up things. Yes, the server can create an actual list of ItemStacks using this information from the client. Basically the server would receive the packet from the client and then it would go through the Item.itemRegistry and would create a list of ItemStacks that would have metadata=0 if there was no match in the packet payload, otherwise would use the value from the packet payload and create multiple ItemStacks (one for each metadata value). So steps would be like this: 1) have a field on server to contain the List of ItemStacks 2) when receiving the client packet, the server should iterate or loop through the Item.itemRegistry and check if the item has an id that matches a key in the map sent in the packet. If yes, then use the map value, otherwise use 0. 3) For the number you get in Step #2, you'd loop and create a new ItemStack that contains the item. Like if the packet said there were 2 values, then you'd create one stack with metadata 0 and one with metadata 1. You'd add each stack to the List from Step #1. After that the server would permanently have a list of all items and subtypes that you could use to do what you want. This was actually an interesting topic. It does indeed suck that the getSubTypes() method is only client-side. It does seem useful to have an easy way to access all items including subtypes. I think I'll write this up as a utility as it might be useful sometime.

I don't think you understand how easy it is to do what you want. All you need is the client to send information about those few items that have more than one type. I wrote some code to do this, and this was the result (item id and number of subtypes): {1=7, 322=2, 3=3, 5=6, 6=6, 263=2, 139=2, 12=2, 397=5, 17=4, 145=3, 18=4, 19=2, 24=3, 155=3, 349=4, 350=2, 31=2, 95=16, 159=16, 351=16, 160=16, 97=6, 161=2, 98=4, 162=2, 35=16, 38=9, 168=3, 425=16, 171=16, 44=7, 175=6, 179=3, 373=61, 126=6, 383=27} You can double check the accuracy here: http://minecraft-ids.grahamedgecombe.com/ For example, it says iD#1 has 7 sub-types, which is correct (it is various types of stone block). So you just need to pack that info into a packet and send it. Here is my code. I run it in the client proxy since there are some client-only methods. Note you must do this in the post-init stage since you want to make sure all mods have registered their items as well. I just run each method during post-init. I have two map fields, one that holds all items and another that is "sparse" meaning only containing those items that have more than one sub-type. Then if you send this info to the server in a packet, it would go create a list of ItemStack by through the list of items but also accounting for the number of sub-types the client said there were.

I really haven't experienced that. Is it related to performance of the computer or something? I did a quick search and couldn't find much mention of such a problem.

Sorry but I read your other thread this can be done with more simple payloads. The server already knows all the items, and yes you're right that it is easier to pick sub-type on the client. But you can still get a list on the server by going through the item list once and querying a client to get info on the subtypes. The only code you should have following logic: 1) server goes through the item registry and sends packet to client indicating which item (the payload can simply be the integer ID from the registry) 3) client checks whether the item has subtypes and if it does it does the getSubItems() and finds the size of sub-type list. 4) client sends packet to server indicating the number of subtypes. 5) server updates a mapping of items and number of subtypes. So two very small packets are required. Now if you really want to continue in the way you were, I'm surprised that the packet is large. You only need to have the client send a list of item ids that have subtypes and how many there are. Server can assume that remaining items don't have subtypes. So it should only be several dozen bytes long I think -- for example all 16 dyes would just be represented by three bytes (two for id and one for number of subtypes). In either case you get the best situation -- server gets complete list and therefore prevents hacking and can control the probability of selection to ensure all items have equal chance (or some other distribution if you want). By the way, to answer your specific question about large payloads: for the logic in creating large payloads, the protocols are usually simple -- in the first bytes of the payload you simply send a boolean to indicate whether this packet is the last packet or not. If not, the receiver will continue to concatenate incoming packets. You don't need to send anything about the actual size, just whether you're finished or more is coming.

Also, for fog effect there are a couple specific events: RenderFogEvent FogColors FogDensity I give an example of using these events in my events tutorial, look at Example #3 at the bottom of this page: http://jabelarminecraft.blogspot.com/p/minecraft-forge-172-event-handling.html

Which tutorial did you use? I think I tend to follow this one: http://www.minecraftforge.net/wiki/How_to_make_an_advanced_configuration_file

While it is good to worry about performance when choosing an approach to a problem, I really don't think that reflecting 5 fields every tick on an occasional tile entity will have any real impact. Generally, regarding performance optimization you should first code "correctly" (meaning in simplest, common, readable way) and only optimize if you identify a problem. Otherwise you can spend a lot of time and pain on something that didn't matter in the first place.

This has nothing to do with unlocalized names. Okay, you're right except most modders I've seen use the unlocalized name also as the tag to register their items. But you're right that the string used to register is what is required and it might be different. Anyway, you need to know the string used by the other mod for the item name when it is registered.

Yeah, not sure what is up with their download pages, but I use: http://files.minecraftforge.net/ If you use http://files.minecraftforge.net/minecraftforge/ it seems to be out of date.

Basically you need to have a translation file for each language you want to support. I have a tutorial on language localization using lang files here: http://jabelarminecraft.blogspot.com/p/minecraft-modding-localization.html

LivingHurtEvent maybe?

Well, your mod then would have a dependency on the other mod. So you'll want to make sure you indicate that in your @Mod annotation with something like: @Mod(modid = "yourmodid", version="yourversion", dependencies="required-after:othermodid") Of course you need to replace your mod's id and version, and the other mod's id as appropriate for your case. Once you're sure the mod is loaded, you can look up the item using the GameRegistry if you know the mod id and the unlocalized name used to register the item. So you could have code like this whenever you want to the item: GameRegistry.findItem(modid, itemUnlocalizedName) Of course you need to replace the modid and itemUnlocalizedName to match the mod.

Are you sure its not a lag issue of some sort? What else is your code doing each tick?

That is odd. registerModEntity() should be the correct method to use. Maybe you have the tracking parameters not set up properly (there is tracking speed and tracking distance I think as parameters)? I use something like this successfully: EntityRegistry.registerModEntity(parEntityClass, parEntityName, ++modEntityID, MyModClass.instance, 80, 3, false);

Well, the best way to debug such things is to trace the execution to see if everything is behaving like you expect. You can put logger or console statements (like System.out.println() method) in each method of your entity and AI classes, where the statements print out values of the key fields. Then you can usually quickly determine what is going wrong. Just looking quickly at your code, I'm wondering if your setTamed() method should be calling the setTameValue() method as well. I don't see where the datawatcher value is being updated if you don't call that. So perhaps it is never really getting tamed due to you not setting that value. I have some tutorials that might interest you as well: - Creating custom living entities: http://jabelarminecraft.blogspot.com/p/creating-custom-entities.html - Creating custom AI for entities: http://jabelarminecraft.blogspot.com/p/minecraft-forge-1721710-custom-entity-ai.html - Creating custom animation for entities: http://jabelarminecraft.blogspot.com/p/introduction-first-of-all-to-understand.html

Do these child entities need hitboxes and stuff, or are they more just a visual effect (like a something flying around a parent entity)? If it is mostly visual, then I suggest you have just one entity (the parent) and just render the others (only on the client). The parent entity would have fields to keep track of the child entities, and the server would only keep track of the parent entity. If the server needed to know or control the child entity positions, you could have a custom packet that updates them all at once.

Yeah, that is my opinion too. You can certainly code a precise hitbox, and logically it will be correct, but practically it could be really annoying where the client looks like it hit but server doesn't register it due to lag. Like you said, you can't have the client determine the hit because that opens the door for hacking.

What exactly did you mean by that? Isn't IEEP made up of NBT fields? Or are you talking about putting a full compound into the IEEP? In the case of putting a full compound into the IEEP, I actually think that is a good way to do it, because then your compound is more likely to be compatible with other mods -- what if your mod and another mod both add a "mana" field to the IEEP? Or maybe IEEP already handles that with an IEEP for each mod separately? Anyway, when I use IEEP I tend to make a full compound, fill it with my tag fields, then write that with a mod-specific tag to IEEP.