Ernio

1. RenderPlayer extends EntityPlayer Wtf? Render is not Entity (EntityPlayer). You need to extend Render class or some subclass (e.g living render). 2. As of 1.9 (I think) you no longer register Render in Init - you register factory in PreInit instead. RenderingRegistry.registerEntityRenderingHandler(EntityClass.class, new FactoryClass()); Your factory should return Render instance in createRenderFor.

Umm... wait a second. Why are you calling drawRect from initGui()? That method is called once on opening gui. You need to draw stuff in drawScreen. And super-drawScreen should be at end (depends).

Not really possible unless you mess with GL states. Post your GuiScreen code and all other relevant classes.

Making it in forge is 100% possible. Mark your @Mod with: acceptRemoteVersions = "*" serverSideOnly = true Use @SubscribeEvent on ItemUseEvent (idk naming) - check if you are holding some sword and call World#spawnEntityInWorld to spawn fireball entity. Examples on how to can be found in code (you want to use constructor with player param).

You can always use rendering events to detect if given item is worn and apply animation/effect to player. But that will be only useful if you want to e.g: render spell-orb in player's hand. Not really if you would like to e.g: have sword glow.

Here we go again... getDescriptionPacket() and onDataPacket() is used by internals only in one case (generally speaking) - when block is loaded by given client and server sends data about it, it (obviously) knows that this block has TileEntity and sends it too using those methods. This update happens only when block is loaded (first packet) or when you tell it (block) to update. This is why it requires few of mentioned fields. Generally speaking - if you don't need to send something, you don't do it. And what I mean by that is that if you need to update NOT ALL of values held by TileEntity, you don't send ALL. You use SNW and IMessage and send: x/y/z and data (not even NBT). On client you get TE in x/y/z and update it. End. Of. Story. Anything that you do that is not needed is sign of poor or bad design. SNW: www.minecraftforge.net/forum/index.php/topic,20135.0.html As to how use markAndNotifyBlock - in this case it is quite bad in my opinion, but as to params - just look at callbacks

IRecipe

In simple words: Nooope. In bit longer: Nothing stops you from coding in 2 separate packages and compiling once, then packing to 2 different .jars. You just have to make sure to not cross-reference stuff. I for one have 4 mods(@Mod) in my workspace - API, Common, Client and Server. Logically - You always need API and Base + one of two sided mods to run stuff on proper side. But to simply add on your own stuff (for devs) you can just work with API. When compiling I just grab packages and throw them in 3 Jars: API.jar, Server.jar (common+server packages), Client.jar (common+client packages) + There is some trickery with side only stuff, but that is my magic. In final case: Everything is possible, nothing stops you from learning how to use build script and write what should be put where or in what .jars.

API is just a set of public classes/methods/fields that in some way make interaction with your mod easier. There is nothing speacial about APIs - they are just mods or libraries that you give other people to use. It's other devs that decide if they want to have dependency to your API mod and then use it. E.g: You want to have some recipe API. You make interface IMyRecipe that other can implement and register to your mod using that API.

How about update to 1.9 (finally) and rewrite stuff to proper main<->network thread handling. 1.7.10 is ancient and networking changed enough for most of us to simply not be able to help. Anywaya: No, I have no idea and you must be doing something REALLY weird. If you are not using any of your own packets, it must be some kind of return you do or something else. For one I'd be interested in "and pick up the resultant item" - what do you mean? Do you use item, catch entity and then pick it up or what? Again: code (and yeah, I know it is big and super messy, so only github is accepted in this case). Because that is what messing with threads do.

Could you elaborate on what you want. Sentences like this just don't make sense. Any block can be rendered at any Y pos. I guess you ment "renders differently at different Y" - even if that is correct, that is still not enough apparently, because next thing you say is that block should not be based on Y pos, but on: Fix your question.

You are fking with threads. Something from somewhere (thread) is editing something it is not supposed to. What did you do... (this time) ? (code)

Have you considered that "if (this.hasStoredBlock())" might be false?

There is no how-to. Basically - there are so much changes that best way is to rewrite everything based on most basic tutorials on google.

