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?

Don't get me wrong, I don't object to the model-based system. For mostly-static rendering, it's fine, and a great improvement. But I don't like being forced to use it, and having to use ugly workarounds to make it more dynamic when needed. The frustrating thing is that it doesn't need to be that hard. There's a place in BlockRendererDispatcher that switches on the block's renderType to choose between model rendering and fluid rendering. If there were a Forge hook in there to allow you to plug in a custom renderer at that point, like there used to be, all would be well. Is there an official place to make Forge feature requests?

It still seems like terribly convoluted way of going about things. Seemingly I have to extract all the information out of my tile entity and encode it as Properties, only to immediately decode it again in my model. It would be much easier if I just got the world and position passed in directly. Then in the model, instead of just rendering things using the tessellator, I have to construct a list of quads in a screwy low level format that involves shoehorning floats into ints? Really? The whole thing feels like a massive kludge. The old way may not have been ideal, but it was easy to do unusual things with it. This seems very constraining. I hate to think how mods such as Forge Multipart will deal with this. It's not going to be fun for them.

Someone please tell me this is all a bad dream... It seems that to use ISmartModel I need to pass information from the tile entity to the model via an IBlockState. That's not going to work. There are far too many possible states to encode that way. Plus I need information from adjacent blocks as well.

Is there any way to register a custom block renderer in 1.8? In Greg's Blocks for 1.7 I have a block renderer that dynamically computes what to render based on information in the block's tile entity and those of surrounding blocks. There are too many variations on the shape to use a separate model for each one. The textures to be used also depend on the tile entity. I don't want to use a TESR because these blocks are typically used in large numbers, and re-rendered on every frame would be very inefficient. I can't see how to handle this with the new rendering system in 1.8.

Project Blue This is the beginnings of an add-on for Project Red. I hope to add a lot more content. Control Panels If your contraption requires more than a couple of buttons or levers to operate, the controls can take up a lot of room and leave you puffed out running back and forth between them. A Control Panel lets you fit up to 16 levers, buttons and indicator lamps into one block space for the ultimate in compactness and ease of use. You can make a Control Panel out of any material that a Cover can be made from. Controls for use on the panel can be left plain or painted any of 16 colours. Individual labels can be placed above and below each control. The control panel can be mounted on a surface as shown here, or it can be placed flush in a wall with the cable connecting from behind, so that all the wiring is hidden. Bundled Cable to RedNet Adaptor Relays signals between a Project Red Bundled Cable and a MineFactory Reloaded RedNet cable. News Version 1.1.6 Fixed controls reverting to white when removed from a control panel. Version 1.1.5 Fixed crash when spawning a control panel using the /give command. Version 1.1.4 Now works in multiplayer again. Version 1.1.3 Control panels may be rotated by right-clicking on an empty cell with a screwdriver, and the initial orientation of a horizontal control panel is determined by the direction the player is facing when placed. Control panels can be placed side by side without connecting to each other, allowing larger control panels to be assembled. Control panel related recipes appear in NEI. Control panels retain their controls when broken and placed down again. Shift-left-click on a control panel with a screwdriver to pick it up instantly. Breaking a control panel in creative mode does not destroy it. Version 1.1.2 Fixed breakage of MFR 2.8.0 RC3. Names used to find blocks and items from other mods are now configurable to allow any future incidents of this kind to be worked around. Version 1.1.1 Fixed crash with MFR 2.8.0 RC4. Version 1.1.0 Added Bundled Cable to RedNet Adaptor. Version 1.0.1 Now works on server. Fixed display of colour names in tooltips. Added more miniature control creative items. Downloads http://www.cosc.canterbury.ac.nz/greg.ewing/minecraft/mods/ProjectBlue/

Project Red makes extensive use of multiparts. Also Forge Multipart itself includes multipart versions of some vanilla items such as torches and levers. Finally, for what it's worth, here's some code of my own (incomplete) implementing a pipe part. The canConnectToTube() method contains an example of looking at a tile entity to see whether it contains another pipe part. It's a bit specialised, because my pipes are always centre parts and therefore can only appear in slot 6 of the part list. In the general case you would have to iterate over partMap.

You need to all markDirty() whenever something in your tile entity changes, so that it will be written out when the world is saved. Also, you need to implement getDescriptionPacket() and onDescriptionPacket() even for a single-player environment. There is still a server and a client in single player (they just exist in the same process) and they need to be kept in sync.

You need to call markDirty() on the tile entity whenever the inventory changes, otherwise the tile entity won't be written out when the world is saved.

I've never tried it, but it looks like you should be able to just define your own subclass of Event and then post() it to the relevant event bus. Should be pretty simple -- try it!

Something like NBTTagCompound nbt = stack.getTagCompound(); if (nbt != null) { NBTTagCompound disp = nbt.getCompoundTag("display"); if (disp != null) { NBTTagList lore = disp.getTagList("Lore", ; if (lore != null) { // lore is now a list of NBTTagStrings } } }