Arithmetics and Logic

[Auriga_Nexus]

So this is an idea that I had to add additional functionality to the logic system, making it more practical in use. Because even if you could design arithmetic circuits using purely boolean logic, it would take a LOT of blocks and a LOT of work, and may not exactly be practical for logic-based controls on ships and stations. The idea is for a set of blocks that work similar to logic blocks, only instead of passing a Boolean value (1 or 0), they pass a variable containing a numeric value.

These are some of the ideas I had for the different blocks and how each system would work. I've boiled it down to the bare basics because I believe you shouldn't just be able to program a single block to do whatever you want. However, using these blocks would enable players to make arithmetic programs that can do more than just basic logic blocks while still requiring a base level of ingenuity and creativity to make a functional logic system.

Meter Block: This block would basically measure things related to the blocks slaved to it and output the numeric value of what it is measuring. For example, slaving Shield Capacitors to the Meter Block would output your current shield value, while Shield Rechargers would display your current recharge rate. We could also connect them to weapon systems to measure parameters in regards to those systems. Since there are multiple things they can measure with weapon systems, there would be a drop-down menu similar to production menus in factories, except this would list the possible things it could measure based on what is slaved to it. When the parameter is set and the block is activated (either manually or through Boolean logic blocks), it will take the value it is supposed to measure and send that as a numeric logic signal to other numeric logic blocks connected to it.

Memory Block: Similar to the Meter Block only instead of actively measuring, this block "holds" a numeric value, either set manually or passed from another numeric logic block. When activated with a Boolean "on" signal, it passes the value it is holding to the numeric logic blocks slaved to it. There can be variants on how this works, say one memory block that holds a value indefinitely, or one that erases its value when it is deactivated.

Operator Block: These would be blocks that would perform a specific arithmetic operation based on numbers passed to them. There would be one for each major operation: addition, subtraction, multiplication, and division, the block would take inputs from connected numeric blocks and send the result as output. For subtraction and division blocks, it will have drop down menus to determine which value is being subtracted/divided by the other. For simplicity's sake I think each individual operator block should be limited to two inputs; you can always send the output from one operator block to another allowing you to easily construct equations.

Conditional Block: The Meter and Memory Blocks can output a numeric value in response to being sent a Boolean signal. This block would do the opposite: it would compare numeric values received from inputs and output a boolean "true" or "false" value, making it the logic block representation of an if-then statement. You can use the drop-down menu to select both the order of the inputs and the comparison you are using (greater than, less than, or equal to.)

Finally, I think you should be able to assign names to numeric blocks like you can with factories and storage areas. The idea is that the block's "name" is essentially a variable name representing that block's output value. This is helpful for setting up conditional and operator statements as you know which input is which. I also think that if a named numeric logic block is connected to a display module, you should be able to set the display module to show that output using a syntax like [numericBlockName]. Display modules can already do this with your ship's shield and power variables so adding that functionality shouldn't be hard.

I've heard suggestions that the devs should implement blocks that hold basic LUA scripts for use with logic systems. That's all well and good but I think this system would be simpler and would tie into our existing boolean logic system quite nicely.

 

[Megacrafter127]

So this is an idea that I had to add additional functionality to the logic system, making it more practical in use. Because even if you could design arithmetic circuits using purely boolean logic, it would take a LOT of blocks and a LOT of work, and may not exactly be practical for logic-based controls on ships and stations. The idea is for a set of blocks that work similar to logic blocks, only instead of passing a Boolean value (1 or 0), they pass a variable containing a numeric value.

These are some of the ideas I had for the different blocks and how each system would work. I've boiled it down to the bare basics because I believe you shouldn't just be able to program a single block to do whatever you want. However, using these blocks would enable players to make arithmetic programs that can do more than just basic logic blocks while still requiring a base level of ingenuity and creativity to make a functional logic system.

Meter Block: This block would basically measure things related to the blocks slaved to it and output the numeric value of what it is measuring. For example, slaving Shield Capacitors to the Meter Block would output your current shield value, while Shield Rechargers would display your current recharge rate. We could also connect them to weapon systems to measure parameters in regards to those systems. Since there are multiple things they can measure with weapon systems, there would be a drop-down menu similar to production menus in factories, except this would list the possible things it could measure based on what is slaved to it. When the parameter is set and the block is activated (either manually or through Boolean logic blocks), it will take the value it is supposed to measure and send that as a numeric logic signal to other numeric logic blocks connected to it.

Memory Block: Similar to the Meter Block only instead of actively measuring, this block "holds" a numeric value, either set manually or passed from another numeric logic block. When activated with a Boolean "on" signal, it passes the value it is holding to the numeric logic blocks slaved to it. There can be variants on how this works, say one memory block that holds a value indefinitely, or one that erases its value when it is deactivated.

