stupid merge conflicts. This was originally with the ICBM api commit but
something fucked up. Anyways this should prevent future errors when
.java files decide that binaries have changed.
This is more of me starting back up on global access lists for sentry
guns and chests. The idea right now is to create a system like bukkit
plugin permissions has. In which a player can create a group, assign
command node, and then assign players. As well can assign direct command
nodes to the player user instance. These groups will be managed from a
GUI that can be access anytime. The data will be saved to a NBT file in
the map, and can be access by any object. Objects will not save a copy
of the list but will request it to be loaded.
Not sure why but i decided to work on these. I know i'll end up using
them but not sure why i decided to make them now.
Converted UE Eletrical Display into two separate classes for my use.
EletricUnit enum, and MeticUnit enum.
Added enums for force, pressure, temperature. Force is filled out but
not completed. As well each of these are missing more units but the main
ones are there.
Tbh i'm done for now as i need to think of a fast way to do this.
Possibly i might just want to consider only filling in the elements i
plan to use. Eg Fe, Ag, Au
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.
