Ernio

( hiding == not rendering ) => (not) using GL => GL PLAYS ROLE Not rendering blocks is the only logical thing to do. Even if you don't need to see them, you still need to have them (to e.g walk), so removing would be stupid. Also - I doubt many here approve cheat mods, but do as you like As to how and what - Forge doesn't provide per-block rendering events so only option would be to hook into vanilla with AT (bytecode). Without it, only way to do stuff like this would be to rewrite (replace) world renderer or dynamically replace block textures to transparent (which is possible without mod, but whatever). P.S: Don't bump soo early... jeez

Not to be rude, but do you even brainz? event.getSuggestedConfigurationFile() returns a FILE. That File will be used as place to generate/read/save a Forge's Configuration.class Instance. Logically - you can have those Configurations saved in any other File directory. So you can e.g: new File(event.getSuggestedConfigurationFile(), "/one/two/configNumber10.cfg"); // might have syntax problems, whetever. So if you would want to have e.g infinite number of configs you can simply list files in some directory and create Configuration instance for each file found.

http://www.minecraftforge.net/forum/index.php/topic,36234.msg190652.html#msg190652 Literally same issue. Only you will be sending/receiving/changing block's data.

Ever heard of search feature? You must have some Render.class ref or extensions. Find them.

Without reading code (I am going to bed), I can point few things: - If you are using setBlock, use propeer flags. - Even that is shit (above), so what you really want is to manipulate world's block data directly, without asking for shit, you could do that with: Chunk chunk = event.world.getChunkFromChunkCoords(event.chunkX, event.chunkZ); for (ExtendedBlockStorage storage : chunk.getBlockStorageArray()) Do note that this will introduce new problems because you WILL have to do post-processing (light updates and chunk-synchronization calls), but it will be fast. There is also partial solution by introducting Queued placement with ServerTickHandler that will place blocks per tick. Idk if that satisfies you, but I can tell that even when it's slow, it looks damn cool in-game (filling effect). *flies away* #pointingOutObvious #notUsefulAtAll

If you don't know yet about this topic, I recommend reading: http://www.minecraftforge.net/forum/index.php/topic,22764.0.html Also some of my shit-talk: http://www.minecraftforge.net/forum/index.php/topic,33918.msg178740.html#msg178740 Now that you know how it is handled - the problem is that your code (mod) tries to reference a Class that doesn't exist on Dedicated.jar. You must have made some reference to Render.class, if you have extension to that class, also mark them with SideOnly (tho I am unsure if it is needed, just idea). Anything that is marked with SideOnly must be placed in proxy.