You also have working code (src and resources) examples here: https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample Pretty nice for starters.

Spigot has close to none affiliation with Forge - Cauldron was maybe one of them, but as said - Cauldron is dead. Spigot is Bukkit-based (server-side plugins), Forge is Forge (server, client or both sides mods) Currently best (in my and many other devs opinion) option is Forge server with SpongeAPI. Forge is best modding platform there is and SpongeAPI allows you to have bukkit-like (I hate to say it like this) server-side plugins (ofc. Forge doesn't need Sponge to run server-only mods). It is all much simplier and cleaner than those ancient dead projects.

You are still not showing what we NEED to see. MC is built by 2 logical sides, each built by 2 threads (main and netty): http://mcforge.readthedocs.org/en/latest/concepts/sides/ You can't just call rendering from anywhere without GL rendering context. Only way to do it properly is to either open custom GuiScreen (stuff like guis like GuiContainer, MainMenu, Options, etc.) or to draw directly onto screen using rendering events like: RenderGameOverlayEvent or other world-based (3d) rendering events. If you are not doing it like mentioned above, you are simply doing it wrong, but seeing that "it worked in past", you must have been doing it at least partially correct, just now it stopped working because it no longer is. So I need to ask again: What is responsible for rendering your gui. Is it some GuiScreen extension or are you using event - which one? We need much more than what you gave to track error down, rendering goes waaaaay back into base classes.

Where are you rendering, we need whole code. Probably changing some GL states.

Well, for some time now everything is strongly based on Attributes and AttributeModifiers. Same goes for swords which return Modifiers thet need to be applied when you attack. Since on the moment of attack you don't really know how much dmg you actually cause (target armour and stuff) you need to to it post-damaging. You could: * Use LivingHurtEvent - event.source. Check if source is entitiy and if he holds some kinds fo sword. Heal attacker for event.amount. There are other ways I guess.

I am thinking along these lines: 1. Get model from registry 2. Get its BakesQuads. 3. Find the one facing top (I think if the block is as you said "full block", there will be only one Quad facing "top", is it north?) 4. BakedQuad has link to texture sheet u, v, doesn't it (or just take that BakedQuad and copy it)? Last time I was surfing with rendering was early 1.8... Might be a way to go (if even makes sense), there is probably better one tho.

Proper args: player.posX player.posY, player.posZ player.worldObj

Look into @Mod class. You need: acceptableRemoteVersions = "*" and might want to mark your mod serverSideOnly = true for convinience/security. Notes: You cannot reference ANY Side.CLIENT classes/methods/fields. You DON'T need proxy - why would you. (I see it quite often that people make sided mods and add proxy, totally pointless). As to sound - I can't help without knowing your forge version.

https://github.com/TheGreyGhost/MinecraftByExample This repo is still partially (mostly) valid.

1.9+ is not much different from 1.8.9. There has been changes in advanced rendering (models) and Entity stuff (new off-hand and action classes/enums), but that's it mostly. So yeah, rendering and models you can be learn from 1.8+ TileEntities and most Entity tutorials are cool even with 1.7.10, only registration changed a bit. Also, new versions have java docs, if that is not enough - you can just read code. And I ddon't belive you looked hard enough when you say you can't find any tuts. There are plenty.

Yup, you want to use packets: http://www.minecraftforum.net/forums/mapping-and-modding/mapping-and-modding-tutorials/2137055-1-7-x-1-8-customizing-packet-handling-with http://www.minecraftforge.net/forum/index.php/topic,20135.0.html As to other - I wouldn't directly sync "screenshots" as in vanilla ones. KeyBinding that does same as vanilla screenshot, but also sends it. KeyBindingEvent or KeyboardEvent might be useful (I don't remember). Anyway - you need to know this: * Packets from server to client will get split into partial packets if data is too big. * Packets from client to server WILL NOT. You will have to handle splitting on your own if you need bigger than standard size (which I don't think you will). * Also this: http://greyminecraftcoder.blogspot.com.au/2015/01/thread-safety-with-network-messages.html * And for some of those request based system you might wanna use PlayerLoggedInEvent or one of FMLNetworkEvent (e.g client connection).