jabelar

In the meantime can you replace the vanilla anvil with a custom one, or can you intercept other events for player interaction with blocks to help you make an educated guess on who's working on the anvil?

Hey, I'm just in the process of updating my mods (and tutorial information). In general there are some simple tricks to use your IDE (like Eclipse) to help you find the new names and approaches to things when the versions change. For example, if it says that a method doesn't exist then often by looking at the Type Hierarchy for the class that used to have the method you can see a method that has similar name that is probably the new one. Also, often the classes in the new version are written in fairly close order to the previous version so you can just open a project in the old version and compare that class with the new one and it is usually obvious what the replacement is. In cases where they have deprecated a method, they often provide a comment to explain which method you should use now. You can also look at vanilla classes and see how they are now doing whatever you want to do. Sometimes it is a bit more complicated, where a whole system is replaced -- like how Extended Entity Properties is replaced with Capability. In that case it is best to look up tutorials and search the forums. Most of the questions have already been answered. Anyway, I can look at the extended reach tutorial over next couple days and see what is required to update. But don't wait for me, see if you can figure it out on your own -- I'll just have to do the same thing you will need to do!

I already mentioned that. It would help, but wouldn't be foolproof because other mods could also do that (in which case I think it would still load in alphabetical order). More importantly, canceling events is not a foolproof way of preventing other mods from intercepting your mod's functionality. For example, even if your mod gets to handle the mod first and then cancels it (so no other mod gets the event) other mods can actually set receiveCanceled=true and still get the event. Furthermore, canceling events can really screw up other mods and even vanilla functionality. A lot of times with events you want to do something additional to vanilla but not prevent all the vanilla stuff from also happening. Anyway, I'm just saying that there is not really a foolproof way of preventing other mods from interfering with yours. You can try to increase the priority of your handler and get your mod to the front of the load order, but there are still ways the other mods can affect you. Best bet is to make users aware of incompatibility and contact as many mod authors as you can to help improve compatibility.

It's not strange at all. The lang files are simply piggybacking on the resource loading system which allows lang files in resource packs (mods are resource packs). If you are adding lang key for your mod, they are no different than vanilla lang keys. Really? so you're saying that if another mod tries to get the unlocalized name for my mods item it doesn't realize that it is from my mod and look only at my lang file? It will look in all the lang files for all the mods that are loaded for a match to my item's name? How would that work? Anyone can call I18n.translate from anywhere. How does that know which lang file to use? Well, the unlocalized name is called against the instance of my item which I assume the game knows was from my mod. If it really doesn't do what I assumed, then there is really no safety in using a lang file at all because no matter how unique you try to make the unlocalized name it is not foolproof... I have no idea what you are on about here but it sounds horrible. Yes, which is why I'm arguing against it. Other cases? No. You use registry name if you want the ID. You never use anything else. Right that's what I said. If there are no other cases then you mean never use unlocalized name ever? Unlocalized name is if you want to display the name of the thing. That's it's only purpose and you should not use it for something else. I think we're saying the same thing. That unlocalized name is for displaying the name, and you want to make it unique enough that it is unlikely to be copied. However, you guys are scaring me off of using unlocalized name even for displaying the name. You're implying that translation won't just look in your mod's lang file for matches. Anyway, I'll defer to you guys' recommendation. All I was trying to tell people was that there was still a place for using unlocalized name (for use with lang files), but I guess there isn't...

Sorry but your problem is really mod incompatibility. There is always the possibility in modding that there are mods that can't be used with yours. For example, imagine you have a mod that creates a special sword and another mod replaces all swords for some reason. Those two mods simply can't be used together. You have to tell users that you're incompatible with mods you know don't work, and tell users you might be incompatible with other righ-click mods. Hopefully your mod is more interesting to them than the other mod and they'll choose yours. If there is a popular mod that you think people want to use with yours and the author won't or can't make it compatible you might consider adding those other right-click features so users don't feel the need to run both mods.