Never used it but as name suggests its "Inter Mod Communication Packet Handler" which can be used to make 2 or more mods to establish "weak" kind of communication without having to develop with their dev-releases (not obfuscated jars or sources) and/or java reflection. This basically allows one mod to send data to other mod via "local packet". Obviously - this has to be implemented by mod and handled somehow. From what I remember it allows you to send ItemStack (which can contain any data in its NBT) or maybe a String (i don't remember really). But basically that's the idea of this thing. Do note that it has nothing to do with networking. EDIT As I got confused: Well, as said "I never used it". OP asked what it is and I simply assumed that it's a Forge class, because of my knowledge of existance of InterModComms I assumed that that's this class So basically I described something else above.

@Override public void readFromNBT(NBTTagCompound nbt) { TriggersMod.logger.info("reading channels to nbt"); redstoneChannels.clear(); NBTTagList channels = nbt.getTagList("channels", Constants.NBT.TAG_COMPOUND); for (int i = 0; i < channels.tagCount(); i++) { NBTTagCompound miniCompound = new NBTTagCompound(); // HERE You are reading NOT from list provided but making new Compounds. You should get Compounds from within list.

Such Doge, Much Wow, so 3D. Seriously, such majesty, did you come up with that avatar on your own, wow? (I am doge here :C wow, since forever) As to problem: are you asking how to make block render item or how to render item? You probably want TileEntitySpecialRenderer if you want to draw item by frame. Other option would be using static models, but idk how well that will go with many items (also idk how it goes with 1.8.9). Damn, seems like I need to update.

@gummy You totally missed the point IGuiHandler is nothing more than super-simple call-do system. It handles only opening of gui, nothing more. Every mod can have one IGuiHandler implementation. Whenever you call "player.openGui" you will be passing Mod's instance. If called on client - your client will open GUI. If called on server - the server will attempt to open container and if succesful - it will send packet to client that will call opening Gui for given container. Packet that opens gui on client can have 3 integers shipped within. They are called x/y/z but can ship any kind of data. That's it. If you need ANY kind of synchronization you will (almost) always write custom packets. End of story. Only built-in systems (not counting internals like ItemStacks which are always synced) are placed in: Entity: IEntityAdditionalSpawnData // Allows sending additional data when client starts seeing entity (becomes visible). DataWatcher // well... don't. And if you must - only for your shit. TileEntity: getDescriptionPacket() + onDataPacket(...) // Server writes shit, client reads shit. Sent only when TE is being loaded by client (becomes visible). Container: ICrafting#sendProgressBarUpdate(...) // send shit with integer ID and integer data. ICrafting can be obtained like this (from Container): ICrafting iCrafting = (ICrafting) this.crafters.get(index); // and yeah, you can for-interate crafters. updateProgressBar(...) // Receiver (client) for some integer data with given integer ID. There is also: detectAndSendChanges(); Which can be overriden and filled with your call-to-send stuff. One plus is that is will be called by vanilla whenever someone opens container and that means anything you put there will be called on opening (thus: auto-sync). TileEntity + Container: You can combine methods from Container to send data from TileEntity. Hell, there is even a "nice" abstraction layer on TileEntity: getField(...) // by some ID setFiled(...) // By some ID, set to some integer. Which can be used with methods from TileEntity to send simple integer data between TileEntity and container. There are few more things, but not worth mentioning. Any inventory or slots / guis sync must be made by modder. Disclaimer: I am remembering systems/code from very old parts of my mod (months), so might messed up something with Container stuff.

http://stech1.firstpost.com/tech2images/640x359/proportional/jpeg/gallery/2013/feb/yunomeme_281836203546.jpg[/img] Y U NO UPDATE?!?!?!??! Seriously tho... we alredy have peek on 1.9, and ppl are still on goddamn 1.7... Solution: You will have to replace camera entity on game startup. You can find the field in Minecraft.class and replace it with extension with changes you need.

Define what is your "schematic" (what data structure) and what you mean by "spawning structure" (on generation or per command/action or what). Putting random loot into chest is a matter of simply putting it into chest's TileEntity when chest is detected during structure-spawning. Question is when do you want structure to spawn. There are also events that might help, but you need to be more specific.

Pretty much: Subscribe to events needed (GuiOpen event for example you provided). Make event check if player has some permission, if not - cancel event. Permission can be saved in some static Map<UUID, PlayerPermissions> where PlayerPermissions would be an object containing some perms that were read from file on server startup. File can be a Forge Configuration or pretty much any other stream. Since you (might) need interaction with permission on client-side, you will probably have to use packets to sync some of them via SimpleNetworkWrapper (google). Note: You could also use IExtendedEntityProperties to save perms once player logs in. Would require some smart design since permission files should be read on startup and saved to memory (and during startup you don't have EntityPlayer so you have to still use some static map).

Well, if author doesn't provide dev-source which you can use to direct-reference his classes, then your best shot is to use Reflection. You will simply need to check if Mod is loaded and then use Method/Field to change stuff. Note that you should reflect method/field once and then reuse it. Google Reflection tutorial.

You need: - Block - table that opens Container/GuiContainer when clicked. - TileEntity + IInventory - assigned to Block, stores Inventory (grid) and saves it to disk (read/write to NBT). - Container - created when someone accesses inventory in TileEntity, represents your inventory (on both client and server). - GuiContainer - displays a Container opened on client side. - IGuiHanlder - handles guis/containers, used to open them on block click. Additionally IMessage and SimpleNetworkWrapper for advanced gui updates. That should give you head start (google stuff above). If you are looking for a copy-paste tutorial, have fun not learning anything Show what you tried.

How exactly did you install your workspace? You need to unpack Forge (Gradle) src and run 2 commands: gradlew setupDecompWorkspace gradlew eclipse If you did that (and it doesn't work) - we need more info.

RenderPlayerEvent. Cancel rendering, make your own. That's all regarding Forge. Everything else on this topic is pure GL which you will need to learn if you want to render anything remotely awesome.

Well, you can hook yourself into packet pipeline (idk proper naming). That way you can catch any kind of packet, including entity packets and then remove sending packets that contain entityID which client should never receive. This is probably easiest way to do it, but it is literally fighting symptoms (not source). Not really huge overhead, but still not the best solution (which requires a lot more work and is simply not easy to apply to mc code). How to do it... well - diesieben will probabyl ram into thread soon and if not - look at his post history (should find something about it).

How glad I'd be if that was true... There is no "event that sends out the packets". There isn't even event that gets called when packet is sent. Only thing that, you could say "is binding" events and packets is PlayerEvent.StartTracking. That one will not do since it only allows you to do additional stuff. In past I alredy tackled this problem (making client not receive (ANY) info about given entity), but it is not really possible with standard modding. When asked why there is no event that could help - simple answer would be: too many places that send entity packets to be altered with one or even few events. "Advanced" modding solution is to replace all things that call packet-sending. Last time I checked: can be done with lots of ASM or mayyybe some instance-replacement (lookup where packets are sent). Note: Vanilla, and because of that also Forge, is not designed to support such actions. E.g: Spigot/Bukkit plugins allowed that because those were servers written from scraps - with a lot more hooks and design decisions that would allow such action.

"I know Java" Do you know what is super.method() and why it exists? Call it, don't copy whole method (onUpdate()).

As of 1.8 reflection is the only name. (Idk maybe changed in 1.8.*+). The name stays the same forever (unless MC Devs, will move field elsewhere). Those are SRGs, You can find them somewhere in workspace (google it).

It's a getter, not setter - logically: You don't call it, you override it to return stuff you want it to return. You need to make class extending Item class that Overrides Item#getColorFromItemStack and returns some integer (color is an integer) based on ItemStack passed to method. Inside ItemStack you can save color as damage or NBT data. EDIT Ahhh.. he was faster

if (event.entity instanceof EntityItem && !(event.entity instanceof SpecialEntityItem))

Prerequisites: - Learn what is Forge Event, how to make a class with Event methods and how to register it (on game startup). - Try it, print something in event, make it actually work. - Understand concept of Item, Block, TileEntity and especially Entity - those are one of pillars of minecraft. DO NOT continue without Events knowledge (GOOGLE). Now: public class ForgeEvents { @SubscribeEvent public void onEntityJoined(EntityJoinWorldEvent event) { if (event.entity instanceof EntityItem) { if (((EntityItem) event.entity).getEntityItem().getItem() == Items.blaze_rod) { event.setCanceled(true); WaterEntityItem wEntity = new WaterEntityItem(event.entity.worldObj, event.entity.posX, event.entity.posY, event.entity.posZ, ((EntityItem) event.entity).getEntityItem()); event.entity.worldObj.spawnEntityInWorld(wEntity); } } } } public class WaterEntityItem extends EntityItem { //constructors @Override public void onUpdate() { if (isInWater()) { this.setDead(); EntityItem entity = new EntityItem(this.worldObj, this.posX, this.posY, this.posZ, new ItemStack(MyItems.cooled_blaze_rod)); this.worldObj.spawnEntityInWorld(entity); } } Code written from memory so some parts will not work. Fixing it I am leaving as an exerice. YOU FOOL! I TOLD YOU TO NOT READ IT BEFORE FULFILLING PREREQUISITES!

I am sorry, but why the hell are you making NEW Inventory? You need to pull one out of players IEEP. Unless that is done somewhere internally. Show your inventory in that case.