Create Wareworks

Added

• Hand the warehouse a shopping list. The Warehouse Terminal has one more slot, for a clipboard. Put a clipboard with a list of items in it, press the list button, and the warehouse works the whole list off: it fetches what it can, ticks each entry off on the clipboard as it delivers it, and waits whenever the terminal is full instead of refusing — so a whole building's worth of material arrives in portions while you carry the crates to the site. There is no "your output cannot hold 40 stacks"
• The clipboard is the order and its receipt in one. Pick it up at any time and the ticks tell you what arrived and what is still outstanding. An entry that arrived only partly stays unticked, because the warehouse never ticks a line it did not finish, and putting the clipboard back in carries on where it left off. The ticks belong to that one clipboard: a copy of it made with Create's own copying recipe stays as it was
• The row under the delivery slots keeps saying what the terminal is doing. While the list runs it counts the entries down; when the list is finished it says so for a moment and then goes back to the crane, and the finished receipt stays on the clipboard's own tooltip. A terminal that has lost its aisle or its crane says that first, because it is the reason the list is not moving
• A Schematicannon's material checklist works as it comes. Print the checklist onto a clipboard at the cannon and carry it to the terminal — "build this schematic" becomes "hand the warehouse the shopping list". A hand-written clipboard works exactly the same, and a read-only checklist is still ticked off
• It asks before it starts, if it has to. If the list wants more than the warehouse holds, the terminal says how much is missing, names the entries it is short of and asks whether to fetch what there is. If something on the list would have to be produced first, it asks about that too — it never starts your machines for a list without being told to. A clipboard so long that part of it was left out says that in the same dialog, before anything is fetched. A list a stocked warehouse covers starts with no questions at all
• A question that comes up while the list runs names what it is about. The warehouse asks again, item by item, whenever one portion would reach into a reserve, store something above a maximum or start a production run bigger than you agreed to — and that panel names the item, how many of it, and what would be made. Saying yes pays for that one item and nothing else, saying no leaves the rest of the list for later instead of stalling it, and the list button brings the question back if you closed the panel
• An entry the warehouse can neither stock nor produce never blocks the rest. It is stepped over, left unticked and counted in the dialog; everything behind it is still fetched. A list that cannot be served at all stops trying after a minute and waits for you to click it again, instead of leaving the crane running
• Nothing new happens underneath. Every entry becomes an ordinary request, so batching, storage filters, priorities, reserves, maxima, production chains and the safety stop all apply unchanged, no item teleports, and the crane physically fetches every single one. Four new server config keys in the stations section (maxTerminalListEntries, terminalListOpenRequests, terminalListIntervalTicks, terminalListStallTicks)
• The terminal's goggles say how many entries of a clipboard order are done and how much is still to fetch, and its Ponder scene "Requesting Items at a Terminal" ends on the new beat
• The terminal can sort by what you actually use. The sort button has a third order, "most used": the items you request most often come first, so a warehouse holding hundreds of item types opens on the twenty you keep fetching instead of on the twenty it has the most of. Each request counts once, whatever amount it asked for, so one ctrl-click on a thousand cobblestone does not outrank a hundred deliberate requests. The terminal remembers a bounded number of item types per player and lets an old habit fade as a new one grows, so the order follows what you are building now rather than what you built in your first week. Until you have requested anything it is simply "most available first", and the search, the "only what is available" filter and the offers a production station makes all behave exactly as before. Handing the terminal a clipboard list counts every item type on it once, so the lists you fetch again and again are what the order learns from most
• What the warehouse actually holds always comes first. A favourite the warehouse has just run out of does not jump to the top of "most used" — not an item a production station could make, and not one a Warehouse Stock Keeper is calling for: both keep their row, behind everything you can really have right now. The top of the list is never a row that cannot be ordered
• The order you pick is yours, and it stays picked. The terminal remembers which of the three orders you chose and how often you have asked for each item — per player, on the server. So it is the same at every terminal of the world, it survives closing the game and rejoining, and on a server everybody has their own order and their own list of favourites
• One button, three orders you can tell apart. Each order has its own icon — chevrons for most available first, a target for most used, a list for by name — so the button says which one is on without being hovered. Hovering it names the order, says in a sentence what it does and tells you which order the next press would give, so the cycle does not have to be learned by pressing it; while you have requested nothing yet, it also says why "most used" looks like "most available first". Changing the order takes you back to the top of the list, because that is where the answer to the new order is, and nothing else ever moves the list under you
• Clicking the same cell twice asks for the same item twice. Under "most used", requesting something raises its count, which would otherwise pull that row to the front of the list about a tick after you clicked it — so a second click on the same spot would have ordered whatever had slid into it. The new counts therefore take effect the next time you ask for a list: when you press the sort button, type in the search or flip the filter. The list never reshuffles under the cursor that is using it, and the next terminal you open is in the full order
• Only a player's request teaches the terminal anything: clicking an item, and handing it a clipboard list. A redstone request at a Warehouse Output — the warehouse's port — counts for nobody, because a port is not a player. One new server config key, maxTerminalUsageEntries in the stations section, says how many item types the terminal remembers per player (64 by default). What is remembered is bounded in size as well as in number: an item carrying a whole inventory with it — a filled shulker box, a written book — is not remembered at all, so nobody's save file can grow by kilobytes per favourite. Requesting such an item works exactly as before; it simply never joins the order

