Draco18s

You can also make the block have a shorter physics hull than rendering hull (think soul sand) and use onEntityCollideWithBlock. https://github.com/Draco18s/Artifacts/blob/master/draco18s/artifacts/block/BlockQuickSand.java You will need the physics hull to be at least 1% smaller than the actual hull, or the collision won't be detected on every side that you wish for the damage to be dealt (linked block is top, cactus is top and sides).

"Dark magenta and black squares" is "missing texture." Check your logs.

Probably not. Particles are rendered elsewhere in the code. Your best bet would be to create a thin plane and render the particle manually just prior to the candle cube. I don't have any example code, but there's math that can be used to determine which direction to rotate to face the player. I used it to create a plaque on one of my models, but I stripped out the rotation code.

Basically for each pair of opposite sides (north+south, east+west, top+bottom) it figures out which of the 8 blocks around it would have an effect on the texture. Then based on which ones are itself it picks the appropriate texture and places it into the front of the array.

IExtendedProperties You're probably also going to need a packet handler and some kind of GUI.

Also don't new Object(){} for your recipes. You can just add them as parameters: GameRegistry.addShapelessRecipe(new ItemStack(BlockTrap.instance), new ItemStack(Item.painting), new ItemStack(Block.dispenser)); or GameRegistry.addShapedRecipe(new ItemStack(BlockWallPlate.instance, 2), "s", "s", "s", 's', stone);

It's only 4 packets sent off all at once. I haven't tried to handle edge cases like that yet. Which is part of the reason I was looking for another solution, because I knew that the one I have is untenable at larger scales.

I think I might just yoink that. Thanks

I have a need to send a packet from client to server (and back) dealing with data sizes larger than 32 kb. A lot larger. (Interestingly an array of 4096 integers is the max the current packets can handle, which should only be 16kb) Based on my current handling of ~128kb, I'd like to increase this at least 4 fold (~512kb) without having to do the same thing I'm currently doing, where the server can only handle one player at a time sending the data (it sets a Lock flag until it receives the final packet from the original player). This is reasonably acceptable for only 4 packets and the communication I'm performing, but for something a lot larger I'm not as certain. Someone pointed me at FMLPacket, as it had a way to automatically split packet data into 32kb chunks, but that won't work, as the FMLPacket is only used for specific FML purposes: it requires a packet type, which is one of: mod_list_request/response, mod_ids, mod_missing, guiopen, entityspawn(adjustment), or mod_idmap. Any other ideas?

Server code does not have any class found in net.minecraft.client.* Which includes all rendering classes.

make unlocalized names also lower case then make sure that all files and folders are ALSO all lower case.

In which case, your mod is not SMP compatible. You'll get classNotFound errors when you install it into a server.

So look at Artifacts. You're going to be using almost the entire code base. "Components" you'll be replacing to be the effects YOU want, and the FactoryArtifacts is going to need to be changed as well (as its based on the assumption that things are random).

Better yet, don't. FML is just an API to turn ModLoader calls into Forge calls. There's ZERO reason to do that if you're trying to work with Forge. Unless you want the extra overhead of multiple unnecessary dot references and function calls.

I had already, actually.

Even if it doesn't have a texture, you should be able to see it with the MISSING TEXTURE texture. :\

On the other hand, when Minecraft updates, Bukkit takes a year and a half to update all their stuff so that mods are functional with the new version....

So start coding o..o

Dude, the client and server can be running on different machines. The client CANNOT get a memory address for the server object.

So use an NBT tag to store your "metadata" and just use that value everywhere the Item class calls a function and passes an ItemStack.

Your game mode is a WORLD PROPERTY not a PLAYER PROPERTY and therefore not actually a game mode. "Game Mode" just sets various PLAYER PROPERTIES (like the ability to fly, the ability to instantly break blocks, the ability to have infinite resources, the ability to respawn, etc.) You're asking the wrong question.

"Get server side entity from the client side" -> You can't. You need to use packets to communicate from the client ("This event has occurred") and interpret it on the server ("Event A has occurred? Ok, I'll do X")

RenderingRegistry.registerEntityRenderingHandler(NameOfYourEntityClass.class, new NameOfYourRenderer());

Ok, so to start off, all you're talking about is making new items that behave in different ways, each one will have its own class. Different maximum damage is simply just a property of that class instance. You haven't even gotten to the point where you need NBT data yet. My artifacts are unique in that they all use the same class, and the effects ("throws fireballs" "heals the player" "causes lightning") are handled separately with key-value data stored in the NBT.

Ah ha. See, I knew jack about Java when I started, but I was coming from a programming background. So all of my questions have either been highly technical, dealing with a section of Forge/vanilla I'm not familiar with, or deep math (as I'm not so good at designing algorithms). You're more in the dark, so when you run into posts like the one in your OP, you don't grasp the solution as readily.