LBP Showcase / Reviews / Recommendations #1
Incremental Piston
Archive: 38 posts
| This is a post in response to Tamland's Incremental Bolt (https://lbpcentral.lbp-hub.com/index.php?t=t=19915). He had requested pics of my object in his thread, but since this is a different object I wanted to post it in a new thread as to not derail his ^_^'' Tamland, I finally have some pictures! Prepare for a long post, and some really unrefined logic. Unfortunately I do not have a tutorial level on this object, but once I get it refined I will make a level for it  The Whole Object http://i841.photobucket.com/albums/zz337/Mennenth/Little%20Big%20Planet%20-%20Incremental%20Piston/main.jpg In the far bottom left is a red switch which begins the whole activation process of going up. Along the left side are the state switches or event switches (These switches have a 2 small grid gap in between them, so the piston moves ~5 units each activation). In the center channel is the primary piston with an idiotic structure on the end I plan on doing away with. On the right is the UP and DOWN timer pistons. On the very bottom are the winches hooked up to the 3 way switch which is hooked up to the primary piston. In between the primary piston and the 3 way switch is some more idiotic messy logic that will also be gotten rid of in my new version. Main Logic Area http://i841.photobucket.com/albums/zz337/Mennenth/Little%20Big%20Planet%20-%20Incremental%20Piston/moredetail.jpg Here is a more detailed shot of where crap goes down. As you may notice, the structure on the end of the primary piston is in line with the first state, but not activated. This was a need of my player piano level, but I'll be refining it so that step will not be needed. Basically, here is the process: 1) The red switch activates, causing the piston in the glass structure to move the key into range of the first event or state and moves it out of range of the switch directly bellow it. 2) When the switch directly bellow it activates, it triggers the emitter all the way on the right, which emits dissolve a green key on the right and a blue switch attached to the dissolve on the left (picture bellow). 3) The switch all the way on the right triggers, activated the piston directly above it (the UP piston), and the winch on the right of the 3 way switch so the primary piston goes up 4) When the UP piston reaches the top, the key enters the range of a final switch, which activates the center bottom emitter. 5) That emitter places a thin piece of dark matter with a blue key on the left of the dissolve over the blue switch 6) The dissolve goes away, causing the switch on the right to deactivate, stopping the primary pistons motion and retracting the UP piston. 7) When the primary piston reaches the top, the final switch activates the left most emitter, putting a block of dissolve on that left channel above the 3 way switch, activating the switch on the left 8) That switch causes the left winch and the DOWN piston to activate 9) When the DOWN piston reaches the bottom, it activates a switch which triggers the center top emitter placing a dark matter key deleting the left dissolve block, stopping the action. At this point the system should be reset and ready to go through its run again if needed. A Shot Of the Action! http://i841.photobucket.com/albums/zz337/Mennenth/Little%20Big%20Planet%20-%20Incremental%20Piston/updetail2.jpg Here you can see the block of dissolve when its emitted, along with a little of the action. You can also see the DOWN control piston, along with the respective "stop" switches. Primary Piston Setting http://i841.photobucket.com/albums/zz337/Mennenth/Little%20Big%20Planet%20-%20Incremental%20Piston/primarypiston.jpg UP Piston Settings http://i841.photobucket.com/albums/zz337/Mennenth/Little%20Big%20Planet%20-%20Incremental%20Piston/uppistonsettings.jpg DOWN Piston Settings http://i841.photobucket.com/albums/zz337/Mennenth/Little%20Big%20Planet%20-%20Incremental%20Piston/downpistonsettings.jpg I will say that this is my real first attempt at home brew logic which is, to say the least, very in need of refining. That is why I love your incremental motor bolt, Tamland. I never thought to use flipper pistons. Using those would get rid of the need for directional control switches and emitters. I plan on refining soon, though it depends on when I can play and on how much I can get done, as right now my attention in the game is really focused on making version 2 of my player piano more stable (right now it breaks when transitioning between lines of music : ). I'm sorry I didn't crunch the numbers on what settings are needed for the timings, so that is why I posted screen grabs of the piston settings. Even though I'm not looking for feedback on this object, any thoughts or comments would be appreciated, especially if a friendly person feels like taking the settings I used and crunching the numbers. | 2010-01-10 04:27:00 Author: Mennenth  Posts: 52 |
| seems a little complex, but very cool. | 2010-01-10 05:28:00 Author: horwitzer  Posts: 255 |
| Thanks! I do intend to reduce the complexity. I did make this when I was still learning the ropes. | 2010-01-10 05:48:00 Author: Mennenth Posts: 52 |
| Quick question... what happens when you get to the end? If it just stops, then I have a super-simplified version of this... | 2010-01-10 05:54:00 Author: comphermc  Posts: 5338 |
| @comphermc When it gets to the top of its run, it activates the final (20th in this case) switch, which emits a key for the down control piston. That piston is timed so it doesnt stop until the primary piston is all the way back down. I do not believe it is as good as Tamland's incremental motor bolt though. I do plan on retooling mine though to be a lot more simplistic. It will have no emitters and (hopefully) no reset system because it will be built in. | 2010-01-10 06:17:00 Author: Mennenth Posts: 52 |
actually im confused, what is its purpose, is it just to go up and down in increments, because if it is i think i could make an immensely simplified version. no offence.  | 2010-01-10 06:39:00 Author: horwitzer Posts: 255 |
| No offense taken. This was really just a response to Tamland. He asked me to post my idea of an incremental piston in his thread, but I just wanted to make a new thread to not clutter his. The purpose is pretty much similar to Tamlands incremental bolt, only with a piston. I use it as an event sequencer in my player piano level to pop out the measures for the reader bar at certain times. *edit* If there is confusion about the over complexity of my object, please note I made this object ~3 or 4 months ago when I was still learning. I saw Tamlands incremental bolt recently and realized that it was a much cleaner approach. When I mentioned what I had done, he got curious as he said that he had tried with a piston previously and couldn't get it to work the way he wanted. I am planning on adapting some of his ideas into my piston to make it much much cleaner and less complex. | 2010-01-10 07:30:00 Author: Mennenth Posts: 52 |
| Hi there! Cool contraption! Though it looks a little too complex I would love to see this in action! If you wanna show it to me you can add me on PSN (tamland). The way that I experimented with this was just by using my multidirectional controller connected to a piston which made it move in increments.. But not in the increments that i wanted And the tweaking got the better of me  One of the biggest Pro's you get by using an incremental Piston is that you have restrictions to how many steps it can take. In comparison to my design where it endlessly loop, unless you hook up some logic that makes it stop when you want. though that's more of hassle if we can get a "clean" incremental piston. I have some ideas on this.. will try them out and get back to you. //Mattias | 2010-01-10 08:54:00 Author: Tamland Posts: 106 |
| Hi there! Cool contraption! Though it looks a little too complex Yep. It was a very early home brew attempt xD. I would love to see this in action! If you wanna show it to me you can add me on PSN (tamland). I'd love to. I'm not sure when I'll be able to though (sad fact, I don't actually own the ps3 or the game due to money reasons so I rely on a friends console) The way that I experimented with this was just by using my multidirectional controller connected to a piston which made it move in increments.. But not in the increments that i wanted And the tweaking got the better of me At first the tweaking got the better of me too. Well, it was frustrating because I wanted the switches in a certain place and then have the piston move accordingly. That turned out to be stupid, because the piston was going in nice increments. So I changed my strategy, tweaked the piston timings, and then just placed the switches in line with where the contraption was. One of the biggest Pro's you get by using an incremental Piston is that you have restrictions to how many steps it can take. In comparison to my design where it endlessly loop, unless you hook up some logic that makes it stop when you want. though that's more of hassle if we can get a "clean" incremental piston. I actually like the endless loop idea that the motor bolt gives, and will actually be using that object in my next player piano. The ability to stop where it starts would benefit my player piano design of being able to play the song over and over without resetting the level. Though the ability to go up or down in equal measure through a ton of different "states" or "events" does open up a large amount of possibilities (just to note, the object I have pictured in this thread has a primary piston length of 142 and can go through 19 states spaced a little more than 2 small grid squares apart. By fine tweaking and extending the length even further you can imagine just how much stuff a single piston could control.) I have some ideas on this.. will try them out and get back to you. //Mattias Great! Feel free to use my piston settings as a guide to help, its why I posted them (if you wanna /shrug) | 2010-01-10 16:28:00 Author: Mennenth Posts: 52 |
| What about a mag key operated piston and having an emitter emit keys that will disappear after a set interval? Then you would know, by the length of time the key is there and the speed of the piston, how far it would move? | 2010-01-10 16:50:00 Author: ButterflySamurai Posts: 98 |
| I was going to use just emitters at first, but I could never grasp the timing of how long they live as easily as I grasped the timing of the speed control on pistons (the "time" is how long it takes for it to fully extend and then retract, so if you want to know how long it takes for it to travel one way/be directional just divide the timing in half. If you know the timing you want, put in a time double what you want the timing to be). So, I decided to control the life span of the emitted objects via the timing of the pistons. The timing of emitter life span also just felt weird to me, I've always had issues with stuff lasting longer then I liked. My new design is not going to need emitters at all hopefully. It will just use one shot mag switches to control flipper pistons, as opposed to the current design of emitters and directional mag switches. Go check out Tamland's incremental bolt if you havent. My goal is to hybrid his system with mine, to create incremental movement that is lateral as opposed to rotational. Just to have options open. I'm also going to play with the idea of the "primary" piston also being set to flip so it can reset without the aid of extra logic. This would free up the "down" control piston so it doesn't have to be locked into a certain timing, opening up new possibilities with doing the whole, "2 steps forward, 1 step back" stuff, and maybe more complex motions. I wonder if there is some crazy logic to dynamically change the speed of a one shot flipper piston? That could get even more interesting. | 2010-01-10 19:15:00 Author: Mennenth Posts: 52 |
| I finally got around to completely redoing my incremental piston. It wasn't on the top of my to-do list, but now it is done. Gone is the huge pile of dark matter. Gone are the emitters. Gone is all the clunky logic and guess-work. Simply Put; gone is the over complexity, hello to simplicity. This new system is in 2 parts; the main controller which I call the Directional Timing Unit, and the piston itself. I also sat down and thought of the math behind piston timings and have perfected my system to very small, very precise increments. I'll post that math after the pictures. Full System http://i841.photobucket.com/albums/zz337/Mennenth/New%20Incremental%20Piston/newincrementalpistoneverything.jpg Directional Timing Unit http://i841.photobucket.com/albums/zz337/Mennenth/New%20Incremental%20Piston/newpistonmaincontrol.jpg Primary Piston Settings http://i841.photobucket.com/albums/zz337/Mennenth/New%20Incremental%20Piston/newprimarypistonsettings.jpg UP control piston settings http://i841.photobucket.com/albums/zz337/Mennenth/New%20Incremental%20Piston/newpistonuppistonsettings.jpg DOWN control piston settings http://i841.photobucket.com/albums/zz337/Mennenth/New%20Incremental%20Piston/newdownpistonsettings.jpg Primary Piston starting position http://i841.photobucket.com/albums/zz337/Mennenth/New%20Incremental%20Piston/newpistonsmallgridunits.jpg In action: UP control http://i841.photobucket.com/albums/zz337/Mennenth/New%20Incremental%20Piston/newpistoninaction.jpg After one UP activation http://i841.photobucket.com/albums/zz337/Mennenth/New%20Incremental%20Piston/nepistonafteroneupactivation.jpg As you can see, the settings are adjusted to allow the primary piston to move UP/DOWN precisely one small grid, or 2.5 units of piston length. I have tested it out and it is completely consistent on the way up, and on the way down. This new system, like the previous system, has a total of 20 stops. Actually, 21 if you count the starting position. Here is the math behind the timings: The timing you see in the settings for most pistons (will talk about the exception in a second) is the total time it takes for the piston to both fully extend and fully retract again. So a piston with a timing setting of 20 will take 10 seconds to fully extend and 10 seconds to fully retract, a total of 20 seconds (the number you see in the timing.) If you want it to take an exact amount of time, say 5 seconds, to fully extend (or retract), put in double the number for the timing, in this case 10. Since I have 20 stops for my piston and wanted it to take 1 second to go from one stop to the next, I want my primary pistons timing to be 40. The exception to the double or half rule are flipper pistons. Since flipper pistons take zero time to go one of the directions, the timing you see is the timing you get when it comes to going the other way. Since I want my primary piston to stop after a single second of motion, my flipper piston timings are thus set to 1 second (with the exception of the UP control. For some reason the primary piston was moving too far, so I had to reduce it to 0.9 seconds. I'm guessing this is because the 3 way switch takes a very small amount of time to return to the neutral position). When one of the flipper pistons gets activated via its one shot switch, it flips the key away from an inverted switch. That switch activates and pulls on a winch, activating the primary piston. In 1 second, the control piston returns the key to the switch, deactivating the switch, letting loose the winch, stopping the primary piston. Far simpler then my original, horrible idea of an overly complicated system of emitters. On a side note; I'm thinking of taking the Directional Timing Unit and hooking it up to one of Tamland's incremental bolts instead of my incremental piston. The ability to go both ways could also potentially alleviate the issue in that thread of having 7 outputs. 7 outputs causes that system to go out of sync. My Directional Timing Unit could use one of the controls to move it clockwise 7 times, and then the other control to move it counter clockwise a tiny fraction to re-sync the system. | 2010-01-25 22:46:00 Author: Mennenth Posts: 52 |
| Oh, I've been making these for months. Love it. Just knocked up a few after seeing I was late to the party. Basic Omnidirectional Incremental Piston Basic Dark Matter Blocker application: http://i600.photobucket.com/albums/tt82/rtm223/Incremental/APhoto_6-2.jpg When you hit the one-shot input, it emits a piece of dark matter and the piston is then triggered to extend. http://i600.photobucket.com/albums/tt82/rtm223/Incremental/APhoto_7-1.jpg http://i600.photobucket.com/albums/tt82/rtm223/Incremental/APhoto_8-1.jpg etc. Piston length is such that you stop at the last mag key. Or you can keep on going if that is your whim. Omnidirectional Incremental Piston with Loop As before, but when the piston is in the final position and the emitter is triggered, the end green magnetic key pulls the winch in fast and lops you back round to the start. http://i600.photobucket.com/albums/tt82/rtm223/Incremental/APhoto_9-2.jpg Bi-Directional Incremental Piston If I understand correctly, this has the same behaviour (more or less) as the device above? Bi-directional piston with no looping. Uses two emitters and the piston direction is controlled by a set-reset device. One interesting thing to note is that it takes directional inputs, treating them as rising edge triggered, which is far more useful than 1-shots, for integration with other logic systems as far as I'm concerned. Anyway: Config: http://i600.photobucket.com/albums/tt82/rtm223/Incremental/APhoto_2-6.jpg Right once: http://i600.photobucket.com/albums/tt82/rtm223/Incremental/APhoto_3-4.jpg And Again: http://i600.photobucket.com/albums/tt82/rtm223/Incremental/APhoto_4-3.jpg And left: http://i600.photobucket.com/albums/tt82/rtm223/Incremental/APhoto_5-1.jpg The device in the image actually has a bug whereby if you hold one input down, it disables the other input. This is easilly avoided by splitting the right angled AND at the bottom for two separate, piston-activated moving parts. Alternatively you could very much see it as a "feature"  Looping is also doable, but it's a bit of a pain. | 2010-01-26 00:30:00 Author: rtm223  Posts: 6497 |
| Wow. I'm going to have to keep those designs in mind, and once again modify my design. Like I can't believe I didn't think of flipper pistons to control the timing at first (instead using emitters in excess), I can't believe I didn't think of using a fast moving winch to reset the system : | 2010-01-26 01:41:00 Author: Mennenth Posts: 52 |
| Ah, the water level logic finally makes sense! Thanks, rtm. | 2010-01-26 02:27:00 Author: comphermc Posts: 5338 |
| This is awesome! I tried it quickly with DM-blockers when Mennenth mentioned his design a while, but mine kept breaking all the time.. About the looping.. i think that a looping feature is not needed when you use incremental pistons. It is very useful to have something only go a predefined distance and then stop.. And i would call the hold-a-button-to-stop-the-other a feature and not bug BTW @ Mennenth: I like the way that you made your design much better than your previous! but rtm kinda hit it out of the park on this one.. | 2010-01-26 08:09:00 Author: Tamland Posts: 106 |
| Ah, the water level logic finally makes sense! Thanks, rtm. I doubt it. You could make the water logic out of this, but the one in the level is slightly (distinctly) less neat - this one wouldn't have broken simply because I copied it lol. Yes, you're gonna need to set up the piston timings so that Time = (n-1)/10 seconds and set strength to 5. There are a few other configurations that work, but off the top of my head that one is a good rule of thumb for this [quote]And i would call the hold-a-button-to-stop-the-other a feature and not bug I'm gonna market it as a "build option", I think  | 2010-01-26 10:02:00 Author: rtm223 Posts: 6497 |
| Yes, you're gonna need to set up the piston timings so that Time = (n-1)/10 seconds and set strength to 5. There are a few other configurations that work, but off the top of my head that one is a good rule of thumb for this Ohh ok! that sounds like a good rule! will check it out when i get back home. I'm gonna market it as a "build option", I think Yeah.. unnecessary to fight against your problems when you can work with 'em | 2010-01-26 10:28:00 Author: Tamland Posts: 106 |
| Oh I forgot to say. In terms of the looping, I know what you mean about sometimes it's preferable to have looping on a highly customisable system. I've got a bit-pattern generator on my moon. I need it to be able to loop and also be able to vary the number of steps around, and also the n-bit bit pattern at each step. With a modified version of the looping piston above, I can configure the whole thing using a 2d grid of mag keys - time on one axis and input values along the other. Varying number of steps is a case of moving one mag switch, and each step can be quickly altered in a couple of seconds. There is no way I'd use a rotational device for something like that. It's a very specific application, but there are times that you may want looping motion on pistons. | 2010-01-26 10:57:00 Author: rtm223 Posts: 6497 |
| @rtm223: Yes, ofcourse there are times you wanna use a looping incremental piston rather then a incremental bolt (that is "destined" to loop).. But there is one big disadvantage: you have to go through all the increments before you can get to the beginning.. though you can easily solve this by using a simple AND.. | 2010-01-26 12:06:00 Author: Tamland Posts: 106 |
| But there is one big disadvantage: you have to go through all the increments before you can get to the beginning.. What what? Wouldn't you have to do that anyway with the incremental bolt? Sorry if I'm wrong here, but a "return to start at any time" would be much harder to implement with an incremental bolt. I'm not entirely up to speed on the incremental bolt thread so forgive me if I've missed something. | 2010-01-26 12:26:00 Author: rtm223 Posts: 6497 |
| sorry.. i think i misunderstood.. To return to the start at any time it doesnt matter which of these solutions you would use.. You would always have the problem with the other increments being passed by on the way over there.. Though a piston is probably prefered because its easier to pull it all the way back without using any "skip" logic. I was talking about looping the increments.. Then its a big disadvantage when using the Incremental Piston. Because you have to go through all the increments before you can get to the beginning.. Where the Incremental Bolt just turns to the next step and gets to the beginning.. We should make a Pro's and Con's list about these two designs | 2010-01-26 12:39:00 Author: Tamland Posts: 106 |
| 'tis a fair point, Tamland. Solution: emit the extender arm, and demit it when it gets to the end. (Note: that would include any included logikz) | 2010-01-26 12:52:00 Author: comphermc Posts: 5338 |
| To return to the start at any time it doesnt matter which of these solutions you would use.. You would always have the problem with the other increments being passed by on the way over there.. Uh, I'm pretty sure you can pull the winch in fast enough to trigger nothing on the way back, but I'll have to check on that one. Worst case scenario is that during a reset you move the side arm out for a moment as you pull back. @comphy, you can't remit the extender using dark matter blockers. You would need a method to remove the blockers too. | 2010-01-26 12:58:00 Author: rtm223 Posts: 6497 |
| Creative thoughts you have! Though wouldn't it be easier to just have the bottom part (where all the magnetic switches are) move down a bit so they cant get activated while the piston makes it way back to the start? Like a big AND gate. | 2010-01-26 12:59:00 Author: Tamland Posts: 106 |
| Though wouldn't it be easier to just have the bottom part (where all the magnetic switches are) move down a bit so they cant get activated while the piston makes it way back to the start? Like a big AND gate. Sorry, that's what I meant by the following: Worst case scenario is that during a reset you move the side arm out for a moment as you pull back. Not exactly being very clear there I really don't think it's needed though | 2010-01-26 13:01:00 Author: rtm223 Posts: 6497 |
| yeah but i posted without knowing that you had posted | 2010-01-26 13:09:00 Author: Tamland Posts: 106 |
| I'm sure you can do this much easier by learning the following the instructions posted in a tutorial thread by comphermc a while back, which was based on rtm's original theory of incremental pistons. I've done it myself and made pistons work incrementally using only their own settings and mag switch inputs, no complex hidden logic gates involved. In this case the player moves objects toward a cracked egg, and as each object is pulled into range the egg gradually opens wider and wider to reveal a chicken inside. The piston set-up was sound, incremental, but logic variables meant if the objects were brought down out of order then the pistons wouldn't register until the object that triggers the first increment was pulled into range. Fortunately, rtm was kind enough to pop in and whip me up a very simple, but unfamiliar looking logic gate that accounted for all variables and allowed the the objects to be brought to the egg in any order, but still triggering each increment in sequence. I asked him what the logic gate was called and he said it had no particular name, just something he thought up. rtm223 = the best "technical consultant" that a serious creator could hope to procure the services or advice of. Listen to him and learn everybody. | 2010-01-26 13:18:00 Author: Ungreth  Posts: 2130 |
| Actually Ungreth, that's a slightly different mechanism, the variable length pistons, where you can select the length by using winches to limit the length of the piston. This is a piston that takes a single input and steps it's way forward, triggering outputs in a predefined order. | 2010-01-26 13:29:00 Author: rtm223 Posts: 6497 |
| Actually Ungreth, that's a slightly different mechanism, the variable length pistons, where you can select the length by using winches to limit the length of the piston. This is a piston that takes a single input and steps it's way forward, triggering outputs in a predefined order. Aye, but could you not adapt the variable length piston/winch concept to devise a less complex, more thermo friendly set-up than the prototype showcased here? | 2010-01-26 13:43:00 Author: Ungreth Posts: 2130 |
| Aye, but could you not adapt the variable length piston/winch concept to devise a less complex, more thermo friendly set-up than the prototype showcased here? You could, but it may take a lot of winches, and resetting the whole dang thing would be harder. I like where your head's at, though... | 2010-01-26 13:51:00 Author: comphermc Posts: 5338 |
| You could make it by using the Incremental Bolt and then just hook it up to a variable length piston... But that would probably end up taking more thermo then the incremtal piston that rtm showed in this thread earlier. And it would also make the piston quite redundant.. | 2010-01-26 13:56:00 Author: Tamland Posts: 106 |
| The issue, that Tamland kinda highlighted, would be that the variable length piston needs a set of magnetic switches to activate each position. If you want to move through those positions in order, then you would indeed need some logic to trigger the magnetic switches, so you have a kind of circular problem. Me and grant managed to make a three-way switch behave like a 2-way switch yesterday, using a fair bit of redundant logic lol. What you could use that concept for, is to create a system that moves slowly and smoothly to the selected position. That could be used for a variety of applications. | 2010-01-26 14:12:00 Author: rtm223 Posts: 6497 |
| Run the inputs through a Logic Pack AND gate with n-inputs. It removes the ordering issue, correct? Put mag key switches at different points... etc | 2010-01-26 14:20:00 Author: comphermc Posts: 5338 |
| Not really, you have just created the separate problem of "how do I activate N inputs, one at a time, but in any order".... Rather than the AND gate you would be better emitting blocks with mag keys into a column. Each with a mag key on and mag switches set to inverted, then pump that into your winch array. But you aren't going to achieve much by doing that.... | 2010-01-26 14:24:00 Author: rtm223 Posts: 6497 |
| No, no, no... I meant for an intermediate step before the Variable Length Pistons setup Ungreth suggested. I do agree that the DM blocker method is best. | 2010-01-26 14:25:00 Author: comphermc Posts: 5338 |
| BTW @ Mennenth: I like the way that you made your design much better than your previous! but rtm kinda hit it out of the park on this one.. Thanks, and I totally agree. His designs are absolutely amazing. I love the use of a set-reset to replace the 3 way switch. Worst case scenario is that during a reset you move the side arm out for a moment as you pull back. If you go back to my original, clunky design, you'll notice I took a similar approach on what I call the Primary Piston. It moves a glass box up, and that glass box has a small glass block in it with the key that can move back and forth to prevent any activation until you want it to. The piston aligns the key with the next output, and then another switch is activated to push the key within the trigger radius, and then it quickly retracts again. I got rid of that in my newer design simply because I wanted to focus more clearly on how the piston can move up and down in small increments. In any event, I love the direction this thread has taken to come up with solutions that can make the system even better. EDIT: Now that I think about it, I'm still partial to my design, and not simply because its my own. While it may not be pretty, my design has the potential to have some extra logic added to it to allow "skipping" over various outputs, along with being able to go several outputs at a time without stopping. The idea would be to chain my "control" pistons together in an AND gate series, one AND gate for one direction and another for the other. Each piston in the series would have a longer timing then the next, preferably in integers of a second. Combining this with an AND gate on the end of the primary piston (I envision a stream-lined version from my ol' clunker) to allow the key to pass over stops without activating, and that could allow for a good deal of variation. I'm not sure how well the designs rtm posted earlier could be modified to fit this idea, which is why I'm going to go back to the drawing board on it. When I have something figured out I'll take pics and post. SECOND EDIT: I have a unit now that can go up 1, 2, or 3 increments at a time, down the same amount (and is modular up to however many you need at a time), is set up to not activate any unwanted outputs until it stops moving, and has a reset. The problem? It takes almost 2 of the small notches on the thermo. I'll be posting pics later, and if someone wants to take the object and fiddle with it to make it take less thermo I'd be glad to send the object to you (or make a level with it as a prize). | 2010-01-26 16:27:00 Author: Mennenth Posts: 52 |
| And here is my latest revision for my incremental piston. The Main Structure http://i841.photobucket.com/albums/zz337/Mennenth/Incremental%20Piston%20Revision%20Three/entirestructure.jpg Yes, its more complicated then my previous version. Also, you can see the temp off to the side. The new features of this system: - It does not activate any outputs until it stops moving. This is thanks to an AND gate that detects when the piston is in motion, retracting the key on the primary piston away from the switches. This is useful when considering the next two features. - It is not restricted to moving only one increment at a time, thanks to 2 more AND gates, 1 for each direction. Each piston in an AND gate is 1 second slower from right to left, furthest right being 1 second and furthest left being 3. More pistons with longer timings, or making the timings of the current pistons longer, could be added to allow it to go further per activation. - It now has a very fast reset winch. The switch to toggle it is the red switch. It is hooked up to 1 piston in an AND gate for determining when the activation key is extended. UP control and DOWN control AND gates http://i841.photobucket.com/albums/zz337/Mennenth/Incremental%20Piston%20Revision%20Three/upanddownandlogicforvariabletiminga.jpg The two activated green switches you see are fed into the other 2 pistons in an AND gate (along with the red switch for resetting) for the purpose of determining when the activation key is extended. EDIT: I realized that I can remove the 2 activated mag switches and it will still work. I'd just set the other pistons in the and gate to be backwards and hook the already directional switches that control the winches on the 3 way switch to also control the pistons in the and gate. AND gate for Activation Key http://i841.photobucket.com/albums/zz337/Mennenth/Incremental%20Piston%20Revision%20Three/ANDgatecontrollingactivationkeypist.jpg Activation Key http://i841.photobucket.com/albums/zz337/Mennenth/Incremental%20Piston%20Revision%20Three/activationkey.jpg Now I just need a way for the system to know its own location, along with a method for the player to tell the system what location he/she wants it to be at, and a way for the system to calculate the distance up or down it needs to travel to get there, and that would be one ballin' elevator. EDIT: After thinking about it, a simple addition/subtraction grid would work with say the Y axis being another incremental piston that moves in sync with the primary one (albeit small scale), and the X axis being what floor the player wants to travel to. not sure how heat efficient the entire thing would be, but sounds pretty beast to me. | 2010-01-27 01:54:00 Author: Mennenth Posts: 52 |
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.