oitsjustjose

Wow, this is perfect! Thank you!! I've implemented it, with modifications, here if anyone is curious as to what the solution is -- of course be sure to properly credit Choonster's hard work.

That makes sense. I had a hunch that it had something to do with priority / race condition, it I wasn’t sure and wondered if it was something else. Ok. Is there a way to programmatically remove recipes? I’m aware of RecipeManager but I’m not sure in which context I can obtain an instance (or should I declare my own?), and either way I’ve had issues with not being able to remove from the list (I imagine by the time it becomes accessible it is immutable but I didn’t look too far into it as it felt like a hack).

I've just spent hours trying to figure out what's wrong, and I give up for now and figured I'd ask here. I'm working on a custom Natural Progression mod wherein you can only craft planks by combining a log with an axe (for 1 plank) or a saw (for 4 planks). Since I'm able to say "hey this recipe belongs to me" with any shapeless recipe, I'm also nabbing any recipes where the input is a single Log (determined via ItemTags and BlockTags [block derived from a BlockItem]) so that I can set the output to ItemStack.EMPTY. This works as expected for many logs (including stripped and some of BoP's and others who use the tag and name system similar to Mojang/Forge specifications/recommendations). But the issue is that random (at least as far as I can tell) blocks - such as the Jungle Log and all #minecraft:jungle_logs don't work. I've narrowed it down to this: ShapelessRecipe#matches does not even get called when inserting a single stack (of any qty) of <problem log> to any slot in the crafting table Upon inserting 2+ stacks of any qty into the crafting table, ShapelessRecipe#matches is called (but at this point it has failed my qualifications for a single log) The tags are correct for Jungle wood, the only problem child. My custom recipe of axe + <problem log> = 1 plank works My custom recipe of saw + <problem log> = 4 planks works Is this an issue in Forge or is it just me? I know I can disable the recipe(s) via JSON but would like to have automatic compatability since this non-hacky solution is available. Here's a video of the problem: https://drive.google.com/file/d/1pFYcqrqI9z0XHxObUTdS__XynVNdSeao/view?usp=sharing Here's the code in question: https://github.com/oitsjustjose/Natural-Progression/blob/master/src/main/java/com/oitsjustjose/naturalprogression/common/utils/PlankRecipe.java

FYI the answer is to use List<? extends String>

Hey all! I'm having a hard time figuring out how to get an array of Strings working in the new nightconfig setup that Forge has adopted via ForgeConfigSpec. Does anyone know how to implement it? I've tried to declare my config value as ForgeConfigSpec.ConfigValue<String[]> but I get a Reported Exception for com.electronwill.nightconfig.core.io.WritingException: Unsupported value type: class [Ljava.lang.String;. Relevant log output here.

Fair - I'm just used to things in Forge having fewer components and allowing for some difference in implementation, and having Forge offer some default implementations.

That was it. Wow, there's so much involvement in getting a Capability to work with little-to-no wiggle-room for error. Thanks for the help!!

Ahhh that makes sense. I already have the @CapabilityInject portion in the Geolosys API, but your instanceof point is spot on. Let me try it and see if that resolves my issue.

Here - and it triggers so I know I haven't botched something with the static vs. non-static access:

I've been working on using Capabilities (instead of WorldSavedData due to issues with its complexity mentioned in another thread) and at this point, I'm lost. I'm instantiating my Capability and everything seems to be initialized as it should. You can see here how I'm calling it, and it always comes back null; at this point in execution I have an IWorld instance as I'm generating plutons in the world. Since it always comes back null, there's nothing I can do with it -- am I not supposed to be doing this?? I've seen : GeolosysAPI.PLUTON_CAPABILITY.getDefaultInstance() But it seems like "default" is implying that this isn't how I should be using this, and I haven't seen any other 1.14.x code using a World capability as of yet. As usual, thanks for the help!

Ah, heck. I didn't think of that.

So, I can't figure out the difference between Block#getItem and Block#getPickBlock; Block#getPickBlock requires more arguments I don't readily have and just returns the value from Block#getItem. Is there a difference?

Right, this I knew - plus I want to report the block itself not what it drops -- that being said, Block#getPickBlock is closest to desireable.

To your first point: Fair - how would you suggest I go about getting a localized name for a block? I haven't really found any good, fully dynamic solutions. And to your second: You make a good point -- so then I should reverse my logic, have the server send the BlockState to the client, and then have the client packet handler handle the localization (which as mentioned needs improvement) since that's where it should be done?

Do you mean when I do player.sendStatusMessage(msg, true);? msg is a TextComponentTranslation, so I believe it should be translated once it gets to the client unless I'm using it all entirely wrong. And that's the thing - any translations that come from Geolosys itself worked (before I attempted all this packet stuff that isn't working) -- but other mods' blocks would come through unlocalized.

Alright, so this one's been quite a tricky bit and I can't quite figure it out. I'm working on the Geolosys Prospector's Pick, which is having a localization issue with blocks not from Geolosys when prospecting on a server. I figured this was because the server doesn't translate anything, but I could be wrong. Overall, I've been working on this for hours and I have absolutely no idea what I'm doing wrong. I've thought it out, and have tried using Packets to transmit the localized name from the client to the server before the server sends the notification to the player using player.sendStatusMessage(msg, true);. I'm not sure what I'm doing wrong, but for some reason, I'm getting this error. Overall, I'm confused as to why I'm having this problem in the first place and the back-and-forth between client and server is starting to confuse me. You can see my network code (and other stuff) on GitHub. And don't hesitate to call me an idiot, sidedness is not my expertise.

Hey all - I've had a really hard time finding docs on how to use the DataBuilders for recipes and block drops, so I've decided to try out the JSON format because I can easily automate creating them via Python. I'm running into a problem though - while porting Geolosys to 1.14.x, I'm setting up smelting and blasting recipes for clusters -> ingots. I've already gotten data tags set up on clusters and ingots, but I will eventually allow ingots to be disable-able like in previous versions. Therefore, I don't want to rely on every single mod offering ingots to smelt up #forge:ore/some_ore into their some_ingot, so what are my options? The result object in the recipe JSON only accepts an item_id of form namespace: id, so I'm not given a lot of options on the JSON front.