The Meaning of Life, the Universe, and Everything.
Join Date:
5/31/2011
Posts:
314
Minecraft:
Electrobob99
Member Details
Even with what scoceev9 said about this, I still think this Is a great idea and is much easier to download than having to download separate api's. And from what he said, Modders May use only a few parts of this api, but it is better to have more then one part anyway, so then the modders have the choice to use them all if they want too. I do have my doubts, but If I was a Modder with an awesome mod I would just go with the flow and at the very least try this out. I mean heck what is there to lose anyway. Besides sooner or later people will end up accepting this. If it works like we all hope it will. Like I do. I know when all the mods that will be using this are updated to use it. I will download some if not all of them and see for myself if they are compatible or incompatible, and if they are compatible I will post a vid on youtube to show that some if not all of them work together. If they do I will have so much stuff in it. :-)
Hmmm... How would everyone feel about allowing ScotTools API as the tool compatibility fix, rather than the practically feature-less fix you have used (opinion! not trying to offend anyone...) when this API becomes more stable and usable (and modified Minecraft files for MCP are added, since it doesn't seem like they are included in the source downloads), and when more modders convert their mods to use this API? I still am having difficulty deciding if I want to just lose my 28,000 downloads/month from ScotTools (that's a little more than $40). That would really cut into my bills and food money... =/
Then again I want to help (and I do NOT want ToolUtils implemented, no offense to Shockah, I just don't like ToolUtils).
I will spend some time pondering the subject of this matter and may come up with a solid statement some time later, or I may just remain iffy for a while. We'll see...
Hmmm... How would everyone feel about allowing ScotTools API as the tool compatibility fix, rather than the practically feature-less fix you have used (opinion! not trying to offend anyone...) when this API becomes more stable and usable (and modified Minecraft files for MCP are added, since it doesn't seem like they are included in the source downloads), and when more modders convert their mods to use this API? I still am having difficulty deciding if I want to just lose my 28,000 downloads/month from ScotTools (that's a little more than $40). That would really cut into my bills and food money... =/
Then again I want to help (and I do NOT want ToolUtils implemented, no offense to Shockah, I just don't like ToolUtils).
I will spend some time pondering the subject of this matter and may come up with a solid statement some time later, or I may just remain iffy for a while. We'll see...
I haven't looked at your tools API, so I can't give any firm answers, but we'll seriously look at it, if you feel like contributing it.
EDIT: I took a look through the SSP API source version on your forum thread, and with some modifications, we could certainly adapt this into MinecraftForge.
OK, let's get IC (67 BlockIDs, 109 ItemIDs), BTW (30 BlockIDs, 27 ItemIDs), Buildcraft (19 BlockIDs, 8 ItemIDs) and Aether (113 IDs) together in one file.
Each of these mods (except Buildcraft) already has clusterf**k-config, and you wish to MERGE THEM.
Because finding the empty slots for all of those blocks can be a nightmare when they are all located on 4+ different props files, if they are all in one, it's just a matter of going down the line numerically and finding the ones that conflict and moving it to an obviously open one.
Though even that last part seems unnecessary since Space Toad said that it's gaining BuildCraft's autoIDing mechanic.
In any case my point is it's easier to organize, compare, and adjust one file of block IDs rather then 4 or more.
I haven't looked at your tools API, so I can't give any firm answers, but we'll seriously look at it, if you feel like contributing it.
EDIT: I took a look through the SSP API source version on your forum thread, and with some modifications, we could certainly adapt this into MinecraftForge.
What 'modifications' could this mod need? It's got everything needed, and more... I don't know of anything that needs changing/improving/added/etc. Did you have some plans/ideas or something?
What 'modifications' could this mod need? It's got everything needed, and more... I don't know of anything that needs changing/improving/added/etc. Did you have some plans/ideas or something?
Just a few small technical tweaks under the hood, nothing major. Swapping out the use of 6 different arrays for a more generic data structure, for example.
Just a few small technical tweaks under the hood, nothing major. Swapping out the use of 6 different arrays for a more generic data structure, for example.
Oh yeah. Using multiple ArrayLists was the easiest method of permanently saving the blocks' harvesting level that I could manage at the time XD. Took me a few hours just to come up with a way to even do that... I didn't really know what I was doing at the time since I only knew normal Minecraft Java. XD
I was a little surprised that saving the blocks in ArrayLists and then parsing through them didn't cause any twitch or anything when mining. Lol
EDIT: Using the CraftingManager as a template wasn't a good way to start out, I'll just say that. XD
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?
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?
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.
The second makes more sense to me, if it's not already possible.
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.)
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.)
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.
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.)
That's unfortunately not an option. I can speak for BuildCraft, but I'm assuming it would be the same with others. With the next development, BuildCraft will require modifications in the base Minecraft classes, and I'm afraid that will grow. There's too many things that are just not possible without it. So this is fact, with or without the Forge, the next versions of BC are going to get a growing set of incompatibilities.
It's very much the same with RedPower. The list of changes to the base classes I needed to manage the most recent update would have been quite problematic without MinecraftForge.
Still, RedPower gets along fine with Buildcraft 2.0.1, as I understand it. I've been so busy coding that I haven't had a chance to try, but still.
The hic is the Fd.class contain the lag spike of dead ...It's the auto-save ....
The autosave is set to 4 sec ...this can be a problem for medium to big worlds ...Cause saving 20 mb and more each 4 sec cause the spike of dead ...
The guy of Optimine founded the problem and just have add one line in the Fd.class ...
It's something like autosave=6000 ....Ask albaka he know what it is ...he integrated this to Industrial craft ...
For now the autosave is set at 40 ...So it's not a mod or a big deal ...it's just adding one line of code ... to make a little fix for everyone .
I have 2 ssd in raid 0 and i still have a spike when the auto-save ..do save.
Something else I've looked at doing that would require base class edits and I believe could be done relatively easily the way you have your hooks designed - adding items to what the dispenser can "fire", ala arrows and eggs, instead of just chuck out the front. Adding an IDispensable or something with a function that gets called when the item is going to be launched would be great. Feel free to tell me I'm wrong and this is actually horribly difficult.
Something else I've looked at doing that would require base class edits and I believe could be done relatively easily the way you have your hooks designed - adding items to what the dispenser can "fire", ala arrows and eggs, instead of just chuck out the front. Adding an IDispensable or something with a function that gets called when the item is going to be launched would be great. Feel free to tell me I'm wrong and this is actually horribly difficult.
ModLoader already seems to provide that hook. Just add a DispenseEntity to your mod class.
Just a question.. With the item sprite fix, did you just make an instance check on the item in the ItemRenderer and RenderItem classes and used an interface with a method that gets the item sprite sheet path like I did with ItemSpriteAPI? Just wondering, because if that's all you've done, maybe you could rename/use the files from my ItemSpriteAPI since I already know of quite a few modders who use it, and it would be one way to help ease the transition over to this API.
Arcane Aerotech - Custom Modded Minecraft MineFreaks - Unmodded Minecraft
Aerotech Networks - Space Engineers/Team Fortress 2/Gmod
Occasional Game Nights
Then again I want to help (and I do NOT want ToolUtils implemented, no offense to Shockah, I just don't like ToolUtils).
I will spend some time pondering the subject of this matter and may come up with a solid statement some time later, or I may just remain iffy for a while. We'll see...
I haven't looked at your tools API, so I can't give any firm answers, but we'll seriously look at it, if you feel like contributing it.
EDIT: I took a look through the SSP API source version on your forum thread, and with some modifications, we could certainly adapt this into MinecraftForge.
Because finding the empty slots for all of those blocks can be a nightmare when they are all located on 4+ different props files, if they are all in one, it's just a matter of going down the line numerically and finding the ones that conflict and moving it to an obviously open one.
Though even that last part seems unnecessary since Space Toad said that it's gaining BuildCraft's autoIDing mechanic.
In any case my point is it's easier to organize, compare, and adjust one file of block IDs rather then 4 or more.
What 'modifications' could this mod need? It's got everything needed, and more... I don't know of anything that needs changing/improving/added/etc. Did you have some plans/ideas or something?
Just a few small technical tweaks under the hood, nothing major. Swapping out the use of 6 different arrays for a more generic data structure, for example.
Oh yeah. Using multiple ArrayLists was the easiest method of permanently saving the blocks' harvesting level that I could manage at the time XD. Took me a few hours just to come up with a way to even do that... I didn't really know what I was doing at the time since I only knew normal Minecraft Java. XD
I was a little surprised that saving the blocks in ArrayLists and then parsing through them didn't cause any twitch or anything when mining. Lol
EDIT: Using the CraftingManager as a template wasn't a good way to start out, I'll just say that. XD
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?
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.
The second makes more sense to me, if it's not already possible.
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.)
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.)
It's very much the same with RedPower. The list of changes to the base classes I needed to manage the most recent update would have been quite problematic without MinecraftForge.
Still, RedPower gets along fine with Buildcraft 2.0.1, as I understand it. I've been so busy coding that I haven't had a chance to try, but still.
The hic is the Fd.class contain the lag spike of dead ...It's the auto-save ....
The autosave is set to 4 sec ...this can be a problem for medium to big worlds ...Cause saving 20 mb and more each 4 sec cause the spike of dead ...
The guy of Optimine founded the problem and just have add one line in the Fd.class ...
It's something like autosave=6000 ....Ask albaka he know what it is ...he integrated this to Industrial craft ...
For now the autosave is set at 40 ...So it's not a mod or a big deal ...it's just adding one line of code ... to make a little fix for everyone .
I have 2 ssd in raid 0 and i still have a spike when the auto-save ..do save.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAlso, I'd love to see ScotTools merged in.
INFORMATION WANTS TO BE WRONG
ModLoader already seems to provide that hook. Just add a DispenseEntity to your mod class.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumHuh, never knew that. Thanks!
INFORMATION WANTS TO BE WRONG