Blueprint identification has been adjusted a bit in order to make it easier
to have an ordered list. Loading functions are temporary deactivated waiting
for some more insights on the serialization. Server and client databases have
been separated.
This patch changes a bit the behavior of the Library. Instead of being an
item browsing blueprints on the server, it's going to retreive blueprints
built on the server for the client, and then allow the client to send back
its blueprints to the server.
This patch is a first milestone, with functional serialization and
deserialization of a blueprint over the newtork, using the Library as interface.
ClassMapping now supports more advanced behavior, in particlar cases where
the destination object do not exist. It has now a much more comprehensive
documentation. TileNetworkData has been renamed NetworkData, as it's used
for more than just tile synchronization. Some additional markers have been
placed on the blueprints to make progress and identify which areas still
need support.
same system as tiles, and fields selected through @TileEntityNetwork. Improved
the TileLibrary rpc calls to take advantage of this new capability. The RPC
world identification has been fixed as well.
implementation.
Through the process of implementing RPC, a intrusive simplification in the
network message system has been implemented, completely removing the use
of PayloadArray. On top of that, ClassMapping is now much more flexible,
and doesn't need to be provided with a static size anymore, making it closer
to a suitable class for the needs of RPC message passing.
The result of this simplification is also a slight optimization of message
passing, where certain data needed to be passed over the network (for example
on null objects) which is not needed anymore.
With regards to the TileLibrary itself, the implementation is yet pretty
basic, showcasing the use of RPC to retreive a list of strings computed on
the server.
Attempt at improving SafeTimeTracker interface and implement
automatic randomization. If interface is confirmed, other places
in the code will need to be updated to the interface.
-Added Integration Table Recipes
-Finished and tested Integration Table
-Re-added all Gate recipes
-Clean up Pipe Wires, Chipsets, etc...
Changes:
-Gate Logic Swap recipes moved from Workbench to Integration Table.
-Pipe Wires condensed into a single Item
-Pipe Wires are now distributed evenly between the gates: Red with the
Basic Gate, Blue with Iron, Yellow with Gold, and Green with Diamond.
Recipes adjusted to match.
As of this commit, Gates should be both craftable and usable again. The
Integration Table is also ready to be used. Gate Expansions are
completely implemented and usable.
Enjoy!
Expansions are synced in a similar manner to fluid ids. A packet is sent
on login with a String<->Byte mapping for each Expansion. The Pipe uses
this lookup table construct the Gate on the client side.
Remaining Todo List:
-Add Integration Table for adding Expansions to Gates
-Add Deconstruction Table for dismantling Gates
-Adapt Clock Timer Expansion to new framework
-Add Redstone Fader Expansion (name not final)
It was sending a ton of unused bytes, whoever did the Liquid->Fluid API
update left a bunch of old metadata related stuff in.
Also checking for valid fluids is necessary because its possible for
FluidStack.getFluid() to return null.
GateKind enum is gone, replaced with two enums: GateMaterial and
GateLogic.
Pulsars and Timers are abstracted into GateExpansions that can be
applied to "upgrade" a gate. (Incomplete)
GateExpansions will eventually be moved to the API so that other can
define new expansions easily.
GateExpansions are not currently serialized or synced to the client.
This remains to be done.
Legacy migration support is included, but untested.
Currently only the base logic texture layer (white/black) are being
rendered. Eventually the material and expansions will each render an
additional texture layer onto the gate.
There existed a race condition where either the client could pass an
item from one pipe to another (with intact ItemStack NBT data) or a
packet could arrive from the server to inject the item into the pipe
(without NBT data). This resulted in incorrect Icons being occasionally
displayed for a moment for Items that use NBT to determine the Icon
(Forestry Bees/Trees).
To eliminate this race condition, all Traveling Items are now cached
(weakly) and ItemStacks are no longer sent as part of the Traveler
Packet. The client must instead request the ItemStack from the server.
The bonus being that the ItemStack (NBT and all) needs only be requested
when it first enters the network.
This also has the affect of further reducing bandwidth usage by Item
pipes, though it should be noted that Item pipes where already the least
bandwidth intensive pipe.
Additionally I rewrote the Item Grouping code. I'd never looked at it
before, but I figured I should make sure it properly maintains the pipe
state after grouping. What I found was 200 lines of wtf code that was
horribly outdated and broken. I replaced it with 20 lines of code that
are less dependent on implementation details of how pipes work. -.-
Quartz gates act like gold gates with 2 exceptions:
They can connect to all pipe wire types.
There are 3 additional gate triggers that function as timers.
The timers have a short, medium, and long mode which can be set via config.
