Ernio

Update what? Workspace? Gradle? Code? All of those can be found either on google or in code itself. There is not much to update if you are not using rendering.

If you do stuff on client - server doesn't know about it. Even if you'd send packet telling server that you did something, server might not really "accept it" - meaning: client opens gui, sends packet with request but on server it happens that "you are not allowed to open the gui right now", but its alredy opened on client - boom, not desired outcome. (same goes with interaction - since client only has "predicted" server values, some things might be true on client and false on server). I for one always code stuff in order: client -> req -> server decides -> packet (or GuiHandler call) -> client does stuff server tells. All in all - is depends on what you need and if server needs to know what you do. You can even open gui directly from Minecraft class. Mind that if client alredy has values that need to be displayed on gui and server doesnt need to know shit, you are free to operate on client only. E.g: Display player stats from IEEP/Capabilities which you KNOW are always synced.

1. Don't do this (initialize). Forge does it for you. public static Main instance = new Main(); 2. Everything else seems fine. You say that your ModDrops is initialized? And event inside never called? One explanation could be that your IDE is not recognising changes in .java and event method is simply not there in .class file. Idk really, but I know that it's possilbe. Rebuild WS and maybe even reinstall.

There is client and there is server. You either run client connected to integrated server (SP) or you connect to others (MP/LAN). Client has nothing to say (aside from player commands/movements) when it comes to data computing/saving/loading. When you have data loaded by config - you will load different on server and client - again - while client might be using his own data, it will simply display wrong things if server does something differently. Solutions are mainly: * Sync client config using packet from server to client on connection (send config values). As of now - both sides make same computations, thus - they will be mostly correct. (mind that sometimes you need to correct client by sending additional packet). * Sync on change - just send packet whenever server does something. How and what really depends on situation. Other problems: Note: if(!world.isRemote) makes code run only on server. You should use it almost always if client doesn't need mirrored computing (following servers acts, which might or not be correct). So back to problem: In snippet you gave you are modifying experience and try to remove entity from world on BOTH sides. THIS IS BAD. Both exp and entitie's death is synced and should be made on server. Expression "this.worldObj.removeEntity(this);" is quite bad. Use this.setDead().

1. What do you mean? If you are doing everything according to vanilla code (you use model system) then you don't color stuff on your own. You colorize Quads. 2. Well, without looking at internals (can't now) - if that "one variable" is "int" then I don't understand your problem. int =(bits)= 0xRRGGBBAA (I am unsure as to the color ordering). BakedQuad can have texture and color, texture can be applied as u,v coords and use e.g grayscale image, while colorization is one value (to my understanding). 3. What way do you mean? You are doing nothing that actually generates any image OR quads. Also - are you sure about what you are asking - "to generate a texture". From what I understand you want to make 16x16x16 cubical model that can be rendered from ItemStack, e.g: https://encrypted-tbn1.gstatic.com/images?q=tbn:ANd9GcRbr6VYHu1JTJXVLEB93D_6j1I3DwnU0HetRlou4Wp9BRnXBbGq[/img] You want to (based on ItemStack) make those cubes (like on img) and colorize them (also based on ItemStack). Is this correct? Well, you can either make 4096 grayscale model files that cover every mini-cube, name them cube_x_y_z and then in your smart item combine them. But that we all know is stupid. What you want is generate them on your own - which is simple. Without learning BakedQuad format you can't do shit. You need to create 6 BakedQuads for evey cubical. and place them in proper position of model. Which you probably alredy know - yet still, I have no idea what you are asking of us. Side note: (optimization) When you generate your ItemStack's model for the 1st time - while 4096 (considering worst case) of BakedQUads can be handled, you can easily track and remove some of Quads that are not visible (remove each side of mini-box that contancs other).

Move registration to preInit.

This is like asking: "Why is economy so stupid? I can learn about it and make better one ON TOP of it!" As of now I can only say that Minecraft fails on Server side, where there is no Multithreading (e.g: per world, which I heard might be implemented in future). As to everything else - there are some stupid flaws (leftoverst from early code), but game like MC written in Java is probably worst part of it (GC and RAM freeing). While saying it is bad, I personally love MC in Java so... yeah. Anyway - you can't possibly lag whole game, unless you'd make large computational operations - which are special case so I'll skip them. As to small things - you want to avoid making expensive per-tick operations and/or constant syncing. Prefere to send more small packets to update specific things, and only when it's needed, than sending everything (e.g whole player data) every tick or few. I can't imagine how bad of a coder you'd have to be to actually write that laggy mod (again: not considering heavy computations).

