mnn

TE is not needed to open a gui, proof is the code I posted earlier. I seriously doubt that Red Power or Forestry uses TEs for their bags.

you cannot have "dynamic" stuff in Item class. every item in game has just 1 Item (inheriting) class. you have to work with NBT in ItemStack if you want to have different lasers (or what the item is) on different cooldowns. also I think your code should not run on a client AND on a server (spawning entities on a client side is not good).

I was looking for a tut for this also, in the end I implemented my GUI based on few sentences from some forum by trial and error. Most of the code related to GUI is in these files (you can browse the repo, all necessary should be located in the food module): https://github.com/mnn/jaffas/blob/0ff7080783cdded74c8d6f4d735160fa9c52395e/src/minecraft/monnef/jaffas/food/common/SpawnStonePacketUtils.java https://github.com/mnn/jaffas/blob/0ff7080783cdded74c8d6f4d735160fa9c52395e/src/minecraft/monnef/jaffas/food/item/ItemSpawnStone.java https://github.com/mnn/jaffas/blob/0ff7080783cdded74c8d6f4d735160fa9c52395e/src/minecraft/monnef/jaffas/food/client/GuiSpawnStone.java

I have implemented custom painting, but it's kinda old code. I think I fixed same issue as you're describing. My registration code: registerEntity(EntityJaffaPainting.class, "jaffaPainting", 160, Integer.MAX_VALUE, false, JaffaPaintingEntityID); private void registerEntity(Class<? extends Entity> entityClass, String entityName, int trackingRange, int updateFrequency, boolean sendsVelocityUpdates, int id) { EntityRegistry.registerGlobalEntityID(entityClass, entityName, id); EntityRegistry.registerModEntity(entityClass, entityName, id, this, trackingRange, updateFrequency, sendsVelocityUpdates); } Not sure if it helps, but it's better than nothing .

maybe it can't write to the lib directory? the title you chose is not the most descriptive .

every tutorial I saw was just modifying vanilla furnace, so a lot of "magic" code. you can take a look at my kitchen board (although there are some redundancies in the block class, it does work), maybe it helps you. it needs a knife instead of fuel to work. http://jaffas.moxo.cz/wiki/_media/pictures/kitchenboardgui.png[/img] https://github.com/mnn/jaffas/blob/0ff7080783cdded74c8d6f4d735160fa9c52395e/src/minecraft/monnef/jaffas/food/block/TileEntityBoard.java (you can browse the repo)

No need to be an idiot Clearly I'm new and learning so the normal thing to do is to help out. Therefore screw you you shouldn't have bumped it so soon. your code formatting is awful. your usage of @init method is unusual (mildly said). you don't use config files to get IDs. ugh, I can't look at this code anymore, there's probably more problems... this is not a Java support forum, learn basics of Java first. *sigh*, pretty similar to http://www.minecraftforge.net/forum/index.php/topic,6456.0.html.

looks like a handy tool . for those who don't want to use ImageMagick (command line discourages a lot of ppl) definitely useful. +1 for "stickying" it

