Was doing the connection checks wrong. Now its check for meta data if
the pipe uses the same class file for connections. Its should connection
to any generic pipe of its color and iron pipes. This should allow for
unique pipe networks for generic liquid types. This however will not
allow for a set liquid type filtering or transport.
Also in an earlier push i changed generic pipes to only move 1 bucket a
request but 3 request for non-generic pipes a request.
pipe crafting is now a set recipe instead of shapeless. Though with this
change you can now use any pipe color inter mixed with a dye to get 4
pipes of that color back. As well sticking a pipe in the crafting grid
will result in an uncolored pipe back.
There is however an odd error with old pipes updating to the new system.
Since the new pipes are an extend of the old pipes they may thing
themselves as old pipes. breaking them and replacing solves this isssue
still need to test and debug including create new textures for specific
pipes. Recipes are also still need for new items as well as reversed
color crafting
Just need to add renders too the new pipes and change the textures off
the old ones. I might also need to do some testing since i changed a few
methods.
Not sure if i want to work on this right now as its just a bonus
addition to FluidMech a this point. Though it badly needs overhauled to
include its own pathfinder. The rods need to work as one rod using the
same pos, spin speed, Force, etc. As well math needs to be added to calc
force correctly
Going to copy Electrical Expantion a bit and add a similiar system for
version #s and info file management. This way version # match up better
between the 3+ things that use it.
Tested and it looks like it works as well though i have to give
aidancbrandy(IDK github name) some credit for giving me the ideal
earlier to remove non-source Fluid Block each update. It will the
collection sorter lets the drain method over power water's ability to
refill the area.
This should if done correctly place the closest and lowest Y fill-able
blocks at the top of the list so they get fill first. So far in testing
it looked like it worked as the water bubble created expanded evenly
outward instead of more in one direction.
can't recall all the work i've done since last commit. However, i've
test and improve the path finder and how its used by the drain. It now
works 100% but need more improvement. Especial the draining part as
source will keep refilling if not drained right
This path finder no longer depends on Calc's PathFinder to function.
however it is derived from his work so he still gets credit.
The new pathfinder works about the same as calc's except instead of
trying to find a path its trying to find all resources along the path. I
still need to improve this to have a dumped down version of A* so that
i'm filling the closest blocks first and draining the furthest block
first.
This should? Fix the issue with the drain trying to fill outside of the
possible path bounds. What is is doing is finding a bath from the drain
to the next Y level change. If it fails to find a path the yFillStart
doesn't increase to the next level.
