LBP Showcase / Reviews / Recommendations #1
Mutual Exclusion Switch
Archive: 55 posts
| Hiphopliveson sent me a PM asking if I could make a 3-input set-reset last night, and as luck would have it, I actually made one a couple of days ago, so I've modified my design and uploaded it into a demo level. The principle is for a device that has n inputs and n outputs, where only one of the outputs can ever be active at any one time. So if you activate input 1, output 1 becomes active... activate input 2 and output 2 becomes active, but output 1 becomes inactive, etc. The design uploaded is based off of Aya's Zero latency set resets (https://lbpcentral.lbp-hub.com/index.php?t=23400-Zero-Latency-Set-Reset-and-Toggle-Switch&highlight=latency), but slightly modified for several inputs / outputs. It's fully modular, so each input/output pair has a device and you just place down as many as you require, with no inter-wiring required - this is also a major bonus on the thermo considerations as you add more and more devices in. Downsides: It needs 1-shot inputs, and I'm not entirely sure what happens if two inputs are triggered at once - it probably ends up with both being canceled out and no outputs being active at all. This therefore is a design consideration and quite possibly a feature  Level Name: Mutual Exclusion Switch for hiphopliveson PSN: rtm223 Location North pole | 2010-04-07 17:09:00 Author: rtm223  Posts: 6497 |
| This could be useful - you mentioned it would work in principle for n inputs, so it would be easy to take the design and modify it to be a 6-input? Because that may help me out a good deal. | 2010-04-07 17:41:00 Author: Jagrevi  Posts: 1154 |
| Yep, it's completely modular. The example a published is for 5 and you will see 5 blocks sitting next to each other in the logic part. You just need to add an extra block alongside and it will work. My application will require one of these for every checkpoint in a level, so obviously the modularity is a massive bonus as I currently don't know how many checkpoints will be required. | 2010-04-07 17:54:00 Author: rtm223 Posts: 6497 |
| I guess just using 3 set-resets is a no-go? I'm pretty sure shadowheaven tasked me with a similar issue. It had 4 lights, and each light was activated by a switch. If any other light was switched on, it would switch off the active one. Or am I misunderstanding? | 2010-04-07 17:54:00 Author: comphermc  Posts: 5338 |
| Well I had a look at making this out of more traditional set-resets (both in modular, self-resetting format and in a OR'd reset format), but it worked out more complex than this method. Plus if you use the modular directional set-reset (which is the only practical alternative - the non-modular OR'd reset was a horrible drain on thermo) you end up with timing considerations on the inputs (i.e. the input must be active long enough to ensure that the previous output has reset) and I think there was even more awkwardness than that as well. | 2010-04-07 18:01:00 Author: rtm223 Posts: 6497 |
Hey thanks a million ...  YOU ARE THE BEST !!! | 2010-04-07 18:59:00 Author: hiphopliveson  Posts: 47 |
| Hiphopliveson sent me a PM asking if I could make a 3-input set-reset last night, and as luck would have it, I actually made one a couple of days ago, so I've modified my design and uploaded it into a demo level. I just took a closer look at this, as I neglected to save the copy you left on my moon. Probably a good thing anyway, since I wouldn't want to come back later and find you'd also left your lips on my piston.  It's quite ingenious actually, and quite possibly the first practical application where 'one-shot' logic is actually more thermo-efficient than directional logic. Plus, of course, you get the benefit of zero-latency, at least in the off->on transition for each LED, so it's kinda the best of both worlds. Downsides: It needs 1-shot inputs, and I'm not entirely sure what happens if two inputs are triggered at once - it probably ends up with both being canceled out and no outputs being active at all. This therefore is a design consideration and quite possibly a feature I don't see why requiring one-shot inputs is that problematic, and after testing, as I was expecting, firing two at the same time causes both blocks of dissolve to be annihilated simultaneously. Not much of a 'feature', since it's probably more efficient to have a separate emitter fire a mag key into the radius of all the switches, should you need the ability to reset it to its initial state. However, as I mentioned previously, unless you're wiring the same switch output to multiple inputs, this is highly unlikely to occur in practical use, since it's only a problem if both inputs fire on exactly the same simulation clock tick. As long as there's at least one tick between each input being triggered, then, in theory, whichever input was triggered last will 'win'. Actually, screw theory, I just tested this. If I chain together two piston-based buffers, so that one fires about 25ms after the other (which is faster than the speed of dissolve), and feed one into each of the two emitters, then the last one triggered does indeed 'win'. When I re-tested with a chain of one-shot buffers, then it fails, since they do fire on the same clock tick. This also might be further evidence to support my earlier speculation about this query of yours... Would this be evidence that emitted mag switches will trigger in the order of which one was emitted first? I think that's how it works when you place mag switches into a level, so it would make sense. I'm just suprised it works with dissolve as there is latency so you'd think all of the switches would have time to trigger....I think what actually happens is that the dissolved block, or at least the components stuck on it, are removed from the simulation on the same clock tick as its mutually-annihilating partner is emitted. The reason why it then takes another 35(ish)ms to cause any switches relying on it to change state is less obvious. | 2010-04-07 20:37:00 Author: Aya042  Posts: 2870 |
yes i understand what you guys are talking about , but, in my level ... the triggers are quite distant and that equals up a rather small chance for 2 of them (or 3 in my case)to be triggered at the same time... if this actually does screw up when im testing tomorrow ... il change that part of the lvl... i can manage to what my possibilities are ...  | 2010-04-07 21:25:00 Author: hiphopliveson Posts: 47 |
| Right, forgive me for being a *******, but I'm trying to improve my logic knowledge and this is as good a place as any to start. In theory it sounds useful, but as usual i have difficulty imagining actually applying it to anything. Can you give me a quick 'in game example' (i.e. Stephen Fry language ) of how this could be used? | 2010-04-07 21:34:00 Author: julesyjules  Posts: 1156 |
| I must tell you guys that so far it works in singleplayer,but, it has to be playable by 4 sackpeople... it has some multiplayer challenges... il post again tomorrow in this same thread... | 2010-04-07 21:45:00 Author: hiphopliveson Posts: 47 |
| I was wondering if I could design one and submit it to you. I'm kinda not sure what you want though. Do you want it to be customizable for how many inputs and outputs you have or do you just want a set number made for your needs? I think I understand the mutual exclusion part of having only each thing active, like if you had 3 things that were tied to this switch and you activated one the others would deactivate. Just let me know if I could help, I would really love to. | 2010-04-08 00:32:00 Author: Brian.C.Powers  Posts: 54 |
| I don't see why requiring one-shot inputs is that problematic, and after testing, as I was expecting, firing two at the same time causes both blocks of dissolve to be annihilated simultaneously. Not much of a 'feature', since it's probably more efficient to have a separate emitter fire a mag key into the radius of all the switches, should you need the ability to reset it to its initial state. I'd just rather everything ran off a directional signal, it's not that much of an issue though. As for the "feature" thing, I just like branding any annoyance in behaviour as a potential feature If I chain together two piston-based buffers, so that one fires about 25ms after the other (which is faster than the speed of dissolve), and feed one into each of the two emitters, then the last one triggered does indeed 'win'. When I re-tested with a chain of one-shot buffers, then it fails, since they do fire on the same clock tick. This is what I was expecting to be the case, but thanks for testing it This of course would be a distinct benefit of one-shot logic in this case, I guess.yes i understand what you guys are talking about , but, in my level ... the triggers are quite distant and that equals up a rather small chance for 2 of them (or 3 in my case)to be triggered at the same time... if this actually does screw up when im testing tomorrow ... il change that part of the lvl... i can manage to what my possibilities are ... You would have to trigger 2 of them at exactly the same moment in time for it to make any difference, is the gist of Aya's experiment. Right, forgive me for being a *******, but I'm trying to improve my logic knowledge and this is as good a place as any to start. In theory it sounds useful, but as usual i have difficulty imagining actually applying it to anything. You're forgiven Not a practical example of how to use it, but it is the basic principle on which checkpoints work. When you trigger one, the one that is currently active is turned off, only one can be active at any given time. My actual application is simply to light up checkpoints, so that when you run past them, they light up, and the old one's light switches off. I'm sure you could work a puzzle around such a dynamic as well.I was wondering if I could design one and submit it to you. I'm kinda not sure what you want though. Do you want it to be customizable for how many inputs and outputs you have or do you just want a set number made for your needs? I think I understand the mutual exclusion part of having only each thing active, like if you had 3 things that were tied to this switch and you activated one the others would deactivate. Just let me know if I could help, I would really love to. That is the basic idea, but I have solved the problem for any number of input/output pairs, this thread was just to share it with other people, seeing as I've published the level for hiphhopliveson anyways. Feel free to come up with your own solution though and share it with us though | 2010-04-08 00:52:00 Author: rtm223 Posts: 6497 |
| Nevermind then. Just wondering if I could help in any way whatsoever. | 2010-04-08 00:56:00 Author: Brian.C.Powers Posts: 54 |
| What exactly is a 3-input set-reset? How is it related to your mutual exclusion switch? Anyway, brilliant work, as usual | 2010-04-08 01:34:00 Author: Incinerator22  Posts: 3251 |
| A 3-input set-reset is how hiphopliveson described it in his original PM. The behaviour he was looking for is what I had already made for this, so effectively, what he was describing is a 3-input version of this. Note that if you create a 2-input version of this, you end up with something essentially the same as Aya's set-reset. On a side note, Aya came up with the "mutual exclusion" moniker. I'm not entirely happy with it, as although the outputs are mutually exclusive, the term mutual exclusion has other, more complex meanings as far as I'm concerned. But I couldn't think of anything better, so mutual exclusion it is | 2010-04-08 01:52:00 Author: rtm223 Posts: 6497 |
| What about mutual single output switch? A single output from many possible inputs. I think that's a simpler and better way to word it. | 2010-04-08 02:02:00 Author: Incinerator22 Posts: 3251 |
| ok... here's what im working with... there are 4 platforms that stay put , and 2 moveable ones. the logic is going to make the 2 moveable platforms to change position ... in order to ascend you must push a button to trigger the next position , but , there are 3 so its A,B and C ... ok... if you fall from C to A then push button !A the 2 moveable platforms will come in position A then you climb them and get to button !B... and the same goes for !C ... this switch resolved 95 % of my problems ... it works ... you just need to adjust it to suit your lvl or needs ... | 2010-04-08 02:11:00 Author: hiphopliveson Posts: 47 |
| On a side note, Aya came up with the "mutual exclusion" moniker. I'm not entirely happy with it, as although the outputs are mutually exclusive, the term mutual exclusion has other, more complex meanings as far as I'm concerned. Really? I don't remember coming up with that name. It's true that the term "mutual exclusion" is more commonly used in a programming sense (http://en.wikipedia.org/wiki/Mutual_exclusion) (assuming that's the more "complex meaning" you're referring to), but its use in programming is ultimately derived from the discrete mathematics sense (http://en.wikipedia.org/wiki/Mutually_exclusive_events). The closest equivalent in electronics would be a finite-state machine (http://en.wikipedia.org/wiki/Finite-state_machine), albeit with a very limited state transitions. Indeed, your "ordered inputs tool" is another example of a finite-state machine. | 2010-04-08 02:38:00 Author: Aya042 Posts: 2870 |
| I checked it out, and it IS far superior to using set-resets. The only complaint I have is that the magnetic key radius on the emitted bits is too small. You mentioned extendability, but if you make it too long, you have to tweak the objects in the emitters. This isn't a problem for me, since I'd just make my own, but if you're giving it away as if it were a tool to be used, then you might want to tweak that. Should take you all of 45 seconds. (Well, actually, Clapton just put it down in my level, and I assumed it was yours. For all I know, it could be a recreation.) Yep, it wasn't yours. | 2010-04-08 03:44:00 Author: comphermc Posts: 5338 |
| The only complaint I have is that the magnetic key radius on the emitted bits is too small. You mentioned extendability, but if you make it too long, you have to tweak the objects in the emitters. Problem is if you make the radius too large, then other mag keys in the level might start interfering with it. | 2010-04-08 03:57:00 Author: Aya042 Posts: 2870 |
| Yeah, but I noticed problems with as few as four inputs... | 2010-04-08 04:19:00 Author: comphermc Posts: 5338 |
| Yeah, but I noticed problems with as few as four inputs... Doesn't sound like rtm's version then. The radii were large enough to fit way more than that many in. | 2010-04-08 04:32:00 Author: Aya042 Posts: 2870 |
| Ah, I apologize then. Silly Clapton! | 2010-04-08 04:35:00 Author: comphermc Posts: 5338 |
| I noticed something... rtm is finally seeing the light and using dissolve! Furthermore, this switch doesn't use a single winch! | 2010-04-08 08:21:00 Author: Incinerator22 Posts: 3251 |
| Really? I don't remember coming up with that name. On your moon, you were like "ahh, mutual exclusion". I am aware of the origins of the phrase, but it doesn't stop me thinking of mutex semaphores when I hear it, despite me having been familiar with it in maths (from basic probability), for so much longer. Of course, now I'm trying to think of a use for a mutex switch so that I have justification for designing one. Problem is if you make the radius too large, then other mag keys in the level might start interfering with it. This is an annoyance with those "backwards looking" mag switches (on the dissolve). You do need quite a large number of i/o pairs for it to become significant though, and I now tend to keep a policy that a couple of magswitch colours are "reserved", so that if you need large area detection, you don't end up interfering with other parts of the level (and vice versa). Especially after it took me sooo long playing "hunt the mag key" whilst doing some logic enhancements on Grant's section of Cap'n SackBeard's Booty  rtm is finally seeing the light and using dissolve! Self-dissolving emitted dissolve though, which I've always been a fan of | 2010-04-08 09:07:00 Author: rtm223 Posts: 6497 |
| Furthermore, this switch doesn't use a single winch! Quick, rtm! You'd better add a winch in somewhere! On your moon, you were like "ahh, mutual exclusion". Ah. That's possible. Still a pretty accurate description. From WP... In probability theory, events E1, E2, ..., En are said to be mutually exclusive if the occurrence of any one of them automatically implies the non-occurrence of the remaining n − 1 events. ...but you're right in that there's more to it than that, after all, the randomizer in the logic pack also has mutually exclusive outputs, but there's more to it than that. I am aware of the origins of the phrase, but it doesn't stop me thinking of mutex semaphores when I hear it, despite me having been familiar with it in maths (from basic probability), for so much longer. I assumed as much, although that was more for the benefit of those who might not be so geeky familiar with such concepts. This is an annoyance with those "backwards looking" mag switches (on the dissolve). Indeed. That's why most of my designs, including this SR-latch... http://www.lbpcentral.com/forums/attachment.php?attachmentid=13872 ...have much more DM than they really need. It's to ensure that the radii of all the mag switches never extend beyond the bounds of the device, so it can't be interfered with by any other device. Of course, that's never really going to be possible for an extensible design such as yours. | 2010-04-08 13:57:00 Author: Aya042 Posts: 2870 |
| Ah, I apologize then. Silly Clapton! >_> Heh heh. Yeah...silly. :kz: Well, when I tweaked the radii on the dissolve switches to 320' (like rtm's version), every other emitter would trigger and none of the pieces would "exclude" the others. Apparently my clone version needs some fine-tuning to function as it's intended to. | 2010-04-09 19:21:00 Author: claptonfann  Posts: 228 |
| NYEH? God, I wish I knew what you were talking about... | 2010-04-09 19:50:00 Author: SPONGMONKEY56  Posts: 209 |
| NYEH? God, I wish I knew what you were talking about... You should try rtm's level. It's very simple when you actually see it. In rtm's example, there are 5 sensor switches and 5 lights. Each sensor switch you trigger activates the light it's attached to, and turns off the other light. Only one light can ever be active at once even when multiple sensor switches are active. rtm wrote how it can be useful: for checkpoints. It can be used to control checkpoints by switches, because each time it activates a new checkpoint, the other one will turn off. | 2010-04-10 00:56:00 Author: Incinerator22 Posts: 3251 |
| rtm wrote how it can be useful: for checkpoints. It can be used to control checkpoints by switches, because each time it activates a new checkpoint, the other one will turn off. Actually, no. The checkpoints already have this feature built in, only one of them may be active at any time. I was simply using the checkpoints as an analogy. | 2010-04-10 17:28:00 Author: rtm223 Posts: 6497 |
| My bad, rtm. Also, Aya, I just realised that in your other guide you said you had an instant toggle too, like your set-reset. Do you have any pictures of that? (And congratulations on the new modship!) | 2010-04-11 02:47:00 Author: Incinerator22 Posts: 3251 |
| I just realised that in your other guide you said you had an instant toggle too, like your set-reset. Do you have any pictures of that? It's exactly the same switch (https://lbpcentral.lbp-hub.com/index.php?t=23400-Zero-Latency-Set-Reset-and-Toggle-Switch), just depends how you wire it up. | 2010-04-11 02:52:00 Author: Aya042 Posts: 2870 |
| My bad, rtm. Also, Aya, I just realised that in your other guide you said you had an instant toggle too, like your set-reset. Do you have any pictures of that? (And congratulations on the new modship!) Since emitters are the key for "instant" activation, wouldn't the emitter-based toggle from the Logic Pack be instant? (Sorry for the off-topic) | 2010-04-11 02:53:00 Author: comphermc Posts: 5338 |
| Since emitters are the key for "instant" activation, wouldn't the emitter-based toggle from the Logic Pack be instant? Only in one direction - the other will operate at the speed of dissolve. | 2010-04-11 02:58:00 Author: Aya042 Posts: 2870 |
| Oh, thanks Aya. | 2010-04-11 03:16:00 Author: Incinerator22 Posts: 3251 |
| Since emitters are the key for "instant" activation, wouldn't the emitter-based toggle from the Logic Pack be instant? Only in one direction - the other will operate at the speed of dissolve. No it won't. It operates at the speed of emitters in both directions. We discussed this the other day, remember? I was being really irritating about "just put an emitter on a piston" as the answer to everything The limiting factor on both your toggle and the emitter toggle is throughput, i.e. the number input changes that can be handled per second. Both are zero-latency and both have a hard to measure but pretty much equivalent max throughput. The logic pack one is a hell of a lot easier on the thermo though and doesn't require the awkwardness of double outputs (which will actually add to the latency in a real system, as you will either need a convertor, or you take a single output, in which case you are running at the speed of dissolve when switching off).The LogicPack emitter toggle wins for latency in this case I think, as it is genuinely instantaneous. | 2010-04-12 16:27:00 Author: rtm223 Posts: 6497 |
| Oh snap! *grabs the popcorn* | 2010-04-12 16:48:00 Author: comphermc Posts: 5338 |
| ACtually, thinking about it, I might be able to create a alternative Set Reset that doesn't need multiple outputs but can generate a single, instantaneous (in both directions) output... Thinking about it more... Maybe not | 2010-04-12 16:52:00 Author: rtm223 Posts: 6497 |
| No it won't. It operates at the speed of emitters in both directions. We discussed this the other day, remember? I was being really irritating about "just put an emitter on a piston" as the answer to everything My memory must be broken, because I don't remember that. However, your memory seems to be glitching as well. If you recall this... You can't actually output and instantly switching directional signal, for example? Not sure. I'd have to think about it, but I don't think the game engine can support an instant switch in both directions from the same mag switch. The switch is only instant when a mag key is emitted in the radius of an extant mag switch, and since a switch can either be inverted or not, but not both at the same time, then it would seem reasonable that a single switch could never make both transitions instantaneously. ...it sounded like we'd already agreed that any switch with only a single output would, necessarily, only be able to make the transition in one direction instantaneously, which is the case with the one in the logic pack. The key to successfully chaining logic switches, while retaining the instant switch in both directions, is to have two one-shot outputs, each representing one of the two state transitions. The limiting factor on both your toggle and the emitter toggle is throughput, i.e. the number input changes that can be handled per second. Both are zero-latency and both have a hard to measure but pretty much equivalent max throughput. This is definately true, however the logic pack's design is limited by the speed of the piston, whereas I believe mine is only limited by the speed of dissolve because my emitted blocks of dissolve are potentially blocking the emitter. However, if your emitter blocking theory is correct, then simply gluing a block of DM to the emitted blocks of dissolve should bypass this problem. I shall test out this theory shortly. The logic pack one is a hell of a lot easier on the thermo though and doesn't require the awkwardness of double outputs (which will actually add to the latency in a real system, as you will either need a convertor, or you take a single output, in which case you are running at the speed of dissolve when switching off). I agree on the point of thermo-efficiency, my design only scores better on the moving objects thermo, which actually isn't all that useful. As for just using a single output, that really only puts it in the same league as the logic pack version, which also has this limitation. Like I said before, my design is really only useful when you need to chain a large number of switches in series, which really doesn't occur often enough to be of much practical value, or at least it's far less frequently an issue than requiring thermo-efficiency, in which case your other design (https://lbpcentral.lbp-hub.com/index.php?t=21996-Lowest-Thermo-Toggle-(lol)) is probably the most useful in practise. | 2010-04-12 17:21:00 Author: Aya042 Posts: 2870 |
| ...it sounded like we'd already agreed that any switch with only a single output would, necessarily, only be able to make the transition in one direction instantaneously, which is the case with the one in the logic pack. The key to successfully chaining logic switches, while retaining the instant switch in both directions, is to have two one-shot outputs, each representing one of the two state transitions. I don't think so, the emitter based toggle from the logic pack will switch instantly in both directions. As the emit of the key object will instantly (in the same in-game clock cycle, which is what we are taking as instant) demit. So if emit and demit are instant actions (I'm pretty sure they are, not in a position to check right now), then demitter based logic is instantaneous as well. This is definately true, however the logic pack's design is limited by the speed of the piston, whereas I believe mine is only limited by the speed of dissolve because my emitted blocks of dissolve are potentially blocking the emitter. However, if your emitter blocking theory is correct, then simply gluing a block of DM to the emitted blocks of dissolve should bypass this problem. I doubt it. Because you have to wait until the next clock cycle for the dissolve to be dissolved, so you would still be limited by that. I'm unsure of how frequently you can even activate a 1-shot trigger, tbh, as that will most likely be the limiting factor here. It's going to be incredibly rare that you a throughput response quicker than the speed of a piston, seeing as there is very little in the game that could actually handle that responce at the end of the logic system. Like I said before, my design is really only useful when you need to chain a large number of switches in series, which really doesn't occur often enough to be of much practical value, or at least it's far less frequently an issue than requiring thermo-efficiency, in which case your other design (https://lbpcentral.lbp-hub.com/index.php?t=21996-Lowest-Thermo-Toggle-(lol)) is probably the most useful in practise. As per my first paragraph, the emitter-based toggle from the logic pack still works out faster than your instantaneous one, even in a long chain, as each part of the chain is instant, and there is no conversion on the output still. Obviously as the chain becomes longer the benefit becomes less and less, but it is still quicker. | 2010-04-12 17:29:00 Author: rtm223 Posts: 6497 |
| So if emit and demit are instant actions (I'm pretty sure they are, not in a position to check right now), then demitter based logic is instantaneous as well. Ah. I think this is the point on which our opinions differ. I've always been under the impression that demitting is exactly the same as dissolving from the game engine's POV. This will need to be tested to determine which theory is actually the case. I doubt it. Because you have to wait until the next clock cycle for the dissolve to be dissolved, so you would still be limited by that. I thought that any object attached to DM could be emitted on top of any other object attached to DM. If all that the emitter is waiting for is for a block of dissolve to move out the way then surely this would circumvent that problem? Of course this depends on the accuracy of my theory about mag keys being removed from the simulation faster than the block of dissolve is deemed to be gone from an emitter-blocking POV. Like I said, I will test this shorty as I've definately noticed a limitation in switching speed on my device. I'm using a wobble bolt set to >= 360 degree rotation fed by a directional input in order to create very fast one-shot pulses, and as you increase the pulse frequency, there's definately a point where it stops toggling. I'm unsure of how frequently you can even activate a 1-shot trigger, tbh, as that will most likely be the limiting factor here. It's going to be incredibly rare that you a throughput response quicker than the speed of a piston, seeing as there is very little in the game that could actually handle that responce at the end of the logic system. The only limitation I've noticed with one-shot frequencies is when you're generating them from a grab switch, which could well be just a limitation of grabbing. When generated from the wobble bolt I just mentioned, it can switch pretty quickly. | 2010-04-12 18:01:00 Author: Aya042 Posts: 2870 |
| *finishes eating popcorn* I don't know which is the best method yet, but I had noticed the switching limitation in Aya's converter. Basically, my question is: if the clock cycle refreshes after every .05 seconds, then the converter switching at such a rate is a non-issue, right? As long as your chain of logic is "instantaneous," does is matter that there is a .05 second delay from the converter? I'm basing all of my comments on my understanding of the clock due to incremental bolts. The minimum time that a switch can be activated for is .05 seconds. If I'm talking nonsense, then ignore me. | 2010-04-12 18:13:00 Author: comphermc Posts: 5338 |
| I don't know which is the best method yet, but I had noticed the switching limitation in Aya's converter. Yes, but I only use that to make it convenient to use a two-way switch to test the set-reset version - there's no reason I couldn't have used two separate one-shot grab switches instead, much like your set-reset design (https://lbpcentral.lbp-hub.com/index.php?t=21827-Low(est)-Thermo-Set-Reset), in which case there would be no additional latency. The toggle version doesn't really need such a converter. I think I'll refrain from making any more comments until I've done some more tests, as I'm working on some speculative assumptions which could well turn out to make everything I've said so far to be highly inaccurate. | 2010-04-12 18:32:00 Author: Aya042 Posts: 2870 |
| YI think I'll refrain from making any more comments until I've done some more tests, as I'm working on some speculative assumptions which could well turn out to make everything I've said so far to be highly inaccurate. Demit is a cycle later. Maybe we should all stop speculating, eh | 2010-04-12 18:43:00 Author: rtm223 Posts: 6497 |
| But the speculation hat fits so comfortably, doesn't it? | 2010-04-12 18:46:00 Author: comphermc Posts: 5338 |
| Demit is a cycle later. Maybe we should all stop speculating, eh Not sure what you mean by "a cycle", but I still believe there to be some latency between the point where the mag key is demitted out of the switch's radius, and the switch switches from the on to off state. I still need to look at this though. I have completed some tests, however, and here are the results:- To answer the question about the maximum one-shot pulse frequency it's possible to generate in LBP from a single mag switch. With a simple piston set to 0.1s, it would seem reasonable to assume that the the reciprocal would be the maximum, i.e. 10Hz. N.B. it's not 0.05s this time, since the piston would have to make a complete cycle. With a wobble bolt, the fastest settings are a rotation of 540 degrees and a cycle time of 0.2s, any faster than that, and the bolt starts to spin in the opposite direction and slows down. If you test this, it actually rotates 540 degrees in 0.1s, making 15Hz. The only other option I considered was using the 'special' emitter from the MGS bubble dispensor to emit mag keys, but I discounted that as the minimum lifetime would probably not allow that to work. Now, using a binary ripple counter as per the the setup in this diagram... http://www.lbpcentral.com/forums/attachment.php?attachmentid=13871 ...the counter was able to switch at the 15Hz rate, meaning it counts to 256 in about 17.1 seconds, which I also confirmed with a stopwatch. I still have some more tests to do, but I'm just about to head out, so I thought I may as well post what I'd found so far. | 2010-04-12 20:03:00 Author: Aya042 Posts: 2870 |
| but I still believe there to be some latency between the point where the mag key is demitted out of the switch's radius, that's what I was saying. My speculation was wrong. Although, in my defense, I genuinely thought I had tested this before | 2010-04-12 20:07:00 Author: rtm223 Posts: 6497 |
| Not completely on topic, but what's the fastest possible demmit/remmit cycle? | 2010-04-20 01:55:00 Author: Incinerator22 Posts: 3251 |
| Around 0.05s (the time required for your piston to move it's full length) as you can trigger the demit from a 1shot that will also trigger the moving piston that triggers the emit. Of course this would require that the object has no moving parts, in which case you wouldn't need to demit, you could just emit over the top of itself, so 0s If you have moving parts then you will have to wait for the piston to settle before doing the emit. The most up-to-date logic switches I have take around 0.3s I think (but that is a guess). | 2010-04-20 09:50:00 Author: rtm223 Posts: 6497 |
| Updated the demo with a version that allows for 2 outputs at once, at the request of sneakysteve. There are two versions - the first one is buggy, but I left it in to demonstrate the design flaw in it. the second one is robust, but probably not the most thermo - efficient. Thought I'd let you know in case anyone else was interested | 2010-04-26 19:35:00 Author: rtm223 Posts: 6497 |
| 5 input/ output solution d wwwwwwwwwwwwwwwww|------|wwwwwwwwwwwwwwwwwwww d d wwwwwwwwwwwwwwwww|......|wwwwwwwwwwwwwwwwwwww d w = winch d wwwwwwwwwwwwwwwww|......|wwwwwwwwwwwwwwwwwwww d d = dark matter d wwwwwwwwwwwwwwwww| MK.|wwwwwwwwwwwwwwwwwwww d MK = mag key d wwwwwwwwwwwwwwwww|____|wwwwwwwwwwwwwwwwwwww d MS = mag switch dddddd MS ddddddd MS ddddddd MS ddddddd MS ddddddd MS dddddddd Each winch works in a pair with another winch on the other side of the moving block with the mag key on it to pull the block over one of the mag switches. Each pair is set to pull the block to a different position and works of a directional input. You probably need a stablising piston or spring to keep the block moving on one axis and I dont know what would happen if 2 inputs were triggered at the same time. You could also expand it by gluing this on top: d wwwwwwwwwww[ ]wwwwwwwwww d. i hope that made sense and Im pretty tired so it probably wont work... -_- | 2010-05-03 00:21:00 Author: R0GUE--Elite  Posts: 118 |
| You'll want a piston set to be off at all times to stabalise that, but otherwise it's a pretty neat design. Sadly, you're gonna trigger trigger outputs inbetween the states using that though., which makes it unsuitable for a lot of applications. the result of 2 active inputs will vary depending on a number of factors, but would settle as long as they are not turned off at the same time (whichever one was switched off last would be the final result). | 2010-05-03 15:13:00 Author: rtm223 Posts: 6497 |
| I made a design like this a while ago- however, it wasn't very expandable. Lemme show: (A 4x4 dissolve block with a mag key on the bottom half of the block, and a mag key in the upper half(wired to dissolve the block), radius was really large and angle was 300-ish is emitted here) Dm block W/mag switch emitter that emits the dissolve block You can put several these nearby and have the "checkpoint situation". The mag switch on the dissolve block covers all the nearby blocks but it's own key. It must have ON input, because then it will 1. emit the block and dissolve all the other blocks with itself and 2.emit itslef again. Basically it's based on the belief that the player can't get the switch to "off" position before the block is emitted again. Also gives a little blink effect when activated... At least it's very low-thermo. | 2010-05-03 15:23:00 Author: Arradi  Posts: 183 |
| I've fixed up my design so it doesn't trigger outputs between states, but it seems to break if you used it frequently in a short period of time. I've published it in a level thats locked. The key is in my Vault level under the code; 2550344 . | 2010-05-03 22:13:00 Author: R0GUE--Elite Posts: 118 |
| Thanks for the information rtm. This was the cornerstone to a project I'm working on. I did run into an interesting issue, however. A workaround would be easy enough, but it's kind of bugging me, because I'm stubborn and like to solve things. You guys seem to know enough about the under the hood mechanics of LBP to figure this one out. In my project, I am using a 3-input, mutual exclusion switch: Two choices, one reset. Because of the nature of this project, the two "choice" switches themselves are de/emitted into the scene. This is unavoidable. First I'll lay down the order of relevant events, and then I'll explain the issue: Choice is made The choice's switch emits a key Reset switch emits a key, removing the choice key The choice switch is demitted, then re-emitted. The issue arises if the same choice is made again. For some odd reason, the choice's key and the active reset key will dissolve each other instead of the choice key dissolving the reset key. This has to do with the order of events. The reset key (step 3) spawns before the re-emitted choice switch (step 4), so they both go poof if the newly emitted choice switch emits a key. I know this is the case, because if I pause the simulation after step 4 and either allow the reset switch to emit a new key, or add one in manually, it works as expected. Here is a video example: http://www.youtube.com/watch?v=zLJW-Aan8OM As I said before, a work around would be easy. For example, I ccould simply set the reset key to have a 0.1 second lifespan and be done with it, but where's the fun in that? I really just want to know why it matters that a switch must spawn before a key for it to work properly. EDIT: Sorry for the poor video quality. I'm holding a camera phone in one hand and the controller in the other. | 2010-06-09 02:34:00 Author: cgCody  Posts: 16 |
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.