The Daizuli Pipe is similar to a Iron Pipe, except it only routes
matching colored itemstacks that have been painted by a Lapis Pipe.
The color can be set via Gate Action or via shift-click with a Wrench.
This pipe paints passing items pretty colors.
TODO:
Add support to Diamond Pipe for painted items.
Add actions to set the Pipe color.
NOTES:
This required way more changes to the Pipe code that it should have.
Moved most of the Gate logic out of Pipe and into Gate. Expect some NPEs
on pipe.gate.
Converted the Trigger/Action API to key off of unique Strings instead of
IDs. Legacy conversion code implemented as well so it shouldn't affect
worlds.
Simplified Trigger/Action Icon functions. No more indexes.
More busy work is needed to convert the existing Triggers to the new
code.
Mainly just cleaned up the code and replaced the TreeSets with Deques.
Also made it so the pump will only keep the pumping the same type of
liquid it started on. If you wish to reset it to pump any liquid hit
with a wrench and the next liquid it pumps will be the new filter.
This doesn't control items passing between pipes, only a condition for a
PipedItem to prevent itself exiting the network in specific places.
This modification allows BC to have more advanced sinking conditions
(eg: the discussion about coloured pipes/items)
Logistics pipes currently modifies something via reflection to prevent
it's liquid packets from being sunk to standard IInventories.
PipeLogic is now only used by Iron and Wooden pipes. All other pipes use
the empty PipeLogic() class.
Pipe connections are now handled by the new PipeConnectionBans class.
Added a alternative payload system for update packets that uses data
streams instead of arrays. Note: It is not compatible with
@TileNetworkData so you will have to handle all the data yourself.
Also added a TankManager class to contain commonly needed code for
tanks: Serialization, TankInfo, Network Data, etc...
The Refinery still needs a fair bit of work, but its mostly limited to
the GUI filter code. That needs a complete rewrite of some kind since
Fluids aren't items and can't be rendered as such.
Some significant hurdles remain to be overcome in regard to how the
BlueprintBuilder interacts with EntityRobot.
Also, rotation and builder positioning is a massive headache that still
needs to be tackled.
Killed Engine class, merged into TileEngine and subclasses.
Converted to Forge rotation API.
Split heat from stored energy and set proper temp bounds.
Rewrote IronEngineCoolant API, changed to degree based temp reductions
(its 0.0025 times the previous values). Added support for solid coolants
(they have to melt into a liquid coolant, like Ice to Water).
There is a commented out alternative implementation for constant power
output instead of pulsed.
And fixed a issue with the PowerProvider casting objects to TileEntities
that aren't TileEntities. Fixed by adding a getWorldObj() function to
IPowerReceptor.
PowerFrameWork is gone.
PowerProvider is final.
Can have multiple PowerProviders (one for each block side).
PowerProviders can either accept power from pipes or they can't, defined
in constructor.
Removed a bunch of excess code that just cluttered the API.
Its now restricted to Wooden Power pipes.
Before:
The trigger was useless because it was triggering off the powerQuery
array which was always true so long as there was any device on the
network requesting power. This made it rather useless for scaling
production to demand.
After:
It now triggers whenever the Wooden Power Pipe's internal power buffer
drops below a certain point. This however required a modification of the
wooden pipe's internals because it was getting stuck in the "Off" state
due to how it handled transferring power from the buffer to the pipe
network.
Anyway, it works now and is somewhat useful.
Note: The Wooden Power Pipe's internal buffer stores 1500 MJ, this was
true even before this commit.
Requests Energy: Activated when the pipe has an active power request.
Use to allow your network to respond to demand dynamically.
Energy Overloaded: Activated when the pipe turns red, in case anyone
wants to know when that happens.
Its now the same as the quarry, 60 MJ per block.
Also tweaked power provider settings on the Mining Well and Quarry to
prevent smaller engines from being unable to overcome the maintenance
drain.
This is an interesting commit, it not only fixes the RS Cells
(@King_Lemming) it also makes it so the network can respond to demand as
needed by shutting down overheating engines, since the pipes won't
accept power now unless something is requesting it.
@King_Lemming this will break compat with RS Cells because you're doing
it wrong. Don't use powerRequest() like that and don't ignore the return
of receiveEnergy().
PS. It was already broken because the cell was just throwing power away
because it was ignoring the return of receiveEnergy().
...instead of their neighbor. The result being that they are constrained
by the new limits and that they actually render the power flow in
themselves.
Wooden Pipes are set with a input cap of 32 MJ/t, buffed from the
previous effective limit of 29 MJ/t.
Note that this also effectively adds a 32 MJ/t pipe that can be used for
limiting flows.
Split inventory into input/output sections.
Added support for retrieving ingredients from neighboring inventories.
Yes, this means crafting chains are possible.
Various other minor tweaks to when it requests power, how it decides it
has everything it needs to craft, etc...
Can only remove 1 item at a time, but that's almost always sufficient.
Also added a bunch of helper functions in InvUtils (moving items between
inventories, counting items, etc..).
Item and Power.
Item Pipe won't connect to Stone or Cobblestone and has half the
friction of Stone.
Power Pipe takes the place of Gold (64 MJ/t) and bumps Gold and Diamond
up to 256 MJ/t and 1024 MJ/t respectively. Expanding the upper tier
power distribution capacity.
Various textures adjusted to keep pipes distinct.
This pattern is basically the old Flatten pattern that would clear all
the way to the sky.
Recipe
GGG
GGG
BBB
Flatten got a matching recipe:
GGG
BBB
BBB
This NEEDS extensive testing. I only have a vague idea how this code
works.
The original code was just tossing any power beyond what it could
handle, with no throttle on how much it was requesting from its
neighbors.
I think its working, more or less, but you'd probably have to hook it to
some TE Cells or something to know for sure.
Explosions are gone, loss over distance is gone.
Added two new Power pipes, Cobble and Diamond.
All pipes have much smaller max throughput:
Cobble = 8 MJ/t
Stone = 16 MJ/t
Gold = 64 MJ/t
Diamond = 256 MJ/t
The power display will turn red if a pipe has hit its max capacity. You
can use smaller pipes to throttle certain parts of your power net.
Machines are more lossy now to make up for the lossless pipes. Expect
low power draws even when idle.
Also added on/off Gate action support to lasers and ACTs.