Operator Block: These would be blocks that would perform a specific arithmetic operation based on numbers passed to them. There would be one for each major operation: addition, subtraction, multiplication, and division, the block would take inputs from connected numeric blocks and send the result as output. For subtraction and division blocks, it will have drop down menus to determine which value is being subtracted/divided by the other. For simplicity's sake I think each individual operator block should be limited to two inputs; you can always send the output from one operator block to another allowing you to easily construct equations.

Conditional Block: The Meter and Memory Blocks can output a numeric value in response to being sent a Boolean signal. This block would do the opposite: it would compare numeric values received from inputs and output a boolean "true" or "false" value, making it the logic block representation of an if-then statement. You can use the drop-down menu to select both the order of the inputs and the comparison you are using (greater than, less than, or equal to.)

Finally, I think you should be able to assign names to numeric blocks like you can with factories and storage areas. The idea is that the block's "name" is essentially a variable name representing that block's output value. This is helpful for setting up conditional and operator statements as you know which input is which. I also think that if a named numeric logic block is connected to a display module, you should be able to set the display module to show that output using a syntax like [numericBlockName]. Display modules can already do this with your ship's shield and power variables so adding that functionality shouldn't be hard.

I've heard suggestions that the devs should implement blocks that hold basic LUA scripts for use with logic systems. That's all well and good but I think this system would be simpler and would tie into our existing boolean logic system quite nicely.

You forgot 2 basic ones:
Counter block: Outputs the number of high or low inputs(setable on a per-block basis) on the block as numerical value.
Constant block: Permanently outputs a number configured in the block itself, it does not react to ANY input.

 

[Auriga_Nexus]

You forgot 2 basic ones:
Counter block: Outputs the number of high or low inputs(setable on a per-block basis) on the block as numerical value.
Constant block: Permanently outputs a number configured in the block itself, it does not react to ANY input.

Yeah those will work too. The Constant Block I was already thinking of... instead of it being just an entry textbox however, why don't we make it a keypad block instead? Like, when you press R, it shows a keypad on screen with the numbers 0-9. You type in the number setting and hit Enter to set the number, or hit Clear to reset the value to zero.

As far as Memory Blocks go I was thinking they can be configured with two possible options: Volatile/Non-volatile and Constant/Variable. Constant Memory Blocks check for an input number once when powered on, while Variable Memory blocks constantly check for input when on and change their stored number accordingly. As for volatile/non-volatile, that one is obvious; volatile blocks lose their stored number when powered down e.g. Boolean low input, while non-volatile blocks keep their number when powered down and only change when their input changes. And we could also create a constant block by slaving a non-volatile memory block to a keypad block and setting the number from the keypad, so long as no one touches the keypad the number will remain the same.

Also your idea for an incrementor block is one I overlooked. Of course, the same idea could theoretically be accomplished with a constant memory block set to 1 and an addition operator block. The idea is that constant memory blocks only output their number when they are activated or receive an on pulse from a boolean block - therefore by setting up a loop where the increment value (1 in this case) and a variable memory block with a default value of zero both hook into an addition operator block, which is then hooked back into the variable memory block, you create a system where each time the boolean block switches on, the number in the constant block is resent to the operator block and the operator block performs the operation again.

Left to their own devices the operator blocks would be constantly performing their operation; that is why the memory blocks are there, they combine the high/low signal from the boolean system with a numeric value. This way they "delay" sending their value to other numeric blocks until receiving a boolean high pulse. Otherwise, increment loops such as the one described above would occur instantly and indefinitely and would not be practical. So your counter block could be accomplished with the blocks I've already come up with, provided the correct memory blocks are used.

But you are right, being able to do a cyclical increment/decrement by combining boolean and numeric logic blocks would be critical for developing some of the more obvious uses, one of which would be a countdown clock; same idea as above, only replace the activation module with a delay signal loop or "pulse clock", have a conditional statement slaved to the variable memory module, and replace the addition block with a subtraction block. Set the timer with the keypad and start the pulse clock to start counting down. When the timer reaches zero the conditional block switches from "false" to "true", and that triggers a boolean logic system for something else... maybe the metric assload of warheads you've got stockpiled around the enemy base? The possibilities are limited only by imagination...

 

[Knack]

Most things you suggest are already doable through logic, but as you said, that takes some space.
Basic arithmetic operations, memoryblocks, counter, that is not realy a problem to do with logic. If you know how.

A Meterblock would be cool

I would love a Logic-Container-Block, where you could put in a little complex logic. It could for example hold 8x8x8 logic blocks. there you could store 2 Bytes (a value from 0 to 65535).
The connections to and from the block could be maintained similar to weapon computers with their two slaves.

