Since I'll be using MCForge for the next version of BetterOres and this requires a bit of recoding I might not release an update until 1.8 is out. I have a mod in mind for the new lighting system as well.
If anyone wishes to have a version BetterOres for 1.7.3 please say so. I can release the SAPI version but I am not happy doing so.
New Poll for handling the conversion of the mod to not edit vanilla classes.
At the moment BetterOres modifies the BlockOre class to provide the functionality of the mod. You as a (potential) BetterOre user have a choice to make.
Your choices are:
[1]Allow the mod to modify the BlockOre cLass.
[2]Make the vanilla blocks use instances of BlockOreSubtype which can break saves but will provide the following:
The iron ore block ID can be used for all metal based ores. (This ID will store iron, gold, copper, ..., etc ores)
The gold ore block ID can be used for all mineral/gem based ores. (This ID will store coal, diamond, maybe clay and other types)
The coal ore block ID can be used for ingot storage blocks.
The lapis ore block ID is now free to use. You can have subtypes stored here.
The diamond ore block ID is now free to use. You can have subtypes stored here.
This option will break on on old saves. The world will load fine but you will not find the correct ores at the places they existed before.
This option will break on on new saves without the mod installed. The world will load fine but you will find ores in places where they should not be.
Well it adds the ability to easily add subtypes for blocks and items. It custom renderer which will allow overlays to be rendered on blocks (the same way the biome grass works.).
If you want to add a new metal to the game it will produce everything needed for that metal (ore, nuggets, ingots, ingot storage blocks) without adding more IDs.
Just read a bit here (Better Ores) and check the images which i posted in this forum as well.
I'm still working on including some systems into Forge to make this easier for people. I'm currently implementing a metadata-sensitive tools API into Forge, which will let you share block IDs between up to 16 diffent kinds of "simple" blocks, like ores or building blocks.
It's the other way around ;-). If the Aether wants to use the Forge, we're happy to include patches for it! But we're unlikely to start adding features if we're not sure they'll be used...
I saw that block intercepts where handled in the EntityPlayerSP class. If we don't want to modify the default class then we can just have a class that extends the EntityPlayerSP class.
[disappointed_rambling]
Has anyone even looked at the spoiler in my earlier post?
I don't know if this is possible, mostlikely not, but if and later ore adding mods would use forge, could it be possible to let forge map the ore onto the currently used stone texture?
I'm asking since I had to change my stone and with that other ore textures too in my texturepack so the IC ores don't look totally misplaced everywhere.
If now forge could take added ores as a transparent texture with just the ore texture without the stone 'in the back' on it and map that onto the stone texture from the currently used texturepack every ore added this way would fit without problems into the world even when changing the texture pack.
But I guess that's something so big to change that it would go way deeper into MC, am I right? :/
I'll make a little diagram to show better what I mean. Just for the case anyone would ever be able to mod this in.
Edit: Pic!
But I guess it's currently not even closely possible to dynamically modify textures, eh?
Well my API does something like this. Didn't even see the discussion about this.
This image shows off using sand as a base texture.
The overlay ore texture can be changed to suit a texture pack.
An easier method than trying to make blocks that can change their material type for damage values would be to add something that allows selective block placement prevention, since that's the primary function of materials.
If anything, someone should post a tutorial somewhere on how to give a block damage values.
The point of my API is to avoid having to learn how to do subtypes by oneself. Material types was just an example.
From what I know though, you can easily store multiple blocks in one ID, but how this exactly works, I don't know.
Depending on how modders want to use those blocks my API provides an intuitive way of adding block subtypes to a main type (e.g having step blocks as a main type and adding different materials for use like stone, wood, etc..)
My alloys mod adds in new ores with nuggets (see how Better Ores works to understand nuggets) which smelt into ingots which can be made into storage blocks (like iron and gold blocks). One ID is used to store any number of ore subtypes in it and another to have the storage blocks. As for the item IDs two are used (nugget and ingot). Subtypes can be classified by colour which is used during item rendering and block rendering. The custom ores are also coloured without requiring multiple textures for each ore.
I was thinking about how the modders for the Aether incorporated some of their needed features. For a large amount of things they made their own extension of EntityPlayerSP to add features such as new equipable slots. Should we include something like this for MCForge?
To make an item/block mod use MC Extended, all you have to do is make sure it doesn't modify the same core files as MCE, and use the .cfg file to put the block IDs in the [256, 1023] range. (And make sure the item IDs are above 1200 or so. Even in vanilla, item IDs can be anywhere from 256 to 65535, all MCE does to items is move the vanilla ones to start at 1024, and create room for more sprites in extra items.pngs.)
And AFAIK, the Optimine creator is planning on making his mod compatible with MCE eventually (he said two versions after HD_G, but that was before the 1.7 update).
I will not be using MCE as I will be converting my mod to use MCForge.
I have a version for 1.7.3 available in the meantime. It uses SAPI till i can get hooks for block intercepts into MCForge. Should I release it?
Yes, that makes sense. For changing the vanilla drops, you could still swap the blocks in Block.blocksList, but while that's base-clean, it's a little bit brute-force.
Swapping blocks in the blocklist is okay but will result in worlds which will fail to load correctly when going between updates of MC. Invalid block IDs are not loaded by vanilla MC and would result in no ores appearing on the map. However which block intercepts vanilla ores will still be available.
Might seem like an arbitrary point but I think its valid.
Another supporting statement is adding addition drops t blocks without having to replace blocks in the blocklist with custom created classes (e.g grass blocks dropping grass seeds as well as the default dirt block.)
Do you actually need the first one? Can't you just override damageDropped in your own ore block class, maybe extending BlockOre? RedPower does much more involved handling of harvests, so if you need a little help, drop by #minecraftforge on espernet or send me an IM.
Basically my mod changes the amount of drops from vanilla ores and also makes added ores have configurable drops. Overriding would only work in the latter case.
Unfortunately I am work most of the day so I might be able to come on IRC later (web client as others are blocked by university policy.)
I wasn't very happy with scokeev9's first post. The tone didn't seem right. He did mention some important points though.
I agree that MC Forge should not re-implement API's which are available. Obviously if a mod maker with an API which is needed (such as the block harvesting API in what ever flavour you like) does not want to join in the project we cannot force them to do so, however, if possible we can make then compatible. Since Modloader does quite a bit of core modding (chunk population, entity spawn lists, etc) I feel MC Forge does not need to re-implement the mature features. Adding textures for blocks and items is what I consider to be an immature feature of Modloader, Eloraam's multi-Tessellator code being the next stage of this feature.
Anyway back to coding :tongue.gif:
Feature request!
Intercept block harvest
Not sure if anyone on the project has ever used my mod (I get like 200 DL a month :sad.gif: :tongue.gif: ) but I was modifying the BlockOre class to accomplish the goal of my mod, adding custom ores without adding more block IDs. After seeing that SAPI had an intercept hook when harvesting a block I added the hook into my mod to eliminate the need to modify the BlockOre class. If we cannot get Shockah on board to integrate his API (@scokeev9 I am not saying we are using ToolUtils as a whole but ideally work out differences and come to a common standpoint) then I propose we add this feature to MC Forge.
Smeltable subtypes
smith_61's MCE had a Furnace API specifically for this. Basically it allows smelting of items with subtypes/damage (coloured wool, half steps are some examples). I added my own furnace to accoplish this for my mod as I did not want to edit too many vanilla classes. Can we also add this to MC Forge?
I have a question about the configuration class. Why is there a custom class for properties if there is a java.util.Properties class which can handle most of that if used as an instance in the Configuration class.
0
If anyone wishes to have a version BetterOres for 1.7.3 please say so. I can release the SAPI version but I am not happy doing so.
At the moment BetterOres modifies the BlockOre class to provide the functionality of the mod. You as a (potential) BetterOre user have a choice to make.
Your choices are:
[1]Allow the mod to modify the BlockOre cLass.
- The iron ore block ID can be used for all metal based ores. (This ID will store iron, gold, copper, ..., etc ores)
- The gold ore block ID can be used for all mineral/gem based ores. (This ID will store coal, diamond, maybe clay and other types)
- The coal ore block ID can be used for ingot storage blocks.
- The lapis ore block ID is now free to use. You can have subtypes stored here.
- The diamond ore block ID is now free to use. You can have subtypes stored here.
- This option will break on on old saves. The world will load fine but you will not find the correct ores at the places they existed before.
- This option will break on on new saves without the mod installed. The world will load fine but you will find ores in places where they should not be.
[2]Make the vanilla blocks use instances of BlockOreSubtype which can break saves but will provide the following:
0
Positive feedback yey!
Are there any plans for harvest handlers? I really want to code base-free but without harvest handlers then Ill have to modify BlockOre.
0
Well it adds the ability to easily add subtypes for blocks and items. It custom renderer which will allow overlays to be rendered on blocks (the same way the biome grass works.).
If you want to add a new metal to the game it will produce everything needed for that metal (ore, nuggets, ingots, ingot storage blocks) without adding more IDs.
Just read a bit here (Better Ores) and check the images which i posted in this forum as well.
0
Have you even looked at my API?
0
I saw that block intercepts where handled in the EntityPlayerSP class. If we don't want to modify the default class then we can just have a class that extends the EntityPlayerSP class.
[disappointed_rambling]
Has anyone even looked at the spoiler in my earlier post?
[/disappointed_rambling]
0
Has anyone working on MCForge actually used the MCP mod system?
0
Well my API does something like this. Didn't even see the discussion about this.
This image shows off using sand as a base texture.
The overlay ore texture can be changed to suit a texture pack.
The point of my API is to avoid having to learn how to do subtypes by oneself. Material types was just an example.
0
Depending on how modders want to use those blocks my API provides an intuitive way of adding block subtypes to a main type (e.g having step blocks as a main type and adding different materials for use like stone, wood, etc..)
My alloys mod adds in new ores with nuggets (see how Better Ores works to understand nuggets) which smelt into ingots which can be made into storage blocks (like iron and gold blocks). One ID is used to store any number of ore subtypes in it and another to have the storage blocks. As for the item IDs two are used (nugget and ingot). Subtypes can be classified by colour which is used during item rendering and block rendering. The custom ores are also coloured without requiring multiple textures for each ore.
0
0
I will not be using MCE as I will be converting my mod to use MCForge.
I have a version for 1.7.3 available in the meantime. It uses SAPI till i can get hooks for block intercepts into MCForge. Should I release it?
0
Swapping blocks in the blocklist is okay but will result in worlds which will fail to load correctly when going between updates of MC. Invalid block IDs are not loaded by vanilla MC and would result in no ores appearing on the map. However which block intercepts vanilla ores will still be available.
Might seem like an arbitrary point but I think its valid.
Another supporting statement is adding addition drops t blocks without having to replace blocks in the blocklist with custom created classes (e.g grass blocks dropping grass seeds as well as the default dirt block.)
0
Basically my mod changes the amount of drops from vanilla ores and also makes added ores have configurable drops. Overriding would only work in the latter case.
Unfortunately I am work most of the day so I might be able to come on IRC later (web client as others are blocked by university policy.)
0
I agree that MC Forge should not re-implement API's which are available. Obviously if a mod maker with an API which is needed (such as the block harvesting API in what ever flavour you like) does not want to join in the project we cannot force them to do so, however, if possible we can make then compatible. Since Modloader does quite a bit of core modding (chunk population, entity spawn lists, etc) I feel MC Forge does not need to re-implement the mature features. Adding textures for blocks and items is what I consider to be an immature feature of Modloader, Eloraam's multi-Tessellator code being the next stage of this feature.
Anyway back to coding :tongue.gif:
Intercept block harvest
Not sure if anyone on the project has ever used my mod (I get like 200 DL a month :sad.gif: :tongue.gif: ) but I was modifying the BlockOre class to accomplish the goal of my mod, adding custom ores without adding more block IDs. After seeing that SAPI had an intercept hook when harvesting a block I added the hook into my mod to eliminate the need to modify the BlockOre class. If we cannot get Shockah on board to integrate his API (@scokeev9 I am not saying we are using ToolUtils as a whole but ideally work out differences and come to a common standpoint) then I propose we add this feature to MC Forge.
Smeltable subtypes
smith_61's MCE had a Furnace API specifically for this. Basically it allows smelting of items with subtypes/damage (coloured wool, half steps are some examples). I added my own furnace to accoplish this for my mod as I did not want to edit too many vanilla classes. Can we also add this to MC Forge?
0
0