There's no helper function for FusionRecipes.Material for Ore Dictionary. The fusionFurnaceRecipes one will not access the sub class so to use the "Material.of" function to allow Ore Dictionary FusionRecipes.Material must be imported. I'm not sure if this was intended.
Also I've noticed that other mods copper and tin can't make bronze in the fusion furnace as they are not using the Fusion Recipes Ore Dictionary supporting Material function. PR request fixing that.
Updated the main page and added some tutorials to the Github wiki, which are linked in the main post. I will gradually go through using all of the API classes.
So I've gotten the (hopefully) latest SimpleCore code down from your GitHub and have been staring at it during slow times today. I already have a few questions:
Why do you initialize the mod info programmatically instead of using a mcmod.info file? Is there some advantage to doing it this way?
Where do you register armor renderers? I can't see any place that is done. (By this I mean the call to RenderingRegistry.addNewArmourRendererPrefix())
What about milk buckets? Or other liquids added by mods? How extensible is SimpleBucket?
More questions to come as I actually get to porting code.
2. RenderingRegistry.addNewArmourRendererPrefix() is actually a redundant feature in the API. By overriding the getArmorTexture method in the Armor class, you don't need that constant anymore.
Why do you initialize the mod info programmatically instead of using a mcmod.info file? Is there some advantage to doing it this way?
Because I have multiple mods/plugins, if I were to use the mcmod.info file, I would have to include all the info in the same mcmod.info file. This would be fine, except for some reason it wasn't working for all the plugins, despite the info and format being correct. Another reason is that it allows me to keep the version number for the mod the same as the version number in the mcmod.info file, and I only have to change one variable, rather than 2. Previously, I always forgot to update the mcmod.info files. Doing it programmatically simplifies this.
Where do you register armor renderers? I can't see any place that is done. (By this I mean the call to RenderingRegistry.addNewArmourRendererPrefix())
As zot201 said, RenderingRegistry.addNewArmourRendererPrefix() is redundant now, so there's no need for the armor renderer integers. However, the ItemArmor constructor still requires a renderer integer, which is why I have just been passing it an uninitialized integer. Now that you mention it, I'll add to my to-do list to remove the renderer int from the SimpleArmor constructor, and I'll just pass some integer through to ItemArmor.
What about milk buckets? Or other liquids added by mods? How extensible is SimpleBucket?
At the moment, SimpleBucket is not very extensible at all. I AM going to re-do it and make it work with other liquids. The reason it's not extensible at the moment is because it's a large amount of work just for some buckets the vanilla bucket code makes it a real pain to account for all possibilities, and it has the potential to get very messy, but it's definitely do-able. So I'll get to work on that too.
More things for you--your TabHelper doesn't have a helper function for returning the "general" or "other" tabs. In my opinion, the helper options should fall back to the "general" tab if a specific "materials"/"blocks"/etc tab isn't found, for those of us who just use one tab for our mods. Currently, TabHelper functions give up and return the vanilla MInecraft tabs if they can't find the specific one in the ContentRegistry. "General" tabs are completely ignored.
In the meantime, I am using the classic function to set tabs.
I am finding your organization of SimpleOres useful, and I'm tearing apart and re-writing the first mod to be ported (which is Simple Tungsten) to use a similar organization. Re-factoring into Content, Settings, etc classes makes for much less clutter, and I'm using the opportunity to make things much more configurable, a la SimpleOres.
However, I couldn't find the part where SimpleOres handles customized higher (and lower) dimension generation. It seems hard-coded to only generate most ores in the Overworld and onyx in the Nether, ignoring additional dimensions.
p.s. You do need milk buckets, though, since they are a vanilla bucket-able liquid.
More things for you--your TabHelper doesn't have a helper function for returning the "general" or "other" tabs. In my opinion, the helper options should fall back to the "general" tab if a specific "materials"/"blocks"/etc tab isn't found, for those of us who just use one tab for our mods. Currently, TabHelper functions give up and return the vanilla MInecraft tabs if they can't find the specific one in the ContentRegistry. "General" tabs are completely ignored.
In the meantime, I am using the classic function to set tabs.
I am finding your organization of SimpleOres useful, and I'm tearing apart and re-writing the first mod to be ported (which is Simple Tungsten) to use a similar organization. Re-factoring into Content, Settings, etc classes makes for much less clutter, and I'm using the opportunity to make things much more configurable, a la SimpleOres.
However, I couldn't find the part where SimpleOres handles customized higher (and lower) dimension generation. It seems hard-coded to only generate most ores in the Overworld and onyx in the Nether, ignoring additional dimensions.
p.s. You do need milk buckets, though, since they are a vanilla bucket-able liquid.
Thanks, I've added that bit about tabs to my to-do.
As for higher generation, it's part of the API now, so you don't have to have SimpleOres installed if you, say, want to generate Netherrocks in a different dimension, you just need the API. See alexndr.api.helpers.game.CustomGen.java, that's where the higher generation is handled now. It's not extensible, and so probably doesn't belong in an API, but it's better than creating a new plugin just for it.
And yes, moving things to Content, Settings, Recipes, etc. is much easier. It also allows it to be much neater in the case of, for example, Fusion, where I have separate separate content classes for those mods that add alloys.
Okay, so I've been working on making SimpleBucket more extensible, and I'm fairly confident I've come up with a good way to do it. It SHOULD support any liquid (well, technically any block, but that block has to be of a material specified as a liquid).
As I don't have Buildcraft installed in my development environment, I can't test this myself. Buckets are created pretty much as they were previously, except now you also need to create a SimpleBucketType, in which you can specify variants. I'll try to get the source code up in the next few days. I'm still working on some other things, such as improving TabHelper, but there should be an update inbound in the next week or so.
I just have to tell you, the new organization is making it *much* easier to port/update akkamaddi's Additions to the new SimpleCore API. Working everything out with the first one (Simple Tungsten) was tedious and time-consuming, but the re-organization is really paying off in speeding up additional upgrades. I just finished re-coding Sterling and Black in less than two days.
Thanks; the new code layout is really helpful when it comes to making code maintenance easier.
I just have to tell you, the new organization is making it *much* easier to port/update akkamaddi's Additions to the new SimpleCore API. Working everything out with the first one (Simple Tungsten) was tedious and time-consuming, but the re-organization is really paying off in speeding up additional upgrades. I just finished re-coding Sterling and Black in less than two days.
Thanks; the new code layout is really helpful when it comes to making code maintenance easier.
Yeah, organisation helps more than one would expect. I HAD started to port Sterling and Black myself, however it was mostly just an example of how you guys could port your own. I stopped working on that though, and started working properly on Aesthetics and improving the API, so I'll probably just scrap it.
Don't forget, if you have any questions about the API, or any requests, feel free to ask. The API is mostly about making it as easy as possible for you all to create plugins, with as little work as possible. If it means I have to add 1 new API class to save you from creating 3, then it's worth while and I really don't mind.
As for progress, I should be able to get the new API build up (including wherever Aesthetics is at at that time) sometime this week. It hasn't changed too much, but there was a change to the ContentRegistry content types, they now use enums rather than strings. If you're using the existing API content classes that register blocks/items for you, it won't effect you. But anything you are manually registering with ContentRegistry will need to be changed. It's literally just replacing a string with an enum reference, it's not a lot of work.
Also, for those who have used it, what do you guys think of the API? I'd really like some feedback, as no one has really offered any do you think I've gone overboard with the ContentRegistry? Do you think it makes things easier or harder? Have I included enough in the API? Have I included too much? Any feedback is appreciated, as long as it's constructive I'm no software engineer, so I'm certainly not a pro at this XD
I'm working on creating a new XML Configuration and adding it the the API, as I find the Forge one to be rather messy when there's lots of settings to add (which there is with SimpleOres). It also has the nice side effect of allowing me to easily create a small java application to edit the config using a GUI. I obviously have no timeframe on that at this stage, as my Java Swing skills are limited, but I have been steadily working towards it.
For anyone interested, here's how it works:
Firstly, you create a new ConfigEntry instance. These are class files that store data relevant to that thing, such as ConfigBlock, which stores settings related to blocks, like hardness, resistance, harvest level, spawnrate, etc. These settings are themselves stored as ConfigValues, which allow for current, default, minimum and maximum allowed allowed values of this setting. For example, the maximum spawn height of Copper might have a ConfigValue that looks like this:
CurrentValue = 58 (modified by user)
DefaultValue = 60
MinimumValue = 0 (can't spawn below the minimum world height)
MaximumValue = 255 (can't spawn above the maximum world height)
The ConfigEntries are then saved to an XML settings/config file, which would look a bit like this: http://pastebin.com/69n33T0N. All the comments are generated automatically thanks to those handy ConfigValue settings described above.
When you want to access the settings, you call the ConfigEntry instance, then the setting you want. For example, when setting the hardness of copper ore:
copper_ore = new SimpleBlock(Material.rock).modId("simpleores").setHardness(Settings.copperOreEntry.getHardness()).setUnlocalizedName("copper_ore");<br>
I'll try and keep you guys updated, let me know if you have any suggestions I still have a lot to add, but this looks really promising.
EDIT: Completed a lot more of the new config system, it now generates a config that looks like this: http://pastebin.com/raw.php?i=yeznEDzZ. Still need to do toggles and other stuff.
Note: in the latest recommended Forge build (1291), customCraftingMaterial is deprecated; it's being replaced with SetRepairItem(), which takes ItemStack args. I'm guessing this is to allow meta-data items to be used in crafting repairs? (e.g. dyes).
I am rebuilding against Forge 1291. Does anyone remember where the setting is in Eclipse to make it not tell me about all the warnings in a project? I don't want the ignorable warnings from SimpleCore cluttering up my warnings list.
Update 20/03/2015
What was updated: SimpleCore API v1.1.0, SimpleOres 2 v1.6.0, Fusion v1.6.0, Netherrocks v1.3.0, Aesthetics v1.1.0
SimpleCore API v1.1.0 Changes:
Added a new XML Config system to the API.
The UpdateChecker now checks for updates for each mod in its own thread, elimination the game-halting that was happening with the previous system.
SimpleOres 2 v1.6.0 Changes:
Now uses the new XML Config system included in SimpleCore API.
Fusion v1.5.3 Changes:
Now uses the new XML Config system included in SimpleCore API.
Netherrocks v1.2.3 Changes:
Now uses the new XML Config system included in SimpleCore API.
Mining an ore with the Fyrite Pickaxe now drops the smelting experience associated with that ore too.
Aesthetics v1.0.0 Changes:
Now uses the new XML Config system included in SimpleCore API.
As always, let me know if you find any bugs/issues.
Also, for now the new XML config system is very sparsely documented. I plan to refine and document it over the next few weeks, assuming there's no immediate issues with the latest update. I apologise for the lack of documentation for it, however it should be fairly straight forward to work out by following how the plugins use it.
Of course, if anyone has any questions regarding the latest update, I'm happy to answer them.
Thanks guys
I've mentioned this elsewhere, but last month I finally finished porting all of akkamaddi's Additions not claimed by TheOldOne822 to the new SimpleCore API. Also I've done a fair amount of work in making the alloys more ore-dictionary friendly, so people can use, for example, TE copper in arsenide bronze, or ElectriCraft Silver in sterling silver, assuming the other mods properly ore-dictify things.
Sooo... looking at either adding more mod compatibility stuff (alloy recipes for Ender IO/ MFR compatibility/Thaumcraft aspects/ whatever..) or starting to port stuff to 1.8. Do you plan to port Simple Core et al to 1.8? If not, I won't worry about it and go work on porting my other stuff and akkamaddi's Ashenwheat to 1.8, and work on mod compatibility issues instead.
Note: I do have Thaumcraft aspects listed in a modtweaker script for the akkamaddi materials; I just don't have them added yet via the TC API.
I will be porting to 1.8, however it's unlikely to occur before I complete my exams for this semester. So that puts it at about the end of June, unfortunately. At the moment I'm too busy with university work to even open Eclipse :S
github link for SO 1.3.2
True that I forgot about that. The only issue with that though is my unreliable GitHub committing
Also I've noticed that other mods copper and tin can't make bronze in the fusion furnace as they are not using the Fusion Recipes Ore Dictionary supporting Material function. PR request fixing that.
--<@ My collection of Actually Somewhat Useful Minecraft Modding Links @>--
My Mods: Sinhika's Bark
Ported Mods: akkamaddi's Additions, akkamaddi's Ashenwheat, AleXndrTheGr8st's SimpleCore/SimpleOres/etc
Other Stuff: old/obsolete Ruins templates, updated to Ruins 1.7.10
Others questions may have to be answered by Alex.
Because I have multiple mods/plugins, if I were to use the mcmod.info file, I would have to include all the info in the same mcmod.info file. This would be fine, except for some reason it wasn't working for all the plugins, despite the info and format being correct. Another reason is that it allows me to keep the version number for the mod the same as the version number in the mcmod.info file, and I only have to change one variable, rather than 2. Previously, I always forgot to update the mcmod.info files. Doing it programmatically simplifies this.
As zot201 said, RenderingRegistry.addNewArmourRendererPrefix() is redundant now, so there's no need for the armor renderer integers. However, the ItemArmor constructor still requires a renderer integer, which is why I have just been passing it an uninitialized integer. Now that you mention it, I'll add to my to-do list to remove the renderer int from the SimpleArmor constructor, and I'll just pass some integer through to ItemArmor.
At the moment, SimpleBucket is not very extensible at all. I AM going to re-do it and make it work with other liquids. The reason it's not extensible at the moment is because it's a large amount of work just for some buckets the vanilla bucket code makes it a real pain to account for all possibilities, and it has the potential to get very messy, but it's definitely do-able. So I'll get to work on that too.
In the meantime, I am using the classic function to set tabs.
I am finding your organization of SimpleOres useful, and I'm tearing apart and re-writing the first mod to be ported (which is Simple Tungsten) to use a similar organization. Re-factoring into Content, Settings, etc classes makes for much less clutter, and I'm using the opportunity to make things much more configurable, a la SimpleOres.
However, I couldn't find the part where SimpleOres handles customized higher (and lower) dimension generation. It seems hard-coded to only generate most ores in the Overworld and onyx in the Nether, ignoring additional dimensions.
p.s. You do need milk buckets, though, since they are a vanilla bucket-able liquid.
--<@ My collection of Actually Somewhat Useful Minecraft Modding Links @>--
My Mods: Sinhika's Bark
Ported Mods: akkamaddi's Additions, akkamaddi's Ashenwheat, AleXndrTheGr8st's SimpleCore/SimpleOres/etc
Other Stuff: old/obsolete Ruins templates, updated to Ruins 1.7.10
Thanks, I've added that bit about tabs to my to-do.
As for higher generation, it's part of the API now, so you don't have to have SimpleOres installed if you, say, want to generate Netherrocks in a different dimension, you just need the API. See alexndr.api.helpers.game.CustomGen.java, that's where the higher generation is handled now. It's not extensible, and so probably doesn't belong in an API, but it's better than creating a new plugin just for it.
And yes, moving things to Content, Settings, Recipes, etc. is much easier. It also allows it to be much neater in the case of, for example, Fusion, where I have separate separate content classes for those mods that add alloys.
As I don't have Buildcraft installed in my development environment, I can't test this myself. Buckets are created pretty much as they were previously, except now you also need to create a SimpleBucketType, in which you can specify variants. I'll try to get the source code up in the next few days. I'm still working on some other things, such as improving TabHelper, but there should be an update inbound in the next week or so.
Thanks; the new code layout is really helpful when it comes to making code maintenance easier.
--<@ My collection of Actually Somewhat Useful Minecraft Modding Links @>--
My Mods: Sinhika's Bark
Ported Mods: akkamaddi's Additions, akkamaddi's Ashenwheat, AleXndrTheGr8st's SimpleCore/SimpleOres/etc
Other Stuff: old/obsolete Ruins templates, updated to Ruins 1.7.10
Yeah, organisation helps more than one would expect. I HAD started to port Sterling and Black myself, however it was mostly just an example of how you guys could port your own. I stopped working on that though, and started working properly on Aesthetics and improving the API, so I'll probably just scrap it.
Don't forget, if you have any questions about the API, or any requests, feel free to ask. The API is mostly about making it as easy as possible for you all to create plugins, with as little work as possible. If it means I have to add 1 new API class to save you from creating 3, then it's worth while and I really don't mind.
As for progress, I should be able to get the new API build up (including wherever Aesthetics is at at that time) sometime this week. It hasn't changed too much, but there was a change to the ContentRegistry content types, they now use enums rather than strings. If you're using the existing API content classes that register blocks/items for you, it won't effect you. But anything you are manually registering with ContentRegistry will need to be changed. It's literally just replacing a string with an enum reference, it's not a lot of work.
Also, for those who have used it, what do you guys think of the API? I'd really like some feedback, as no one has really offered any do you think I've gone overboard with the ContentRegistry? Do you think it makes things easier or harder? Have I included enough in the API? Have I included too much? Any feedback is appreciated, as long as it's constructive I'm no software engineer, so I'm certainly not a pro at this XD
Thanks all
What was updated: SimpleCore API v1.0.3, SimpleOres 2 v1.5.2, Fusion v1.5.2 Netherrocks v1.2.2, Aesthetics v1.0.0
SimpleCore API v1.0.3 Changes:
Have a play with SimpleBucket, it should now be considerably more extensible.
As always, let me know if you find any bugs/issues.
For anyone interested, here's how it works:
When you want to access the settings, you call the ConfigEntry instance, then the setting you want. For example, when setting the hardness of copper ore:
I'll try and keep you guys updated, let me know if you have any suggestions I still have a lot to add, but this looks really promising.
EDIT: Completed a lot more of the new config system, it now generates a config that looks like this: http://pastebin.com/raw.php?i=yeznEDzZ. Still need to do toggles and other stuff.
I am rebuilding against Forge 1291. Does anyone remember where the setting is in Eclipse to make it not tell me about all the warnings in a project? I don't want the ignorable warnings from SimpleCore cluttering up my warnings list.
--<@ My collection of Actually Somewhat Useful Minecraft Modding Links @>--
My Mods: Sinhika's Bark
Ported Mods: akkamaddi's Additions, akkamaddi's Ashenwheat, AleXndrTheGr8st's SimpleCore/SimpleOres/etc
Other Stuff: old/obsolete Ruins templates, updated to Ruins 1.7.10
Also, for now the new XML config system is very sparsely documented. I plan to refine and document it over the next few weeks, assuming there's no immediate issues with the latest update. I apologise for the lack of documentation for it, however it should be fairly straight forward to work out by following how the plugins use it.
Of course, if anyone has any questions regarding the latest update, I'm happy to answer them.
Thanks guys
I've mentioned this elsewhere, but last month I finally finished porting all of akkamaddi's Additions not claimed by TheOldOne822 to the new SimpleCore API. Also I've done a fair amount of work in making the alloys more ore-dictionary friendly, so people can use, for example, TE copper in arsenide bronze, or ElectriCraft Silver in sterling silver, assuming the other mods properly ore-dictify things.
Sooo... looking at either adding more mod compatibility stuff (alloy recipes for Ender IO/ MFR compatibility/Thaumcraft aspects/ whatever..) or starting to port stuff to 1.8. Do you plan to port Simple Core et al to 1.8? If not, I won't worry about it and go work on porting my other stuff and akkamaddi's Ashenwheat to 1.8, and work on mod compatibility issues instead.
Note: I do have Thaumcraft aspects listed in a modtweaker script for the akkamaddi materials; I just don't have them added yet via the TC API.
--<@ My collection of Actually Somewhat Useful Minecraft Modding Links @>--
My Mods: Sinhika's Bark
Ported Mods: akkamaddi's Additions, akkamaddi's Ashenwheat, AleXndrTheGr8st's SimpleCore/SimpleOres/etc
Other Stuff: old/obsolete Ruins templates, updated to Ruins 1.7.10
I will be porting to 1.8, however it's unlikely to occur before I complete my exams for this semester. So that puts it at about the end of June, unfortunately. At the moment I'm too busy with university work to even open Eclipse :S