Draco18s

Or your code. Also, "an error was encountered" is not an error. It's a notification that an error occurred and you will need to investigate.

What. This is not how you catch exceptions.

Let me clarify: You cannot. In general, yes it can be done, but you aren't interested in building those APIs and as those APIs don't already exist, the thing you want to do cannot be done.

You've gotten that answer. "You cannot." Something something flies and honey.

Look at existing calls to the method.

The reason no projects exist is because there's no pre-written API. Because there is no pre-written API, it is not possible for you to contribute to an existing project. As such you would have to write the API yourself. In Java.

Well, unfortunately, because of <thing you already know>, it isn't possible because <thing you already know.> As such what you want to do would require <doing things you don't want to do>.

This does not do what you want it to do, unless you want all copies of your item to share fuel values. You need to store this data in a Capability. Your code is only calling extract once, so I don't know what the problem is. Your stack handler class is fine, but you should override initCapabilities on your item class and attach the capability there, rather than...whatever nonsense you're doing with getItemStackHandlerTestItem.

Create a json file with the correct syntax (see vanilla tag jsons) in data/{MODID}/tags/items or data/{MODID}/tags/blocks as appropriate (note: recipes work on items) Recipes, simply use "tag":"{MODID}:{TAGNAME}"

Not easily. And older save formats don't support an increased world height either. (In fact, I'm pretty sure the current save format goes back to like 1.7. Edit: just checked, Anvil has been in use since 1.2.1)

I mean...that's literally what the error says. a-z, not a-Z.

You're already basically doing the thing you need to do, just in a different place. Once you have an IItemHandler you can get, set, insert, and remove items.

Almost certainly true.

No, because he has this already: https://github.com/hakerman74/ModPractice/blob/main/main.java#L50-L55

https://github.com/hakerman74/ModPractice/blob/main/BlockList.java#L18-L22 https://github.com/hakerman74/ModPractice/blob/main/ItemLists.java#L21-L25

Because you changed BOTH of them.

I didn't have that version downloaded so looked at the most current version I had.

I think that came from him copying the testmod file. But yes, don't conditionally register stuff.

So, if your parses throw a NumberFormatException.... what values will price and quantity contain when buyItem is called? You still don't actually need this check. You don't need to do this... signTe.signText is a public ITextComponentString[]...

You will need to look at the SignTileEntity class to determine what functions are available server-side that lets you access the data you want. Ok, yes, it's OAK_SIGN. But you can skip that check entirely and just grab the TE at the location. If it is null or not a sign TE, do nothing.

Yes. Let's let the client that is a cheating bastard be the only side that knows anything happened. Additionally: This is not how you catch exceptions. Ah yes, the only type of sign that matters is the one that has the stringy name minecraft:oak_sign. Why not use the constants in the Blocks class? if(blockSign == Blocks.SIGN) Or fuck it, skip straight to here. If there isn't a sign below your shop, there won't be a SignTileEntity below your shop. ItemStacks should never be null. Use ItemStack.EMPTY and use .isEmpty() What if the player has two stacks of credits in their inventory, each smaller than the price, but totaled is greater than the price? i.e. what if you set the buy price to 100? What happens if the quantity is greater than the maximum stack size for this item?

Have you checked if doApply is being called? You'll still have to use sears on wheat with your json as it is right now. As for updating the conditions, you need to find the point in the vanilla code where the dungeon loot table gets invoked and check the LootParameters passed. You can then use LootConditions to match those parameters.

Show what you've tried.

(Eclipse) F4 on any class name will open the type hierarchy (so if you did it on Block, you'd see all the subclasses, and if you did it on HorizontalBlock, you'd only see the subclasses of that). I can never remember the "go to definition" hotkey (it's F12 in Visual Studio, because of course I can remember that one), but hovering over a thing will give you an intellisense popup and clicking on the class identifier in that will do the same thing.