-
Notifications
You must be signed in to change notification settings - Fork 95
Printing Press Internal Mechanics
Because the printing press stores a lot more state, and because I hate custom text formats, printing presses are stored as serialised Java primitives using Object{Input,Output}Stream. Because some context is needed to deserialise, the standard Externalizable interface is not used - the serialisation and deserialisation is handled by the manager.
The stream begins with a version number - 1 in this instance. This should be incremented whenever the format is changed. Each release should write its own version number and be able to read at least the version before so that an upgrade path is available.
We next have the number of factories to be read.
Each factory then has a series of fields, which are read out in a loop. These fields include all the normal state and a snapshot of materials and the production queue. The aim is that you can shut down the server and start it up again and they don't miss a beat.
Costs are adjusted through the config.yml . Costs are as a "lot", which is associated with a certain number of pages or outputs. The page lot doubles as the feed rate - only one lot per update can be loaded.
Pamphlets and security notes each have their own costs, and the number of pamphlets/notes produced per lot can also be changed.
The repair and "Set plates" recipes have times which can be configured in the config.yml.
The printing recipes are a continuous process, so have a recipe time that should never be met (~1 year real time). These times are not adjustable as they should never be met.
When printing starts, all material counts and the queue are zeroed. Each time fuel is consumed, the press attempts to produce outputs and load materials.
The queue is, by default, 12 slots long (configurable). Each time fuel is taken, we take items off the end and add a lot of books/pamphlets/security notes to the start. This creates a 12 x energy time minimum run period. Inputs can arrive at any time, and as long as we keep feeding we'll get outputs 12 x energy time after the materials are taken.
First, it produces any outputs. It takes a number off the end of the production queue, and puts that many items in the chest.
To load materials, it loads a single lot of paper and ink (16 paper + 2 ink). This is added to the input buffer. Then it tries to consume other materials - bindings or security materials - until it has enough for all the paper currently held.
Once this is done, it uses the currently held paper and other materials to add items to the queue. As long as it has enough for a single copy, this will be added. We write the number of books we have materials to produce to the start of the production queue, and take those materials out of the input buffer. After 12 fuel has been burned, this will be the front slot of the queue and those items will emerge.
Books have both the "binding" cost, which is per discreet book, and the "pages" cost, which is part of the pages lot. If we have a 5-page book and can load 16 pages' worth per tick, we'll consume 16 pages and 4 bindings in the first tick. Three books will go in the queue, and we have 1 page and 1 binding left. The next three updates, we'll consume 16 pages and 3 bindings, and three books will go in to the queue. On the fifth tick, we'll consume 16 pages and 3 bindings, but we have enough pages to use that extra binding - four books will go on the queue. We're now back to no surplus, and the cycle begins again.
- The queue is implemented as a ring buffer because its size is fixed.