Jump to content
Search In
  • More options...
Find results that contain...
Find results in...


  • Content Count

  • Joined

  • Last visited

Everything posted by Akjosch

  1. This will very likely not work with a dedicated server (... but feel free to test it out and report your findings).
  2. A few notes: * I'd make an IAnimatedModelCustom interface (extends IModelCustom). No need to support all those no-op methods for model types which can't even support them, and you can easily find out if you can call the animation functions via "instanceof". * COLLADA in particular (but also other model formats) supports multiple named animations. I'd suggest getting and using those animations this way: ModelAnimation anim = animatedModel.getAnimationAll("AnimName"); /* Alternatives: ModelAnimation anim = animatedModel.getAnimationPart("AnimName", "GroupName"); ModelAnimation
  3. The question is a bit ... confusing. Construction of a mob's models happens at most twice during the game run: Once into Minecraft's internal representation of it (during the constructor call of its Model) and once when the model first has to be rendered, into graphic card memory (in compileDisplayList(float) of its ModelRenderers). Neither of them involve any texture binding. Texture binding (for mobs) happens once per frame the entity is to be rendered in renderModel(EntityLivingBase, float, float, float, float, float, float) (actually more of a renderModel(<? extends EntityLiv
  4. Thanks! Now I need to make "one project per mod in the same workspace" work and modify the build.gradle file to work like I want it to and I'll be a happy camper.
  5. The problem is that the Anvil file format still saves just 12 bytes off a blockID, meaning we don't gain much of anything ... yet. (See aor.class for details)
  6. DemoXin just published his "FortuneOres" mod which does exactly that and is open source, so you can check for yourself how he did that - or ask him: http://www.minecraftforum.net/topic/2079807-fortuneores/
  7. The "problem" with EntityRegistry.registerGlobalEntityID() is that it doesn't fill up a couple of FML maps, which means (from what I understood of the code) you can't use FML's custom mod spawning and tracking. As a workaround, would the following fill them up properly? Looking at the code for 1.6.4, it seems it might just work, but I'm not sure were the FML or the Forge team want to take those ... EntityRegistry.registerGlobalEntityID(EntityMyMob.class, modID + "." + mobUntranslatedName, id, backgroundEggColour, foregroundEggColour); EntityRegistry.registerModEntity(Entit
  8. Right now, I'm registering mobs with the game as follows. In the mod's initialisation routine: // We'll need that later. Map<Class, Integer> classToIDMapping = ObfuscationReflectionHelper.getPrivateValue(EntityList.class, new EntityList(), "classToIDMapping"); // For every mob, repeat the following // Registering the mob with FML (this also fills EntityList's stringToClassMapping and classToStringMapping) EntityRegistry.registerModEntity(EntityMyMob.class, mobUntranslatedName, mobInternalID, this, trackingRange, updateFrequency, true); // Add a readable
  9. You can access getRecipeSize(), which can give you the answer for 1x1, 2x2 and 3x3 recipes (it returns 1, 4 or 9 in those cases). For everything else ... public static int[] recipeSize(ShapedOreRecipe recipe) { int width = ObfuscationReflectionHelper.getPrivateValue(ShapedOreRecipe.class, recipe, "width"); int height = ObfuscationReflectionHelper.getPrivateValue(ShapedOreRecipe.class, recipe, "height"); return new int[]{width, height}; }
  10. ok i really need an example.... let's suppose my texture is "assets/minecraft/textures/entity/MYTEXTURE.png" DON'T. Mod resources go into "assets/(modID, lower case)" and no-where else. In other words, this should be "assets/modid/textures/entity/MYTEXTURE.png" In your entity renderer (extends one of the sub-classes of net.minecraft.classes.renderer.entity.Render): private static final ResourceLocation texture = new ResourceLocation("modid", "textures/entity/MYTEXTURE.png"); @Override protected ResourceLocation getEntityTexture(Entity entity) {
  11. He means you can simply use GL11.glBindTexture(GL11.GL_TEXTURE_2D, textureID) with textureID being an integer with the (OpenGL-internal) texture number, usually from GL11.glGenTextures(), which you previously assigned some image data to via GL11.glTexImage2D(), GL11.GL11.glTexSubImage2D() or similar methods. If you have the textures referenced as Minecraft's ResourceLocation though (and you should), it can do all of it for you "automagically" by simply calling Minecraft.getMinecraft().renderEngine.bindTexture(textureResourceLocation).
  12. Chunks get rendered up to (64 << (3 - renderDistance)) or 400 blocks, whatever is bigger, far. The far clipping plane (which "cuts off" the rendering) is at (256 >> renderDistance) meters (blocks) in the direction your camera is pointing at.
  13. Test #2, time to implement my own InputStream which can deal with directories (and handles zip files as directories as well). Wish me luck. package my.package; import java.io.File; import java.io.FileInputStream; import java.io.FileNotFoundException; import java.io.IOException; import java.io.InputStream; import java.util.Enumeration; import java.util.Iterator; import java.util.zip.ZipEntry; import java.util.zip.ZipException; import java.util.zip.ZipFile; /** * An InputStream supporting files and directories. * <p> * It works in one of several modes, depending on what the argu
  14. Some test reports: Well, hooking up my resource pack in FMLClientHandler.instance().resourcePackList and FMLClientHandler.instance().resourcePackMap in pre-init, followed by Minecraft.getMinecraft().refreshResources() works to a point - the FallbackResourceManager calls it up. However, it then tries to construct a SimpleResource, which needs an InputStream, which won't work and makes no sense with a directory. Time to implement my own ResourceManager and convince Minecraft to use that for my mods ... Which will be kinda hard given it only uses one, in Minecraft.getMinecraft().mcResou
  15. And how is that a drawback for a ResourcePack ? A server doesn't need multiple versions of the same thing... Well yes, yes they do. Examples: Localisation of server messages (depending on client's language setting) Server-generated resources (again, depending on client's capabilities, localisation or settings) Dynamically extending instead of replacing resources, which is the whole point of the exercise of having directories and wildcards as valid resource locations.
  16. Yeah ... would be nice to have it running for 1.6 though. Given how long some mods are taking to upgrade from 1.5 already, I'm not in a hurry. Forge already changes "private" class members to "public" at Minecraft startup (and before the mods load), so it works by simply changing them to "public" in your development environment and making sure you don't include anything which isn't in your packages when you make the distribution. ... and changing the functionality via ASM hacks is what I'm trying to avoid doing.
  17. Ok, so I'm trying to do something which should be simple: Creating my own ResourcePack class. The currently available net.minecraft.client.resources.AbstractResourcePack just doesn't cut it for the following reasons (and I'd prefer to leave that alone so not to break anything else): It's client-side only. At least one of its implementations (FolderResourcePack) considers a directory to not be a valid resource (see: hasResourceName() checking for isFile()). Mind you, an archive file (which is basically the same thing: both are containers for resources) is accepted just fine, which is b
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.