Jump to content

oitsjustjose

Members
  • Posts

    17
  • Joined

  • Last visited

oitsjustjose's Achievements

Tree Puncher

Tree Puncher (2/8)

0

Reputation

  1. 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.
  2. 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).
  3. 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
  4. FYI the answer is to use List<? extends String>
  5. 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.
  6. 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.
  7. 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!!
  8. 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.
  9. Here - and it triggers so I know I haven't botched something with the static vs. non-static access:
  10. 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!
  11. 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?
  12. 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.
  13. 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?
  14. 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.
×
×
  • Create New...

Important Information

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