Draco18s

No. And not actually for the reason you think. I forget exactly what happens when using DimensionManager.getWorld(id), but it's not reliable. Here's how you should do it: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/industry/CommonProxy.java#L10 https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/industry/client/ClientProxy.java#L20

Your code will also crash if you punch something to death (assuming you aren't on 1.11). plr.inventory.getCurrentItem().getItem().equals(BrandyWeapons.vorpalBlade) What happens if plr.inventory.getCurrentItem() is null?

That wasn't the problem at all. The problem is this: leftleg.mirror = true; leftleg = new ModelRenderer(this, 0, 17); Notice how it sets the property on the variable before the variable has been defined and given a value.

Imports are syntactic sugar. They avoid you having to use fully qualified names.

How about tall grass? Flowers? Fences? Farmland? Cobblestone? Gravel? Sand? Sandstone? Water? Snow? Ice? Arbitrary mod-added block? Your if-statements are poorly defined as "isAir() == !isGround()" is not a tautology. What happens if your code encounters a cave (stone, air, stone)?

The block isn't destroyed. When it's "destroyed" the Fire class does this: world.setBlockToAir(pos) Your block does not get notified at all. There's a special-case handler for TNT.

"predicate"s are specifically items. You can't use them in blockstates.

AFAIK no such event exists.

Where do you instantiate it? Move your entity rendering registration to literally anywhere (that's client-sided).

SUDO = Super User DO Pseudo = "fake" And yes, you are. You are incorrectly determining the end of the loop and the set-floor position booleans. If it finds a floor, then the loop exits, right? In which case make it so that when it sets the floor the loop exits. There's a dozen ways to do this and all of them fail proof. You're trying to use two checks that don't have an inverse relationship (i.e. isGround(state) == !isAir(state) is not true for all possible blockstates). Again: What happens if the column at the search location contains a tree? (Log on top of dirt)

Your class should be declared like this: public class RenderShuriken extends RenderSnowball<EntityShuriken> { ... } This will fix all of your errors. Remember, this is like ArrayLists: The ArrayList class is defined as public class ArrayList<T> { ... } and you instantiate it by telling it what T is. Same is true for the renderer. So alternatively, you could just instantiate the renderer by saying new RenderSnowball(...); and not having a custom class at all (see: the vanilla usage).

Should be able to with IntelliJ too. But yes, it depends on the IDE. Mind, there are some bits of your code that even if you make non-breaking edits, won't affect the running code, because that part already ran and won't run again. E.g. changes to constructors, your main class, etc. The objects aren't reinitialized, just that their methods are updated.

isCollidable() -> only called by Block#canCollideCheck which is passed an IBlockState (and literally the only thing that overrides this to do something special is stairs, and stairs uses it to call back to the stone block that they're the variant of--does the same thing with tick rate --and as the stone block class doesn't override it, it returns true). This really isn't significant. tickRate() -> only called externally by the command block and ForgeFluids--both for causing update ticks after making a change--universally returns 10 in all cases. Called internally by tripwire and tripwire hooks for the same purpose. This really isn't significant. getTickRandomly() -> you should just return true in all cases. Scheduled block updates override random updates anyway (if there's a tick in the queue the block at that position doesn't get a random tick--I've only observed this with blocks I've coded I haven't dug into the tick scheduler to verify, but I've scheduled ticks for hours into the future and not had it receive a random tick). This really isn't significant. ====== Pretty much if there is no World/BlockPos/IBlockState parameter passed to a block method, it's used by so little that the state-ness of a block needing to alter functionality isn't needed. They're basically dead-end functions.

Block#tickRate is used by virtually nothing, externally. It's used internally for a block to define how often to regularly schedule ticks (eg. redstone wire/repeater) internally. It doesn't take a blockstate parameter because it's irrelevant.

Nah, don't bother. The likelyhood of a collision is very low. Add on top of the fact that you're going to store the blockstate in your TE, so if the location in the dimension doesn't match the stored block state, you overwrite it, make the calls you need, then you're done.

No, because mods can define their own properties. https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/api/blockproperties/Props.java#L22-L36 What you can do though is create a dimension: https://github.com/Draco18s/ReasonableRealism/tree/master/src/main/java/com/draco18s/industry/world Place the stored block into that dimension and when you need to pass interaction to it, get that world and perform operations on it: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/industry/entities/TileEntityFilter.java#L145

Well they're wrong because all resources must be in lower case now. That includes the language files.

What happens if a block is neither air nor ground?

There are some places where vanilla takes the client's report at face value (e.g. position) but they're things that Mojang did wrong. In other places they did it right (such as item crafting recipes: the client needs to know and compute the result so it can be displayed, but if you attempt to pick it up and the server doesn't agree that the item can be crafted, you don't get anything). All I'm saying is: assume the client is a lying fuck and do the calculation on the server (or at least, not only on the client).

Well duh it doesn't work on the server. Look where you put EntityHelper.registerEntities();

You cannot create block and items after preInit.

There are so many things wrong here....Why are you using | instead of ||? Anyway, your problem is thus: 1a. for(int u = 1; b. isGround(pos.up(u)); c. u++){ 2. if(isAir(pos.up(u))) { 3. floor = pos.up(u-1); 4. } 5. } Line 1a executes: u = 1 Line 1b executes: the block is dirt, returns true Line 2 executes: returns false (it was ground, so it cannot be air) Line 4 executes [end of loop, returning to top] Line 1c executes: u = 2 Line 1b executes: the block is air, returns false Line 5 executes [end of block] And you would know this without wasting my time if: a) you doodled on some paper and tried running through it yourself b) you used the debugger that God gave you and watched your code execute

Remember: Someone could decompile your mod, change the value, recompile it, and get a different effect than your intent. Say, by removing the jump back to the prior slot. The client always lies.

That will never, and should never, work.

Server is authority. The client should not do anything but send input requests to the server. The server then insures that the action is allowable and changes state (or not).