Aarilight

Here's where I get the ItemStack: private static ItemStack getOreDictItem (JsonObject result, JsonContext context) { if (JsonUtils.getString(result, "type", "").equals("forge:ore_dict")) { String ore = JsonUtils.getString(result, "ore"); ItemStack stack = OreDictionary.getOres(ore).stream().findAny().orElse(ItemStack.EMPTY).copy(); stack.setCount(JsonUtils.getInt(result, "count", 1)); int data = JsonUtils.getInt(result, "data", -1); if (data > -1) stack.setItemDamage(data); return stack; } else { return CraftingHelper.getItemStack(result, context); } } Would this not work for it? Should I be looping through it manually to find a valid stack? As of now I've made 8 recipes that seem to work with it, but I guess if the list could include empty item stacks I should probably do that? I would think that would be a mod bug tho, if empty stacks are being added to an ore dictionary (and should probably be reported to those mods)? Also, conditions were mentioned previously in this conversation. The reason I didn't want to go for them is afaik, it requires adding additional information to each json recipe. It would have to be a recipe condition, as it's based on whether the "result" property in the json is a valid ore dictionary item. So basically, what would happen is the condition would check if the result !isEmpty(), and if it is, it would pass the condition, and then this code would be run again when the recipe is actually built. Since I'm doing this additional parsing as part of the recipe, to me it makes sense to allow failing during that.

I actually ended up just deregistering any recipes which were instances of my table's recipes and had an empty output. I realised that the major downside to this way was the advancement issues, and since the recipes are optional depending on mods anyway, having advancements relating to them (if I were to ever make them) wouldn't even really make sense. If I ever need to jump over that hurdle, I'll rewrite this then. Thanks for your help. =) Out of curiosity, do you think a recipe factory returning null would make sense to fail silently? Cause I still think that would have been the most elegant solution... maybe I should make a forge issue/pr, but I feel like that would be a controversial change? If there would be people that disagree with a change like that I don't think my needs here are important enough to warrant it.

No, I register them with the rest of the normal recipes (via _factories.json) ... the instances simply don't match unless they're used in my crafting table. The reason I do it that way is my crafting table also supports all vanilla recipes. It's an autocrafting table =P

I'm not really too fond of that solution either because it requires adding additional information to the json, things which I just want to happen by default for this recipe type. Also, I phrased the initial post wrong, I said "if an item is present", I should have said "if an item in a given ore dictionary is present" My current recipe factory actually supports using the first ItemStack in an ore dictionary as it's result, and I'm combining that with an ore dictionary ingredient. I guess I might as well post my current recipe: { "type": "soulus:composer_shaped", "time": 16, "pattern": [ "eee", "ede", "eee" ], "key": { "d": { "type": "forge:ore_dict", "ore": "dustLead" }, "e": { "item": "soulus:ingot_endersteel" } }, "result": { "type": "forge:ore_dict", "ore": "ingotLead", "count": 8 } } Everything is implemented and works except for the issues with not being able to fail it silently. If there really is no other solution I'll add in that new condition, I guess.

