LittleBigPlanet 2 - 3 - Vita - Karting #1
Comparing 4 analog signals to find the strongest
Archive: 44 posts
| So I'm down to the last major bug in my level (Yay!) and I'm going crazy trying to figure it out. I have a boss who can trigger attacks that come from the walls, but those attacks need to target the player who is closest to the boss. All the players are controlling bots and each bot has its own tag, so once the closest one has been determined, it can easily be targeted, but I'm having the darndest time figuring out how to tell which one is closest. My solution was to subtract all the signals from each other with combiners. Tag sensor one and tag sensor two go into a combiner and the outgoing signal is checked to see if it's positive or negative. If it's positive, tag sensor one's signal is passed through, but if it's negative, sensor two's signal passes through. The same process is done to signals three and four and then the outcome of one/two is compared to the outcome of three/four. It works.... mostly. The problem is that if there are two equal signals, they cancel each other out completely and the third closest player is targeted. You wouldn't think that there would be much chance of two players being exactly the same distance from the boss, but as it turns out, there's a pretty big zone that's considered 100% by the tag sensors, so if two players are ganging up on him (it's close range combat), the third closest player becomes the target. Since the attacks aren't all that dangerous (they're easy to beat if you're not actively fighting the boss) and are mostly to try to distract you so that the boss can get a hit in, they can be rendered completely useless by this flaw. So is there a better way to compare four analog signals and/or determine which of four tags is closest? | 2011-02-18 12:50:00 Author: Sehven  Posts: 2188 |
| set min radius to be 0.1. this kills the 100% zone. | 2011-02-18 13:26:00 Author: rtm223  Posts: 6497 |
| set min radius to be 0.1. this kills the 100% zone. Heh. I was sure it had to be something simple. Thanks. | 2011-02-18 14:04:00 Author: Sehven Posts: 2188 |
| I have to ask why all the complicated subtraction and comparing when an OR gate is a max() function for analog signals? Just run all four through a 4 port OR gate and the result will always be the strongest. Of course you still won't know "which" one it is - perhaps that's what you're trying to accomplish? Edit: I reread your original post and misunderstood - you are trying to determine which tag is the closest. Sounds like you've got it now with rtm's suggestion. | 2011-02-18 14:18:00 Author: Shanghaidilly  Posts: 153 |
| THat will give you strongest value, not anything by which you identify the source of the strongest value. The OR gate answers the question "how close is the closest?", whereas the answer needs to be "who is the closest?" | 2011-02-18 14:22:00 Author: rtm223 Posts: 6497 |
| How are you determining which is the strongest signal? I havent used combiners in this way. I tried linking the sensors into the combiners but cant get it to sense the closest if all tags are in the radius of the sensors at the same time. I found an alternate way to sense for the closest when they aree all being sensed by using a selector activated by a timer set to speed scale, but it requires a maximum of 0.4 second reactivation reset so that it wont become fixed on just one tag. It works but isnt as quick as I would like. | 2011-02-18 15:42:00 Author: SteveBigGuns  Posts: 423 |
| THat will give you strongest value, not anything by which you identify the source of the strongest value. The OR gate answers the question "how close is the closest?", whereas the answer needs to be "who is the closest?" Another solution, then, would be to get that answer ("How close is the closest?") and then find out who is that close... | 2011-02-18 16:21:00 Author: tetsujin  Posts: 187 |
| Maybe get the closest value with an OR gate , subtract it from all players' values(from values of each player, not from the sum) and take a 0% value | 2011-02-18 16:43:00 Author: darkphoenix  Posts: 97 |
| I don't mean to get off track, but how are you retaining the player data? When I start passing it through AND gates or OR gates and especially combiners, somewhere along the way it gets lost. Plus, the analog/digital duality (as rtm refers to it) drives me crazy as I can compare two values, but since the digital component is not bound to the analog one, I can't convert this to yes/no answers (like if A>B then true, else false). It can be done, but not on the same frame as certain required components introduce latency. | 2011-02-18 17:00:00 Author: Shanghaidilly Posts: 153 |
| Another solution, then, would be to get that answer ("How close is the closest?") and then find out who is that close... by doing: Maybe get the closest value with an OR gate , subtract it from all players' values(from values of each player, not from the sum) and take a 0% value 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. shanghaildilly: you don't need to deal with player data - you have 4 distinct tags in this case, so you automatically have 4 distinct logic paths and can identify player by the input signal number. | 2011-02-18 17:16:00 Author: rtm223 Posts: 6497 |
| @rtm223 Wut? Fail when all tags aren't in the range? | 2011-02-18 17:29:00 Author: darkphoenix Posts: 97 |
| Nope, I'm saying it could fail if the calculations required introduce even a fraction of a percent of error. I don't know if that would happen and even if empirical evidence tells me that it appears sound I can imagine a failure mode... | 2011-02-18 17:37:00 Author: rtm223 Posts: 6497 |
| Couldn't you just use four identical tags on the sackbots? A tag sensor should automatically focus on the closest one. | 2011-02-18 18:32:00 Author: tdarb Posts: 689 |
| (****able lack of nested quotes! We were talking about finding the magnitude of the closest signal, and then selecting signals with that magnitude - as an approach for negotiating who gets targeted. 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 had occurred to me - the possibility that there might be some delay introduced somewhere, in which time the closest player would move away from the monster, and as a result no one would be targeted... But considering the circuit that would likely be used, it doesn't seem like there's an opportunity for this to happen: 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!) If there were delay, the problem could be solved by clocking the circuit. You probably don't want to switch targets too rapidly anyway. I do understand what you mean about not wanting to introduce a potential source of error, though. Sometimes it's just not worth the headaches. | 2011-02-18 21:10:00 Author: tetsujin Posts: 187 |
| Actually, I literally mean the evaluation of the maths that leads to an equality, regardless of temporal issues. Testing which is exactly 0 will fail if errors in the arithmetic exist. The issue is that each selection is evaluated independently, and in the case that error causes none to return true, you have no back up and this "return zero for all" gives you no clues, due to the independence. If error occurs in sehven's method, you can always ensure that 1 or more return true and you also know the reason why they return true (because they are equidistant, or almost so). So you can force a resolution for the error by simply taking one of those equidistantly closest responses, which are equally valid. Or something like that. I started drinking a while ago. The truth is, I don't expect the compare each with min to ever fail, and at worst the return zero for all will occur for single frames incredibly rarely and in that case can pretty much be ignored  | 2011-02-18 21:59:00 Author: rtm223 Posts: 6497 |
| 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. | 2011-02-18 21:59:00 Author: Shanghaidilly Posts: 153 |
| 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. | 2011-02-18 22:19:00 Author: Sehven Posts: 2188 |
| 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...) | 2011-02-18 23:27:00 Author: tetsujin Posts: 187 |
| , 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? | 2011-02-19 01:57:00 Author: rtm223 Posts: 6497 |
| 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. | 2011-02-19 06:03:00 Author: tetsujin Posts: 187 |
| Do you have reason to believe it wouldn't work? Don't take it personally. Rtm has done more with lbp logic than ... um... . 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 [I]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. (https://lbpcentral.lbp-hub.com/index.php?t=50110-Star-Wars-Jedi-Arts-Lightsaber-Duels) | 2011-02-19 07:29:00 Author: Sehven Posts: 2188 |
| 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  | 2011-02-19 14:42:00 Author: rtm223 Posts: 6497 |
| @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. | 2011-02-19 18:07:00 Author: Sehven Posts: 2188 |
| 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. | 2011-02-21 15:22:00 Author: Shanghaidilly Posts: 153 |
| 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). | 2011-02-21 16:34:00 Author: Antikris  Posts: 1340 |
| 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 0i, 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 0i to R, as seen from 0i)*. 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 nth 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 nth closest - i.e. that I would be able to pull out the distance to, and value of the nth 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. | 2011-02-21 19:33:00 Author: rtm223 Posts: 6497 |
| 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 nth 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 nth closest - i.e. that I would be able to pull out the distance to, and value of the nth 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? | 2011-02-22 12:56:00 Author: Sehven Posts: 2188 |
| 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 (https://lbpcentral.lbp-hub.com/index.php?t=48523-Analog-Signal-Display), 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 (https://lbpcentral.lbp-hub.com/index.php?t=44113-Logic-Probe-and-Signal-Combiner) 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). | 2011-02-22 16:20:00 Author: Aya042  Posts: 2870 |
| This logic probe (https://lbpcentral.lbp-hub.com/index.php?t=44113-Logic-Probe-and-Signal-Combiner) 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. | 2011-02-22 16:53:00 Author: Shanghaidilly Posts: 153 |
| 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. | 2011-02-22 17:43:00 Author: Aya042 Posts: 2870 |
| WHY can't we have nice things? The quote for this reply makes no sense unless it includes the nested quote, so I've had to reproduce that myself... 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 (https://lbpcentral.lbp-hub.com/index.php?t=44113-Logic-Probe-and-Signal-Combiner) seems to be able distinguish the two, so open up its chip to see how it works. Ah, Balorn's signal probe and digital/analog combiner. That thing was pretty much my introduction to LBP2 logic, love that thing... I can tell you how it works: In general, to pick the analog or digital component out of a signal, you just hook it up to something that takes that analog or digital portion. So if you hook the signal up to a piece of holo set to "on/off", it'll operate on the digital logic part of the signal. If you want to change an analog signal into a digital one (such that any non-zero analog signal creates a digital "true" state), create a sequencer, set it to "positional", and put in a battery on the whole width of the sequencer. If you want to differentiate between positive and negative signals (digital or analog), use a direction splitter. Balorn's analog/digital combiner is a great tool for understanding LBP2 logic and exploring some of the corner cases that can occur with mismatched analog/digital portions of the signal. You can use it to take any digital logic signal and any analog signal, and combine them into a single signal. Very handy. It's been a while since I've fully explored that circuit, but I can tell you basically how it works. First, if you take a battery at 50%, it has digital +1 and analog 0.5: if you pass it through a NOT gate, you get digital 0 and analog 0.5. If you then combine the two signals in a direction combiner, you get a digital +1 with analog 0 - and if you invert that signal with a NOT gate, you get digital 0 and analog 1.0. You can then use those two signals to strip the analog or digital component out of any signal you like. ((digital X, analog Y) AND (digital 0, analog 1.0) = (digital 0, analog Y)) And if you have a digital-only signal and an analog-only signal, you can combine them with an OR gate. ((digital X, analog 0) OR (digital 0, analog Y) = (digital X, analog Y)) I found Balorn's tools and tutorials very enlightening. I highly recommend exploring them yourself. | 2011-02-22 19:38:00 Author: tetsujin Posts: 187 |
| If you want to change an analog signal into a digital one (such that any non-zero analog signal creates a digital "true" state), create a sequencer, set it to "positional", and put in a battery on the whole width of the sequencer. If you want to differentiate between positive and negative signals (digital or analog), use a direction splitter. You are correct, for the most part. It can fail though if any substantial math is done on the analog component, as LBP2's inaccuracies can cause it to sway one way or another. For instance, I ran a loop where I was adding 1 to a number until it reached another. All analog. So my test consisted of using a combiner, subtracting one from the other, and using a sequencer to test when the difference became negative. The answer? It varied. In a lot of cases, where Balorn's probe showed I had an negative number, or zero, my sequencer still triggered the battery. I even made sure my digital components were squared away, and I got unreliable results. I plan on trying that accurate probe to see exactly what values I was getting. I suspect they are off by enough to cause the sequencer's position to register as a positive number. Also, one caveat to using a sequencer is the built in latency of one frame, and it occurs on the back end. In other words you can send a sequencer a single frame pulse and it will register the result one frame later. Most things that have latency (microchip activation) have it on the front end, and so will not even register with a single frame pulse (unless you use the input node trick). The result for me has been way too many race conditions. EDIT: I want to add that the direction splitter has not been helpful to me at all. Let's say you feed it a negative analog value. You'll get the negative analog out of the bottom output, but with a zero digital component. This is fine if you're feeding movers or rotators. But if you want to test whether you got a negative component - you're right back to the sequencer. I tried to feed this into a combiner using the absolute value of itself, and then testing using a sequencer for a zero. Unfortunately, it also triggers the battery. | 2011-02-22 20:37:00 Author: Shanghaidilly Posts: 153 |
| You are correct, for the most part. It can fail though if any substantial math is done on the analog component, as LBP2's inaccuracies can cause it to sway one way or another. For instance, I ran a loop where I was adding 1 to a number until it reached another. All analog. So my test consisted of using a combiner, subtracting one from the other, and using a sequencer to test when the difference became negative. The answer? It varied. In a lot of cases, where Balorn's probe showed I had an negative number, or zero, my sequencer still triggered the battery. I even made sure my digital components were squared away, and I got unreliable results. Do you mean you used a splitter and a sequencer to test when the difference became negative? I'm not clear on exactly what your test case was... But a sequencer set to positional discards the sign of its input. So it basically activates if you have a non-zero value. And Balorn's signal probe only shows two digits - it is possible to get non-zero analog signals that are less than 1%, which would therefore read zero on his meter. If you need a reading with greater precision, you could try phort's Analog probe (https://lbpcentral.lbp-hub.com/index.php?t=48523-Analog-Signal-Display), which shows 4 digits. Also, one caveat to using a sequencer is the built in latency of one frame, and it occurs on the back end. Quite true. It is important to be aware of the latency. If there's a way around it, though, I don't know it. EDIT: I want to add that the direction splitter has not been helpful to me at all. Let's say you feed it a negative analog value. You'll get the negative analog out of the bottom output, but with a zero digital component. True only if your input signal had a non-negative (positive or zero) digital component. If you hook a controllinator analog stick to a direction splitter, for instance, and you push the stick all the way left, you'll get negative analog and digital components on the output. But if you start with the stick centered and push it left to 50% - the stick will output an analog -0.5 but a digital 0 (because you haven't pushed the stick to 75% yet). The direction splitter performs basically the same operation on the analog and digital portions of the signal. | 2011-02-22 21:02:00 Author: tetsujin Posts: 187 |
| Look at rotators follow whoever and whatever is closest to the center. You don't have to calculate anything for it. Have a tag sensor or player sensor with a skinny radius tilted on the 90 to match the look-at-rotator. Whatever the rotator is pointing at (which will ALWAYS be whatever is closest to it, whether a tag or player, whether 1 or 4), the tag/player sensor's tiny radius (like an old spotlight sensor) will act as your identifier. Adjusting the speed & strength of the look-at rotator alters it's accuracy, and a piece of holo like this can tag-follow itself to whatever spot, appendage or position you want it to on your boss. Wire that sensor into an AND to go with with whatever initiates the attack. http://i8.lbp.me/img/ft/f48b2ec3638d53910c51d126f3b2c16051a34f16.jpg http://ie.lbp.me/img/ft/11e651fc63e00fe1d08f494ab7fcd8fd43d6a705.jpg http://ia.lbp.me/img/ft/6ca70d459b91a427127e383bff6a4deb3c03dd5d.jpg you can have it turn on tags that follow each bot independently, depending on their presence within the look at field. 4 tag sensors labeled or colored for each player in place of that sensor switch, to tell their target-now tag that's following them to turn on and be targeted by whatever means, whether wired or indirect. Your emitters, wherever they are, fire their follower ammo and it heads towards that tag. The following tag, could then be slowed or weakened to effect it's accuracy. | 2011-02-22 21:08:00 Author: Unknown User  |
| Do you mean you used a splitter and a sequencer to test when the difference became negative? I'm not clear on exactly what your test case was... But a sequencer set to positional discards the sign of its input. So it basically activates if you have a non-zero value. And Balorn's signal probe only shows two digits - it is possible to get non-zero analog signals that are less than 1%, which would therefore read zero on his meter. If you need a reading with greater precision, you could try phort's Analog probe (https://lbpcentral.lbp-hub.com/index.php?t=48523-Analog-Signal-Display), which shows 4 digits. Correct. That's the probe I wanted to try next. The thing is that since the sequencer discards the sign of the input, a 0.3 and a -0.3 would still have the sequencer returning the value of the battery. So as I count down (or up using subtraction on the upper limit and the current value), then if there is the smallest inaccuracy, it would go something like 2.06, 1.03, 0.01, and then -0.06 as I loop through. In every case, the sequencer would output the same value since it bypasses an absolute zero, which is the only condition where the sequencer returns zero. The other problem is that I can't use counters for this, since although my test counted up by one, I need to support any value. True only if your input signal had a non-negative (positive or zero) digital component. If you hook a controllinator analog stick to a direction splitter, for instance, and you push the stick all the way left, you'll get negative analog and digital components on the output. But if you start with the stick centered and push it left to 50% - the stick will output an analog -0.5 but a digital 0 (because you haven't pushed the stick to 75% yet). The direction splitter performs basically the same operation on the analog and digital portions of the signal. True, but what I'm struggling with is tying the digital component to the analog component. I need these to stick together, so I can test for negative or positive values, returning a true or false. Let me tell you what I need and perhaps you can help me: A simple analog to digital converter. I need to allow a battery to be hooked up to an input, and whatever the battery is set to be converted to it's binary equivalent (8 wires going into a signed 7-bit register). To do this sounds simple: Just subtract 64 from the number, test the whether it's negative (zero or one for that wire). Then repeat for 32, 16, 8, etc. | 2011-02-22 21:50:00 Author: Shanghaidilly Posts: 153 |
| This might help: http://www.johnher.com/Steamtechgen.html | 2011-02-22 21:57:00 Author: Unknown User |
| Correct. That's the probe I wanted to try next. It's a nice piece of work. It lacks the digital logic portion that Balorn's probe provides (though it's simple enough to implement a digital-only probe separately - it's just a direction splitter and two lights set to ON/OFF) but its capabilities are greater than most analog probes, and phort's done a fair amount of work ensuring that the results displayed by the probe are correct. The thing is that since the sequencer discards the sign of the input, a 0.3 and a -0.3 would still have the sequencer returning the value of the battery. So as I count down (or up using subtraction on the upper limit and the current value), then if there is the smallest inaccuracy, it would go something like 2.06, 1.03, 0.01, and then -0.06 as I loop through. In every case, the sequencer would output the same value since it bypasses an absolute zero, which is the only condition where the sequencer returns zero. If you don't want your positional sequencer to activate when given a negative input, pass its input through a direction splitter and connect the positive output of the splitter to the sequencer. If the splitter gets any negative analog value as input, the analog output of the splitter's positive output will be zero. True, but what I'm struggling with is tying the digital component to the analog component. I need these to stick together, so I can test for negative or positive values, returning a true or false. You can test for a negative analog value with a direction splitter and sequencer. That's easier IMO than trying to make sure the analog and digital parts of a signal match. Most of the time, only one part of the signal is being used in the end anyway... Let me tell you what I need and perhaps you can help me: A simple analog to digital converter. I need to allow a battery to be hooked up to an input, and whatever the battery is set to be converted to it's binary equivalent (8 wires going into a signed 7-bit register). To do this sounds simple: Just subtract 64 from the number, test the whether it's negative (zero or one for that wire). Then repeat for 32, 16, 8, etc. Probably the easiest way to do that is with a big positional sequencer. To get the whole 7 bits all at once, you'd need a sequencer 64 stripes wide. Your highest-order bit would simply be a battery covering the right half of the sequencer range. The next lower-order bit would be two batteries, one covering 0.25-0.5 and one covering 0.75-1.0 - combined with an OR gate. The next bit would be four batteries, 0.125-0.25, 0.375-0.5, 0.625-0.75, and 0.875-1.0... And on until the last bit. The problem with that approach is it's a lot of wiring. The last row would have 64 batteries. And you can't rotate the OR gates, so the sequencer gets very tall unless you use multiple, smaller OR gates to wire up small groups of batteries, and then wire those small groups into larger groups, to get them all into a single sequencer output. You could split up the problem, by decoding, say, 4 bits at once, then subtracting signal values corresponding to those 4 bits from your original signal, multiplying the difference by 16, and then decoding another four bits (dropping the last one, since you only want 7...) Then, to get a sign bit - direction splitter, negative output into a positional sequencer with a battery covering the whole range. That gets you binary signed magnitude. If you want two's complement, you might need to use a binary adder on the magnitude to add the value of the sign bit to the magnitude. Using sequencers means a lot of wiring - but it saves you latency that's incurred by repeated subtraction and testing the sign of the result. (The sequencer has its own latency, but it's one frame of latency per sequencer instead of one frame per bit...) | 2011-02-22 22:35:00 Author: tetsujin Posts: 187 |
| Look at rotators follow whoever and whatever is closest to the center.... They're supposed to, but I got weird results from the "look at" rotator on Vader's lightning bolt. Often, if there were players on either side of him, even if they weren't equidistant, he would fire his lightning into the ground or up into the air instead of at whoever was closest. Since I already had sensors doing the calculations to find the closest player (and they're accurate after Rtm's .1 min range advice), I gave the lightning four "look at" rotators--one for each of the player bots--and set them to be individually turned on/off by the same tag that tells the debris who to attack. Now his lightning and the debris target the closest player without fail. [edit] Holy freakin' typos. I must've been talking to somebody at the same time I typed this comment 'cuz it made no sense at all. Fixed now. | 2011-02-22 23:38:00 Author: Sehven Posts: 2188 |
| Yeah I see what you mean now. I tried it with 4 tag blocks exactly 1 big grid distance from the center holo square with no compensation, and it freaks out. 1 small grid away for 3 of them and it homes on on the 1 big grid distance block remaining. I can't see 'exact' distances being likely outside of grid movement, but it's bound to happen. | 2011-02-23 01:23:00 Author: Unknown User |
| 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. Seems I was wrong on this one. At a guess, the delay is added when linking from a tag sensor to a tag (I suppose as a kind of potential feedback loop??? IDK). Needs more investigation that I don't care enough to do really 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). Not convinced this is deliberate, and even if it is then it's inconsistent as hell The errors I was seeing with scaled systems really correspond to whole frame errors either I don't think. Either way, using a timer-based scaling solution, for whatever reason, is gonna throw you ever-so-slightly off 0 error, was the point I was making So margins of error are still pretty darn useful. Think I need to remake my "entire width of the level" sequencer again for doing < delta comparisons  | 2011-02-23 14:34:00 Author: rtm223 Posts: 6497 |
| If you don't want your positional sequencer to activate when given a negative input, pass its input through a direction splitter and connect the positive output of the splitter to the sequencer. If the splitter gets any negative analog value as input, the analog output of the splitter's positive output will be zero. You can test for a negative analog value with a direction splitter and sequencer. That's easier IMO than trying to make sure the analog and digital parts of a signal match. Most of the time, only one part of the signal is being used in the end anyway... I know I've tried this before, and didn't get the results I was expecting (or needing). But will try again. Thx. Probably the easiest way to do that is with a big positional sequencer. *snip* The problem with that approach is it's a lot of wiring. Which is why I gave up on that approach. With the lag that incurs hooking up that many wires, it became impossible to do. I've derailed this post enough. I've picked it back up here (https://lbpcentral.lbp-hub.com/index.php?t=50781-Why-sequencers-don-t-work-for-me-logic-heads-please-read) if you're interested. | 2011-02-23 15:39:00 Author: Shanghaidilly Posts: 153 |
| At a guess, the delay is added when linking from a tag sensor to a tag (I suppose as a kind of potential feedback loop??? IDK). I don't think it's that clever. I'm beginning to think that the default component update order is sorted by component type (so all tags are always updated before tag sensors), and that order is only modified where there's a connection between one component's output, and another's input, BUT not all inputs are treated as inputs for this reordering algorithm, such as: selector cycle, microchip enable, sequencer position, and now tag enable. Given a chain of tag/sensors, there is only one update order which would make the thing work on a single frame, which is: tag 1, sensor 1, tag 2, sensor 2, but if the "sensor 1 to tag 2" connection isn't counted as dependent for re-ordering, you'll end up with an order something like: tag 1, tag 2, sensor 1, sensor 2, and given that each component is only re-evaluated once per frame, you'll see a frame of latency somewhere in the chain. There's a rather long example in this post (https://lbpcentral.lbp-hub.com/index.php?t=48419-Lamenting-on-the-latency-of-logic&p=769583&viewfull=1#post769583), which is for a microchip enable case, but the theory is the same. What I still can't work out is how the components are ordered by default, particularly when dealing with many instances of the same component. I remember prior to beta 1.02 it was partly based on the order in which the components were created, but after this was changed, I'm not quite sure. While writing this, I was playing with feeding the various sensors into XOR gates in order to detect where the latency was occurring, but in doing so, I noticed something rather strange. Depending on which way 'round I had the inputs wired up into the XOR, the frame would either be there or not, allowing me to completely eliminate all latency from a chain of three tag/sensor pairs. This may hint toward a reverse depth-first or breadth-first tree search in order to determine the update order, and, in theory, may provide a generic method for forcing the update order to be whatever you want. For example, in this photo... http://if.lbp.me/img/ft/c5fb6a3ce76c1a616c1a80eeffb2029c69d68a8a.png ...each sensor is wired into an XOR gate from left to right, and shows a frame of latency between each one, but in this photo... http://i3.lbp.me/img/ft/4c365ff679e61878af71150c704c182b33534404.png ...the sensors are wired right-to-left, and shows zero latency. Kinda defeats the purpose of wireless logic, I suppose, but perhaps useful nonetheless. Not convinced this is deliberate, and even if it is then it's inconsistent as hell Well, that was based on the same speculation I put in this post (https://lbpcentral.lbp-hub.com/index.php?t=47951-Guide-to-Speed-Rotation-and-length-units-in-LBP2-UPDATED-SOME-NEW-INFO&p=765993&viewfull=1#post765993)... ... 0.9s = 27 frames (0) 1.0s = 29 frames (-1) 1.1s = 33 frames (0) ... In retrospect, I suspect the timer being short by one frame was deliberate, and the cases where it's 'correct' are actually the rounding errors. You would assume that creating a 1 second timer and connecting the output to the reset (in order to create a pulse every second) would be quite a common use of timers, but since the reset takes 1 frame to occur, they deliberately fudged the figures so that your timer wouldn't go out of sync by one second for every 30. ...so I see it as kinda consistently inconsistent at least. Either way, using a timer-based scaling solution, for whatever reason, is gonna throw you ever-so-slightly off 0 error, was the point I was making So margins of error are still pretty darn useful.I see. Sure, you're always gonna have problems with floating point accuracy even if you aren't actually doing any mathematical operations, as some numbers are just unrepresentable in floating point. Just asking Python to evaluate 0.1... >>> 0.1 0.10000000000000001 ...is enough to show this. So you always have to use a "delta is less than tolerance" type system when comparing floats. Think I need to remake my "entire width of the level" sequencer again for doing < delta comparisons Heh. | 2011-02-23 16:47:00 Author: Aya042 Posts: 2870 |
| Did that eliminate the latency, or just shift it to prior to the XOR giving a reading? I'm curious if what happened is occurring as an indication of behaviors inside the XOR gate, or as a result of something in the activation order of the tags. If it is inside the XOR, then the latency in the tags is unchanged, and the XOR has just somehow masked it. | 2011-02-23 17:23:00 Author: tdarb Posts: 689 |
| Did that eliminate the latency, or just shift it to prior to the XOR giving a reading? It's completely eliminated - everything goes high on the same frame you grab the grab switch, which also implies that matching tag/sensor combos always update in the correct order, since the tags themselves are not connected to the XOR gate directly. I'm curious if what happened is occurring as an indication of behaviors inside the XOR gate, or as a result of something in the activation order of the tags. It's almost certainly not specific to the XOR gate, I merely exploit it to influence the order in which the connected components are updated. If the algorithm which determines the update order starts with the XOR gate, then iterates through each of its inputs in turn (recursively), then finally reverses the list, that would account for the observed behaviour. The same approach also fixes the selector cycle problem, and the microchip enable one, by feeding back the output into a gate inside the chip. What I still can't seem to eliminate is the positional sequencer one, so it may just be inherent to the way in which they work. | 2011-02-23 18:00:00 Author: Aya042 Posts: 2870 |
LBPCentral Archive Statistics
Posts: 1077139
Threads: 69970
Members: 9661
Archive-Date: 2019-01-19
Datenschutz
Aus dem Archiv wurden alle persönlichen Daten wie Name, Anschrift, Email etc. - aber auch sämtliche Inhalte wie z.B. persönliche Nachrichten - entfernt.
Die Nutzung dieser Webseite erfolgt ohne Speicherung personenbezogener Daten. Es werden keinerlei Cookies, Logs, 3rd-Party-Plugins etc. verwendet.
Die Nutzung dieser Webseite erfolgt ohne Speicherung personenbezogener Daten. Es werden keinerlei Cookies, Logs, 3rd-Party-Plugins etc. verwendet.