I use something like ([Robo-Network-Content] * -1) + Constant-Combinator to set filters.
To check on my outposts I have an percentage indicator at my main base which rotates through the outposts addresses. At each Outpost there is a combinator setup which switches the outpost's content in percentage of a set target level. I have a constant combinator which holds the item counts (like 25 repair packs, 5 turrets, 100 ammunition, ..) for the unloading from my supply train this works just fine. But to calculate the percentages which get reported back to my base I have to manually set up all the individual combinators. (eg. 5 turrets is the target so I have to multiply the count by 5 to get the percentage) But for some bases this value differs from the standard because of size or thread level. So I would like to do this instead: (100/[each target count]) * [each item count] For that to work I need the arithmetic combinator to multiply / divide the green signal with/by the red signal without the automatic addition of both signals.
Re: A way to divide red by green signal?
Posted: Sat Jul 23, 2016 10:40 pm
by DaveMcW
Plug the green wire into an arithmetic combinator
Input: Each * 100
Output: Green signal
Plug the red wire into an arithmetic combinator.
Input: Each * 1
Output: Red signal
Now you can use a third arithmetic combinator to divide the signals
Input: Green signal / Red signal
Re: A way to divide red by green signal?
Posted: Sat Jul 23, 2016 11:34 pm
by EvanT
Each * 1 = red gives the sum of all the input items. eg. (Input: 100 Ammunition, 5 turrets, 20 Repair packs) => 125 red
Each * 100 = red gives the sum of all the input items *100 . eg. (Input: 100 Ammunition, 5 turrets, 20 Repair packs) => 12500 red
Same with green signal.
To calculate the percentage I need to divide the each-item-count on the red cable input by the each-item-count on the green cable.
eg:
Green cable holds the current item count at the outpost.
Red cable holds the target item count at the outpost.
To calculate the percentage:
(100 / [each Red cable item count]) * [each Green cable item count] = [each Percentage]
Re: A way to divide red by green signal?
Posted: Sat Jul 23, 2016 11:47 pm
by XKnight
Yes, it is possible.
But such contraption will be efficient only if you have ~20 different items, otherwise it will be better to use separate combinators for each signal.
Re: A way to divide red by green signal?
Posted: Sun Jul 24, 2016 7:48 am
by XKnight
Also, you can make a semi-solution: divide each signal separately in a loop and put the summary in output.
This setup is bigger than "combinator per signal" with a few signals and slower than "true green-red division" with more than ~20 signals, but if you have ~7-10 signals it will be the best among them:
Hope this will help you.
Blueprint
Do not forget to switch on const combinator (in video).
So there is no simple way like: "Yo noob! Just change the mode setting on the combinator!"
Re: A way to divide red by green signal?
Posted: Tue Jul 26, 2016 10:33 am
by kann_
This is an interesting problem. I didn't check XKnights solution in detail, but isn't there a simple way like how we divide in second class of school?
A/B=C can be changed to B*C=A and even simpler to B+B+B...(C times)=A. Because of the mixing of red and green cable we have to change it to:
A-B-B-B..(C times)>0
So my idea is to have a combinator substract B to itself (EACH<0 = Each(input)). Connect -B-B-B.. and A to a decider second combinator with Each > 0 = Each(1) feeds into a memory cell that keeps track how often "B fits into A".
That should be it. Obviously it only makes sense if C is expected to be reasonable small, which might be a problem.
Since you want percentage values without decimals so the maximum step size should be 100, which is less than 2 seconds. Correct?
Re: A way to divide red by green signal?
Posted: Tue Jul 26, 2016 3:04 pm
by EvanT
The example does address the item type via middle left part. The division per item type is done in the top part. On the right there is a memory cell which accumulates each division result and is reset on each circle.
I guess your solution is even more complex and needs more tics for the complete result than this (item-type-count)
Values from 80% to 150% are the most common. (Because of stack-size-bonus the item count may be higher than the target)
I'm considering making a mod but so far I could not find a method to get the wire-colour-specific circuit-network values. The in-game GUI does show the values separated by wire colour so it must be possible..
Re: A way to divide red by green signal?
Posted: Sun Sep 04, 2016 10:26 pm
by aober93
XKnight wrote:Also, you can make a semi-solution: divide each signal separately in a loop and put the summary in output.
This setup is bigger than "combinator per signal" with a few signals and slower than "true green-red division" with more than ~20 signals, but if you have ~7-10 signals it will be the best among them:
This blueprint is buggy. i get an error message in game . Using mod Blueprint String and Killrog Blueprint manager both getting the same error.
Would you upload a working blueprint again please?
Getting error "Error on event on_gui_click. conversion of data to int failed" when clicking empty blueprint on the mod buttons.
Re: A way to divide red by green signal?
Posted: Mon Sep 05, 2016 5:15 pm
by XKnight
aober93 wrote:
XKnight wrote:Also, you can make a semi-solution: divide each signal separately in a loop and put the summary in output.
This setup is bigger than "combinator per signal" with a few signals and slower than "true green-red division" with more than ~20 signals, but if you have ~7-10 signals it will be the best among them:
This blueprint is buggy. i get an error message in game . Using mod Blueprint String and Killrog Blueprint manager both getting the same error.
Would you upload a working blueprint again please?
Getting error "Error on event on_gui_click. conversion of data to int failed" when clicking empty blueprint on the mod buttons.
Don't understand where problem is, because there is no any error in my version (I am still using 0.13.20).
Anyway, here is the blueprint for KBlueprints (seems like it works in 0.13 and 0.14):