I do admit that it's one of the weirdest logic pieces, but at least I can say I made something unique; watching it bounce is quite ridicuolus, and I admit that I use a strenght of 7 on the spring only because it looks funnier :D
Printable View
I do admit that it's one of the weirdest logic pieces, but at least I can say I made something unique; watching it bounce is quite ridicuolus, and I admit that I use a strenght of 7 on the spring only because it looks funnier :D
Nice! That seems to be almost the least thermo possible, unless somehow it can be made with one piston/winch/anything else.
At the moment I primarily use Compermc's one toggle that utilizes the fact that a one shot goes faster than .1 seconds. (I'm not sure what its called?)
This, and SBG's glass one, seems to me... a bit less....... potentially stable? If you're toggle can freely move, (piston at 0 strength or no piston) then I would be worried about something ptentially messing up and it, pretty much sliding/falling into a different position, unless it's using pink floaty.
Perhaps I am unfamiliar with the subject, as this is not what I would generally be looking at inventing.
You mean it could fail if you move it around or throw something at it? Logic devices are not meant to be collision-proof; other than that, using the grid will grant that it won't slide to the left/right, since the 0 strenght piston takes care of the only external force, the gravity - about its stability, take a look at the replies, both I and Rtm explained its mechanism more than once. For the glass one, I haven't tested it yet, I couldn't tweak it correctly.
Wrong - Rtm's is more efficient than the flipper based, not only for the number of components, but also for the time needed for the change of state; let's analyze the actions that occur in both of them:
Comphermc's flipper based toggle:
- one-shot input -> flipping piston (time: < 0,1 sec - let's call this X)
- change of state for the key -> change of the direction of the other piston (time: 0,05 sec + 0,05 sec)
- change of state for the output (time: 0,05 sec)
Rtm223's toggle:
- one-shot input -> flipping winch (Time: X)
- change of state for the output (time: 0,05 sec)
Total time: X + 0,15 seconds against X + 0,05 seconds - I don't need to add more, I think :)
That's why I used an unknown quantity (X) - It could also be 0,01 for all we know, since there isn't an instrument to misurate it accurately - It surely is less than 0,05 anyway, which is the time needed for mag switches to detect a key, so if assuming it's instant is not the thrut, it's quite near to it.
Well I'm not quite sure of this (tell me if I'm wrong) and I will test it later, but...
If you have an increadbly long flipper piston, dosen't the side of it movement when it "flips" instantly "teleport" to the extended/contracted psition? (I mean, doesn't it go through objects on the flipper motion side?)
Again, I might be wrong, but this was the basis of my thinking from what I've seen.
It's true that a flipping piston allows an object to pass through another in the moment it flips, but it's not the mechanism used in this device.
Basically, when the device is in active status, the brown connectors are overlapped; since each connector has a lenght of 1.25, it's like having the winch at an actual lenght of 2.5, from 1.25 inside the DM and 1.25 inside the moving part, and not 0 as you could think; so, when the winch receives another one-shot input, it shoots the moving part from -2.5 to 0, and thanks to the piston that negates most of friction, it goes to full lenght. As I said, you can watch it in the level I use as a backup for logic devices.
http://i600.photobucket.com/albums/t...Photo_10-2.jpg
^^^ in this image the winch lenght is -2.5, not 0
how do you deal with the (can't remember what is called) that the Mag Switch holds onto the mag key?Quote:
There you go, I just finished testing it:
It requires two directional inputs, and both the pistons have the following settings:
- lenght (min/max): 5 / 15
- strenght: 6
- time: 0,1 s
- stiff, inverted
Spring settings:
- Lenght: 10
- strenght: 7 or higher (basically, the higher the strenght, the less it swings, but it doesn't matter much)
- stiff
It swings a bit when activated, but the switch radius manages to cover for it. You
Erm, you mean the switch's area? In my setup, It's 80 degrees, and the radius is shown in the picture. If I got your question wrong, ask away.
If this is too much off topic, be sure to tell me, and I'll open a thread.
I think it was hysteresis but i'll let RTM correct me if im wrong...
I get how it works. ;)
I was debating the flipping piston's speed. :O
If it goes through objects it is therefore not affected by physics leading me to believe it instantainiously(sp?!) "teleports" to to the in/out location upon flipping. If it's speed were above instantanious then it should break, as it would still come in contact with the piston.
Of course, it does take some amount of time due to the following:
Your TV's refresh rate. Is not instantanious, even if it seems like it.
The very fact that your PS3 has to calculate were it goes and then display it.
Therefore: 0.05 > X > 0
Ah I'm just having fun. :P
Yep it's hysteresis, I couldn't make this device without knowing that it's in LBP too: specifically, while it bounces, the hysteresis grants a stable output - if it wasn't for hysteresys, this device wouldn't work at all.
@Fishrock123: I just tested it, flipping an object through a long one works - it breaks while trying to go back - so basically pistons are instant, or equal to the game's refresh rate
I can make one with 2 pistons (maybe a piston and a winch -- i'll have to experiment), 1 DM blob, and 1 cardboard blob -- the catch is that i need an extra mag key. Is that the most efficient?
OK, the flipper movement does seem to be instantaneaous, at least as far as we can see it. However, the update ont he magnetic switch is not. If you trigger a 1-shot signal into a flipper piston that then activates another one-shot, there is a delay of 0.05s, which appears to be the magnetic switch sampling rate (for directional and one-shot signals, I'm still unsure on on/off and speed, they may have higher sampling rates).
As for the parrallel pistons toggle, the update time will be 0.05s, based upon the updated of the flipper motion. You don't have to take into account the directional piston motion as the output is already updated before that piston moves.
With the design in the OP, remember that it pulls in using flipper motion, then requires that the object be slingshotted past the centerpoint and over to the other side. I don't know how long that takes, it probably occurs within the 0.05s, but I don't know. If anything it might be slower than other forms of toggle, so your time analysis was a little backwards shadowheaven ;)
-edit: To get instantaneous propagation of signals you will need to use emitters, I'm almost 100% sure that it's the only way.
As for comphermc's replcement design, it failed for me on the 2nd and 3rd times I hit it with inputs, then never again. I did see a bit of bounce on the output a couple of times too. TBH, I'd consider modifying it to use a triangle and a 180 degree magnetic switch, but I haven't tried that.
The XORs: There are some nice concepts there, but you've not reduced thermo in any realistic manner (by that I mean you've increased some thermo to reduce other thermo and I'm not buying this "1 connector costs less than an moving object argument" :p)
@RCIX, what device are you talking about? A toggle?
For the response time, I agree with you that the emitter based one shown in the logic pack is still unbeaten.
The piston based device actually requires 0,1 seconds to change state - I compared it to a chain of two flipping pistons, so that I had a perfect delay of 0.1 sec to compare with, and the time response was exactly the same - the winch based device had a response time of 0.05 secs when flipping in, and 0.1 secs when flipping out.
I'ts still 0.05/0.1 against a fixed 0.1 - it's faster half of the time :)
All of the above was tested with the following assumptions:
- a flipping piston/winch takes 0 seconds to flip when it receives an input
- the mag switches sample rate is 0.05 sec
I noticed also that a flipping piston and one set to directional with a time of 0,1 give the same exact response time.
For my XOR, I told you it requires a lot of tweaking ;): I tested it with two inputs, one with frequency 0.1 and the other with a variable frequency between 0.1 and 0.5, and it works perfectly - it has some problems when one input is 1 and the other is flipping at 0.1 secs, but it's spring based, so of course it isn't stable - I mostly made it for fun :p - I may have been lucky getting the exact range, so I added it as a prize in my logic level, should you have too much trouble tweaking it.
@RTM: An XOR. I'm hoping that a force of two conflicting pistons (or a piston and a winch) at the same strength will cancel out and make the object under their influence return to normal.Thus, all i have to do is mount 2 keys to the DM blob and i get an XOR! maybe i better publish a level showing my idea later. It's quite possible it won't work...
The two pistons will cancel each other out and create a zero force and stay stationary. See comphermc's set-reset thread and the logic pack sackperson tracker for applications of this.
@shadow, I'm not following you 100%, I'll have to wait for my controller to charge and then have another look. I was sure the magnetic switch activation happens before the directional piston finishes moving though. Edit, no it definitely does, it's the output that drives the directional piston, so there is no way the output takes 0.1s to activate..... Give me an hour here.
I'm happy knowing that I'm not the only one that speaks to himself to solve problems ;)
If I wasn't clear on something, please tell me - I will probably be out all day tomorrow (erm, today... the 5th, okay?), so I won't be able to reply before saturday.
You and me both, I also didn't get back on my PS3 properly because I didn't actually plug the other end of the lead into anything. Apparently the cable on it's own is not enough to charge the controller :rolleyes: