Ernio

I don't really see your truble. If you want to make arrow have specific effect depending on what kind of bow was it shot from you can simply pass argument into arrow entity the moment you shoot it (when you spawn entity to world). What is your problem? Checking enchantment? Passing argument? Making boom? Synchronizing server with client? Maybe reading NBT from bow (your ench)?

Not to be unhelpful or anything, but this forum is for Forge, it's not Java school, so I strongly suggest learning that 1st. As to code - I don't think anybody will write it for you. Base sample: Register event class in client proxy (gui is for client only obviously). MinecraftForge.EVENT_BUS.register(new ClientForgeEventClass()); @SubscribeEvent public void onScreenDrawing(DrawScreenEvent.Post event) { if (event.gui instanceof GuiMainMenu) { // Do your stuff. } }

Hook into GuiScreenEvent.DrawScreenEvent.Pre or Post. Check instance of current (inside event - accessing via event.gui) GuiScreen (for main menu its GuiMainMenu). Draw your stuff, remember you are in Pre or post of main drawing, so all GL states are inherited. Use Gui.drawTexturedModalRect to draw .png file as ResourceLocation.

Have look at: net.minecraft.client.gui.GuiVideoSettings net.minecraft.client.settings.GameSettings.Options.GUI_SCALE

HarvestDropsEvent check if harvested by player, check item (remember != null), change dropped items list.

No you don't. I am CERTAIN that fading text using normal fontRenderer is possible as I archieved it accidentally while coding my entity labels. It's matter of some GL state/mode. I'll have look.

You need to call GL before you draw EDIT Also few things - when you finish (depending WHERE are you drawing things) you need to get back to previous state. Where are you drawing your cards? (From where*, my guess overlay event?)

So pokemon it is. Few things 1st: - Why are you saving entity to both ItemStack and player? - Will this caught entity always be your custom made one (EntityCustom), following that - consider using EntityLivingBase && !EntityPlayer. - What is EntityPartyMember - my guess it's an interface, but how do you use it? Now to problems: Many pointed out- you can't use Minecraft.class on server. How to fix it? By passing args. Your #onEntityCaught() is called from The Holder that has the entity it is catching and has the catcher who want to catch it. Change it to #onEntityCaught(EntityPlayer catcher, EntityCustom entityCaught), you will need to pass them and then do same with #tryToAddMobToParty() -> #tryToAddMobToParty(EntityPlayer catcher, EntityCustom entityCaught). That way you will now be able to: PlayerParty pp = PlayerParty.get(catcher); I don't quite know where those methods are palced (example: pp.setPartyMember(pp.getNextFreeSlot(), this.hitEntity); seems like being inside holder/projectile, which mean you can access it faster) but you probably get what I mean. I am sometimes bored (I really am) so if you want insight help call me Skype: ernio333

Thornack, srsly bro - past your whole code that is used by IEEP. If you don't know where the problem is, how can you expect others to find it without your full code. Aside from the fact mentioned above (diesiben), when I pointed out your saving method - you made typo. You: @Override public void saveNBTData(NBTTagCompound compound) { NBTTagCompound properties = new NBTTagCompound(); for(int i=0; i < NUM_SLOTS; i++){ System.out.println("test equals " + test); if(partyNbt[i] != null){ compound.setTag("Slot"+i, partyNbt[i]); } } compound.setTag(EXTENDED_ENTITY_PROPERTIES_TAGNAME, properties); } Me: (compound parameter is the full NBT of given player, you shouldnt save data directly there, so I belive it's a typo) @Override public void saveNBTData(NBTTagCompound compound) { NBTTagCompound properties = new NBTTagCompound(); for(int i=0; i < NUM_SLOTS; i++){ System.out.println("test equals " + test); if(partyNbt != null){ properties.setTag("Slot"+i, partyNbt); } } compound.setTag(EXTENDED_ENTITY_PROPERTIES_TAGNAME, properties); } If you care for my opinion - your design is NOT good. Many here would probably help you do better (suggestions), but you would need to post full code as picking parts that YOU THINK don't work doesn't mean that those are only ones that are badly written.

PlayerChangedDimensionEvent FML event, has from and to dimension.

Look at your saving code. ;p @Override public void saveNBTData(NBTTagCompound compound) { NBTTagCompound properties = new NBTTagCompound(); for(int i=0; i < NUM_SLOTS; i++){ System.out.println("test equals " + test); if(partyNbt[i] != null){ properties.setTag("Slot"+i, partyNbt[i]); } } compound.setTag(EXTENDED_ENTITY_PROPERTIES_TAGNAME, properties); }

- Create new Entity extending either EntityThrowable or implementing IProjectile (1st one easier). - Copy and learn from fireball/arrow/snowball entity code. - Use ItemSword#onItemRightClick (i think) to shoot. - In method (above) you will need to spawn entity in world (plenty of examples in vanilla code - eg. snowman shooting snowballs). - The projectile shoots. - Hits. - BOOM - does something - now that something you should figure out how to write (by looking at arrow/fireball code), you need to make action on hit and e.g entityHit.setFire(2);

Best way to handle this is to create dictionary. You should be after something that Forge does itself with block/item IDs. As you probably know when new world is created IDs are assigned to blocks and items and are stored internally inside world. For every .json file you should make such dictionary. eg: The structure you want to save is made of different-coloured clay blocks. Your json would be saved something like this: <internalID><IBlockState>, Example: <0><minecraft:clay[type=red]> <1><minecraft:clay[type=yellow]> <2><minecraft:clay[type=green]> Then your actual structure could be saved just as those internalIDs. Obviously this all hav reason: - File size - Speed - most important. Why is this design important? To recreate anything inside code - which will be answer to your question on how to recreate IBlockState, you need to scan string - scanning it once (the dictionary of .json) and using internalID to read rest will get you at least few dozen times faster processing. As to recreation - you will need to split your string into parts. GameRegistry.findBlock - to get Block instance. As to states and types: Only thing that comes to my head is doing it on your own, scan strings, make switch, set state. There is probably some smart way, I will probably look into it if noone comments.

This is pretty much right. Now you just need to catch and handle message on Bukkit. To do that you will need: //Not really sure about code below (method names) Bukkit.getMessenger().registerOutgoingPluginChannel(this, "YourChannel"); Bukkit.getMessenger().registerIncomingPluginChannel(this, "YourChannel", new YourMessageHandler()); And just catch it. Remember that you will need to skip 1st byte (message id) or don't send it at all (I suggest using native vanilla packet code).

Use server plugins that check incoming packet data with big anti-cheat net? I don't quite get what your mod adds that is so different from other mods. Read again what Lex told you - ani cheat systems should be on server, doing ANY checks on client is close to pointless. You argument that "is will make it harder in 90% cases" is not really correct. If person can code - passing such MD5 check is easy. If person cannot - you are still better off with server-side anti-cheat. If you want client side mod - write it in Forge. If you want ani-cheat system - write it on server. If you want what you want - which is additional VERY EASY to falsificate packet that will tell server if client is cheating (since it's being sent from client), you can simply send packet from mod to bukkit plugin: http://www.minecraftforge.net/forum/index.php/topic,28953.0.html Please tell - what is the point of all that?

In 1.8 Minecraft has beed split into 4 threads, not 2 like it was before. New threads are: Client, Server, Client Netty and Server Netty. Those 2 last are threads responsinble for handling packets. What happens in your code: Client logs in, server creates instance of player entity and sends packet to client via LoggedIn event. The problem here is that the client HASN'T created EntityPlayer yet, since spawnin entity to world (spawn packet) occurs after LoggedIn event. This results in packet being delivered but not processed since you don't have entity to process it on (player). EVERYTIME (strongly suggeted) you send packt from server to client you have to ensure thread-safety by creating new Runnable and putting it into main client thread. @Override public IMessage handleClientMessage(PacketSendData message, MessageContext ctx) { Minecraft.getMinecraft().addScheduledTask(new ScheludedClientTaskData(message)); return null; } ScheludedClientTaskData implements Runnable and in run() you put all code to be processed. Note: This way you don't have to ever worry about packet being lost to non-existant client entities (that includes mobs if you e.g send packet from EntityJoinWorld, which also happens on server first).

Code please.

for(int a = 0; a < nbt.getInteger("lenght"); a++){ Doing this will leave you with either 0 or null therefore list will be empty/readNBT will crash (catch error). I don't remember what getInteger returns for not-found keys. You made simple typo mistake Edit: If you didn't get me - "nbt" should be "es". Edit 2: I highly recommend using TagList, which has build-in lenght. You can do effect.writeToNBT directly onlo tag in list.

Please describle nullified. Without using packets on client side you will end up with fresh IEEP object. On server it will be the same, unless you load something from NBT - what are you loading, why do you say it's nullified? Do you mean that WHOLE IEEP object just disappears (because that's what nullified means for me)? Post readNBT maybe.

The code looks good. It literally can't be source of any problems. What happens: Server creates entity, registers IEEP, loads NBT. Then client creates same entity, registers IEEP, but never loads (NBT is server-sided). Someone here is confused - question is - is it me or you?

Situation: Client has config with TRUE. Server has FALSE. You log in on server - client will have recipe, server won't. Try crafting item - it will most likely appear in crafting result but pulling it out will not work. To pass this problem you can use packets that will synchronize value on client once he has logged in, then make new IRecipe that will always ask if the result can be crafted (depending on this boolean). Otherwise you will be left with client-side void-recipy that will not work, yet be visible. EDIT: This might have been the dumbest thing I wrote on forums in a long while - please correct me if I am wrong: Are recipes both-sided (like blocks)? If they are server-sided (result from server) then everything above is false. EDIT 2: In case my statement was right: You should never make registration depend on config. Rather make booleans that will be checked in runtime. E.g: Server has recipe, but client didn't register it. What now?

If you are looking for opinions - I am pretty sure it's the strings that are the problem. WorldEdit (Bukkit) works the same - if you set (/set or even do noise-random generation) cuboid programmatically it will be very fast (comparable to world-gen, because it uses references), but if you load it from schematic it will take SOME time. You can try using dictionary-like compression. How to do that - depends how you load your data. Idea is that you convert names to internal name-id's. E.g '1' = 'minecraft:stone'. EDIT: As to block per tick - You can write server-side manager that will be working on ServerTickEvent and will simply go "some" blocks per tick.

http://lmgtfy.com/?q=Dimension+Tutorial Literally 1st link. He (Jimmy04Creeper) even gives you Git with working code.

Well, I don't do this thing often, but I personally went easy way. I use Client->Server only to send small .jar files which contain renderer (and some .png), java model and API registration file (to hook into my mod). That all takes maybe few dozen kB. Splitting it into few packets is literally a matter of getting fileSize, splitting, writing to buffer and sending in portions in next packets with index integer (order of putting together). On server I just read buffer and put it into per-player IEEP map then after last one arrives I make new file from bytes and clear map. Not really hardest thing ever, certainly easier than writing own handler. But yeah - if I had more time, I'd probably write handler, it's just that it is not priority for this mod (server actually), only a feature which I had fun making (which I doubt many will use).

http://www.minecraftforge.net/forum/index.php/topic,27101.msg138343.html#msg138343