Do not strip that off! Unlocalized names are GLOBAL, if you add an item with the unlocalized name "item.thingy.name" (or I should say, that's what shows up when you go to put it into your localization file) and localize it to "Awesome Hat" and then another mod comes along and creates an item with an unlocalized name of "item.thingy.name" localized to "Neat Wand" guess what? Both items in-game will display with the same name, depending on which mod loads second. Instead, if both mods left their mod ID in the unlocalized name, this would not happen. Well first of all, it seems strange that it is really global because the lang files are per-mod assets. You're saying that localization will be overwritten? Unlocalized name is only intended to be used with translation, which I believe will still be per-mod according to the lang file for that mod. That's what I'm talking about. There is a place for using unlocalized name. If the concern is that another mod might actually change the unlocalized name of your mod's item, then that is when I'm suggesting you'd need to use registryName() and strip the modid from it (and add the "item." and ".name" to do the translation). As I said, for other uses where you need a unique id, then in those cases you'd use registryName() as is. Are you guys really saying to NEVER use unlocalized name?

He's already trying the event, and his problem is that he can't be entirely certain that his mod handles the event first or that it prevents other mods from handling the event. Same with any of the block methods, those can be intercepted by other mods handling the event. Back to the original posters question. Regarding mod load order and intercepting them I'm not sure you can fully solve that, but you can probably make it a lot less likely to be a problem. First of all, I believe that the default load order is alphabetical (someone can confirm) by mod id so maybe giving your mod an id with "aa" in the front might help move it forward. In the @Mod annotation, you can add dependencies where you specify whether your mod must load before or after. I'm not sure you want to make a dependency on the other mods (since you don't want to make them required) but there might be a clever way to use this anyway, like make the dependency but handle the error, or maybe look at how the mod load order works and somehow force your mod early. However, none of that will fully work because you can actually make an event handler receive canceled events (so canceling doesn't even ensure that all mods will not see the event). I think maybe an alternative is to actually be the last loaded and then check if any of the right-click mods are loaded and then undo whatever it is that they're doing. In the end though what you're talking about is a mod conflict -- the user has installed the other mod for a reason and you are trying to prevent that mod from working. So basically your mods are probably incompatible and you should advise users and mod-pack makers to not use both. Or if there is some functionality of the other mod you want to leave alone, then what you should do is contact the other mods' author and work with them to create compatibility (maybe the mods can have a configuration that allows one or the other be active on right-click).

I know Chooster recommends this (using getRegistryName()) but it seems to me to be a bit tricky depending on where you are using it. Basically it doesn't return a string directly but rather a ResourceLocation, so you often have to use toString() method on it. And then it will put your mod ID in front like this "modid:my_item_name" which you might have to strip off. I personally think you should use getRegistryName() when you need the registry name (i.e. the one-time set never changing name), and use the unlocalized name when you want an unlocalized name. I guess the main thing that is safe about registry name is that technically other mods could change the unlocalized name of your mod's items. I personally haven't seen a lot of that, but I suppose there are mods out there and therefore a risk. So if you need a name to be the key to something, or help point to a file location, registry name is safer.

I had made this tutorial a while back: http://jabelarminecraft.blogspot.com/p/minecraft-forge-creating-custom.html I made it for 1.8.9 but I believe it should still work for later versions, or at least give you some ideas on how it would work.

Thanks. I've just returned to modding after a year and so these differences are tripping me up. There's some subtle stuff...

I have multiple items in my mod, and only one of them seems to behave oddly when dropped (i.e. when it is an EntityItem). The item is a "golden egg" and the texture is exactly the same as vanilla egg except colored a golden yellow-orange. However, compared to the vanilla egg it is rendered much larger and this furthermore cause it to go into the floor when hovering. Here is a picture of what is happening (my egg on left, vanilla in middle): Now my item model JSON looks like this, which is almost identical to vanilla egg: The item model is registered in my ClientProxy class init stage method like this: The item class is: Don't know what else you might want to see code-wise but the whole thing is on my github (let me know if it is not publicly accessible) here: https://github.com/jabelar/MagicBeans-1.10.2 Note that I've seen where people add scaling and translation in the item model JSON. I tried the JSON like this, but still had same result:

Are you talking about the loading states like "pre init", "init", "post init", "server started" and such? One major use for these is to manage features of your mod that might interact with other mods. The reason is that if the user has multiple mods applied to their game, when starting up it will first call pre-init on all those mods, then init on all those mods, then post init on all those mods. Therefore, if you put code in your post-init, you will know that all the other mods have already finished their pre-init and init stages. So for example if your mod allowed people to make a statue using the model of an entity, and you wanted your mod to include the ability to make statues of entities from other people's mods, then you'd want to grab the models during the post-init -- so you could be certain the other mods' entities are all registered along with their renderers. There are also some standard things that are meant to be done in certain stages. At least you shouldn't do them any earlier. Like registering blocks, events, commands, etc. each have their appropriate place.

You'll need to use math to keep the positions arranged properly. So let's say that the master entity has hit box that is positions where the main body (torso) is. Then depending on how you're crouching and rotated you would move the other hitbox entities into the right places. Note that for debugging it is very useful to use the F3+B hotkey combo which will display all the entity bounding boxes on the screen. But anyway, you'll have to do some trigonometry. Have fun!

Yes, the hitbox is publicly accessible and I'm pretty sure it is changeable dynamically -- for example I think this happens when an age-able entity grows bigger.

I think you'll have to check to see what gets destroyed by comparing what is in the bounding box of the dragon during each living update of the dragon entity. In the current living update code for the dragon entity, it has destroyBlocksInAABB(this.dragonPartHead.getEntityBoundingBox()) That function is private, but that's okay. The main thing is that it destroys the blocks in the dragonPartHead bounding box. So you could simply handle the living update event, check if it is and ender dragon and if so and turn all lava that is in that bounding box to your dragon glass.

Yes, you can add fake entities for all those parts and adjust. Just beware that the hitboxes are still each limited to being square in X, Z, and they can't be rotated. So you wont get a perfect match to your actual model which might be rectangular and rotated. But it should still be much better. And it is important to remember that this is Minecraft after all -- so it isn't a game about precise headshots really. So don't have too high of expectations for making a fully accurate first person shooter.

This forum is for asking questions if you're programming a new mod, not for problems with using existing mods... Anyway, it is obvious that the journey maps mod is crashing. Remove that from your system. You might want to contact the author of that mod to see if they know why that happened. But basically either that mod has a bug, or some of the other mods you have are conflicting with it.

Regarding hitbox, the main hitbox of an entity always has a square base -- at least that was a limitation up until 1.8 when I last tried changing the hitbox. Also, it doesn't rotate but is always square to the world. This is a problem for most interestingly-shaped mobs, since it means there will either be parts of the entity which won't count as a hit, or there will be parts outside the entity which will count as a hit. I believe this limitation is in place to help with path-finding as it would it would cause performance to slow down a lot if Minecraft had to find paths for irregular, rotated hitboxes. So most mods that want more irregular or precise hitboxes tend to make a "multi-part" entity. Basically you can add additional hitboxes by creating invisible entities that follow around the associated entity (in your case the player). If those hitboxes get hit, then you call the same actions as if the main entity got hit. Look at the ender dragon code to understand what I mean if it is still unclear.

Well, you have to admit that git is dangerous in the hands of people just getting started with it because it has power to change a lot of files in one action. That is why I suggest using SourceTree since it give a graphical picture of what is going on (like your branches, head, etc.) to help people understand what's really going on.

Okay, if you really want to do this...shouldn't be too hard. GameSettings and KeyBinding classes are only client side. So if you really want to get that information over to the server, I suppose I'd just copy those classes into custom classes that exist on the server, then both at beginning of session with player and also any time player exits the gui that allows keybinding changes, I would send a custom packet to the server that contains sufficient information to populate the server side version.

You should really handle the FML loading events with a "proxy" system. I'm not certain that checking the side the way you do would really control it. Also, where do you even register your item? Anyway, of course the init() method is going to print twice because it is called on both client and server side. You should see in the console that one print statement comes from the server, and one from the client. That is why you tried to put code to check for client (after your print statement) because otherwise all that code would run twice too.

Well, you'll just have to figure out how to use the various GUI elements to draw the values of those things where you want them to be. For example, you could have the first page of the GUI have a number of buttons where each one has text for each category and then takes you to a page that just has those categories.

I have a tutorial for this. It is fairly basic, but might give you some ideas: Advanced Configuration Files: http://www.minecraftforge.net/wiki/How_to_make_an_advanced_configuration_file Configuration GUI: http://jabelarminecraft.blogspot.com/p/minecraft-modding-configuration-guis.html

Are you sure it is that simple? Maybe in 1.10 they've changed it, but in older versions even if you set it higher the server would still limit the maximum reach. We had to go through a lot of trouble -- see my tutorial: http://jabelarminecraft.blogspot.com/p/minecraft-modding-extending-reach-of.html If it works that easy now, I need to try it!

You don't say whether you're using Forge or whatever, but are you trying to create naturally generating structures or ones that can be created by the player (like with an item)? Anyway, the first thing is to decide whether your structure is "regular" meaning lots of shapes that can be calculated (like rectangular rooms) or "irregular" meaning lots of details that can't be calculated. If it is regular, you can usually just use loops to place the blocks, combining routines to make walls, ceilings, and such. If it is irregular then it is best to read it from a file resource. In the case of a file resource, I usually just come up with my own format that simply lists the block types, relative positions, and any metadata in a text file. Then during the mod loading I just load that information into a list or array, then when I want to generate the structure I just iterate through the list and place the blocks according to the relative positions. One other detail is that some blocks act differently depending on the order they are placed. For example, if you place a torch block before the wall it is supposed to go on then it will fall down and become an ItemBlock of a torch. Most of the blocks that act this way also have metadata. So I actually generate the structure in a couple "passes" -- first the normal blocks, then the special blocks. If your structure contains items for loot and entities you can do a similar thing, using a text file to indicate the item or entity and it's relative position in the structure. If your structure is a simple variation on vanilla structures, you might be able to use the built-in structure generation code. In that case, simply review the village generation code to get the idea how that works and modify to your liking.