How to buffer events (and use it with a counter)

Quote:

---

Originally Posted by Antikris

This won't work with multiple death events, ergo multiple of the same tags lighting up. What would he tag sensor for 2 or more simultaneous tags need to pick up if not a full 100% signal?

---

I think he didn't explain the whole setup. You could have the tags of different strengths be different colors and thus use different sensors, but still use the same loop. I wanted to call him out on it as well, but it sort of makes sense.

Say your pulses on the enemies all have 1% or 2% signal coming in, through blue and green tags respectively. Have two sets of sensors to detect signal strength for each color and stack them like above (so a sensor for 1 tag, 2 tags, 3 tags, etc). Now you don't need the AND gates and everything will get properly added into the loop. Subtract out as before.

Quote:

---

Originally Posted by Antikris

I tried Matt's setup and noticed that the system keeps pulsing endlessly. It appears, due to what seems rounding errors, that the subtracting bit makes the loop dive below zero. This is interpreted by the sequencer as 'not 0' and thus it never ends. Simple fix is to put a signal splitter in front of the sequencer.

Also, it doesn't need the extra delay in a 3gate selector. A two gate is enough and makes the loop unload faster. However, this also causes one too many pulses and needs a slight delay. So I used a 2gate selector, wired the first output to the result action and the second output to the AND gate that subtracts.

http://i8.lbp.me/img/ft/b5855b1368db...890351223b.jpg

---

i tested this setup and kept gettin one less pulse out than was added, however going back to using the top output of a 2 port selector with the added splitter seemed to fix it. with this setup it is pulsing out every second frame, so it's the fastest solution yet
http://i3.lbp.me/img/ft/533718fdc601...3f2f04d14f.jpg

i also tested this in multiple situations, 5 in on one frame, 5 in on consecutive frames then a mix of both and it always pulsed out 5, where using the 2nd output of the selector i kept getting 4

Quote:

---

Originally Posted by comphermc

You could have the tags of different strengths be different colors and thus use different sensors, but still use the same loop.

---

You don't need to use different colors.

If you set a tag sensor to "signal strength" mode, then the "number of keys required" will determine which tag's signal strength it outputs. Setting it to 1 will give the signal strength of the first tag to be enabled within its radius, setting it to 2 will give the signal strength of the second tag to be enabled within its radius, etc.

So this circuit...

http://i3.lbp.me/img/ft/e93ed0a837fc...69a447f086.png

...always outputs the sum of the signal strengths of all green tags (up to five) in its radius, regardless of what values you use... well... except if the sum exceeds 100%. :p

The point about using the emitter is that activating an emitter and a destroyer on the same object on the same frame will cause the emitter to fire, but activating a tag and a destroyer on the same object on the same frame will not cause the tag to enable.

Quote:

---

Originally Posted by Aya042

If you set a tag sensor to "signal strength" mode, then the "number of keys required" will determine which tag's signal strength it outputs. Setting it to 1 will give the signal strength of the first tag to be enabled within its radius, setting it to 2 will give the signal strength of the second tag to be enabled within its radius, etc.

---

Okay. That was a lie. It's actually as rtm223 posted just over a year ago...

Quote:

---

Originally Posted by rtm223

Also, worth noting is that if you use "signal strength" on a tag sensor, and there are multiple matching tags, it will pull the value of the n^th highest signal strength (where n is the number required), regardless of distance. Not sure if this is news to anyone else but me - I seem to remember from the beta assumed that it would pull the strength of the n^th closest - i.e. that I would be able to pull out the distance to, and value of the n^th closest matching tag by using a pair of sensors. This is not the case. Indeed I don't think there is any way to match up the distances and strengths of each tag in a neat manner.

---

...where "highest signal strength" is determined only by the signal's magnitude - the sign is ignored. Still, the main point was that each sensor always measures the strength of a different tag, so the signal summing logic works either way.

This is actually better, cos it means you can easily sort analog signals from highest to lowest, so if your signals are 'scores' and also contain player color info, you can easily output the scores and colors of the players in 1st, 2nd, 3rd, 4th places.

Not sure if it helps for evret's four-signal sorting chip. Best I could think of was to add a distinct microscopic signal to each 'score' before sorting, then subtract the original signal after sorting, and use the remaining signal to determine which was which.