Draco18s

Two statements if(daTimer == 0){ // Timer done run code. daTimer = -1; }else if(daTimer > 0){ daTimer--; } There's literally no need to set it to -1 if its less than -1, as if it is less than -1, you don't do anything anyway.

Get the Item from the Registry by name. Make a new stack from the Item.

Yes

They're all the same because you're storing data in the (singleton) item class. You need to use capabilities. Override Item#initCapabilities and init a capability for the item stack given to you there. https://mcforge.readthedocs.io/en/1.13.x/datastorage/capabilities/

...every time you change daTimer or your timer won't be 200 ticks long. Otherwise it's going to look like this: "Hey! Start a timer!" "How long?" "I dunno, wait until whatever time makes the condition true."

Which player? By doing this, you're making it so that the timer counts up forever, because unless "the" player is in a bed, on exactly tick #200, you never reset this counter. And oh yeah, daTimer2 never gets set to anything, so you might have to wait a long time for no apparent reason (because if daTimer2 is something huge, and daTimer got reset to 0, you have to wait a while).

You can also examine the Minecraft jar file (or client-extra.jar in your IDE) to see exactly where everything is located.

You create a loot table You put it in /data/minecraft/loot_tables It must have the exact same name and location as the vanilla loot table you are overriding.

java.lang.IllegalArgumentException: Cannot get property PropertyEnum{name=half, clazz=class net.minecraft.block.BlockSlab$EnumBlockHalf, values=[top, bottom]} as it does not exist in BlockStateContainer{block=supersurvival:crystal_slab_double, properties=[variant]} at net.minecraft.block.state.BlockStateContainer$StateImplementation.getValue(BlockStateContainer.java:204) at net.minecraft.block.BlockSlab.doesSideBlockRendering(BlockSlab.java:107) You haven't overridden that method, and its doing something that's causing a conflict with your block. You'll have to figure out what to do yourself.

You can't modify a collection while you loop over it. That's why its called a ConcurrentModificationException.

You're trying to get a HALF (top, bottom) value for your double slab block which does not have that property. Also, you didn't include the entire error so I don't know where this is happening.

I don't see a crash report.

https://github.com/aliteraryhigh/FruitBushes/blob/11-04-19/src/main/java/FruitBushes/init/ModBlocks.java#L38-L43 You should still use object holders IMO. https://github.com/aliteraryhigh/FruitBushes/blob/11-04-19/src/main/java/FruitBushes/Blocks/BlockBlackberry.java#L26 You take in a string name and then do fuckall with it. And by calling setRegistryName here, its possible that your block is getting the wrong domain. Forge will apply a domain automatically, but if you're using setRegistryName at the wrong time, it will apply the wrong mod ID. https://github.com/aliteraryhigh/FruitBushes/blob/11-04-19/src/main/java/FruitBushes/Items/BlackberrySeeds.java#L17 Ditto your items, though you construct them in the Register<Item> event, so setRegistryName here works fine. Also, your unlocalized name should contain your mod ID to prevent conflicts.

Rename it to something else, completely unrelated, push that to github, then rename it back and push that. 1) Windows doesn't give a fuck about case, so its lying to you 2) Git does care about case and for some reason it saw the change on only some of the files. Rename, push, rename will fix it

Your lang file is still in an Upper Case folder: https://github.com/aliteraryhigh/FruitBushes/tree/11-04-19/src/main/resources/assets/FruitBushes As are your block models and block textures

Oh sorry, 1.12 You're looking for ItemSeeds

Whoops, it didn't copy correctly. Valid json is valid. Hmm.

You know, there's already a class that seeds use and you don't need to extend it. BlockNamedItem

Any reason you decided not to show your CropCornBottom class?

...or don't even set the field yourself and use object holders

Tool is just another property, add it like you did hardness.

This is not good code, but this isn't the source of your problem. Never covert things to strings in order to compare them, it makes your code incredibly stringly typed and impossible to refactor.

That is not a JSON exposed option. It is a method defined by the IBakedModel interface (note: that is different than IModel). Probably. But can't say, because you haven't really explained what you want to do (so far, this is an XY Problem).

There is no newer function. What you're looking at is Mojang-deprecation, which they aren't using properly, but all they mean for it to mean is "do not call this" (because you should call it on BlockState instead) and you can certainly override it.

Ok, great, but you're not doing it correctly. You aren't performing the increase based on whether or not it was an ore block (of any variety) that was broken. You're doing it all the time as long as there's a smelting result. And you're corrupting the furnace recipes at the same time. Try mining regular stone, see what happens.