RS485/LogisticsPipes — pull request #403 by AartBluestoke (2013-01-16 08:48:12+00:00)
Title: Dev

various routing updates:
Features:
iron pipes now work to allow items to flow one way.
if there is a long way, and a short way, with the short way blocked by iron pipes, passive requests will take the long way, active requests will be blocked.
diamond and obsidian pipes should block routing, but allow power.

the effect on ICS is untested, but should remain unchanged.

Code:

major changes in the routing table - each link now has an associatedEnumSet which is a set of flags for how the link can behave. both directions can have different flags. examples are "blocksPower","passedThroughIronOpen"

PathFinder creates the PipeRoutingConnectionType for a link.
ServerRouter.createRouteTable propagates them out as the routing table is created.
RequestManager.getCrafters/getProviders, and (whatever it is that finds the destination for passive routed items) check to see if specific flags are set and terminate or alter recursion when that happens. This is also involved in the sorting of the SearchNode within Dyjkstra's algorithm, and now provides a mechanism for more complex routing behaviors

coreRoutedPipes now have a simpleID, which is just a number incremented every time a new piep is created. This number, and a bitSet is used as a flag for improving the speed of building the routing table.

No hash-maps are used in creating the routing table with a bitSet (one bit for each possible simpleID) is used to flag, or not, the completion state of a pipe. This means that routes to routers outside a chunk are not calculated, as the pipes are not there. The extra memory used is insignificant, and temporary.

lists of SearchNodes are passed around, rather than just IRouters. a searchNode knows its distance, parent, and anything special about the route (ie, does it pass through an iron pipe)

requests for items do not accept lists of crafters/providers, they just accept the requester itself, then the requester is asked for its list of valid providers.

this means that the crafting list is not reduced by 1 every recursive call, instead the request tree holds the list of used crafters, and the new crafter is compared to that list.

crafting.addCrafting(LinkedList crafters) was changed to return the template it has, rather than accept a list for modification.

Various classes are now Comparable, or have associated Comparitors.

some data structures have been changed to be more appropriate for their current use.

TODO:
no known bugs, unless you consider reversed iron pipes blocking active requests when there is a long way around to be a bug. The fix would be to find the distance to all possible crafters, then ask them how far away they arefrom where they want to send their stuff.

RouterCosts a) doesn't need to hold basic pipes, only things which can provide or sink items
b) should be further reduced by splitting into sinks, provides, crafts

provides/crafts should be mostly merged by moving the concept of providing extras up 1 class level to IProvide, removing the separate provide code, and adding a sort so that providers are effectively priority -1 crafters. either that or just put priority on provides, because i can imagine that at times you would want to maintain a store, and would use a crafter instead.

SOME PERFORMANCE CHECKING IS NEEDED.
-- Significant speedup of Routing in all conditions
-- slight slowdown on networks with lots of branching BC pipes (ie, speedup not quite as good)

-- major code inefficiency removed from crafting tree
-- providers/crafters not passed around at every step, might be saving, extra copies when needed, might be a touch more expensive
-- item routing costs have not changed once they have a route.

-- checking the properties of a link takes no significant cpu time (doesn't appear on profiler at all), as it is a bitwise and between 2 ints.