There were several issues were i over looked how the tools worked. Main
one was canHarvest as i forgot the method and needed to use a forge
version to get it to work correctly. It not works though i'll need to
fine tune it some more.
Read wires.txt for notes on new wire design. As for network i'm going to
create a way to store multi-networks in a block to allow for more
advanced control.
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.
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
tried to use the solar panel for a test of the annotion system for
registering tileEntities and loading block based configs. However, my
code could no get the annotions for use. I will have to correct it and
retest it on another block.
Plan is to replace IExtraObjectInfo with annotations to be used in combo
with the new reflection based block registration system. Might try this
on a few more things and see were it goes.
Used reflection to create new block instances. This was done to prevent
disabled block from trying to take block IDs without doing a if
statement per block declaration. As well to make it a bit easier all
around to work with the system.
Also from Basic Components but they are just temporary to get things
rolling. I do not plan to create release with this code. Most of it will
rewritten to support my collective block designs.
based on Old Basic Component machines. I do plan to rework every aspect
but am trying to maintain that same fill as the old machines. This is
why some of the code is copied so that the handling, and slot IDs match
up.
The item handler for FluidHelper fluid item interaction now returns true
only if the itemStack changed. This way right click with non-fluid
container items will work.
meta for recipes that had no defined meta was getting set to max meta
value. This catches on that and sets its to zero. Later after i work out
other bugs i'll flip this to being random to allow for more complex
salvaging.
unused and when it was it caused more errors that is was worth. Refresh
should be handled by world triggers anyways. Eg. blocks placed next to
network blocks.
Yes the fluid code is based off of Build Craft fluid render and has been
for a while. This is not a copy though as the code is not 100%
buildcraft and has been modified to meet my use of the code.
Didn't noticed that these needed called inorder to function correctly.
Though i guess the UE loader mod would have covered this for me its
better to be safe than sorry.
Instead of ints i've changed it to string IDs too allow for more defined
ids per tile. Should remove any issues with super tiles using the same
packet ID as the tiles that extend them.
This will be the first block of many to have its own config file. The
idea when i created the BlockRegistry was to also implement a system to
allow blocks to declare custom configs. In other words allowing them to
define settings that can easily be linked to the block without large
config files.
Idea is to create a flex-able system to handle block registration,
settings, features, and setup. This include calling methods to register
block ore names, tile entities, and extra settings configuration files.
This will be connected to a more advanced config, id, and a few other
handlers. This way all block/items will be in sync when it comes to
creations, and handling.
The ammount of files in this project are getting out of hand tbh. I will
need to sit down later and sort them all out and remove any that are not
needed.
Mainly just copied the methods but its needed due to future changes to
these methods that were copied. Mainly the collision methods will need
to be redone when the logic is finished for lay down wires.