The big problem at the moment ist the loading time of logic blocks, but the schine-team is working on it.

More posibilities to get values from blocks and to show them in Displays would be cool. 7 segemnt-displays are just too big

 

[Monchoman45]

The real bread and butter here is that an adding block is going to be WAY faster than an adder made with boolean ops - although, I've always sort of thought that part of the fun of sandbox logic systems was learning how to build an adder with the basic boolean components you're given. What's the fun in building a turing complete redstone computer when your AMU is just a couple of blocks that do the hard work for you?

There are a couple semantic issues with this, although they're not terrible. For one, when doing an operation like subtraction, how do you determine which value is the left hand side and which is the right hand side? I don't think logic links are currently stored in any ordered format. You could solve this by adding a negator that outputs the negative of its input, and a reciprocator(???) that outputs the reciprocal of its input, which would be easier than coming up with some sort of "link as input 1" or "link as input 2" system. That would also give you the benefit of allowing the adder and multiplier to take any number of inputs.

More posibilities to get values from blocks and to show them in Displays would be cool.

Also this. Also, more ship-wide variables, like current power consumption and speed and all that.

 

[Snk]

I love this.

 

[Auriga_Nexus]

The real bread and butter here is that an adding block is going to be WAY faster than an adder made with boolean ops - although, I've always sort of thought that part of the fun of sandbox logic systems was learning how to build an adder with the basic boolean components you're given. What's the fun in building a turing complete redstone computer when your AMU is just a couple of blocks that do the hard work for you?

There are a couple semantic issues with this, although they're not terrible. For one, when doing an operation like subtraction, how do you determine which value is the left hand side and which is the right hand side? I don't think logic links are currently stored in any ordered format. You could solve this by adding a negator that outputs the negative of its input, and a reciprocator(???) that outputs the reciprocal of its input, which would be easier than coming up with some sort of "link as input 1" or "link as input 2" system. That would also give you the benefit of allowing the adder and multiplier to take any number of inputs.


Also this. Also, more ship-wide variables, like current power consumption and speed and all that.

Well, the underlying idea is to make building ship-controlled logic systems more practical. To me building an AMU out of logic blocks is a cool novelty exercise but not very practical due to the amount of space it takes up and the work going into it. Not to mention that the meter blocks are the key aspect behind this because they allow for a lot more variety of trigger conditions to activate ship-board logic. Lets say your shields are critical; you could have a set of blast doors/forcefields around your ship that activate in order to give your ship a bit more protection until your shields recharge. OR if your base's power is running low you could have logic systems deactivate your factories until the power comes back online - especially useful if you are under attack and need more power to go to your turrets and defenses. Assuming AI gets improved enough, you could have drones with Astrotech and Shield Supply beams that will automatically launch when your shields go down. There are a lot of possibilities with this system if it can be implemented right.

Also I like your idea of the negator and reciprocator blocks, that would make things a lot easier to set up subtraction and division operations. On that note, we could probably do away with all the other operations other than addition. Why? When you think about it, all multiplication and division operations are are addition/subtraction operations that are repeated a certain number of times, and we can use the incrementor operation i described earlier to set those operations up. If we want to multiply, say, 5x5, we can have a memory value of zero, an incrementor loop that stops at 5, and an addition module that adds 5 to the memory value each tick of the loop. Likewise, a division operation (e.g 25/5) would subtract 5 from 25 then increment a counter starting from zero, and end when the memory value is less than 5. The incrementor value would be your quotient and the memory value would be your modulus (remainder).

 

[NeonSturm]

The real problem with logic is, that the player is too big,

I can imagine a RAM-module (v2) which uses just 3 blocks per bit and 20% additional for addressing.

