gcewing

There is still no clear indication on that page of which version of Minecraft the "Latest" and "Recommended" versions of Forge are meant to go with. If you know about the Forge version numbering conventions, it's possible to make an educated guess by following the download links to get the version number and comparing that with the information in the Old Milestones section, but that's a very roundabout way of finding out. Displaying the relevant Minecraft version somewhere near the Latest and Recommended links would make things much clearer.

There is now a version of the Mining Radar with a colour display that distinguishes the different ore types more clearly. Still only for MC 1.2.5 at the moment -- hope to update for 1.3 soon.

No, it should have all the effects of torchlight, including prevention of mob spawning.

Well, I've completed my first 1.3 conversion project. At least I think so. Hope it works for everyone!

The Container.onCraftGuiOpened method seems to have disappeared in 1.3. Is there a replacement, or is it no longer necessary for some reason?

News Version 1.5.1 Fixed equipped shaped block not showing in first person. Removed spurious "Shaped Block" item from creative menu. Made Pick Block work on shaped blocks. Made "Cut from xxx" message translatable. Version 1.5.0 Updated for Minecraft 1.7.10 Version 1.4.0 Updated for Minecraft 1.7.2 Version 1.3.0 Updated for Minecraft 1.6.2 Version 1.2.0 Updated for Minecraft 1.5.1 - 1.5.2. Fixed rendering of cracks when breaking blocks. Greg's Blocks Ziggurat-style roofs have their place, but you don't want them all the time. This mod gives you the blocks you need to make real roofs with actual slopes. Home Page Further information and download instructions can be found here: http://www.cosc.canterbury.ac.nz/greg.ewing/minecraft/mods/GregsBlocks/

Okay, I can add that, but I haven't been able to reproduce the problem you describe. Placing a torch in the beam path and then breaking it doesn't seem to result in any floodlight beam blocks being dropped for me. Is that all you did, or was there more to it?

Can you tell me what changes you made, so I can incorporate them?

I may have spoken too soon -- it does seem to be gradually creeping up.

I'm running a slimophone and mining radar now, and my client's memory usage seems to be stable at around 100-120MB. Have you tried just Greg's Prospecting on its own? Maybe it's interacting badly with one of your other mods.

I've posted an update (1.2) that should fix the issue with pressing mining radar control keys outside of a game. I'm not sure about the others, but I've gone through the whole process of crafting a slimophone in both SP and MP without any problem.

That seems to have fixed it, thanks.

I'm trying to send tile entity data from server to client using a scheme modelled on the one used by TileEntitySign. My TileEntity class has a getDescriptionPacket() method that returns a Packet250CustomPayload. When the client receives this, it finds its version of the tile entity and updates it. Most of the time it works, but when the client initially connects to the server, some of my tile entity packets arrive before the Packet51MapChunk containing the corresponding block ID, so there is no tile entity there to update. If I create one of the appropriate type and put it there, it gets wiped out when the block ID arrives later. Does anyone have any idea what I might be doing wrong? Are there any examples around that show how to do this correctly? Code follows:

The cobblestone one is fine as it is, thanks for that. I think I'll stick with the one I'm currently using for the IC2 version, as it fits the clean, simple graphic style of that mod. BTW, you've reminded me that I forgot to credit you in readme, sorry -- corrected now.

While being able to see the code is a big help, it's not always sufficient on its own. Often it's very helpful to have a high-level description of how a part of the system is designed to work, written by the people who designed it, or at least someone who thoroughly understands it. Extracting that kind of knowledge from the code itself and its comments can be quite difficult, because it's scattered around in a lot of small pieces. This is especially true in framework-style systems that provide a number of components intended to be used together. It's not always obvious just from looking at the components themselves how they're meant to be connected. I recently had the experience of figuring out how to make a GUI work properly in multiplayer. This involves interactions between 5 or 6 classes, some of which have different versions on client and server. A comment attached to one of the Forge hook methods set me on the right path, but it took me a while to get to that point, and it was by no means straightforward after that. Even now, I don't feel that I fully understand the subject. If I'd been able to read a few paragraphs somewhere about how the GUI system works overall, it would have saved me a lot of time and given me more confidence of being able to tackle more complex GUI coding in the future. Thinking that because you're making the source available, you don't need to provide documentation, is a mistake, IMO.

+1 from me too.

I think I may have been bitten by this as well -- I changed the ID of one of the blocks in Greg's Lighting to 256 to avoid a conflict, and also to test how well the 4096 id support works at the moment -- and now I'm getting Floodlight Beam blocks showing up in NEI. While it's fun being able to place them, it's not really meant to work that way. :-) Is there any workaround for this in the meantime?

No, don't. Doing that to someone else's block looks like a good way to get NullPointerExceptions.

I think Minecraft already does something like this when it downloads player skins -- you might like to look into how it does that. In any case, it's certainly possible -- you can put whatever data you want in a packet, including image data. I wouldn't try to download megabyte-sized files this way, since that might put rather a lot of load on the server, but small images should be fine. As for the protocol, having the client request it from the server is probably best, especially if you're cacheing it in a local disk file, since the client can skip it if it already has the image.

Hmmm... what happens if one of the slots is full, but the others aren't? It seems like items will end up in the invisible inventory with nowhere to go. I was wondering whether I could just have setInventorySlotContents ignore the slot index passed in, and make its own determination of where to put the item. Or would that confuse callers too much? I may have a look at that and see what I can come up with.

I'm creating a device with two inventory slots that needs a specific kind of item to be placed in each slot. Currently I'm using ISidedInventory to allow items to be piped into particular slots, which works okay. But it would be better if I could accept an item from any side and automatically route it to the appropriate slot. Some mods have devices that behave this way -- anyone know how they do it? IInventory and ISidedInventory don't seem to support this behaviour, since they require the caller to have already decided which slot the item goes in. A related question is whether it's possible to reject items of the wrong kind. There doesn't seem to be any obvious way to do that either.

I'm thinking about an advanced version of the Mining Radar with a colour display to help you distinguish between different ores.

Buckets needn't be the only way of getting water in -- water cells, pipes, tubes, etc. should work too. One nice thing about the carbide idea is that all the ingredients -- water, bonemeal and charcoal -- can be made from renewable resources, so it's possible to set up a fully automatic system that runs indefinitely. Whereas short of EE, the only way I know of to get redstone or glowstone is to mine it, with the additional complication of cross-dimensional transport in the case of glowstone. I don't want to make it excessively difficult to set up a self-sustaining lighting system, just not trivially easy.

That's good to know. Although if "it's done" means when the rest of Redpower is finished, we might have to wait a long time. :-(

I'm thinking about another fuel idea now -- calcium carbide. This was apparently used in lighthouses at one time, so it's capable of producing some serious light. The floodlight would use 1 diamond directly in the recipe, and it would have a GUI with slots for a water bucket and a stack of carbide. The carbide would be made by heating a mixture of bonemeal and charcoal in a furnace. I'll keep the glowstone bulb idea in mind for an electrically-powered version. That'd be fine, thanks. I'll be wanting a different texture for the carbide version, something a bit more old-fashioned looking.