Ernio

You probably solved it alredy, but: * Tick Events are FML. FMLCommonHandler.instance().bus().register(new FMLEvents()); While FMLEvents is class containing @SubscribeEvent methods. Note that ALL tick events have 2 phases - START and END - you need to specify phase, otherwise code runst twice per tick. More notes: Server and worl tick run only on SERVER. Client and Render run only on CLIENT. Player runs on both.

Yeah ofc. Why not?

I was the one who said it was easy btw. Look here, very nice: https://github.com/micdoodle8/Galacticraft/search?utf8=%E2%9C%93&q=getGravityForEntity And yes - you basically apply "fly up/down" motion. (without flying game rule)

You messed up registration. Last argument in registration is the "side of handler". If you are sending from server to client, it should be Side.CLIENT. This mistake causes system to not handle received message, because it is sent to client, and handler is server-sided. EDIT Also - DO NOT place both packet and handler inside ONE class. You need to separate them to 2 classes or packet-class + static nested class for handler. Why? It will break otherwise. Just trust me.

private int posY = 100; @SubscribeEvent public void onRender(RenderGameOverlayEvent.Post event) { if (event.type == RenderGameOverlayEvent.ElementType.TEXT && !mc.gameSettings.showDebugInfo) { // now - every tick 'posY' will be +1. } } @SubscribeEvent public void onTick(ClientTickEvent event) { this.posY += 1; } How can you not see this? What, you want "certain amount of time"? if (this.posY < 200) this.posY += 1; Done. If you want smooths stuff - use easing functions.

world.getEntitiesWithinAABB(EntityYouWant.class, boundingBox); For examples look into vanilla.

An FML both-sided event: @SubscribeEvent public void onCraft(ItemCraftedEvent event) { event.player - you can make per-player check. event.crafting - this is ItemStack. event.craftMatrix - this is the crafting slots inventory. } What can you do with it? Well - anything. You can check player, you can make crafting result in multiple outputs (by putting more stacks into crafting grid itself as "leftover"). Only thing you cannot do is to replace result. That, sadly leaves you with only one option - to edit ItemStack itself. You can manipulate all: item, meta and NBT of given ItemStack result. Problem is - you can't really set it to e.g null. What you can do... well, idk really. You could maybe create item "failed crafting" that would be output if player can't craft item. maybe you can nullify it. Doesn't seem like you can tho. EDIT Or as suggested beafore - replace whole crafting. But for that can't write code for you. Try something on your own. I can help later. (I alredy told you where to look).

1. Almost any respectable modder here will NOT download anything from links. You either post GitHub/Pastebin or direct image view. 2. I can walk you through what you need, but the task itself is like... 7/10 hard. Also you will NEVER get working code here. Keep that in mind. Things you need to understand - there are: * IExtendedEntityProperties (IEEP) - every entity (including player) is saved to disk using NBT. Inside that NBT is all data about given entity. Now - Forge allows you to extend that data by using IEEP. To create such data you need to create class that implements IEEP and assign it to entity data-map that looks +/- like this Map<KeyToData, IEEPClass>. Then in that IEEP you can store players additional info, in this case - inventory slots. Note - IEEP can hold ANY data in ANY format - it can be objects, generics or whatever - many people don't see that. To save data stored in IEEp to NBT you simple save it using load/save methods provided there. Tutorial: (2nd post) http://www.minecraftforum.net/forums/mapping-and-modding/mapping-and-modding-tutorials/1571567-1-7-2-1-6-4-eventhandler-and * Inventory - should implement IInventory, an interface that says "this is inventory". Inventory will hold array of ItemStacks[] and will be assigned to given entity, in this case - player. Stacks of this inventory will be saved inside IEEP mentioned above. * Container - containers are something that pulls data from some IInventory and creates "window" from it. Don't mistake it with Gui. Container exist both on client and server once player opens one. Moving things on client will cause server to receive updates and also move it's elements. * Gui - gui is client-side only and will display actuall stuff to player. This is specific gui that will extend GuiContainer and open mentioned cliet-side container that will communicate with server's one. Many people fk up their guis - there are two reasons - they either don't know java (most of time) or are too lazy to look into internals. Now - I don't know about 1.7.10 (don't remember what changed), but you might find this useful: (my last post) http://www.minecraftforge.net/forum/index.php/topic,31297.0.html * SimpleNetworkWrapper - you can't create anything advanced in MC without using packets - you need them to synchronize data. Note the facts: - Sending packet to one player will make only that player know stuff. In case of inventories - you need to know that other player ALSO need to know your inventory - to display it (e.g render armour). Inside packets you need to ship entity.getEntityId() and on client - get entity by id and set it's properties for given client. Tutorial: http://www.minecraftforge.net/forum/index.php/topic,20135.0.html Overall - I STRONGLY recommend updating to 1.8 - I can help more and people - leave the damn 1.7.10 behind alredy! It's been half a year. You can expect hours of coding and reading vanilla code, ask any questions, keep in mind notes above.

I hope you know that this will break for dedic servers and is for client only stuff. (Minecraft.class). Did you even look at Session class? GameProfile getProfile() maybe.

Both UUID and disk-NBT is server sided. Client only has a mirror of server's NBT - yes, you can read it and it will most likely be equal to server's one, but still - it's the server that loads/saves it. Any action that is NOT "read-only" MUST happen on server. Client should never change nbt data - only read it. Yes, UUIDs are ONLY server-sided. Client will always generate different one that is not compatybile with server's one. To run code on server logical side use if(!world.isRemote)

No, that's not right. Lemme explain. There is some EntityPlayer. Each living entity has a map looking +/- like this Map<KeyToProps, IEEP>. You can assign class you create that inplements IEEP to given entity (by putting it into that map) - that happens in construction event - you literally assign "additional" "storage" (called IEEP) to given player. Now - in that storage you can hold ANY kind of data. it doesn't need to be even saved to disk. It can be really anything - object, variable, object iwth other objects. Then if you decide - you can save it to given entity's NBT. That's whole logic behind it. Now - profession is something that is assigned to PLAYER, not all players. That's what you need to do - you need to make fields in your IEEP class that will hold profession data about given player. Design you can do: (nice and readable) EntityPlayer --> ProfessionsMap implements IEEP -----> Herbalism extends Profession -----> Mining extends Profession -----> Combat extends Profession. Where "Profession" would be an object that holds data about specific profession for given player. Then you can load/save that data using load/saveNBTData(...). P.S I wonder how your code (one you posted in last post) is not givng OutOfMemeory. Unless it does (you are literally making infinite number of "Profession" there).

In 1.8 TileEntities have been nicely split into "dead" ones that don't tick, just hold data and the "ticking" ones. You want to use ticking ones. (IUpdatePlayerListBox) Now - if you are planning on having SIMPLE incrementation and if check in onUpdate() then, what can I say... Having even 10000 blocks like that would be literally 10000 iterations (world.tickableTileEntities) and few light operations. Performance hit? Nah. Should you do that? If you must. TE shouldn't be used for super-common blocks like e.g cobble. Other suggestions: Have look at Block.randomTick(...) used by e.g crops to grow. You might want to randomize your timer to work with "close to hour intervals".

Either only I am not the brightest one or noone here understands what you want. What? Why? Send from where to where and why?

No. There are no tutorials for advanced stuff. There are few ways to do it - each mor/less compatyblie with everything else. It REALLY depends on what you need. Right now I know that you want to replace slot in container - but WHY? Depending on why, you can: 1. Repalce whole container with your own, and open whatever inventory you like in your own container. (makes you incompatybile with any mod that does same) 2. Replace crafting inventory inside container and utilize inventory methods to alter how they work. 3. Replace slots adn leave inventory. Do whatever you need using slots. What, why and when?

This issue is VERY specific and I doubt I (or anyone?) can directly help you. You could setup github - would be much easier to test code. As to issue, I will try. 1. While normal player (survival) will receive itemStack updates from server, a player in creative mode is allowed to update itemStack other way around. What I mean in that is you are in creative mode - the server will treat you as one who dictates what itemStack should be, updates are bidirectional. Why I mention this: In case of desynchronization, if you are in creative your client might be overriding changes done by server - you should test this stuff in survival. 2. ContainerPlayer is not just player's inventory. It's actuly three inventories: player's, grid and result. If you are editing behaviour of Container you also have to update it's inventories. Idk exactly what are you doing, but ever considered simply replacing whole crafting grid with your own and handle it on your own? Might be nicely doable with PlayerOpenContainerEvent and GuiOpenEvent. Post more code, might help. EDIT To expand point 2.: 3. Setting slot in index to different slot WILL break container, that's why I told you to "update" all changed stuff. Notice this: protected Slot addSlotToContainer(Slot slotIn) { slotIn.slotNumber = this.inventorySlots.size(); this.inventorySlots.add(slotIn); this.inventoryItemStacks.add((Object)null); return slotIn; } There is much digging to be done there.

I wrote this like 10min ago...(other thread) Ernio Off! *falls on bed*

You also need to hava item.json for this block that will point at parent model.json of this block. Then you need to register it in init() (that thingy with "inventory" at end ). If your block has many variants - you also need to register them all.

Sadly - nothing. Mistake is porbably simple, but right now I haven't slept fort too long and it's 7AM alredy, so I guess you'll wait for some forge Guru. Lemme just give you some hints: Place breakpoints, as many as possible, all the way in preInit. It should lead you directly to error. If not breakpoints - just ad prints every line and go deeper and deeper. 95% problems can be solved that way. Cya, gl m8!

This is at least bad design, comes near bad coding. Don't extend MainMod.class with event handler. You literally declared all mod's fields twice (Items, Tabs, all that stuff). Declaration is not initialization but still - takes space, why would you even extend that? If you separated client/server classes, then next thing is here: FMLCommonHandler.instance().bus().register(new FalloutConfig()); FMLCommonHandler.instance().bus().register(new VanillaBlockDrops()); FMLCommonHandler.instance().bus().register(new ClientProxy()); One of those is probably bad. Post them. It'd be much faster if you would make prints in preInit on every line. All I know right now is that "404 line" is wrong and it's somthing with FML.

As I am not sure, I will throw wild guess: Don't use @SideOnly(Side.CLIENT). Separate your client and common events to 2 classes and register classes based on proxy. Other than that - what is inside Fallout class? (the one you are extending?)

Need exacly this: (alredy noted) Endless.proxy.getPlayerEntity(ctx) // both proxies But coolAlias is most likely right (about that 1.8 ). Also - you packet code WILL break. You cannot have message and handler in one class. Those two simply cannot share fields with each other. You need to separate them to 2 classes or make handler to be a static class inside Message class. This "WILL break" - race conditions and stuff. Just don't do that.

99% sure you came here from coolAliases packets tutorial. Post more code - more proxies (common and your handling methods), example packet handler used by your method. You might wanna print variables (player, msg context, etc).

*Ernio focuses on blank page with white-colored letters that supposed to be OP's code* We are not wizards - post your code.

1. Update your forge 2. randomDisplayTick runs from Block - there is only one BLock instance for given block - it will run for all the same way. What you can ONLY do is to: 2.1. Use metadata of block in given x/y/z to save boolean if given block should be "burning" 2.2. Pull that boolean (isBurning) from TileEntity at given x/y/z 3. this.furnaceParts and this.coalParts == true is wrong. Again - there is only ONE Block. Anything in Block class (this) will be shared for all blocks of this type.

Could you be more specific? You want to ignore all other entities that you hit with rayTrace and only run code on pig-hit? or You want to pass through all entities and hit only pigs (rayTrace beam will pass through others)?