Draco18s

...and this is why models larger than 1x1x1 are bad

I believe that got replaces with something like .startDrawingQuads(), though I can't remember what I was even working on that I had to update some tessellator code. Find some other examples (eg vanilla usage) and see what they do.

Please stop capitalizing every word in your sentence. It looks stupid.

Some conversion needs to be done to update this to 1.10 (Tessellator got renamed and some of the methods refactored, but I was able to update those in another place fairly easily; this code never got ported), but here's how I drew a line between two blocks https://github.com/Draco18s/HarderStuff/blob/master/src/main/java/com/draco18s/hazards/client/HazardsClientEventHandler.java#L371

Yes it will. Because in order to load the class (before any of the class code is even EXECUTED) the JVM has to look at the class and go "ok, here are all of the outbound calls to other classes: are they loaded into the JVM? No? Make sure they exist." The dedicated server performs this check on net.minecraft.Minecraft and discovers that it doesn't exist. The JVM then terminates with a ClassNotFoundException. The JVM cannot know for sure that the if(isRemote) check won't ever pass.

Yes, but all of the IBlockState methods call the deprecated Block methods. But that doesn't mean you shouldn't be using them.

You should be getting the hardness from the IBlockState. If you don't have one, use Block#getDefaultState()

You can't just go around arbitrarily tagging methods with SideOnly Yes. A better name for the variable is isClient

//on client if(world.isRemote) { //this will crash the dedicated server Minecraft mc = Minecraft.getMinecraft(); }

That depends. Yes, if it is on the server, the code will run. But keep in mind that if the else case (run only on client) weill not prevent crashes from loading client size only classes

What do you mean "store the value" and "random item"? What are you trying to store where?

1.7.10 is no longer supported here.

When I was developing several related mods (one of which was a library shared by the other four) I used one workspace, but different gradle commands to build them as separate jar files. For unrelated mods, I'd suggest Ugdhar's method.

I don't think so. Modifying code via bytecode manipulation requires extensive knowledge of the JVM stack and instruction set. You can't really "copy-paste" an injection and expect it to work on a new class. It might work, it might not. To Lex: I support these changes. I will continue to advocate that things should be done through forge and will likely not help people learn how to use ASM, at least not in a public setting, but I would instruct (to the best of my ability) how to coremod safely. I did a lot of it in 1.7.10 (and I'm not necessarily proud of it) and for the folks that merit knowing should be informed. Maintaining compatibility is important. The one thing we will want is an easily accessible guide on signing jars and how to share the singing details correctly. It definitely isn't something i know how to do off the top of my head and I'm not confident that I'd be able to search out a solution either. (Can I search, sure, but I read between the lines that there might be a step that has to be done a certain way and don't know if I would be able to find details). I'm also glad to see the appointment of someone to handle lingering PR requests and filtering, I know I had some that took a while to be approved. Even if in some cases it was my own fault for not following the guidelines, but again, best practices aren't something most people can pick up in an afternoon. Its easy to make mistakes (like knowing that X mistake was made in several places) and I know you don't have much time to impart that knowledge yourself. Don't hesitate to find a few helpers for Mezz, as well. Don't want to see him getting bogged down either.

You mean replace the textures? Yeah, just put them into your assets directory so that their path is the same as the vanilla texture.

Oh sure, I code for fun. But here's the thing: Ideas are cheap. I have hundreds. Why should I work on yours?

Sooo.... Are you looking for someone to program this for you? Because the only people around here that would do it either: a) are programmers of dubious quality b) would charge freelance rates by the hour

That's because installing forge is as follows: 1) Download installer 2) Run installer

Oh gods yes. So many things wrong with the op's code. ALL OF THE REASONS.

Ah! if (!nbt.getBoolean("isPublic")) { ids = nbt.getIntArray("ids"); } else ids = null; You never set the isPublic field. You read the bool from the nbt and do the right thing reading more data, but you never set the field.

I can't see what's wrong. I don't like the way you've constructed your packet class (or its name), but it looks like it's doing safe things and as far as I can tell the TE is correctly saving its data to disk and reading it back again. So I'm not really sure what's up.

The only problem would be if the origin of the beam (where you placed the entity) was in an unloaded chunk for another player. But other than that, probably not. And you can fix that by breaking the beam up into smaller chunks.

A TESR will not help you here. TESRs are for blocks. For this, EntityFX is probably the best route, although you could conceivably also hook into one of the render events and do it there too, but an Entity will automatically sync with all clients.

Good job not reading the thread. He can't do this client-side-only because he needs to know if the user is ALLOWED TO OPEN IT which is information only the server has.

Nah, he's trying to do something else. I think.