Did say i was going to do it. As i started to work down the list i
realized even though its hard to read its better this way. Still need to
test how much this impacts the system and if i should turn it into a
data base instead.
Well at least for those that actually have densities. Some of these
element are man made and don't really exist. So i assume there density
has never been measure or are not public knowledge yet. Either way i
have no use for most of this data so it doesn't bother me. The data i
need is the common elements the rest was just added to have a complete
periodic element list.
Once done this enum will be worth the time. However, its going to take a
lot of time to flush out all the information. As well i still need to
add math helpers to calculate all the formulas that go with these.
I might just merge this with chemElement enum when finished. However,
for now its a bit hard to work with just one. So i started to create a
version just for thermal properties. Main use for my mods will be
heating values.
Ctrl+v for the win. I honestly copied the data out of a csv file and
manually added the ( " , to each line. Honestly this was a stupid move
as i could code something to read and import that csv file. Though i'm
looking to create a code based version. I still need to at least add
density per element and then heating values for the ones i plan to use.
Plan is to include all elements from the periodic table with as much
information as possible per elements. This might get long so i might
want to consider constructing a data base that will be parsed per use.
That way only a few elements are loaded into memory instead of over 255.
I was going to just work on and release the coal gen as a self contained
generator. Instead i'm going to make it a 2+ part system. The system
must contain a heat produce, and heat collector. It can also include
block to help contain, move, and maintain the heat.
The way chicken bones does it is nice but this allows me to add more
complex and refined dependency download info. Especial since my mods can
normal run across several versions of mc. Eg 1.6, 1.6.2, 1.6.4
Though i will need to recode the depDownloader.class from scratch to
correctly manage this. As well create a way to ensure the MD5 matches up
correctly. Not sure how much it can change from sourceforge to my
desktop.
Forgot to correct this after i created a new package for java class that
were not just for minecraft.
As well fixed the issue with farmtech not building correctly
Changed it to actually use ISimplePacketReceiver instead of
TileEntityMachine prefab having a sub class to handle it. Shouldn't
really change anything but does reduce a little bit of code
The idea is to let the object being registered control all aspects of
how its registered. This started with the blocks adding config files,
disabling themselves, and loading their own tile entities. Now i'm
working on having the tile entities register their own renderers, and
have configs as well. Give that the registration is actually handled by
the ModObjectRegistry and the object just provided the data instead of
the mod class.
In some cases this will be needed especial when other mods work with
mine. I'll need to make a system so users can add item to the processor
black list.
Also added damage output to normal processors so that some items don't
return in a clean form. Cases are for planks, ingots, plates, and some
blocks. This is to set the way for salvager machines later down the
road. In which will cost a lot and take a lot of time. Over normal
processor salvaging that will mess up just about anything that goes into
it.
Removed the dependency on using the material enum as it was adding ores
that should not generate which was causing a lot of issues. So to solve
this the block has its own enum set of ores it will work with. However,
i still need to reset the ore generator
