Draco18s

Haha, I would too. The artifacts are totally OP. Took a quick look at his stream, yup, I saw one of my crowns.

You'll need to make your own material. Fuck if I know. Artifacts is in like four dozen mod packs. I don't keep track of their names. But probably. And to think that mod was merely an exploration of a new design pattern I wanted to experiment with.

Its really easy. Flag 3 will cause a block update and send the change to the client. Flag 5 will cause a block update and prevent the block from being re-rendered. Etc.

It appears that this is the check that is used to determine if rain should pass through a block: if (!material.blocksMovement() && !material.isLiquid())

Not something I have messed with. I'll take a peek and get back to you.

Not if you're throwing random values like '5' and '1' in there.

You don't even know what the flag does, do you?

Hmm. Apologies. I was trying to trace the code path and couldn't locate the line the last crash happened at (the line number pointed at a line that didn't make any sense) and then was trying to read the function to determine what it was doing. And it looked like it threw a crash if the replacement block had an ID that was not -1, e.g. it would crash if you had registered the block.

Question: Which class did you subclass? You should be subclassing BlockDirt for this to work and must not have registered the new block with the registry already.

Hmm. Here's what I ended up with. for(ForgeDirection dir : OreData.DROP_SEARCH_DIRECTIONS) { if(!world.getBlock(x+dir.offsetX, y+dir.offsetY, z+dir.offsetZ).isNormalCube()) { EntityItem entityitem = new EntityItem(world, (double)x + d0+dir.offsetX, (double)y + d1+dir.offsetY, (double)z + d2+dir.offsetZ, stack); entityitem.delayBeforeCanPickup = 10; world.spawnEntityInWorld(entityitem); return; } } Shoved the cached array into my OreData class (this being the dropBlockAsItem method of my ore blocks), as it seemed the most appropriate location I already had. public static final ForgeDirection[] DROP_SEARCH_DIRECTIONS = {ForgeDirection.UP, ForgeDirection.NORTH, ForgeDirection.SOUTH, ForgeDirection.WEST, ForgeDirection.EAST, ForgeDirection.DOWN};

You should do all of that in the block's renderer. It is unlikely that you should store this information in the TE/block itself.

No, but you can extend one and insert the duplicated necessary methods of the other.

I thanked this post because just yesterday I did it the "wrong" way (using the integer). But in looking at my code I'm not exactly thrilled with the result, as I was trying to find the "best" adjacent empty block in which to spawn the item drops (due to what happens when the block is broken: it replaces itself at 1 lower meta, restricting how many times it can be harvested, but if the block-above is solid, the items jiggle upwards through the ground and tend to make it to the surface, rather that shooting out sideways). Looping through the valid-directions array is cleaner, but I don't actually care about all of the directions (just the first that isn't full-cube) and would like to specifically do "down" last (the scenario where the player is above/adjacent to empty space, the items shouldn't fall into the void; in the reverse scenario they are retrievable once the player fully mines the block). So unless diesieben07 has a suggestion, I'm going to leave my code alone.

That is not how that works.

The fuck? Sort answer: no. Long answer: yes, but you shouldn't be doing what your saying. Because seriously, you want the SERVER to update the block on the CLIENT, because updating the block on the server and sending the change to the client isn't fast enough. The fuck?

[me=Draco18s]pours a bucket of water on the ground.[/me]

Better question: what is your end-goal?

This isn't useful because the function's return doesn't allow for a metadata specification. Do what diesieben said, instead. The other way would be to override public int damageDropped(int meta) as well. But getDrops is the simplest.

https://github.com/Draco18s/Artifacts/blob/master/main/java/com/draco18s/artifacts/block/BlockInvisibleBedrock.java

Try telling Gradle to look in the place you actually put it (hint: libs is not mods). Adding it to src/api/java means that WAILA will end up inside your JAR

It's a bad idea because Forge hasn't hit the Pre-Init phase yet and it will not let you register blocks and items then.

You should probably call world.notifyBlocksOfNeighborChange(x, y, z, block)

This post makes me lol because it's 4 posts after the solution saying its not possible.

Nope that other mods may still place down the ore. COG works differently and does not fire events to cancel.