I want conditional recipes, which only are registered if an item is present. (So that JEI won't show them). The recipes were already custom classes, because they're for my custom "crafting table". I need to implement this support via the json recipe system (so my options are limited to things I can do inside of Factory.parse, I believe. What I tried so far: 1. Returning an output of ItemStack.EMPTY (just shows up as a recipe with no output in JEI) 2. Returning null instead of a valid IRecipe in the factory (crashes, which I kinda expected) 3. Setting a slot in the recipe to an IngredientNever (basically the same thing as Choonster's) (Just shows up as an empty slot in JEI) The other options I can think of: 1. Throw a JsonSyntaxException. The game doesn't crash if I do this, and the recipe isn't registered, but it will spam the log. 2. Figure out some way of hiding the recipes in JEI. (I've looked into this a bit but haven't found anything yet) 3. Figure out a way to deregister recipes (potentially the same way that CraftTweaker does it? I haven't looked into this yet) I'm not really too fond of these other solutions. Is there a simple solution that I'm missing? If not, do you think it would be reasonable to suggest forge to allow Factory.parse to return null and silently skip the recipe it in that case?

I realised I had overlooked a simple solution all along: hardcode the colours of the arguments when passing them as strings. It's not ideal, but it works, and that's what's important. EG: Biome biome = world.getBiome(pos); ResourceLocation biomeId = biome.getRegistryName(); result.add(new TextComponentString(TextFormatting.RED + biomeId.getResourceDomain())); result.add(new TextComponentString(TextFormatting.GOLD + biomeId.getResourcePath())); The final result:

I can't combine them that way because the command is server-side. EG: doesn't support using whatever language the client is. Therefore, I can't send the client a string, because then they can't translate it on their end. I have to send them an ITextComponent. I could make a packet to show the command output but I would rather keep the code less spread out and more reusable. Anyway, it seems like it's just arguments in general that the TextComponentTranslation can't handle. It colourizes the text inside the translation itself, but resets as soon as it enters an argument. Not sure what else to try.

Biome Types, not Biomes (there's only ever one biome per block x/z, afaik). Also, Structure types. (EG: when mineshafts intersect a dungeon or a stronghold) Since there can be multiple of each of those, depending on your location, I wanted to put them together into a list and have the "list separator" be translatable. (Idk, what if another language actually needed that?) Here's an example of the current output: Dimension: º6overworldºf, Biome: ºcminecraft:º6extreme_hillsºf, Biome Types: ºcMOUNTAINºf, ºcHILLSºf, Structures: ºcNone The colour codes are correct in it, but they're not actually rendering that way. I assume it's an issue with "style", but I don't quite understand how the style stuff works. Anyway, this conversation gave me an idea of a solution: the top layer doesn't actually have to be a variable-length list, that one can be a static translation. This might fix the child styles.

This is much more likely to be your issue: https://github.com/MrMagicPenguin/GFM2/blob/master/java/rug/gfm/init/BlockInit.java You aren't using your BlockTomato class, you're using BlockBase.

Oh well, I tried. The only other thing different that I noticed in my transparent blocks is returning BlockFaceShape.UNDEFINED in getBlockFaceShape, but I'm even less sure about that one having an impact on rendering.

You're using Material.GOURD, which is not transparent. I think that might be your issue. Try creating a new Material that is transparent, or creating a MaterialTransparent

Since I couldn't find something that would work, I went ahead and implemented my own TextComponent. It's called TextComponentList, and it simply joins the child TextComponents together. It seems to work fine, except that for some reason if I put into it a TextComponentTranslation that shows an argument (via %1$s), the colours in it don't work anymore. Example: # colours work: command.soulus:soulus.location.dimension=Dimension: §6some text # appears as white: command.soulus:soulus.location.dimension=Dimension: §6%1$s The TextComponentList implementation. The code that actually uses the TextComponentList. Any ideas as to why that is, or how I could go about fixing it?

I have a command that prints a long list of information about the current location. It occurred to me just recently that it wasn't translatable, so I've been rewriting it for that purpose. I rewrote the whole thing using TextComponentTranslations, and then I realised that the number of arguments passed to a translation is hardcoded in the translation itself. On that note, I figured maybe I could send a TextComponent which contains an array of other TextComponentTranslations, that would just be joined together automatically. Is there any way for me to do that? I don't see another TextComponent class that would do it (but maybe I'm blind). Do I have to roll my own? If that's what I have to do, does anyone have any recommendations of open source mods that have done a similar thing that I can learn from?

Ah, yea, that was the first thing I tried. I wasn't a giant fan of it, based on the texture (I suppose I can just change that tho). I did actually manage to get it to work, just when it's facing up, with some crazy calculations. I might go through and add detection for the other directions, but it's a lot of trial and error and it may not even end up working right, so I'm not sure if it's worth it. If anyone is curious here's what it looks like: https://puu.sh/yPevw/74480107a3.mp4 And you can see how I did it here: https://github.com/Yuudaari/soulus/blob/master/src/main/java/yuudaari/soulus/common/block/Skewer.java#L106-L160

How would I make a collision box that is missing a face? AxisAlignedBB only takes the corner coordinates? Am I missing something?

It can face in any direction. In the example since it's pointing up, it would be safe to walk into it because you would collide with it, but not safe to fall down onto it. It would work the same if it was pointing down, and similar to the side, as then you'd be able to stand on the spikes but not walk into them from the side they're facing. I know sorta the logistics of how it would work if I had implemented my own movement/collision system, but I did not write minecraft and so I'm not sure where to begin, hah.

I wouldn't remove their recipe unless you are explicitly trying to make the mods work together. Let the end user deal with conflicts via crafttweaker. That's just my opinion tho.

We can't do anything without a crash log.

Based on the design for it, that's not something I can do. See attached image. You said you can't think of an easy way to do what I want, but that's okay, I don't necessarily need it to be easy. If you have any ideas, can you point me in the right direction?

You're still not registering your items or their models. See the Forge Docs

You could also try moving your model registration to the ModelRegistryEvent instead of preInit

Try passing ModelBakery.registerItemVariants() the names as ModelResourceLocations instead of ResourceLocations

What do all the blockstate and model files for dummy and another_dummy look like?

Forge is for Minecraft: Java Edition, not Bedrock Edition.

https://minecraft.curseforge.com/projects/angel-ring-to-bauble see the comments, this is an issue with the mod, there's nothing you can really do