Changed

• The Warehouse Terminal's window has one slot more (the clipboard slot, at the right-hand end of the delivery row); the window is the same size, because the delivery row gives up a column for it. A shift-click moves a clipboard in and out. Delivery slots, the stock list and every other click work exactly as before

Fixed

• The terminal's status row no longer cuts off what the crane is doing. The row said "Crane: …" and then ran out of space, so in German the most ordinary line of all — "Regalbediengerät: Wartet auf einen Auftrag" — was drawn with its end missing, and several of the longer English phases came within a few pixels of the same thing. The row now drops the "Crane:" label whenever keeping it would cut the text, and shows what the crane is doing in full instead; nothing changes for the lines that already fitted. Two kinds of text are still longer than the row and end in an ellipsis: the line that says a crane speed factor is 0 in the server config, and the longest refusal reasons — four of the eleven in English and seven in German, among them the one that says production has stopped. Both are readable in full through engineer's goggles, which have no fixed row to cut
• The clipboard order's progress line is no longer cut off. The row under the delivery slots counts a list down as "List 2/9, 320 left (…)", and the word in brackets used to be a whole sentence — "waiting for your answer", in German "wartet auf deine Antwort" — which did not fit beside three numbers and was drawn with its end missing, in both languages. Each state is one word now (fetching, asking, paused, done), everywhere it appears: the status row, the clipboard's own tooltip and the terminal's goggle line. What to do about it is on the list button right beside the row, which changes its face and its tooltip with the same state
• Three German answers of the clipboard order ran past the end of their row. Pressing the list button told you that the question was back, asked you to answer it, or said the rest of the list would be tried again — and each of those sentences was drawn with its end missing. They say the same thing in fewer words now
• A production station's order line cut away the state instead of the item's name. The line reads "Oak Planks x128 - waiting for the result", and because it was trimmed from the end, a long item name pushed the half that actually changes off the row; the note that an ended order's ingredients are not coming back did not fit in either language even with no name in the line at all. The item and its amount now stand on the left and the state on the right, so the state always survives and a long name is what gives way — and the whole sentence is one hover away, in the line's tooltip. In the terminal, where the same note appears, the German wording now says plainly that it is the ingredients that are gone, which is what the English always said
• A production station's red "stopped" row was cut off in both languages. It reads "Stopped: Diamond - click to resume" now; the old wording did not fit the row even before the item's name was put into it. What stopped it and what it cost are still in that row's tooltip
• A refused request shows the reason instead of running out of room. The status row said "Request refused:" and then ran out of space for the reason itself. It drops that label now whenever keeping it would cut the text — the row is red already, and there is nothing else in the window it could be about — so seven of the eleven reasons are readable in full in English and four in German, where it was three and one. The longest ones still end in an ellipsis; a glance through engineer's goggles at the terminal shows them whole