Math blocks

[Lurkily]

So I like logic they way it is, but they idea of analog readings and math keeps coming up. In asides and whispers, perhaps worried that it'll be shot down as embarrassingly out of character with Nimbatus.  I don't think I'd recommend it, but I have a concept on how to implement it. 

This would be a second class of logic blocks - math blocks.  Only an output block would cross that divide, able to output a key or tag based on whether a variable is ==, !=, > or <.

Sensors would have an option to output a variable, as well as ranged key/tag options. (Such as we use now.) Addition blocks could accept two variables and output a third, along with division, subtraction, multiplication, etc.  Thus you could do things like produce decaying averages of sensor readings, or whatever else you like. 

I don't think I'll recommend this, though.  I think solutions to these problems largely exist in basic logic, and that introducing math obsoletes many creative solutions.  Like code, I think mathematical expertise would become a cost-of-entry for complex and efficient builds.  

Right now, a smart novice or an experienced idiot can both work up to very complex behavior with very simple basic tools, and I think that is critical. 

[Ookami-sama]

Where do you input your variable if there is only an output on your mathing block?

My concerns you already have voiced; still, I have but one thing to add: the game's logic is entirely made of boolean numbers right now (True / False, or On / Off), so I am unsure how highly I would value such addition. If you allow me this pun.

[Micha]

I like the idea to apply some conditions to the output events of sensors.
But I'm not sure about the math blocks. 

Part of the fun also comes  from being limited and have to find a creative way to work around the limitations. (At least for me) 
 

[Lurkily]

The output block, like other math blocks, would read a variable, and output a tag or key based on criteria configured in the block. 

Each math block can read and output variables. They need input and output, of course. 

Sensors would create the variable initially, and perhaps some logic parts could set a variable. 

[unmog]

7 hours ago, Lurkily said:

So I like logic they way it is, but they idea of analog readings and math keeps coming up. In asides and whispers, perhaps worried that it'll be shot down as embarrassingly out of character with Nimbatus.  I don't think I'd recommend it, but I have a concept on how to implement it. 

This would be a second class of logic blocks - math blocks.  Only an output block would cross that divide, able to output a key or tag based on whether a variable is ==, !=, > or <.

Sensors would have an option to output a variable, as well as ranged key/tag options. (Such as we use now.) Addition blocks could accept two variables and output a third, along with division, subtraction, multiplication, etc.  Thus you could do things like produce decaying averages of sensor readings, or whatever else you like. 

I don't think I'll recommend this, though.  I think solutions to these problems largely exist in basic logic, and that introducing math obsoletes many creative solutions.  Like code, I think mathematical expertise would become a cost-of-entry for complex and efficient builds.  

Right now, a smart novice or an experienced idiot can both work up to very complex behavior with very simple basic tools, and I think that is critical. 

Yea Im not sure I understood that at all. How would this help me build independant functional turrets?

[Lurkily]

20 minutes ago, unmog said:

Yea Im not sure I understood that at all. How would this help me build independant functional turrets?

It probably wouldn't.  But say you wanted a world-crusher that descended smoothly, strip-mining a planet by altitude instead of just bouncing around drunkenly when it saw land - you could store a value, and every turn, add the current altimeter value to it, divide by two, and have the output overwrite that original value.  An infinite decaying average.

Turrets are simple problems with simple solutions.  I don't think math would help you a great deal; you might read the hinge position of a different turret, to make sure they scanned and covered different directions with little overlap, I suppose.

[unmog]

ooooo, I think I understand it a bit better then. Thanks for clarifying.