Finally someone/some people who have time to maintain a project like this. I was hoping this would happen as I am too lazy/busy to start one myself. I am all for this project. As mentioned by bfree380, I really hope we get Risugami and Shockah on board in some way. Just started using SAPI for blockharvest intercepts to remove modifications to vanilla MC classes.
Hopefully I can add my block metadata system in somehow. I'll have a better example with the next release of BetterOres+Alloys.
This looks like a cool mod. Especially because I was considering uninstalling IndustrialCraft (since all I really use in that mod are Macerators (one ore->two ore-dusts for 2x mining product) and Electric Furnaces (faster smelting)). PlasticCraft has a block that does faster smelting, but I had trouble finding a replacement for the Macerator's effect. BetterOres sounds like it could do that (too bad it needs a special furnace, it would've been nice to have accelerated smelting as well... and it probably also doesn't accept custom fuel, like BetterThanWolves' Nethercoal, does it?)
I can modify the vanilla furnace to work with metadata ( the author of MC extended has done this for an older version). I didn't due to possible conflicts I am not willing to deal with atm. I'll look into it. As far as custom fuel goes I could query ModLoader for added fuels but the main point of not doing this is to have customized smelting times for items based on fuel (Not planning to add this anytime soon though).
Still, I'm planning on using this... and in the 1.7.3 version, could you also have block and item IDs customizable in a .cfg file? I've got a lot of mods (so many that I can't start installing until MC Extended gets updated!), and conflicts in the under-255 range are fairly common.
Two property files (BetterOres and Alloys) are generated when running MC with the mods installed. You can change most options in those files. If you require more options just let me know. As you can see from the poll I am debating usage with MC extended but I use Opti-mine/fog HD which is not compatible with MC extended.
And I assume that, once nuggets are smelted, Iron and Gold Ingots are the same as vanilla?
Correct. Nuggets where created to avoid abuse. Although with the customizable settings it is possible to abuse but that depends solely on the user settings.
I started updating yesterday for 1.7.2 before 1.7.3 came out so I was a bit demotivated after that :tongue.gif:. I will update by the end of next week. I have been trying to find a way for the mod to work with and without GUIAPI installed, so that if people actually use my API for modding then they do not need to install GUIAPI unless they need it.
Hope to include the following in the next update:
Better rendering of Item subtypes using item overlays which are coloured.
Updated BlockSubtype rendering to take into account block orientation.
Storage blocks which use item textures, i.e. bread create which uses the breads icon to show what the bread contains. Will only use one block ID.
Oh, cool, kinda got tired running into those alloys. They are a Bit** to mine, maybe make the mining time shorter? And boy I hope this gets updated soon. Once again, you sir make minecraft better.
Oh, I forgot to mention about ScotTools. Its like ToolUtils but ToolUtils was breaking my mcp so I moved over to ScotTools. Once you have that installed all shall be good with mining speed of the new ores.
As stated before things can go bad if a texture pack adds a mod texture item which is larger than the current texture pack size.
Ill work on a fix for modloader item renderers like 303s hook (currently the hook is rendered as a flat object, unlike pickaxes etc).
The correct image size has to be calculated from the current texture pack based on "terrain.png" for terrain and "items.png" for items.
Then the buffered image has to be rescaled to the target size if necessary.
I made a quick fix with that code using MCP and nothing went wrong so far. Logically texture packs would have mod textures which are the same tile size (x16 or x32 etc..) or less. I have a custom texture for my mods using 32x32 items mixed with 16x16 items and there are no problems so far. I can see that using a 64x64 item in a x32 texture pack might be a problem.
It calculates it from the allocated buffer length, which is by default initialized for x16 texture.
If the width is not matching the image is resized (downscaled).
int w = bufferedimage.getWidth();
int h = bufferedimage.getHeight();
int w2 = (int)Math.sqrt(imageData.length / 4);
pixels = new int[w2 * w2];
if(w != h || w != w2)
{
BufferedImage bufferedimage1 = new BufferedImage(w2, w2, 6);
Graphics2D graphics2d = bufferedimage1.createGraphics();
graphics2d.drawImage(bufferedimage, 0, 0, w2, w2, 0, 0, w, h, null);
bufferedimage1.getRGB(0, 0, w2, w2, pixels, 0, w2);
graphics2d.dispose();
} else
{
bufferedimage.getRGB(0, 0, w, h, pixels, 0, w);
}
Oh, didn't see the buffer length has not changed in the TextureFX class. Given that, is there any problem with this
int w = bufferedimage.getWidth();
int h = bufferedimage.getHeight();
if(w==h)imageData = new byte[w * w * 4];
This is caused by ModLoader which creates the dynamic textures as x16 even when a HD texture pack is used.
Afterwards OptiFog has to upscale them to the correct resolution.
As far as I can see Modloader's ModTextureStatic reads the image size from the texture pack when adding new icons/tiles for mods. Where do you find the code that creates them at 16x?
Since we haven't gotten an answer, does anyone know of a mod that lets you increase the ore drops without adding extra ore types or other things?
Just delete the mod_Alloys.class from your minecraft.jar if you don't want new ores. Delete mod_Lightcrystal.class if you don't want lightcrystal. I have been busy with work lately and I am busy improving the API with the help of another modder.
There are WAY to many mods that add new tools, and honestly you only need one tool set after diamond, two if you want to also have an unbreakable set. And I really hate adding in new ores for any reason.
There are many mods that add new ores/tools/armour. I just want a unified way of adding these things with little coding overhead. Besides my API being used to add new ores, I have made storage blocks (like another mod has food blocks for each food) but only use one ID for a storage block.
lahwran I was tinkering around with TWL and Widget supports the use of property change listeners. Implementing these for Setting* will help reduce dependencies with GUI API. I just made a small change to SettingInt for my BetterOre+Alloys API.
How are your mods not that popular? better ores is amazing. And does the world already spawn the silver and other new blocks even though they dont have a use yet?
I am not sure why they aren't popular. Spread the news about them please?
New chunks will generate the new ores, So if you start a new world it will have the new ores at the start. Older saves will have the ores but only if chunks are generated after installing the mod.
Didn't it only add two item id's before? I can't imagine that being a problem. I guess having to have twice as many furnaces isn't really that much of a problem. I'll just need to redesign my basement to make room. I use a full wall of furnaces to get large projects done more quickly.
Yes it did use two IDs before, one for iron nuggets and one for gold nuggets. If I didn't make the change then Alloys would require an extra 4 IDs for nuggets and another 4 for ingots. For every ore/nugget/ingot would need another ID.
Using the new method which requires the special furnace allows me or any other modder to use just 3 IDs for potentially unlimited amount of ores/nuggets/ingots without adding more IDs.
Gah, why did you make the ores require a different furnace??? That makes this unusable for me now. :sad.gif:
How does a different furnace make the mod unusable? If I modified the original furnace code then that would break compatibility of other mods. The vanilla furnace cannot smelt items that are damaged or use metadata. The new nugget system uses metadata which results in less item IDs being used.
0
Finally someone/some people who have time to maintain a project like this. I was hoping this would happen as I am too lazy/busy to start one myself. I am all for this project. As mentioned by bfree380, I really hope we get Risugami and Shockah on board in some way. Just started using SAPI for blockharvest intercepts to remove modifications to vanilla MC classes.
Hopefully I can add my block metadata system in somehow. I'll have a better example with the next release of BetterOres+Alloys.
0
I can modify the vanilla furnace to work with metadata ( the author of MC extended has done this for an older version). I didn't due to possible conflicts I am not willing to deal with atm. I'll look into it. As far as custom fuel goes I could query ModLoader for added fuels but the main point of not doing this is to have customized smelting times for items based on fuel (Not planning to add this anytime soon though).
Two property files (BetterOres and Alloys) are generated when running MC with the mods installed. You can change most options in those files. If you require more options just let me know. As you can see from the poll I am debating usage with MC extended but I use Opti-mine/fog HD which is not compatible with MC extended.
Correct. Nuggets where created to avoid abuse. Although with the customizable settings it is possible to abuse but that depends solely on the user settings.
0
I started updating yesterday for 1.7.2 before 1.7.3 came out so I was a bit demotivated after that :tongue.gif:. I will update by the end of next week. I have been trying to find a way for the mod to work with and without GUIAPI installed, so that if people actually use my API for modding then they do not need to install GUIAPI unless they need it.
Hope to include the following in the next update:
0
Oh, I forgot to mention about ScotTools. Its like ToolUtils but ToolUtils was breaking my mcp so I moved over to ScotTools. Once you have that installed all shall be good with mining speed of the new ores.
1
ModTextureStatic Fix
As stated before things can go bad if a texture pack adds a mod texture item which is larger than the current texture pack size.
Ill work on a fix for modloader item renderers like 303s hook (currently the hook is rendered as a flat object, unlike pickaxes etc).
0
I made a quick fix with that code using MCP and nothing went wrong so far. Logically texture packs would have mod textures which are the same tile size (x16 or x32 etc..) or less. I have a custom texture for my mods using 32x32 items mixed with 16x16 items and there are no problems so far. I can see that using a 64x64 item in a x32 texture pack might be a problem.
0
Oh, didn't see the buffer length has not changed in the TextureFX class. Given that, is there any problem with this
0
Your graphics card does not support Fancy Fog.
0
As far as I can see Modloader's ModTextureStatic reads the image size from the texture pack when adding new icons/tiles for mods. Where do you find the code that creates them at 16x?
2
Just delete the mod_Alloys.class from your minecraft.jar if you don't want new ores. Delete mod_Lightcrystal.class if you don't want lightcrystal. I have been busy with work lately and I am busy improving the API with the help of another modder.
There are many mods that add new ores/tools/armour. I just want a unified way of adding these things with little coding overhead. Besides my API being used to add new ores, I have made storage blocks (like another mod has food blocks for each food) but only use one ID for a storage block.
0
public void fromString(String s, String s1) { //property changed firePropertyChange(backendname, defvalue, new Integer(s).intValue()); values.put(s1, new Integer(s)); if ( gui != null ) { gui.update(); } ModSettings.dbgout((new StringBuilder("fromstring ")).append(s).toString()); } public void set(Integer integer, String s) { //property changed firePropertyChange(backendname, values.get(s), integer); ModSettings.dbgout((new StringBuilder("set ")).append(integer).toString()); if ( step > 1 ) { values.put(s, Integer.valueOf((int) ((float) Math.round((float) integer.intValue() / (float) step) * (float) step))); } else { values.put(s, integer); } if ( parent != null ) { parent.save(s); } if ( gui != null ) { gui.update(); } }0
I am not sure why they aren't popular. Spread the news about them please?
New chunks will generate the new ores, So if you start a new world it will have the new ores at the start. Older saves will have the ores but only if chunks are generated after installing the mod.
0
Yes it did use two IDs before, one for iron nuggets and one for gold nuggets. If I didn't make the change then Alloys would require an extra 4 IDs for nuggets and another 4 for ingots. For every ore/nugget/ingot would need another ID.
Using the new method which requires the special furnace allows me or any other modder to use just 3 IDs for potentially unlimited amount of ores/nuggets/ingots without adding more IDs.
0
How does a different furnace make the mod unusable? If I modified the original furnace code then that would break compatibility of other mods. The vanilla furnace cannot smelt items that are damaged or use metadata. The new nugget system uses metadata which results in less item IDs being used.
0
Please post any feedback and spread the news about the API to any modders who add new ores or items which differ only by metadata.