-
Notifications
You must be signed in to change notification settings - Fork 19
Home
McJty edited this page Oct 1, 2016
·
18 revisions
- Make sure an inventory or storage system has at least a certain number of some item and if it goes below craft new items
- Automatically craft items on request. Even when some of the ingredients need to be crafted as well (recursive autocrafting)
- Automate more complicated crafting systems as long as they have a way to accept ingredients and react to redstone
- Regulate the amount of liquid in a tank (useful for Deep Resonance lava tank which needs to be between 40 and 60%)
- On request, generate a bunch of materials
- Regulate power generation based on various factors. Like if there is enough charcoal in system switch to coal generators, otherwise enable backup power bank and give alarm to player
- Regulate RCL fluid handling for Deep Resonance using the four opcodes that Deep Resonance adds
- Regulate the timing of an Endergenic powergenerator
- Sort items based on various factors. For example, if you have a tree form you could let a part of the logs go to furnaces for charcoal production, a part of the logs to your storage for general crafting. Similarly for the rftools spawner you can have part of the wheat that is produced go to the spawner and the rest to craft bread
- Precisely control the amount of materials to feed into the matter beamers for the rftools spawner so that nothing is lost
- Collection statistics and display on rftools screens: count how many items some farm produced
- Remove a pickaxe or other tool from a auto-placer if it gets broken and repair it
- Program mini games like memory, mastermind, ...
- Much more...
- Hand-held crafting station so you can remotely order things to be crafted
- Hand-held processor controller so you can issue commands and do things with a processor remotely
- More fluid support, including opcodes to move around fluids
- Possibly integrate with the RFTools storage scanner so that you can autocraft from there
- Support for reading TESLA power values
In this section I try to clarify how a processor works and how programs run on such a processor. Let us first go over some terminology:
- Processor: this is the central computer which does all the work. It supports 6 card slots and 16 expansion slots. Card slots can contain program cards and expansion slots can contain cpu cores.
- Cpu Core: every cpu core can run a single program at any time. So to run multiple programs at the same time you need multiple cores. Note that you can still have multiple 'programs' on a program card without requiring multiple cores. They just can't run at the same time but they can still run when no other is running.
- Program: a program is code that is currently executing. Every core can run one program. A program is typically created as the result of an event firing.
- Opcode sequence: an opcode sequence is a series of opcodes on a program card. Typically an opcode sequence starts with at least one event. If it doesn't then that sequence can never run as a program
- Event: an event is a special opcode that indicates the start of a program. When the condition of the event is satisfied a new program is created (provided there is a free cpu core) and the program is allocated to that core where it can start executing. The program will start executing at the event location and proceed to handle the rest of the attached opcode sequence.
- Card slot: as indicated above card slots can contain program cards.
- Program Card: a program card represents a grid with opcodes. There can be multiple events on a program card (which could be seen as different programs but that's not 100% accurate as a single program can have multiple event entry points). These events are typically connected to an opcode sequence.
Given the terminology above it is important to realize that there is not always a 1 by 1 relationship between an event on a program card and a running program. An example to clarify this:
Lets say we have a Processor with 3 cores and one program card that contains a single event (and some opcodes connected to that event) that triggers when the processor gets a redstone signal. Let's also say that this program needs several seconds to run (i.e. it has a 'delay' opcode for example). What happens if you quickly give the processor 4 redstone signals? The event will fire four times. The first three times there will be a core available to run the program on. So that means that the three cores each get a new running program all originating from the same event on the program card. For the fourth event there was no free core so it will be put in a queue. As soon as a core is available (i.e. one of the three programs finishes running) it will get assigned to that core and the fourth program is created. This example shows that a single event on a single card can still cause multiple programs to run. Sometimes this is not intended and that's why there are ways to solve this problem. More on this later.
The example above demonstrates a situation that is sometimes ok but in many cases it can represent a real problem. Luckily there are several solutions to this. We will go over all of these solutions here:
- The easiest (but most restrictive) solution is to enable the Exclusive mode on the Processor. In that mode core X can only run programs from card X. So in the example above that would mean that only the first core will be able to run that event since the other two cores have no associated program card. This solution is good if you have programs that you really want to make sure only run one time but you still want to be able to run them at the same time with other programs on other cards.
- Another solution is to mark the event on our card as 'single'. Every event has an optional parameter that is disabled by default. If you set this parameter to true then when this event fires the event cannot fire again until the resulting program finishes executing. With this solution every event can only run once at the same time but it can run on any core. In the example above this would mean that the four redstone signals would have to wait on each other and the four programs would run one after another. But other programs would be able to run on any other available core.
- The most complicated solution is to make sure your program doesn't mind running multiple times. For the recursive autocrafting program you want to do this because otherwise you will need to duplicate the program a lot to do this effectively. The problem is that such programs often need variables and slots and when multiple instances of that program run at the same time they can overwrite their data. To prevent this there is a lock system that you can use. When your program wants to start accessing the slots or variables you set the lock. If the lock was already set (by another instance of your program) then your program will wait (but it will stay allocated to the core(!)). If the lock is available the program will obtain the lock and it will execute. This solution is a bit more complicated and you have to make sure to release the lock in all cases. If you don't the Processor may end up being locked up (you can use 'reset' to clear this situation)
In the Processor console you can type various commands. Here is a list of all commands and what they do:
- clear: clear the console output
- stop: stop all running programs
- reset: stop all running programs, clear all locks, remove all queued events, remove all pending craft requests, clear all redstone outputs, and remove all graphics operations
- list: show information about all cores, locks and events
- signal : send a signal. If there is a program card with a signal event that corresponds with that name then it will execute. This is an easy way to have programs to initialize the processor (i.e. set certain variables and such)
- net: see below for network related commands
- db: see below for debugging commands
There are several programs for networking. These need a network card:
- net setup : setup the network with the given channel name. This will scan all network nodes in a 17x17x17 area (or 33x33x33 if you have an advanced network card) and if they match the channel name (case sensitive!) then they will be connected. This will also look for crafting stations in that area.
- net list: list all nodes currently connected to the processor
- net info: show channel name and number of nodes
Debugging commands:
- db debug : set the specified core in debug mode. If no core was specified then all cores will be set to debug mode. In debug mode all programs run one step at a time (with the 'db s' command) so you can closely examine what is going on
- db resume : resume the specified core so it runs normally again. Or resume all cores if no core was specified
- db info: for all cores that are currently in debug mode this shows the next instruction that is about to be executed
- db last : show the last value (the result of the last opcode) for the core. If no core was specified show the last value for all cores
- dp s : proceed to the next instruction. This will execute the current instruction for that core and set the instruction pointer to the next instruction. If only one core is in debug mode then you don't have to specify the core
- In the programmer GUI you can use the ctrl key to select opcodes or you can ctrl-double click to select an entire sequence of opcodes. You can then use Ctrl-C (copy) or Ctrl-X (cut) that sequence and use Ctrl-V (paste) to paste it elsewhere. It will be put as a JSON string in the clipboard so this is also a way to share programs.
- Ctrl-A in the programmer GUI will select all opcodes.
- In the programmer GUI you can press while hovering over an opcode icon to get more information. If you do this above the icons in the left list then you get detailed information on how the icon works and what kind of parameters it supports. If you do this above the icons in the grid then it will show you the values that you set for all the parameters so that you don't have to click on it to examine that.
- Use the 'Val' button in the programmer GUI to validate your programs. It will give errors for unreachable opcodes and errors for opcodes where there are missing parameters. Doubleclicking on an error line will highlight the opcode that is wrong.
- Variables and slot indices start counting at 0. So the first slot that is available for your program is at index 0. Same for variables.
- Think before you add too many cores to a processor. If there are multiple cores then multiple programs can run at the same time. And sometimes that may give weird results if your programs are not designed to run multiple times.
- Use 'db debug' in the processor console to enable debug mode. This will halt your programs and allow you to single step through them (db s ) or show the current last value (db last). You can also resume the programs with 'db resume'
- Wherever you can input integers you can also input them in hexadecimal format like this: $aabc03af. This can be useful when you want to input a color code. For example the color green with no transparency would be: $ff00ff00