But even with this you need 8x8y8z meters for 16 Byte.
1> Which is way bigger than a password-protected air-lock.
2> Now imagine all the air-lock and password-input logic aside that (easily 16x8y16z; 4x a player`s height)

_______
Logic for a simple password-protected air-lock should not be bigger than the air-lock itself, or space ships become even more un-natural.
/> We all should build for player-models scaled to 2x4y2z instead of 1x2y1z and hope for half-sized blocks.

 

[walle_222]

In response to the OP, setting up operations to do on numbers in the form of bits (ex the number 9 is 1001) is actually not that hard to do. all you need is the modules to do it. for example, in order to add 5 (0101) and 7 (0111) in binary, you would only need 4 full adders (one per bit of information) which take up a minimum of 2x2x4 space per module ( 16 blocks per module and 64 blocks total (and yes i have actually built this)). to be honest its not that much space when looking at stations and decently large ships. however, subtraction, division multiplication and modulo etc. operations are a bit more complicated with binary logic. i have not yet ventured into making modules for this, i might in the near future though.

one main problem that i can see with your method of using dedicated blocks to do arithmetic operations is somehting that has been mentioned already, there is currently no way of setting up which inputs are which. whereas doing operations in binary logic there are set inputs that are easily differentiated between.

in response to the counter block suggestion, a few full adder modules can be substituted depending on how many inputs you are trying to count as long as you know how to set them up.

Edit: managed to find an example of an expanded counter setup that can support 15 inputs (counts which inputs are 1 (high))

 

[Wrexin]

damn, if only I was smarter so I could understand.

 

[Megacrafter127]

In response to the OP, setting up operations to do on numbers in the form of bits (ex the number 9 is 1001) is actually not that hard to do. all you need is the modules to do it. for example, in order to add 5 (0101) and 7 (0111) in binary, you would only need 4 full adders (one per bit of information) which take up a minimum of 2x2x4 space per module ( 16 blocks per module and 64 blocks total (and yes i have actually built this)).

It will still be more of a PITA if you want to use (relatively) huge numbers, which require 32 bit.

 

[Tobie]

How about, instead of adding a bunch of new logic blocks, we could write simple procedural code into a display block. Said code would parse the conditions of all of that display block's inputs and/or outputs and send a signal, or perhaps even code-configured pulses, depending on the results of the code. Turning display blocks into... Conditional Gates?... Procedural Gates?
This would also be great if the entity variables (shields, power, etc) that are currently accessible by display blocks could be read in this code as well.

Spoiler: Example of what that code might look like

Counter(OnSignal,1); //Add 1 to counter when OnSignal Received
if (counter >= 10) {
    Send(OnSignal);
}
else if (Counter < 10 && Input_1 == true && Input_2 == false) {
    StartPulse(2,4); //Pulse two times with a delay of 4 delays (2 seconds)
}
else {
    Send(OffSignal);
}
//For arithmetic:
var value_1;
var value_2;
for each (input == true){
    value_1++;
}
for each (input == false){
    value_2++;
}
if (value_1 > value_2){
    Send(OnSignal);
}

 

[walle_222]

How about, instead of adding a bunch of new logic blocks, we could write simple procedural code into a display block. Said code would parse the conditions of all of that display block's inputs and/or outputs and send a signal, or perhaps even code-configured pulses, depending on the results of the code. Turning display blocks into... Conditional Gates?... Procedural Gates?
This would also be great if the entity variables (shields, power, etc) that are currently accessible by display blocks could be read in this code as well.

Spoiler: Example of what that code might look like

Counter(OnSignal,1); //Add 1 to counter when OnSignal Received
if (counter >= 10) {
    Send(OnSignal);
}
else if (Counter < 10 && Input_1 == true && Input_2 == false) {
    StartPulse(2,4); //Pulse two times with a delay of 4 delays (2 seconds)
}
else {
    Send(OffSignal);
}
//For arithmetic:
var value_1;
var value_2;
for each (input == true){
    value_1++;
}
for each (input == false){
    value_2++;
}
if (value_1 > value_2){
    Send(OnSignal);
}

In other words, adding lua to display blocks? Yes please especially since lua isn't that hard to understand. I would just have to dig through some of my lua scripts from other games to refresh my memory.

 

[Ylliab]

I was thinking about that. The logic on my ship is going crasy just to make some simple auto reset activation blocks.
One of my ideas was to make all work through global variables. We already have some for power and shield levels. Why not be able to define some for ourself or adress some auto generated during the buildingof a ship.
For example when placing an activation block it would get a number and we could use it's boolean value in scripts by using the global var containing all activation blocks values (like an array for example).
Less room for logic would be more coherent with the processors getting smaller and smaller nowdays, if we want to keep some balance with reality.
It might also lighten the computing weight on the processor for all the logic. I have notice that, on my laptop, all is smooth until I start putting some logic blocks. And I don't speek about activating anything.

 

[walle_222]

I was thinking about that. The logic on my ship is going crasy just to make some simple auto reset activation blocks.
One of my ideas was to make all work through global variables. We already have some for power and shield levels. Why not be able to define some for ourself or adress some auto generated during the buildingof a ship.
For example when placing an activation block it would get a number and we could use it's boolean value in scripts by using the global var containing all activation blocks values (like an array for example).
Less room for logic would be more coherent with the processors getting smaller and smaller nowdays, if we want to keep some balance with reality.
It might also lighten the computing weight on the processor for all the logic. I have notice that, on my laptop, all is smooth until I start putting some logic blocks. And I don't speek about activating anything.

Auto reset activation blocks? This video might be what your looking for.

Except i would use the path of :
activation module --> delay --> not gate --> and gate

Still wired in the exact same manner as the video shows except it sends a high pulse instead of a low pulse and the and gate is your output instead of the not gate.