Draco18s

http://www.avajava.com/tutorials/lessons/how-do-i-share-my-code-formatting-settings-with-another-user.html?page=2

A bit? It's been the wrong way for over two and a half years. It was added in Build 1.8 - 11.14.0.1292 (latest is 1.12.2 - 14.23.0.2512) which was released on Jan 29, 2015.

That's a method in the Block class.

Technically that's an option that is disabled by default. doLimitedCrafting Whether players should only be able to craft recipes that they've unlocked first false

override canHarvestBlock

1) This forum is for developers to get help developing a mod. You want General Discussion. 2) 1.7.10 is no longer supported here anyway.

java.lang.NoSuchFieldException: field_175196_v You need to pass in both names.

Probably because you're still doing it client side.

Use the ReflectionHelper class instead of doing it yourself. When built and released, the field will not be called "overlayPlayerList" but something like field_89034_b

Open up the model json file(s) from the Referenced Libraries -> ForgeSrc[version] -> assets.minecraft.models.block There are 8 template cube_xxx models that are easily located. For other blocks, as long as you know the name of a vanilla block that uses it, you can find its parent name from that model.

You're using cube_all as the parent model, which defines that all six sides use the texture key "#all". You want cube_bottom_top instead, which uses #top, #bottom, and #side.

event.getGui() is returning a GuiScreen that may be GuiCreateWorld (as GuiCreateWorld extends GuiScreen). If it is of the correct type, that's the screen you want to modify, so you get it, pass it to reflection helper, and voila. If the method doesn't like it that's what casts are for.

T is a superclass of T. It's basically just preventing you from putting in Foo.class and passing in an object of Type Bar, which doesn't extend Foo.

Note: this is client side only.

It's client side only, AFAIK. And because of that, it can be more efficient, as lighting (as a mechanic) requires altering data values that are used to validate spawn locations for mobs.

Moving the block isn't the lag inducing part, its the lighting update.

writeNBT/readNBT is for the server so that the data can be saved and loaded from the hard drive. That's it.

You need to sync your capability data from server to client.

itemstack != null Items can't be null, use .isEmpty() instead.

I've also done it. And I limited lighting updates to only move the light emitting block only once the player was a sufficient distance away from it (in my case 3 or 4 blocks).

Please stop saying things like this and calling replies "suggestions." The only place we *can* reply to is below and this adds nothing to your request for help. Calling what we post to help a "suggestion" or "ideas" makes you sound like a YouTuber begging for people to click the like button, that what we're doing is just offering an opinion, not giving needed aid. I might be invoking a Stack Overflow-ism here, but it's noisy and gets in the way.

No. The best way to go about this is creating a block that is for all intents and purposes, air, but emits light. And then placing/removing them as the player moves. And it will lag like a mofo.

There's probably a mutex or priority problem here.

You have "Entityplayer" there, it should be "EntityPlayer" You're also missing a ) at the end of that same line. I put this code into a mod of my own, changed the reference to use vanilla's Leather Boots instead, booted up a server and two clients, equipped one with leather boots, left the other without. Used a command to teleport both players 100 blocks into the air.

The event fires for all players, yes. Use some if-then magic to figure out which player needs to have it cancelled.