gcewing

Thanks. I couldn't see how to make sure my sounds got assigned unique ID numbers, but digging deeper I can see that Forge has its own way of allocating them. All is working now.

Is there a way for a mod to register its own sounds in 1.10.2? The only machinery I can find for doing that is all private.

In MC 1.7.10, is there any easy way to cause a tile entity update packet to be sent to clients without triggering a re-render of the chunk? All I can find is markBlockForUpdate() which does both, and the underlying machinery all seems to be private.

Ah, okay, thanks. Seems I didn't look far enough afield in the cache!

For a long time I've been using a little script that greps the .srg files to find a mapping for a name. But I've just set up a decomp workspace for 1.10.2, and I can't find the .srg files anywhere, not even in the gradle cache. Does anyone know where they've been hidden? Are .srg files even being used still, or have they been replaced by something else?

There are no power or computer interfaces in the 1.8 version yet. I'll tackle that when I finish revamping the 1.7 code. The base itself has never acted as a computer peripheral. You need to use an interface block in 1.7, and it will be the same in 1.8.

Yes, I'm still working on it. Currently working on a 1.8 update. Also hoping to set things up so I can develop 1.7 and 1.8 versions in parallel, although I can't promise anything about that just yet.

Does this still happen with the latest version (1.9.5)?

According to DefaultVertexFormats.ITEM, the layout of the bytes in a normal should be x y z pad But I'm finding I need to lay them out this way: pad x y z All the other code I can find in MC and Forge that deals with normals seems to use the ITEM layout, so I'm confused. Anyone know what's going on? I'm using Forge 1.8.9-11.15.0.1691.

ArchitectureCraft This is a revamped and expanded version of Greg's Blocks for Minecraft 1.8. As well as sloped roofs, you can now have blocks sloping in any direction, create round corners, arches, and other rounded structures, and give your windows nice-looking frames. Home Page http://www.cosc.canterbury.ac.nz/greg.ewing/minecraft/mods/ArchitectureCraft/

I found out what was happening. It seems that the textures are loaded twice when Minecraft starts up. Because I'm keeping my own cache of the sprites that I add, they weren't getting added to the atlas the second time around. Clearing my cache on each TextureStitchEvent solved the problem.

It's definitely doubling things up. The two textures I'm adding are being allocated the same slots in the texture atlas as minecraft:blocks/anvil_base and minecraft:blocks/anvil_top_damaged_0.

I'm trying to add a TextureAtlasSprite by calling event.map.registerSprite() in a TextureStitchEvent.Pre handler. It's not working properly. I get a TextureAtlasSprite with valid-looking texture coords, but the position in the texture that they refer to is occupied by a different sprite. Looking at the dump of the stitched texture map, my texture doesn't seem to appear in it anywhere. Am I going about this the right way? Is TextureStitchEvent.Pre the right time to do this? Am I calling the right method? The equivalent thing used to work in 1.7.

I thought about that, but the layer is ultimately going to be dictated by the base material, e.g. if the block is made from tinted glass, it's going to have to be rendered in the alpha transparency layer. So I'm not really free to (ab)use the layers that way.

I'm porting my roof blocks from Greg's Blocks to 1.8, and I'm having trouble with ambient occlusion. It doesn't seem to be possible to get it to work correctly for faces that are not axis-aligned. In this screenshot, you can see places where the lower edges of roof blocks are incorrectly shaded, because the rendering system thinks that the cobblestone block below the roof block is casting a shadow on it. This happens because the roof block is not opaque, so it includes the block below in AO calculations rather than the block below and in front. The same thing causes the ridge blocks on top to be shaded too darkly, because they have opaque blocks underneath them. In my 1.7 rendering code, I dealt with this by only using AO for the exterior axis-aligned faces and not the sloping ones. But the 1.8 rendering system only allows AO to be turned on or off for the whole model, not individual faces, and unless I'm missing something, only allows one BakedModel to be rendered per block. Anyone have any suggestions?