not true, even with perfect understanding of java (which I have not) I wouldn't necessarily know all about MC code. but on the other hand, majority of question being asked here has either been already answered on the forum in older topic(s) or are described on the wiki. a lot of askers expect to post code here and wait until someone else fixes their code... as diesieben07 wrote, you don't need complete or perfect understanding of java, you need BASIC understanding of Java (e.g. what static means, how to use packages, read crash log, what null means and so on). if you came here to seek infomation about basics of programming and/or Java, you're at a wrong place. this not Java support forum, this is support forum for Minecraft modders working with Forge. it's been written many times, firstly learn basics of java then start modding. if you have programming background from similar OOP language (e.g. C++, C#, Python) it's pretty easy to start modding even without reading much about Java itself. PS: At a start I tried to help many people on this forum, but after some time I realized that most of my replies were just "look at this older topic which solves what you want" or "look at the wiki". Rest of the time I just spent explaining how to use loops to get every block in a cube or why static members in proxy don't work <- I should have just wrote "learn java". I feel that more I help people without basics of Java the less motivation for them to actually understand/learn Java and more useless topics appear here, burying those few with interesting question or elegant soltuions of common problems... @bwrobinson13: I recommned using code tags or forge's pastebin, it's much more readable . If I'm not mistaken the number in constructor stands for number of blocks you want to be generated(~ size of vein). Parameter of a random number generation in yCoord determines maximal height and a number of iterations denotes count of veins per chunk.

I don't think that this forum should serve as a support forum for programming or Java. Imo these topics/posts should be closed/moved/posts deleted, if the problem lies in insufficient knowledge of elemental Java and is not MC/forge/fml specific. Also I don't think that kind souls helping those in need should be posting snippets of code. It would be more logical to just post a description or pseudo-code of how to achieve a solution or fix a problem. If the asker cannot write it on his/her own, he/she should learn Java first.

it can be done via ASM library to only process entities once, just like the original method does. I have it implemented, you can take a look - https://github.com/mnn/jaffas/tree/master/src/minecraft/monnef/core/asm. it's a bit more work, but I don't want to stress cpu (potentially lowering fps) of players of my mod more that it's actually needed.

@nerdboy64 that sounds considerably easier to implement than using threads or custom queue/calendar. also using TEs' NBT tags for saves is a nice and easy, definitely better than going over all the threads and signalizing them to stop waiting and to send the main thread remaining time...

I don't want to be mean, but it looks like a pretty wasteful solution. I might have overlooked something, but it seems like the api in every tick is iterating over all players and doing stuff. The original code is looking for cloaks only once after entity is spawned.

I thought so as well, but under some circumstances there's virtually no cost at all. Method invoking via reflection according to this http://stackoverflow.com/a/414823/1017211 has the same cost as calling it directly. I don't know about fields, but it could be optimized too. (This all is true probably only if the object from reflection is cached.)

well, another "waiting" topic read this: http://www.minecraftforge.net/forum/index.php/topic,5964.0.html ^whole topic, there are two approaches to this problem it would be possible to do this via threads, but you'd have to manage synchronization. also spawning thread for each block/group of blocks just to put them to sleep doesn't seem right, when you can do the same with tick handler without overhead from the threads creation.

I read (on twitter?) that some graphic library which could open and render obj files (don't really know what format is that) might be included into forge.

use setBlockAndMetadataWithNotify?

I'd do this: add a field to fence TE, this field will store which model to render (I mean type like crossing or single rod). this field will be used in renderer instead of the heavy conditions. to the fence block on neighbour change you'd move those conditions and result would be saved in the TE's field. You might need to alert neighbour blocks if your render type changes (it depens on how exactly you have implemented conditions).

it would simply use an int/enum field to identify what it is. this field would be setup by the item used to place the block containing this TE. Disk space needed to save a TE is considerably bigger than just the block itselft, but unless it's naturally occuring block you have nothing to worry about. Not sure about in-game performance though, MC synchronizes TEs server->client even when not forced to, it might get ugly with a lot of TEs, but I haven't really tested it (also it might have been just a bug caused by my mod).

they share world and coordinates, take a look at this: https://github.com/mnn/jaffas/blob/master/src/minecraft/monnef/jaffas/food/block/BlockPie.java#L87 (block "talks" to TE).

I think when player dies new entity is created, it could be the cause of this behaviour (not 100% sure though).

I'll try briefly describe what the pie code is doing. type, pieces and rotation are fields that are being saved and synchronized (= all logic to changes is placed on the server, the client only gets update packets). init is called from item which places the pie (not important for us now). eatPiece - when fired (when right clicked on a block; fired only on a server side) it removes one random pieces and forces TE to synchronize with the client (in sendUpdate the markBlockForUpdate tells the server to create a packet and send it). in getDescriptionPacket lies the packet creation (we just fill NBT via our save method). the onDataPacket handles when sync packet arrives - it unpacks a packet and set fields accordingly (pretty same as loading from a NBT saved on a harddrive). writeToNBT and readFromNBT are for saving/loading TE's status (type, pieces, rotation) on a server (mainly) when chunk gets unloaded/loaded. some wiki articles related to this topic: http://www.minecraftforge.net/wiki/How_to_use_NBT_Tag_Compound http://www.minecraftforge.net/wiki/Containers_and_GUIs (inventory saving, synchronization is handled there by other means) if you still don't understand, it could be because of my lousy english, in that case you'd have to wait for someone else to write a better explanation of this topic.

renderModelAt is called not every second, but every frame (for each your custom block). I'd move the checks into block's onNeighborBlockChange (and fire block changed when renderer type changes).

yep, unlike the other guy you got it fast . you should also consider saving these data (world storage or something), it all depends if without the event fired can something break.

TE can hold data itself. you can use built-in packet synchronizatization; NBT to save type of chest. sample code: https://github.com/mnn/jaffas/blob/98acc4d9607d6493b82b277b3bfea3b7dacffc69/src/minecraft/monnef/jaffas/food/block/TileEntityPie.java