Xfel

As all bounding boxes are axis-aligned, the intersection detection (for collision etc) is very easy. if you take a non-axis-aligned bounding box, the complexity of the collision checks increases drastically. So this would be a bad idea as it would harm performance.

If you say that, you could say the same about the ore dictionary. After all, it is just about resolving conflicting apis too. And I doubt it would be as widely used as it is now if it was a seperate mod.

Hi, As Co-Admin on a FTB Bukkit server I found it always difficult tu limit the use of certain items like the Mining Laser or other mod functions. In my opinion, it would work a lot better if the mod authors would use some kind of permissions system. However, there is no universal permissions api forge mods could use. So my suggestion would be: A Forge Permissions API. I thought about something like this: If a mod wants to check a permission, it posts a PermissionEvent (containing the permission id and the player to check for) to a special permissions event bus. Subscribers to the event can now check whether the player has that permission and set the event's result accordingly. Additionally, one could also post location-based permission event, so items like the Wand of Equal Trade would be limited to the user's own regions. This api doesn't have to define an interface for modifying permissions, that's up to the implementors. I think this should be in forge as it would encourage it's use. It's comparable to bukkit where there was a big chaos in permissions too until they included the unified permissions api.

Where did you get that version from? There isn't even an MCP version for the snapshots

I highly doubt that the forge devs will implement this for the vanilla containers.

As of the latest snapshot 13w03a, the new hopper block is able to interact with furnaces properly. The mechanism it uses to identify the slots is not too different from the sided inventory mechanism. In fact, the Furnace and Brewingstand tile entities are now implementing an IInventory subinterface which actually IS ISidedInventory in all respects (if you don't believe it: the class is obfuscated to "lm"). The problem is: the forge version processes fuel from the bottom, output to the sides. The new vanilla version does it the other way round, as the hopper can only extract from the bottom. So I'd like to know what the forge devs will do when 1.5 comes out. Will you override the vanilla version (which would break the hopper) or will you adapt to it (which will break many existing builds).

For 1): Many mods (IndustricalCraft and BuildCraft for sure) provide a seperate API download, which contains .java files with the general api classes. You can include these files into your mod's source and use them for interfacing. Normally, you are allowed to redistribute these classes with your mod, so that it will run no matter whether the other mod is there or not.

OK. It seems that I have to set RenderBlocks.flipTexture to true during the problematic face renders. If anybody else gets this error: The problem methods are renderEastFace and renderSouthFace.

You have to use renderer.setCustomBlockBounds instead of block.setBlockBounds, as the latter isn't updated while in the render method.

I tried to write my own renderer and it does work fine so far, however, when rendering the south end the west face I happen to get a strange bug. This is what it should look like: And this is what it actually looks like (it's the opposite side of the same structure): I'm using the ISimpleBlockRenderingHandler interface, and this is my render code (based on RenderBlock.renderBlockWithColorMultiplier): Source on github Does anyone have an Idea what's wrong there, and more important how to fix it?

If I want to package my mod, I currently have to 1) copy the source to the mcp src dir 2) recompile my mod and the minecraft sources 3) reobfuscate mod and minecraft sources 4) mcp then goes through some effort to seperate the modified classes from the minecraft source. However, as I'm modding on forge, the only modified classes are my new classes. So wouldn't it be possible to add a modified reobfuscation script that would be able to reobfuscate my mod classes alone? this would enable me to do it like 1) compile my mod's classes (minecraft classes in the classpath) 2) reobfuscate my mod's classes. 3) no need for md5 checking, as we didn't process any unmodified files.

The way hashmaps work isn't the problem. What you're doing would not work for any map implementation. The reason is that array equals and hashCode work on the object identity, not on the contained data. Take a look at the FurnaceRecipes class, that should show you how to do it.

Hi, I'm trying to write some code that looks in all six block directions like for(ForgeDirection dir:ForgeDirection.values()){ ... } However, that doesn't work as it includes the UNKNOWN value, too. So, I'd suggest a field like ForgeDirection.DIRS (or method dirs()) which returns an array containing the six directions, but not the UNKNOWN one.

You are aware of the fact that Class.getResource() (Not as stream) returns an URL you could pass to new SoundPoolEntry? Like: public class SoundHandler { @ForgeSubscribe public void onSound(SoundLoadEvent event) { try { event.manager.soundPoolSounds.addSound("your/sound.ogg", CameraCraft.class.getResource("/path/to/your/sound.ogg")); } catch (Exception e) { System.err.println("Failed to register one or more sounds."); } } } This avoids writing a hacked urlstreamhandler and will work no matter where in your classpath the sound file is.

If you create your byte array "byte abyte0[] = new byte[32768];", it's all zero, which is interpreted as all empty (block 0 = air). The cave generator only creates holes in existing structures, it only sets fields to air. If everything is air already, you won't see anything, of course.