Circuit Control Unit

Post your ideas and suggestions how to improve the game.

Moderator: ickputzdirwech

Post Reply
Factoruser
Fast Inserter
Fast Inserter
Posts: 167
Joined: Tue Sep 16, 2014 5:48 pm
Contact:

Circuit Control Unit

Post by Factoruser »

Suggestion: a new object named "circuit control unit". It replaces all the "combinators" and can do the job of several of them at once. Size is 2x1, like the combinators, it has a separate input and output field. It's not a programmable computer (too complicated for ordinary gamers), but much better and slightly more powerful than the combinators.

Its interface/dialog shows lines with expressions. Line #1 is named/tagged "a", line #2 "b" and so on. You may add many lines, but the limit is at least 26 lines => "z".

Each line consists of 7 elements/fields:
1. the line's letter => "a", "b", "c", "d" ... can't be manipulated BTW
2. an input signal
3. + 4. the operation
5. another input signal or value
6. a signal for output
7. the output signal's value

1. The line's letter is handled like a signal and the return value of the operation. The result of the operation in line "a" is available to all later lines as signal "a". - But only inside of the (same) circuit control unit.

2. You may not select any input signal, in this case the output signal gets always sent; the default operation may be "[anything] ≠ 0", so only a signal is sent if there's a signal in the input network.

3.+4. The operation is divided into 2 selection boxes. The first is to select a group of operations, the second picks the specific operation. There are 3 groups of operations:
= Comparsion: = ≠ < > ≤ ≥
± "Algebraic" ('s there a better name ?): + - × ÷ % (further power function, (square)root, log only if you think it makes sense)
⠶ Bit operations: AND OR XOR NAND NOR << >>

Note: if you use a float type for fluids, "=" would have to check A = B e.g. this way: A > B - 0.000001 & A < B + 0.000001 - hope, you only use integers. 64 bit ought to be enough ;-)

The bit operations are working bitwise. Therefore, if A would be 1 and B would be 2, "A AND B" would be 0 / FALSE. Because of this, the value of TRUE should be -1 (all bits set) and used instead of "1". Whereever possible, TRUE is not identified by comparsion with -1, but by ensuring the value is not 0. Comparsions are returning TRUE or FALSE as result / in the line's signal. FALSE is always 0 and also identical to "no signal". If the player wants to distinguish between no signal and no items, he has to add an additional signal on his own.

5. The third part of the expression can be another signal, but also a constant value. There might be also buttons for TRUE and FALSE in the interface, although they are just special constant values.

6. If the expression results in TRUE, resp. it doesn't result in a value of 0, an output signal could be generated and is picked here. This includes all signals except the internal "a" to "z" signals. If always a signal should be put out, you must use the next line.

7. is the value of the output signal. Default is the expression's result, that might be TRUE in case of comparsions or e.g. the result of "A + 1" if this field stays empty. But you may also demand the value of any signal - including "a" to "z" - or any constant value. A value of 0 would overwrite a signal's value in the network with 0, even item counts, but those only until the next tick.

One line is processed after the other one, in one tick. If line b changes signal T, the new value is valid for line c and later, but not for line a. The output signals are sent once after all lines have been processed.

Post Reply

Return to “Ideas and Suggestions”