Draco18s

You're still extending World. Of course shit don't work. Why are you getting the client world? Use the world given to you by the event (doesn't have one, get the event's player's world).

Yes

That's not how that works.

Extinguishing fire is a special case code not in BlockFire, but rather in the code that handles the player punching things. I recall this from someone else making colored fire about a year ago.

You have up to 64 characters. Use them.

No, this is dumb. There is no reason for it to be here. None. At all. You can call the method without having to ask the class to do it: ModelLoader.setCustomModelResourceLocation(item, 0, new ModelResourceLocation(item.getRegistryName())) instead of: item.initModels() There is literally no reason to ask the item class to do this. Bam WHY ARE THESE METHODS RETURNING NULL!? No one told you to add these methods, so why did you?

Do NOT in any circumstance reference this outside of the client proxy class. public ItemLightBridge() { setRegistryName("overgrownportal:itemlightbridge"); setUnlocalizedName(OvergrownPortal.MODID + ".itemlightbridge"); //you know, this line here: ModelLoader.setCustomModelResourceLocation(itemLightBridge, 0, new ModelResourceLocation(getRegistryName(), getUnlocalizedName())); //DO NOT DO THIS AT ALL EVER }

Well, you have an initModels method. Are you calling it from anywhere? Also, please do not go marking methods with @SideOnly unless you know what you are doing

I did. I specifically benchmarked an code I was doing things with. That is, I specifically wanted to know how long it was taking my code to do its processing. That is, I have code that says "is this an block ore? no? continue. yes? do this other thing with it." In chunks that contained no ore, it took about 400,000 nanos to process. In chunks with ore, it would take as much as 800,000 nanos (usually closer to 600,000; it depended on how many blocks of ore there were and it was usually "less" than "more" due to the distributions I was using). If you're interested, here's the code. The timing was done in the event handler class around the call to this method. (The same method in 1.12; might be cleaner)

Ok, in general, I can agree with you, due to the way the scope works there. There's still, tecnically, the possibility that it could crash, but only in cases where someone else fucked up somewhere. There's the blockBroken method that I think is called after the block is removed that messed with a whole ton of people's code during a major update (1.10 -> 1.12?), and there's the "if someone fucks up their shouldRefresh method." But you are correct in general that when things are working the way they're supposed to, no instanceof is needed. However, this is a very specific scenario that I'd argue is specific to the implementation detail of TileEntities within Minecraft and in not a general rule of programming.

Let me clarify then: Upcasting does not require a check (and, in some respects, the cast isn't needed at all, as the parent attributes and definition should already be available) Downcasting does, as there may be multiple implementations or subclasses Now, if there's an exception by where downcasting does not require an instanceof check, that is not specific to a given implementation (e.g. "EntityFoo is only ever extended by EntityFooBar") I'd be happy to learn about it.

Good news, looking at a block and doing nothing takes almost no time. I've benchmarked this. Scanning an entire chunk (in my case, 16384 blocks as my code stopped when it reached the surface starting at bedrock) takes about 400,000 nanoseconds (0.4 miliseconds). That still limits how many chunks you can scan (if you're doing something every tick, you can probably look at 10 chunks and still be safe). If you're doing it less often (e.g. once when the chunk is generated) you can look at a lot more or schedule it (e.g. only scan one chunk every tick, but change what chunk is being scanned).

Yes it does. In order to override a method, you have to do so in a subclass of the class that defines that method.

That has no bearing here. You've literally stuffed things inside an object that has no relevance. "variants": { //lets define variants! "foo": [{ //this is a variant type named "foo" "bar": { ... } //this is the variant value named "bar" with some model overrides }], "facing": [{ //this is a variant type named "facing" "north": { ... }, //this is the variant value named "north" with some model overrides //other values (south, east, west, up, down...) }], "normal": [{ //this is a variant type named "normal" "custom": { //this is the variant value named "custom" "base": "mff:backsplash_base#base", //override the model property named "base" to have the value "mff:backsplash_base#base" "Solid": "mff:backsplash_base#base", "Translucent": "mff:backsplash_bricks#trans" } }], I am almost certain that that is not what you want. No. Each block needs its own blockstate file. Models are not relevant here.

Yeah, its called BlockPos.getAllInBox(...) ...Yes, by using World#getBlockState(BlockPos) Unless you know what block you want info about and aren't interested in "what block is over there?" In which case you can do something like Blocks.STONE.getHardness(...) BlockPos.getAllInBox(...) Yes

I am not sure what you are getting at here. ?

That is not the correct way to specify variants.

Doing a cast -> always check that it's valid first. I figure that this is implied knowledge for the level of programming knowledge required to be posting here.

Cast it.

Post the blockstate file you do have

Well, you aren't calling this method... Why are you doing this? Not only are you reaching across logical sides, but you were passed a world object in the parameters. It's the IBlockAccess (you know, to access block information about the world from? Take a look at what classes implement this interface...)

Step through it with the debugger.

That code couldn't possibly be running: flag is never set to true anywhere ever. The highlighted chunk is unreachable code.

What. On Earth. Are you doing?