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

malorolam

Members
  • Posts

    12
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed
  • Personal Text
    Developer of Carbonization

malorolam's Achievements

Tree Puncher

Tree Puncher (2/8)

1

Reputation

  1. String s is the return from a function that takes in two files, one of which appears to be the main directory to the assets folder, the other appears to be the mod specific file locations, i.e. the <modname>/textures/blah part, all of which should normally return all lowercase. From what I see, if it throws the error it's because there is actually an error, and the basic Java file structure stuff broke somehow.
  2. Make sure that the file structure for your textures is: src\minecraft\assets\<modname>\textures\blocks/items/etc. there also should be a pack.mcmeta file in the textures folder for ResourceLocation(domain, filename), though I don't know why, I use the "domain:filename" form instead and things work alright. Also, while Forge /should/ recheck LanguageRegistry stuff after PreInit, it doesn't seem to be doing that in 761, so you need to move all the LanguageRegistry calls in your main mod file to PreInit for the texture loading functions to actually be called. That fixed all the problems with block and item textures for me, you can see my code at https://github.com/Malorolam/Carbonization Guis aren't behaving yet for me though.
  3. Inside the forge folder, after you've run the install script and let it do it's work, there should be a folder called mcp, which is the same folder structure as before, so just direct Eclipse to open the workspace from the eclipse folder there and it all works as normal. The directory my Eclipse opens is C:\Users\Mal\Desktop\forge\mcp\eclipse
  4. It is not doing that in the latest version on the file server, you have to put all LanguageRegistry calls in preInit for the names and textures to be found correctly. It might need more, my init method is basically LanguageRegistry, GameRegistry, OreDictionary, and instantiations, so I just grabbed most of it and moved it over. I also added in pack.mcmeta file under assets/modname and almost all of my textures loaded with no other changes to the code. The only one that didn't work after that was my hacked together test block, and that was because I used setUnlocalizedName as the texture reference. My gui textures aren't loading though, so that's next on my list of stuff to fix tomorrow, probably a reference issue. I have it updated on my Github (https://github.com/Malorolam/Carbonization) so there is a more complex example to look at for block and item textures.
  5. https://github.com/pahimar/Equivalent-Exchange-3 However, EE3 uses a separate key-bind for it's crafting grid, and since you asked for on right click, this code will suit your needs better: @Override public boolean onItemUse(ItemStack itemStack, EntityPlayer entityPlayer, World world, int x, int y, int z, int sideHit, float hitVecX, float hitVecY, float hitVecZ) { if (world.isRemote) { entityPlayer.openGui(yourmod.instance, yourguiID, world, x, y, z); } return true; } It's a bit rough, since I wrote it on the spot, but hopefully it makes sense. The core idea is when the item is used (right clicked) it will tell the player to open a gui that you specify. This tutorial is a bit out of date, but most of the code didn't change with 1.5, so it still works as a reference http://www.minecraftforge.net/wiki/Containers_and_GUIs
  6. Hmm, it doesn't look like an issue with the smelting command you had originally as long as you are turning chunks into stone. If it's the other way around, then the parameters are backwards. It looks like you are setting everything up correctly for the items, so the only thing I can think of is either use the item id of the items instead of the config variables, or explicitly tell the ItemStack to make one stone, shown here: GameRegistry.addSmelting(divineChunks.itemID, new ItemStack (divineStone.itemID,1), 1.0f); That should fix it hopefully.
  7. Well, I'm guessing you are talking about @Override public void updateEntity() { // the - 1 prevent it from crashing! for(int i = 0; i < getSizeInventory() - 1; i++) { maxstack += advTinyChest[i].getMaxStackSize(); stacksizes += advTinyChest[i].stackSize; inventorymaxstack += getInventoryStackLimit(); } if(maxstack == stacksizes || maxstack == inventorymaxstack) { isFull = true; } else if(maxstack == 0) { isFull = false; } else { isFull = false; } if(stacksizes == 0) { isEmpty = true; } else { isEmpty = false; } } Since I don't have a precise problem, I'm just going to go through all the things I see and hopefully one of them is the problem you're having. First, you shouldn't need to subtract 1 from getSizeInventory(), since all that does is return the length of the ItemStack array, which is from 0 to par1-1 already. Second, it looks like you don't ever reset the value of maxstack, stacksizes, or inventorymaxstack, so they just keep adding whatever value is returned by the code to themselves every time the tile entity is updated. I'm thinking you want the entity to figure out if it's full by comparing the total number of items inside it to the maximum it can hold, which is what stacksizes and inventorymaxstack is for, since there are items that don't stack to 64. To fix this, just add maxstack=0; stacksizes=0; inventorymaxstack=0; before the for loop. I hope this helps fix the problem, if not then throwing some System.out.println statements returning variables or using debug mode and some breakpoints should give you more information.
  8. First off, the link elantzb provided is very helpful for getting the basic world gen working, so this is kind of assuming you understand that. How I'm going about world gen is through these two files: https://github.com/Malorolam/Carbonization/blob/master/mal/carbonization/WorldgeneratorCarbonization.java https://github.com/Malorolam/Carbonization/blob/master/mal/carbonization/CarbonizationGenMinable.java and adding GameRegistry.registerWorldGenerator(new WorldgeneratorCarbonization()); to your main mod file. WorldgeneratorCarbonization is what Minecraft uses to generate things after Forge tells it that it exists with the register function, with CarbonizationGenMinable being a modified copy of WorldGenMinable. You don't need your own gen class, I have one because I had to change the gen rules a little bit for my fuels. The important part of the code for your question is for(int i = 0; i<diff;i++) { int Xcoord = blockX + random.nextInt(16); int Ycoord = yMin + random.nextInt(yDiff); int Zcoord = blockZ + random.nextInt(16); (new CarbonizationGenMinable(carbonization.instance.fuelBlock.blockID, meta, genSize, diff)).generateStone(world, random, Xcoord, Ycoord, Zcoord); } The WorldGenMinable version of the last line is parametrized exactly the same as mine. To increase the amount of the block that spawns in one vein, just increase genSize. To increase the number of veins in a chunk, diff is what you increase. Keep in mind that how the gen works is nested for loops, so you want to avoid going too crazy with those values or there will be lag everytime a new chunk is generated. From my own tweaking, using a genSize of 50 and a diff of 5 or 6 should give you a large amount of generation, although I would probably favour smaller veins with a higher diff value.
  9. Well my code makes no sense because I haven't quite figured it out myself. I've been focusing the last couple of days on getting a release ready and all the needed information for that set up. The comments are me thinking about how I want to proceed, and I find it easier to figure things out if I act like I'm teaching. What I have so far is I'm going for a multiblock system that is a bit closer to XYCraft then Railcraft, since I find some of the limitations of the Railcraft multiblocks irritating, mainly not being able to have them touch. Thinking this through I'm going to go for figuring the multiblock out through it's internal geometry, since I know each machine is a specific shape and key blocks have to follow certain rules. For your typical fixed size multiblock it's probably a bit too involved. I'll be working on this more in the next day or so.
  10. First, make sure that your texture files are named correctly and are in the correct folders. Since you didn't have this problem a few days ago, I doubt it's this, but it doesn't hurt to be thorough. Second, which is probably the issue, make sure that if you are going to override a method, like you are here, use the @Override tag before the method declaration so it is explicitly using your method when getting the textures for your block. It's also a good way to make sure that you overrode the method correctly, since Eclipse will flip if you try to override a method incorrectly.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.