|
[[File:Simplest PRT Request System.png|thumb|The simplest requester / search system. Expand by adding more chests and item interface (purple) pipes with item broadcasters.]]
[[File:Example PRT Routed Request UI.png|thumb|Example PRT Routed Request UI. You can search for items in the search bar (simple string match), specify an amount to deliver, and submit for the items to be sent.]]
[[File:Autocrafting Alvearies with PRT.png|thumb|An excellent use case for PRT Stock Keepers is keeping exact item counts. This shows an example of keeping the carpenter perfectly filled with the parts for Scented Paneling, a core part of the Alveary (important for bees!)]]
[[File:PRT Interaction with Multiblocks.png|thumb|You may need to get a bit creative when interacting with multis using PR. Here I use EnderIO conduits, do multi-sided chest input for more crafting chips availibility, and use filters sometimes (filtering the tiny ash into trash from the circuit 11 EBF, or distributing inputs for advanced circuit boards).]]
PRT makes a searchable / requestable storage easy to set up. It requires only these things:
== PRT's Sharp Corners ==
PRT is probably 2-3x worse than an equivalent AE2 system in terms of amount of resource load and programming patterns. This section explains why. It is still worth it due to its extremely early tier availability, but don't expect things to be as easy as AE2.
*# Inventories/machines cannot send items to the same pipe section they started in
*#*Each interface'''Routed Interface pipePipe''' can only reliably interact with one adjacent inventory/machine.
*#*For some reason processes which send to themselves are disallowed. For example, 1 wiremill cannot do ingot -> fine wire - the intermediate wire needs to be sent to another wiremill.
*#*Additionally, you cannot connect a machine directly to the same routed interface the input items are on. This is because PR does not have a method of distinguishing between which machine/inventory to send things to.
*#*(Note that the sided access on crafting chips is *solely* for which direction it acts like it is accessing the connected machine from. It does not specify the direction of the inventory it is using.)
*#Limited machine reuse
*#*When a craft request is sent, PRT dumps '''all''' items at once into the relevant machines. It will wait outside machines with full inventories, so it is ok to reuse machines which cannot conflict like bending machines, wiremills, etc.
*#*However, machines with large inventories and easy-to-conflict recipes like assembling machines cannot be reused (unless you are sure you will avoid a conflict).
*#*This makes cleanroom automation basically not viable with PRT. The difficult parts are needing multiple circuit assembling machines (due partially to self-sending restrictions as well) and not having a clear way to swap out lenses.
*#*However, you can automate all circuit subparts like SMDs.
*# Hard to cancel crafts
*#*Unlike AE2, there is no listing of active crafts. Instead, active machines are shown with a pulsing sphere overlaid on the pipe.
**To cancel a craft, you need to slot out chips or break pipes for all involved machines. (Doing it partially may cause the craft to recover and keep requesting.)
#**YouTo willcancel alsoa craft, you need to takeslot theout itemschips outor ofbreak pipes for all involved machines. so(Doing it doesn'tpartially may cause the craft to recover blockand futurekeep craftsrequesting.)
#*You will also need to take the items out of machines so it doesn't block future crafts.
*No crafting table crafts without external machines
**There is no molecular assembler equivalent for#No crafting table crafts inwithout external PRT.machines
#*There is no molecular assembler equivalent for crafting table crafts in PRT.
*#*As a result, you have to use the annoying slow/tiered assembling machine motor crafts, or craft them by hand.
*#*Once you progress enough in PRT, you can set up autocrafting for EnderIO crafters. These are expensive and will only do one craft, but pretty quickly (~1s per craft). They also don't use GT tool durability, which is cool.
*#*Note that Slice N'Splice input is bugged and will try to pull silicon plates into its red alloy plate slot if no red alloy plates are available. As a result, for Z Logic Controller craft stability, I had to keep a buffer of red alloy plates on the system. Maybe you could use a stock keeper for this...?
*# Crafting extension cards are buggy / don't work, so need filters for MB crafts
**If you don't use crafting extension cards, PR expects the input and output for a crafting chip to be in the same block. This is fine for machines. However, it is awkward for multiblocks.
#**TheIf you don't use crafting extension cardcards, isPR supposedexpects tothe beinput aand fixoutput for thisa -crafting itchip tellsto thebe PR system to expectin the outputsame toblock. beThis inis afine different pipefor sectionmachines. However, Iit wasis unableawkward to get this to workfor properlymultiblocks.
#*The crafting extension card is supposed to be a fix for this - it tells the PR system to expect the output to be in a different pipe section. However, I was unable to get this to work properly.
*#*As a result, you may need to use filters to solve this problem. You can also take advantage of the auto-filtering behavior of machines, although you will need to use a screwdriver to re-enable this in the newest builds (2.1.2.1+).
*# GT metaitems reported for missing crafts
*#*When requesting items with missing components, PRT will respond with "Missing X of Y". For non-GT items Y is reported as a readable name, but for GT items it is reported like "gt.metaitem.01.2301.name".
*#*You can figure out what it means by searching 2301 in NEI, which will show you the relevant item.
*# Drawer controller items are not reported correctly
*#*Like the holo glasses, PRT only sees a stack of items at a time in a drawer. This applies to drawer controllers as well. As a result, for very large crafts, it is a good idea to put the precursor materials in your diamond/compressed chests beforehand so the PRT system can see all of them.
*# Stock keeper / crafting chip interaction
*#*In my experience, setting a stock'''Stock keeperKeeper Chip''' for something that's only available on a crafting'''Crafting cardCard''' causes minor issues.
*#*Specifically, the stock keeper tries to pull every second, but the craft takes longer than that. As a result, many items end up being crafted even though only 1-2 items were needed.
*#*This is fine in the long term; those overcrafted items will still be used (and if they aren't, you can just slap an item'''Item broadcasterBroadcaster Chip''' onto the system). But it can be bad if rare components are used; you'll spend more of them than you need for individual crafts.
*# Routed interface pipe chip limit
*#*Routed interface pipes can only accept 4 chips at a time. This limits how many crafts you can do per machine. You can take up more sides, of course, or route through a chest, but eventually it gets very tricky to add more. This is also the case (although less so) with AE2, so it's just part of setting up autocrafting.
*# Item slot hitboxes on crafting chips
*#*At least on my monitor (1440p), crafting chip item pattern hitboxes are a bit buggy left of the furthest right column. You should ensure the slot is selected or else you will accidentally throw the items on the floor (or void if you're standing in an unlucky place).
*# Requesting fluids
*#*Like AE2, there is no good way to send fluids through the system.
*#*Personally I tend to use EnderIO ender fluid conduits for fluid supply and keep bars of each plastic, then extrude it into the correct shape (plate, ring) on demand since plastic extrusion is very fast.
*#Laggy at mega-scale
*#*While it is difficult to make a large enough PRT system that this starts becoming a problem, you should not use PRT after AE2 becomes available.
*#*It is much laggier due to using item entities in pipes and causes bursty lag when autocrafting as it does not spread out computation over multiple ticks.
*#*For context, my skyblock run was built in Sampsa's void world. Their OW was ZPM at the time and we managed to use as much MSPT as the OW with a quite large PR system in HV/EV (200ish machines, 3 drawer controller walls, multiple multiblocks connected). It still stayed under 20 TPS, just wouldn't have easily scaled further.
*
== PRT Example: Passive crafting LV->MV circuits using Stock Keeper Chips ==
Note that the following example uses '''Stock Keeper Chips''', but the same general rules apply to an '''Item Crafting Chip'''. However, unlike the '''Stock Keeper''', the '''Crafting Chip''' will not pull items for the craft until something else on the network requests them, like a '''Routed Request Pipe'''.<gallery>
<gallery>
File:Basic Single Output PR System.png|'''Step 1:''' 6 inputs leading into a '''Circuit Assembly Machine'''. No chips are inserted yet - just the pipes, drawers, and machines added.
File:Setting items and mode for Item Broadcaster Chip.png|'''Step 2:''' Set up broadcast items for all inputs. Once the chip is programmed, add it to the pipe adjacent to the relevant drawer. (For this example I'm using drawers, but this isn't very '''Item Broadcaster Chip''' efficient. Consider using 2x2 drawers or another more compact solution you come up with (filing cabinets?). As long as the network has access to the items, you're good.)
|