Comparing 4 analog signals to find the strongest

[Shanghaidilly]

target_a = (signal_a - max_signal) >= 0 (Direction combiner, negative output feeding a sequencer which feeds a NOT gate)
max_signal = max(signal_a, signal_b, signal_c, signal_d) (OR gate)

signal_a and max_signal are only one gate apart - an OR gate - there shouldn't be any delay there, and there's no reason the signals should differ. (If they did differ, though - that would be an interesting!)

In my testing, the "type" of component is what introduces latency. I found no latency with any of the gates. I sent a single frame pulse down 200 gates hooked in series and ANDed that with a straight path. Both occurred at the same time (evidenced by a light bulb flashing from the output of the end AND gate.

I haven't fully tested sequencers, but I believe they incur one frame of latency. So does activating a microchip (unless you trick the simulation into processing the components in the same pass).

The problem I see above is that one path has a sequencer in it and the other doesn't. They're off by one frame (assuming that sequencers do incur latency). However, the chances that one of the targets would move within one frame enough to matter doesn't seem very likely to me.

[Sehven•]

How are you determining which is the strongest signal? I havent used combiners in this way.

I've got the tag sensors set to "closeness" so they're outputting analog signals based on how close the tags are. When you wire an analog signal into the top of a combiner and another into the bottom, the bottom one is subtracted from the top one (see Rtm's logic blog). So if I've got 80% going into the top and 90% into the bottom, the result is -10%. Then I run it through a signal splitter so any positive signals go to the top and any negative signals go to the bottom. In the example I gave, the top wouldn't get any signal and the bottom would get 10%. I need to convert that to 100% so I run it through a positional sequencer with a batt covering the whole thing (Rtm can probably tell us a better way to convert it ) and run the output of the sequencer through an AND gate with the original signal so that the original signal gets passed through (AND gates will pass the lowest strength signal-see Rtm's blog again). The result is that whichever of the two signals is stronger gets passed through the circuit while the weaker one gets cut off. Then I repeat it for the other two tags and run the two results through another subtractor, giving me the final answer.

Another solution, then, would be to get that answer ("How close is the closest?") and then find out who is that close...

It's a valid theory, but you do have to assume completely zero error for this. I don't know if that is the case though - but it's a clear potential failure mode. With sehven's method you only have to worry about failure in the case of players being equidistant, which can be solved with a simple order of precedence.

That's actually a really freakin' good idea and it would completely eliminate the possibility of two equidistant players cancelling each other out and causing the boss to target the third, further away player. I can't imagine there would be that much potential for failure: each player would have a unique tag and a generic tag. The OR would output the strongest of the generic unique tags and then the result would run through four combiners: one for each of the unique tags; and an output of 0 would signal TRUE. Rather than two players cancelling each other out, both would become targets, which, as Rtm said, can be solved by prioritizing them. I think my method works now after Rtm's suggestion (I'll have to get four players together to test it sometime this evening), but if it doesn't, I'll definitely give your idea a go. As for the margin of error, I could just set it to consider any value below 1% to be true.

[tetsujin]

In my testing, the "type" of component is what introduces latency. I found no latency with any of the gates. I sent a single frame pulse down 200 gates hooked in series and ANDed that with a straight path. Both occurred at the same time (evidenced by a light bulb flashing from the output of the end AND gate.

I haven't fully tested sequencers, but I believe they incur one frame of latency.

Yes, I believe so.

The problem I see above is that one path has a sequencer in it and the other doesn't. They're off by one frame (assuming that sequencers do incur latency). However, the chances that one of the targets would move within one frame enough to matter doesn't seem very likely to me.

Well, if there's a mismatched latency, then any movement will cause it to fail if it's an "equality" test, and any movement away from the monster will cause it to fail if it's a "greater than or equal" test...

But I think you've misunderstood my suggestion. "target_a" is a Boolean telling you whether target_a is one of the targets at the closest range. The "two paths" leading into the direction combiner are max_signal and signal_a. Neither of those paths incurs any delay.

max_signal = max(signal_a, signal_b, signal_c, signal_d)
max_signal is just an OR gate on four inputs. No latency.

target_a = (signal_a - max_signal) >= 0
target_a takes, as input, one of the four input signals and the result from the OR gate, compares them with a direction combiner. Since the OR gate shouldn't be producing any latency, the two inputs will match exactly for at least one of the four players... The output of the direction combiner contains the answer - of whether this is the player you want or not, you just need to process it a bit to get the information into a usable form. This incurs some latency, but the timing-critical portion of the work is already done.

(Also, in my earlier post, I left out the direction splitter from the definition of target_a, which is necessary for "greater than or equal"... It's not strictly necessary since at least one of the direction combiner results will be zero...)

[rtm223]

, the two inputs will match exactly for at least one of the four player

By "will", you mean "should, probably", or "almost certainly will", right?

[tetsujin]

By "will", you mean "should, probably", or "almost certainly will", right?

Do you have reason to believe it wouldn't work? I mean, what would go wrong? Does the OR gate not give exact values? Does the OR gate insert a delay? Does a direction combiner yield a nonzero result for equal inputs? Unless the answer is "yes" to at least one of those questions, the thing will work. It seems to me any of those results would break a lot of current assumptions about LBP logic.

[Sehven•]

Do you have reason to believe it wouldn't work?

Don't take it personally. Rtm has done more with lbp logic than ... um... [insert hyperbolic metaphor that I can't think of atm here]. He's run into things that seemed right on paper, so to speak, but didn't quite work as expected in game, so in his mind, until it's tested, it isn't true. And he's right. I agree that your idea sounds great and will almost certainly work (if I were a betting man, I'd bet on it), but before you can declare something fact, it has to be tested.

Anyway, the logic is working as far as I can tell--I was only able to test it with two players since I couldn't get any of my friends to connect except one but the odd behavior appears to have been eliminated (it used to take a while to switch targets when one moved closer, but now it seems to do it instantly/near-instantly). In addition to raising the minimum range to 0.1, I offset the maximum range of each sensor by 0.1 (player 1's sensor range is 500, player 2's is 500.1, and so on) to further reduce the possibility that two players could ever generate exactly the same distance. I should have the level published soon.
[edit] Published it.

[rtm223]

Do you have reason to believe it wouldn't work?

Yes, as I stated above, the reliability of the system depends entirely on an assumed property of the logic (zero error) which we can't know is true or not. It's a simple mental process - identify things that could go wrong. Decide if those things can happen. If the answer is yes or maybe, then you have a potential failure mode. I'd probably just add margins on the comparison to make it more robust (i.e. (abs(a-b) < 1%) rather than (a-b) == 0)).


I'd still put money on the method passing tests 100% of the time though, without the margins of error


@sehven, the modification of the ranges is quite a nice touch actually. Hard to know how much benefit you'd gain from it, but it certainly can't hurt

[Sehven•]

@sehven, the modification of the ranges is quite a nice touch actually. Hard to know how much benefit you'd gain from it, but it certainly can't hurt

Yeah, I figure there must be some rounding in lbp, but it's pretty clear that analog signals have decimals that we can't see. I set up a 500 second timer, set its current time to 499.9 and ran it through a combiner with a 100% battery and a 99% one. It registered as stronger than the 99% but weaker than the 100%. I'm not sure how deep the decimals go, but I'd bet that it would be impossible to get two tags to register identical distance percentages when one has an extra .1 in its detection.

I was able to get into a three player game last night after I published and I watched the behavior during the Darth Vader fight (that's who the boss is). I watched as one player moved further from Vader than another and the debris (he uses the force to throw debris at you like at the end of "Empire") immediately changed course to home in on the closer player (closer to Vader, not to the debris). I haven't seen it in four player yet, but as far as I can tell, it seems to work perfectly.

[Shanghaidilly]

Yes, as I stated above, the reliability of the system depends entirely on an assumed property of the logic (zero error) which we can't know is true or not. It's a simple mental process - identify things that could go wrong. Decide if those things can happen. If the answer is yes or maybe, then you have a potential failure mode. I'd probably just add margins on the comparison to make it more robust (i.e. (abs(a-b) < 1%) rather than (a-b) == 0)).

I ran into this very thing over the weekend. I tried testing for a zero value by subtracting what I thought should be the same analog signals (after guaranteeing that the digital components were equal). Running it through a probe, I saw a value of 0 analog and 0 digital. However, when running it through a sequencer, I got a value of slightly greater than zero - so a battery run across the length of the sequencer always returned the value set in the battery. Hooking a battery set to zero into the same sequencer returned no value.

I've still not solved my inability to test for a negative analog values. Most things work off the digital component, and the duality of the signals makes it impossible to use one for the other.

[Antikris•]

I haven't seen it in four player yet, but as far as I can tell, it seems to work perfectly.

If you are short a tester, hook me up on PSN (Stellakris).

[rtm223]

Ok, so I actually had cause to play around with something like this over the weekend for something so ridiculously overcomplicated I sharn't get into it. However, as part of that, I had to select the closest of n objects, where n was a subset of potentially a very large number of objects in the level and the value of n varied due to many factors, including objects being emitted / destroyed elements in the level and, due to emitting, there is also the potential for duplicate objects in the level.

Anyways, because of the unknown number of elements, I ended up going for the comparing each signal to the minimum. Because of the dynamic creation of the elements and not realistically being able to assign individual elements with unique tags, I ended up finding the value from the reference point to the closest target object (minimum of the distances from R to 0_i, as seen from R)*. I then detected the distance from each object to the reference point and compared these values at each target object (dist from 0_i to R, as seen from 0_i)*.

However, to get the target object's "distance to closest node" I had to transmit this back to all the objects for comparison... and this is where it got messy. Each tag sensor was incurring a frame of delay and the values to be compared were going through different length paths (one signal had one frame of delay and the other had none). This became apparent as soon as I introduced moving targets and moving reference points into the equation.

At this point it's worth noting that none of the processing so far appeared to be introducing any error (I was ignoring my own advice and using an exactly 0 comparison ).

I tried adding in a delay using a timer-based "divide by 1" circuit and this was pretty confusing TBH. I assume it was introducing error, but i'd have to go back and check exactly how and where (hypothesis: speed-driven timers). I ended up adding an additional wireless link at each target object, to bring the 2 paths back into temporal alignment (basically routing the signal out of the microchip and transmitting it back in again). During the writing of this paragraph I just realised I would have been far better off to do this at the reference point than at each and every target, so clearly it was worth me writing this post even if no one understands what I'm getting at - nope, that's a lie, ignore it.


The short version is that in any distributed system using wireless logic, always remember that wireless transmission (via tags, haven't thought to check controlinators) inserts a delay for every wireless link in the chain. Also, timer-based analogue devices are not zero error, though most other devices appear to be.


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.


*Other observation that I had forgotten about: I have a hunch that the values of distance read in opposite directions may not always be exactly identical. Can't say for sure, but the analogue value produced needs a fair amount of floating point calcs to obtain the result so errors may occur. It's not causing me issues as it's equal often enough for my purposes and I loosened timing constraints to trigger at a point when it was exactly equal, but I really should be adding in margins of error I think.

[Sehven•]

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.

Hm, yeah.... this was about the only part of your post I understood I suppose you could consider a tag sensor with a requirement of >1 tags to be an AND gate. It'll output the lowest value of the inputs. Of course it has the advantage of being able to pick the strongest inputs of a larger group (tag sensor that requires three tags will output the third strongest signal and ignore the fourth and so on). [edit] Oops, turns out I misunderstood that too. Yeah, I knew (and was annoyed) that the signal strength setting completely disregards distance and vice versa. That was why I was asking you about a circuit to average the two values a while back.

As for matching distance and strength, I suppose you could have the receiver grab the distance value and then re-transmit it. The thing being detected could receive the re-transmitted signal and compare to see if it matches its own reading and, if so, transmit its strength signal. ..... that's probably what you said and I just didn't understand it. But if the lag and the floating point variance (if your hypothesis about that is correct) mess it up, then I guess that wouldn't work. Maybe you could use one of your samplers to record the value from a few cycles ago and compare it to the transmitted value to overcome the lag?

[Aya042]

Yeah, I figure there must be some rounding in lbp, but it's pretty clear that analog signals have decimals that we can't see.

You can see some of them with this, but I suspect there's around 6-7 decimal places based on a 24-bit mantissa.

I've still not solved my inability to test for a negative analog values. Most things work off the digital component, and the duality of the signals makes it impossible to use one for the other.

This logic probe seems to be able distinguish the two, so open up its chip to see how it works.

...always remember that wireless transmission (via tags, haven't thought to check controlinators) inserts a delay for every wireless link in the chain.

I don't think that's right. When I test a chain of tag/sensors, it seems like the latency is between the sensor and the next tag in the chain, rather than between the tag and the sensor, although it's tough to tell.

If you're right, then connecting an grab switch to an XOR gate, both directly, and via a tag/sensor combo should make the XOR high for 1 frame, but it doesn't, so it could be one of these component update order problems.

Also, timer-based analogue devices are not zero error, though most other devices appear to be.

Not quite sure what you mean here, but bear in mind that timers are deliberately inaccurate. For most max values they're off by one frame, so a timer val=0.5 max=1.0 will output a signal of 14/29ths (0.4827), rather than the more obvious 15/30ths (0.5).

[Shanghaidilly]

This logic probe seems to be able distinguish the two, so open up its chip to see how it works.

I'd love to, but it's locked. I can't open it up or take apart the object (or haven't figured out how to). That's the probe I use, BTW.

[Aya042]

I'd love to, but it's locked. I can't open it up or take apart the object (or haven't figured out how to). That's the probe I use, BTW.

Just hold the popit cursor over the long chip at the bottom and press R1 - works on my copy.