Socratic_Phoenix

I'm developing a mod that will have many machines & custom recipes (which aren't simply subclasses of IRecipe). I'd very much like to support a JSON recipe system, similar to the vanilla crafting system already supported by Forge.... I've done some peeking into how forge & minecraft actually load their files, and it looks like it's primarily done through CraftingManager#findFiles. My question is, is this a reliable method to discover recipes (supposedly located in assets/modid/extra_recipes)? Furthermore, how do I go about creating a registry for these recipes? I know forge has a built in registry system that supports custom registries, but I don't know where to start to implement my own custom registry... Thanks for any help provided!

You can also invoke sendTo with an IMessage & Player, to send to a specific player when they log in.

Well, assuming the worst case, that they're all longs, you'd have about 300*8 bytes, or 3.2 kilobytes. I wouldn't consider that a lot of data, especially since you'd only be sending it on login. Furthermore, 3.2 kilobytes is worst case - I don't know how many longs vs. ints and booleans you plan on sending, it could easily cut my estimate in half, or more. Also note that Forge tests network transmissions of 2 MB, which is quite a lot larger than your packet. You could also compress the data...

Yep, see the diamond sword recipe from vanilla: { "type": "crafting_shaped", "pattern": [ "X", "X", "#" ], "key": { "#": { "item": "minecraft:stick" }, "X": { "item": "minecraft:diamond" } }, "result": { "item": "minecraft:diamond_sword" } }

How much data do you plan on sending? I doubt the amount of data you'll need to send will show any drop in performance, especially since you'll only be sending the config packet once, on join. The easiest way to fix this would be to just always send the configuration packet... In fact, that's probably the best way to do it. The only way to know if the values were different would be to send all the values either from client->server or from server->client, so you may as well just send them from server->client anyway... Abstract away the config into an object or into static fields. When the client joins the server, the server should send the configuration values, and the client should set all the fields to the received values. Don't save it. Unless you're storing large amounts of data, caching will likely be more trouble than it's worth.. -------------------------------- How much data do you plan on sending? If it really is just a config file of integer settings for machines, it shouldn't be too much...

I'm not really sure how to do this, but the easiest way would probably be to have a single armor piece set all the other armor slots to un-obtainable armor pieces that exist just to show the model... probably not the best way though.... Also, quick note to prevent problems later, you have a type in your armor material texture, you have MODID + ";hjarmor", but it should be a colon, not a semi-colon.

So... I'm a little confused. What exactly are you trying to do? Do you have to blow the block up? Or do you just want to remove it?

hmm... I've experienced the exact same thing. Im not sure how to fix it, but I can tell you that for some reason one of the if statements in WorldGenMineable::generate never passes with a vein size of 1... Not sure which one though... I can't access a computer right now... Edit: Not entirely sure why - I'm not that great at math, but with some debugging I'm pretty sure that it's this line in WorldGenMineable...

Discontinued... MCP isn't discontinued.. it's still used to develop forge and mods. And besides, why do you want to change the source code? Most of the time a forge mod should be sufficient...

I shouldn't have to, no... I've been doing some research, is WorldSavedData what I'm looking for? I need to be able to access the data client side, and the data needs to be synced... will I have to do that manually? Edit: Hmm... WorldSaveData doesn't appear to be what I want... Is there some unique id I can use? Such as a UUID or maybe the save dir name?

A single save (overworld, nether, & end)

When storing information during, how can I uniquely identify a world? Some context: I am rewriting my mod which previously used the world seed (I know, terrible), but obviously more than one world with the same seed can exist. I was also previously storing information in a Map<Seed, MyObjects> which is also pretty terrible. So: What can I use to uniquely identify a world? Is there a better way than using a Map? Is there any easy way to sync data between world & client? Is there any easy way to allow the data to be fully configurable?

I'm no expert, but try returning something other than FAIL. Pretty sure there's a SUCCESS? What I think is happening is your item is opening the GUI, but not saying to ignore block options with it's return, so the chest then opens it's GUI just after, in the same tick. I could be wrong though. Edit: just checked the code for an item of mine that opens a GUI, and I'm fairly sure this is your problem..

Do you want to completely change the texture - or just the color? Just changing the color (like Leather Armor) is extremely easy (look at how `ItemArmor` does it). If you actually want to change the model/texture... I have no idea how to do that.

Issue: The method getArmorDisplay in ISpecialArmor does not work as I believe it is intended. Whatever value is returned there is displayed added to the ArmorMaterial reduction amount. Environment: I've tested this bug only in my development environment, in MC 1.12, and with the forge versions 1.12-14.21.1.2426 and 1.12-14.21.1.2387. The Bug: I have an ISpecialArmor with the following getArmorDisplay method (the armor material also has a reduction array of {1, 1, 1, 1}): @Override public int getArmorDisplay(EntityPlayer player, @Nonnull ItemStack armor, int slot) { return 1; } This results in the below display when wearing the helmet. Notice that there is 1 full shield, when there should only be a half-shield. Research: I've traced the issue back to ForgeHooks#getTotalArmorValue, which is used to calculate this display. I'm not entirely sure what is happening behind the scenes, but I believe that the method Player#getTotalArmorValue is retrieving the armor's reduction from the armor's attribute modifiers, and then the ISpecialArmor's getArmorDisplay method is being added to that. Thus, in the above example, the attribute modifier 1 is being added to the ISpecialArmor display of 1, getting a total count of 2. Test Mod: The mod I've tested this with is here. It's not really a full mod - texture and model errors are thrown, but it is runnable enough to test this bug. Log: I don't see how an FML log could possibly be useful in this scenario, but here it is anyway...