Yeah, the patches are generated using "magic" (no, they are not written by hand, obviously). THey are injected on startup using ASM. Hook = "extra" methods and events. On top of that there is obviously a lot of other things (like model api/loaders, registry, ore dictionary, shit ton of useful things you won't find in vanilla). And by "extra" I mean - Forge adds quite some methods that are called on the way of vanilla calls which allows modders more access to what is happening (those methods are mainly for mod-made code, e.g: You have better access to how your e.g: ItemWand works or methods that ask you what should be returend is very specific situation of using your Item).

Forge + Sponge API is the future. As to other: * Spigot (please don't). * Glowstone (Idk, Sponge is stil better). * Some other, mostly dead or soon-to-be-dead like: MCPC, Cauldron, Bukkit - all of those are officialy dead and only privately updated by some random ppl.

In basic words: Game is launched, forge injects its changes to vanilla code (using ASM). Those changes add new methods that are called by vanilla source, special case - events that are called when something happens. When event happens all mods that subscribe to it can know of it and act. They can also cancel it and/or change outcome. Note that events also can have priority, so its not like full compatibility is always possible. All those questions are pretty broad, and I am not the person who works with internals to descripe exact processes. Anyway - when you setup your workspace - all events are in forge's events packages (client+common). As to question about "code overlaps" - it doesn't really work like that. As said - events can be tracked by every mod which can than respond to them, code won't overlap since its totally separate thing. What can overlap is when you are writing CORE Mod. Core mod is a mod that uses ASM (like Forge itself) to modify code at runtime (startup). Because of that Core Modding is extremely incompatible and can lead to errors - thus it is discouraged to do so (unless absolutely needed, in which case you are most certainly writing something VERY specific, which Forge can't handle for you using events).

I really hope that you understand difference between Item - which is singleton ("description of what you are holding") and ItemStack ("the thing that is actually there"). Now if you know that I really hope you considered the fact that making and registering Item instances should happen in preInit of MOD, which is game load. It is possible to not do it that way, but that introduces you to more problems. 1. Client will have to load server's Item singletons somehow - and I mean again - doing so NOT in preInit() of game (which happens waaay before even joining a server) will again introduce you to client sided problems - mainly rendering systems and registry-to-renderers compatibility. 2. Without even looking at client (which is one of biggest problems, since Vanilla/Forge is not designed to handle it), you will have corrupted data, useless packets "leaks" and who knows what when it comes to: * Loading world (ItemStacks are loaded based on Item registry) - which will totally corrupt everything you have with possible slightest change to your (i think) Json-generated items. * Syncing client - kinda 1st point - if server sends data about item which client doesn't have, it will not go well (pretty bad). That is all ofc. if I an understanding correctly what you are after. As to direct response to questions: If not in ItemStack or Entity, you can store data in WorldSavedData (note that save/load is on-demand) or any self-made system (you could maybe utilize Capability system, but idk). So yeah - Json can be fine if you don't want e.g NBT (WorldSavedData). As to how it should be made: Everything should be saved to ItemStack. If you really have a lot of data - you can easily wrap it up in short namings or ID system that can be stored in mentioned WorldSaveData and synced to client on logging in. Seriously, MC can handle quite some data in ItemStacks (I was once sending textures inside ItemStack, about MC 1.4-1.5).

Those kinds of questions is what's wrong with modders (meaning: everyone stays on 1.7 because everyone else is, so why bother). Answer is obviously and always (for me and some at least) - "Develop for latest possible version and eventually backport if there is need." And btw - you should be asking your users, don't you have some mod thread?

Since process is not realy crashing but just halting any stacktrace sub-command won't help. Since there is no other clue, I can suggest: 1. Retry (which you probably did). 2. Wait a little longer (you might also want to check your net) - and by longer I mean it can be pretty long from what I've heard. 2. Download latest forge (1.8.9) and try it. If it works, it might be something with 1.7.9 (seriously, why do people even start coding in this...) 3. I have no idea. Additional steps: * Stop using Mac (#hate ). * Start using latest versions of Forge - seriosuly, 1.7.10 is ancient and argument that "other use it" is just bad.

@SubscribeEvent public void entityJoinWorld(EntityJoinWorldEvent e) { if (e.entity instanceof EntityPlayer && !e.entity.worldObj.isRemote) // can be replaces by if (e.entity instanceof EntityPlayerMP) ExtendedProperties.get((EntityPlayer) e.entity).entitySpawned(); } That is all it takes. You don't need IEEP null check nor ANY "proxyfication" of code. For future: * Learn what Proxy does - there is difference between logical (world.isRemote) and application side (client.jar / dedic.jar). * Don't ever get world that way.

player.inventory.currentItem

Tesselator (currently rather WorldRenderer) is a "mirror" of standard GL drawing. Basic examples can be found in Gui.class methods. Sadly they are using int params and RGB or I think ARGB (I prefere RGBA). This is prettu much how tess works in GL format: https://en.wikibooks.org/wiki/OpenGL_Programming/GLStart/Tut3 Note: QUADS are anti-clockwise.

I tried to be very exact in my question and ended up with "I am still not sure". Anyway: You for sure don't need IInventory since you won't be using any "new" slots. Okay, so - player has his inventory which consists of, as said: 27 slots, 9 hotbar slots, 4 armour slots. Minecraft itself works this way (talking about inventory and stuff): 1. There is: * IInventory implementation - object responsible for holding and "managing" (poorly) ItemStacks. This object can be encoded on/decoded from NBT and saved to player's data. In case of vanilla - it happens internally. In case of mods - you save this thingy to IExtendedEntityProperties. Note: You don't need this knowledge in this case. * Container extension - whenever IInventory is required to be accessed Container for it is created. Container holds list of Slots (Slot.class) which refere to specific "placement" of ItemStacks in IInventory. Container will (should) be only created when client needs visual interaction with ItemStacks. Instance of container is opened on server and on client. Two objects correspond (weakly) with each other. * GuiContainer extension - a thing that displays Container visually. It is opened only on client and corresponds with Container. * IGuiHandler implementation - allows universal (per ID) opening of containers. When you call player.openGui with proper mod and gui id: Note: IGuiHandler is "designed" to work with Container + GuiContainer. If you don't have Container (on server) and just want to open a Gui (on client), you cannot do this from server (meaning - opening must happen from client thread ("If the server method will return NULL - nothing happends").) To do that (from server) you send packet. Now that you "know" basics: You will need Container and GuiContainer (and few more things). Just extend those two, add proper stuff (slots) and render proper things. That I can't cover without any code from your side (show what you tried). You will need to open your container/gui instead of vanilla one, to do that you can (not sure): @Subscribe to (read: forge events) PlayerOpenContainerEvent and/or GuiOpenEvent. To "lock" other 27 slots (make them not accessible) - this is tricky, you can't "just" do that. This involves some internal knowledge (idk but seems like you are novice): @Subscribe to few events, that includes e.g: EntityItemPickupEvent and PlayerTickEvent. * When picking up - check if you have any of 9 "hotbar" slots freem if not - you can't pick up (you want to lock others). * It is always possible that ItemStack will end up in inventory in undetectable way - Use ticking to remove it. Every tick interate from 9th to 36th slot in player inventory array and remove (move to other free "hotbar" slot ot toss to world). This should cover everything and hell yeah - I am bored AF, there you go... an essay x_x

Arent QUADS (front face) drawn anti-clockwise (unless you make double-sided face)? I think it should solve problem. Also: Why not use tesselator (WorldRenderer)? Have a look at Gui.class - it shows basic usage of this thingy. I personally really like that format (it allows a lot of vertex options). I personally wrote it similar but to be static, accept doubles and use RGBA. Some of Gui.class methods use ARGB i think (and some just RBG for sure).

Before I drop into ocean of knowledge - question: (which one would be correct) * Do you need players to have ADDITIONAL inventory (on top of vanilla's), meaning they have their normal one (9x "hotbar" + 27x "inventory" +4x "armour") + yours (additional 9 slots)? * Do you want (as looking at screen you posted) to LOCK other slots (make 27 of them unusable) and leave only those 9x "hotbar" + 4x "armour"? * Or maybe you don't want any new inventory, and you just want to make different display that shows hotbar slots and armour slots from standard player's inventory?

I am here just to reassure (second others) you that tracking items (itemstacks) in: inventories (mobs, players, blocks) and world itself - while possible for some of those parties - will NEVER be fully safe/working. It is simply impossible to do that using any standard approach. As to non-standard apporach - it won't end well (been there, done that), and again will never be "exact" and safe. You can only track few things about items, but not all.

1. Why is this not in Modder Support? 2. Don't use static to hold data that is not supposed to be static. Read what static means. 3. Don't try to make one packet do everything - if data differs that much, don't force it, it will be bad design and waste of resources. 4. Implement few different packets - each handling different thing. 5. Don't use ByteBufUtild if you don't need to. ByteBuf class is perfectly capable of writing and reading generic types (not only).

Forge packets start with discriminator (packet id). All packets sent from or received on spigot plugin must add that value on encoding/decoding. Readup callbacks (when packet is sent).

When entity is spawned on server a packet is sent to client telling to spawn client-sided representation of that entity. Those 2 entities are bound by entityId. All entities should have constructor that has one arg: World, because that is how they will be spawned on client (internally using that constructor). Now - EntityPlayer is different. While all other entities have one shared class, a player has class for Client and Server: Server: EntityPlayerMP Client: EntityPlayerSP + EntityOtherPlayerMP It is obvious that player is a special entity. So solution: DON'T EXTEND EntityPlayer! Make goddamn entity that behaves like player - it is much simpler and works better. And if you really want to make extension to players - you will need sided implementations (MP and OtherSP probably) and some ASM to make it work NICE. Without ASM you will messup a lot of things. It is not possible to spawn player like a normal mob. You need handlers that handle EntityPlayer (INetHandler).

Can't really say. I recommend debugging with Syso. Place sysos in: * Construction * JoinedWorld * Clone * Packet - on encode and receive. and make them print (client and server) properties. If manas are synced after death and as you say - "has learned about mana" is not - there might be some small mistake in packeting. If none of properties get synced, then debugging will lead to mistake. You can also post full repo if you want.