Draco18s

So, a couple things. chunk.getWorld().getBlockState(...) This can be better. Option 1: store the result of chunk.getWorld() to a local variable and use world.getBlockState() Option 2: skip the world object and use chunk.getBlockState() new BlockPos(...) Don't do this. BlockPos objects are (sort of) mutable. Use a local variable and pos = pos.down() instead.

Diesieben07 got there first: You were already told what to do, you didn't do it, I have free reign to call you out on not doing what you were told to do.

Neither one of the suggestions are (technically) correct. In this case, "implement methods" would work but it may cause a problem (duplicate method signatures) when there's an easier solution (importing the right classes).

(Note: block-meta-4 <==> item-meta-4 only by coincidence (ease of programmer conversion), but there does exist one usage in vanilla code that assumes that they are exactly the same, and technically a bug from the perspective of the Forge team)

Pretty sure that's now how you should be doing the spawn egg. For two reasons: 1) You shouldn't be adding it to the array yourself 2) You're ignoring the two color parameters, which means you aren't going to get an item at all. You pretty much took the fact that someone said "you need to call createEgg" and created a method called createEgg and did random bullshit you thought the method should do. You seem to do this a lot.

I never said anything about a browser, I said the IPS forums. And if it's fine over there, then it is a style problem. That's all I was trying to confirm. I also did not request another screenshot.

Inside the ItemStack class. IIRC, If the entity passed in is null, that check can't be made (because there is no entity, and the damage just happens).

new ResourceLocation(a, b)?

A TileEntity is a class that extends (surprise) TileEntity. Override hasTileEntity and createTileEntity in your block class. By using an IItemHandler and writeToNBT on your TileEntity (you'll also need readFromNBT too, surprisingly enough). By overriding hasCapability and getCapability on your TileEntity, checking if the reqrequested Capability is CapabilityItemHandler.ITEM_HANDLER_CAPABILITY, and if so, returning the IItemHandler field stored in your TE. Same as you would without a TE. Using metadata. Using a boolean in your blockstate, then in your blockstate json file, using a different texture. Particles: look at the vanilla furnace. MORE FIELDS, this time one that's an integer that you add (or subtract) from every tick. Look at the vanilla furnace for a field called (curiously) "burnTime" Look at the vanilla furnace. There's an interface called IFuelHandler that is polled to find out. Technically it doesn't animate. It's just a progress bar that's handled by the client saying "the current burn time is 120, the maximum is 600. I should display (120/600) pixels worth of this texture." https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/ores/client/gui/GuiContainerSifter.java#L37-L41

Try fixing your Invalid sounds.json

Don't use ModelMesher. Use ModelLoader.setCustomModelResourceLocation during preInit instead.

Actually, iterate from world.getSeaLevel (world.provider.getSeaHeight? Something along those lines) upwards. There's no need to check from 0 to 60 in the overworld. You know those are going to be stone, air, or water. And look for areas with sunlight > 5 or so. And look for the last stone, sand, gravel, or dirt block (looking for grass won't help, because it'll just iterate up the trunk of a tree) before finding sunlight. Alternatively you could use the value returned by getHeightValue and iterate downwards until you find sand/grass/dirt/stone/water/lava. That'll get you the best result, I think. You could also check all adjacent blocks to the column being searched and if any meet the criteria for "what is ground" and average the result. Note: vertical cave entrances will give slightly wonky values because their "surface" point will be below the surrounding area, but this may not be a big deal.

If your block is in your inventory, it exists as an item. You need to register your inventory variant or item model to use the closed version.

1) don't use that game registry method. Set the registry name on your block yourself. 2) have you called setUnlocalizedName()?

use new ResourceLocation(a, b)? Seriously, not that hard. You didn't use the new keyword, so you used Eclipse's "dis not right" helper to create a method, which you then pointedly ignored despite the fact that it was a stub. I like Visual Studio's default method instead. It's content is throw new NotImplementedException() which just makes things crash when you're a dumbfuck who didn't implement your stubs.

Or you can fix your method declaration: public static void createEntity(Class<? Extends Entity> entityClass, String entityName, int solidColor, int spotColor) Also your resource location is null: private static ResourceLocation ResourceLocation(String modid, String entityName) { // TODO Auto-generated method stub return null; // <-- THIS HERE } You might want to fix that.

You're basically doing this sort of thing: https://github.com/Draco18s/Artifacts/blob/master/main/java/com/draco18s/artifacts/api/interfaces/IArtifactComponent.java#L28

...You pass in the entity's class?

This is old code (1.7.10 era) and draws a line between block positions (Vec3 ~= BlockPos), as well as some tweaks (color, slight offsets) specific to my use-case, but the general principle is the same. https://github.com/Draco18s/HarderStuff/blob/master/src/main/java/com/draco18s/hazards/client/HazardsClientEventHandler.java#L371

Do you mean drawing a line? A vector is just a mathematical notation of an arrow.

You shouldn't be using global entity IDs. Use EntityRegistry.registerModEntity() and use your own ID list (starting at 0).

Yeah, it's awful. And might not be something the Forge team can fix. Check the IPS Forums to see if they break too. If so, report to them. (IPS Forums are one of my least favorite, but still decently functional, forum software packages)

Actually noCAPTCHA is really pretty good. reCAPTCHA was getting farmed out and they ran out of things computers couldn't recognize. https://www.youtube.com/watch?v=jCr6rNaZ9EU The idea behind noCAPTCHA is that it uses telemetry data (such as how the mouse moves across the page) in order to determine bot / not bot, although I'll agree that the first "checkbox" click is less likely to get flagged as a bot than subsequent checks.

GL commands only work on the current draw frame. IBakedModels are not computed every frame. They're BAKED.

No it doesn't.