Archive: 26 posts

---

Finally decided to create an account here, as I threatened to on the LBW forums on my 1000th post (http://forums.littlebigworkshop.com/lbp/board/message?board.id=creationgen&message.id=41390#M41390) there. Here's looking forward to some heated arguments interesting discussions about efficient logic circuits with the likes of rtm223 and comphermc.

2010-03-01 01:42:00 Author: Aya042 Posts: 2870

---

Welcome! Glad ya made it! Yup.. rtm and compher are around here somewhere. Let us know if you have any questions! Have fun!

2010-03-01 01:45:00 Author: jwwphotos Posts: 11383

---

Eh, we're not so big on arguments here at LBPC, but you can try I guess. Comph tends to shut 'em down pretty quickly. However, welcome to LBPC and I hope you find your time here worthwhile. Cheers!

2010-03-01 06:35:00 Author: BabyDoll1970 Posts: 1567

---

Umm, Welcome you new sexy person! Well to get something off my hairy chest, we don't really have heated arguments on here(Though I wish we did) Instead, we pick up flowers and pet horses, we also adopt orphans and take old people sponge baths. And then we HAVE SOME SEXY FUN BY MAKING ACTION MOVIES AND BEING EPIC AND-- yadda yadda yadda just find out for yourself Welcome and enjoy your stay! If you need any help, feel free to message me or anyone else

2010-03-01 07:48:00 Author: Smart_Alex Posts: 189

---

Eh, we're not so big on arguments here at LBPC, but you can try I guess. Comph tends to shut 'em down pretty quickly. However, welcome to LBPC and I hope you find your time here worthwhile. Cheers! we don't really have heated arguments on here Hehe, where have y'all been hiding? The logic "interesting discussions" still run rampant, with comphy as much at the helm as everyone else. Just take a stroll around the object showcase forum once in a while So, Aya, you finally broke then? I guess this means I no longer have to post blog updates at the Workshop anymore Welcome on board.

2010-03-01 13:50:00 Author: rtm223 Posts: 6497

---

He amended "arguments" so we're all good. I'm getting the sense that I'm some sort of evil dictator of something...? I don't see it... -- Anywho, welcome, welcome. Bring it on!

2010-03-01 13:56:00 Author: comphermc Posts: 5338

---

The logic "interesting discussions" still run rampant, with comphy as much at the helm as everyone else. Just take a stroll around the object showcase forum once in a while I had a brief look through the Object Showcase forum before joining, and that's largely what I was referring to - i.e. what some might deem an "interesting discussion", others might deem to be a "heated argument", particularly in the case of the Low Thermo. 8 Digit Security Vault (https://lbpcentral.lbp-hub.com/index.php?t=22269-Low-Thermo-8-Digit-Security-Vault) thread. A bit of a shame what happened to that thread, but that's the ego for you. I guess this means I no longer have to post blog updates at the Workshop anymore Well, I was hoping for some feedback on my latest post on your Logic Blog (http://forums.littlebigworkshop.com/lbp/board/message?board.id=creationgen&thread.id=35262) thread on LBW, but as you seem to be such a rare visitor there, I thought I'd have more luck moving the discussion over here. However, what with the current issues with the PSN, it's probably not a great time to start that up right now, as I doubt I could even show you the new devices I've been playing with. Plus, jackofcourse suggested to me that LBPC is a more 'mature' community than LBW, so I'd better not see any "GIMMEH TEH CROWNZORZ!!!1!!!one!!!" posts here. He amended "arguments" so we're all good. Sorry if it wasn't clear, but that was a deliberate part of the original post, much like rtm did in the Lowest Thermo Toggle (lol) (https://lbpcentral.lbp-hub.com/index.php?t=21996-Lowest-Thermo-Toggle-(lol)) thread. It's part of the ha ha only serious (http://www.catb.org/~esr/jargon/html/H/ha-ha-only-serious.html) mentality that's quite common among many geeks computer science professionals. Of course, in the 'olden days', you'd've used a number of ^H symbols to pretend it was a failed backspace attempt, but even an old(ish) git like me has moved on from the traditions of the 80-column dumb-terminal days - just about. Bring it on! Oh I will. You just wait until I unveil my zero-latency set-reset and toggle switches with no moving parts and no connectors, which, despite violating the laws of physics, allows you to create the self-contradictary 'synchronous ripper counter'. Unless of course, it's been done before, in which case I'd be very interested to see if anyone's found a way to do the same thing with a two-input AND/OR/NAND/NOR gate. My current design has a minor problem with simultaneous input changes.

2010-03-01 17:54:00 Author: Aya042 Posts: 2870

---

Plus, jackofcourse suggested to me that LBPC is a more 'mature' community than LBW, so I'd better not see any "GIMMEH TEH CROWNZORZ!!!1!!!one!!!" posts here. . https://lbpcentral.lbp-hub.com/index.php?t=23289-I-Need-A-Crown lol. Welcome!

2010-03-01 17:58:00 Author: thekevinexpress Posts: 256

---

particularly in the case of the Low Thermo. 8 Digit Security Vault (https://lbpcentral.lbp-hub.com/index.php?t=22269-Low-Thermo-8-Digit-Security-Vault) thread. A bit of a shame what happened to that thread, but that's the ego for you. That was a shame, but I stand by the closing statement in my post, and the rest of it actually. I can take (and quite like) constructive critisism, but that was something altogether different Well, I was hoping for some feedback on my latest post on your Logic Blog (http://forums.littlebigworkshop.com/lbp/board/message?board.id=creationgen&thread.id=35262) thread on LBW, but as you seem to be such a rare visitor there, I thought I'd have more luck moving the discussion over here. However, what with the current issues with the PSN, it's probably not a great time to start that up right now, as I doubt I could even show you the new devices I've been playing with. Indeed, I am still very curious about this after failing miserably to achieve it one afternoon a month or so ago! I am rarely at he workshop and seeing as you and sehven now both post here too, I'd imagine I'll be over there less. BTW, I got different timings to you for the various latencies, so we may need to compare notes on that. Or I need to re-run my tests Sorry if it wasn't clear, but that was a deliberate part of the original post, much like rtm did in the Lowest Thermo Toggle (lol) (https://lbpcentral.lbp-hub.com/index.php?t=21996-Lowest-Thermo-Toggle-(lol)) thread. It's part of the ha ha only serious (http://www.catb.org/~esr/jargon/html/H/ha-ha-only-serious.html) mentality that's quite common among many geeks computer science professionals. I got the joke, don't you worry, it didn't got completely unappreciated

2010-03-01 18:42:00 Author: rtm223 Posts: 6497

---

I am still very curious about this after failing miserably to achieve it one afternoon a month or so ago! Now that the apocalypse has ended, I'll try to get some pictures together later on today for a post on the Object Showcase. I was just hoping to get someone such as yourself to look at it first, just in case what I've come up isn't as great as it appears to be. BTW, I got different timings to you for the various latencies, so we may need to compare notes on that. From my post (edited)... There seems to be three different latencies for mag key switch triggering, which in decreasing order are: moving connectors (50ms avg*), dissolve (25ms**), and emitters (0ms***). ... * My experiments show that the on->off and off->on aren't necessarily the same speed, but on average they come out to 50ms. ** This is a rough estimate with a 10ms margin or of error. I need to work out a more precise figure. *** I'm not sure whether this really is instant, or just so fast I can't measure it. Suffice it to say, if you're limited to 100 gates anyway, it looks pretty instant to me. I'm now leaning heavily toward believing that the 0ms truly is as it says. I have one more test in mind which should confirm it, but as a consequence of this, I'm finding that emitter-based combinational logic will not work in a feedback configuration, such as this D-type latch... http://upload.wikimedia.org/wikipedia/commons/thumb/2/2f/D-Type_Transparent_Latch.svg/300px-D-Type_Transparent_Latch.svg.png ...since it relies on transistor latency to make the feedback work. I could be wrong, however.

2010-03-02 13:48:00 Author: Aya042 Posts: 2870

---

I made it: directional conectors 50ms / 100ms (depending on mag key config) oneshot flipper connectors: 50ms Dissolve: 50ms emitters 0ms. I'm mostly happy with the 0ms delay on emitters - you can make the game freeze to catch up depending on how you set up your test. However I tried to use that in an application and it slightly failed on me - I had to add in shorter paths for the propogation to get remove visible ripple on my 24hour timer - which should have been fine as it was updating using 1-shot emitter triggers. Haven't looked into that deeply though. Instant propogation will ruin feedback loops though. The simple fact that your emitted object will still be there from the previous loop around should be enough to stop it working.

2010-03-02 13:56:00 Author: rtm223 Posts: 6497

---

Don't worry man, I got the humor. I was being cheeky myself. Welcome again. Just to add a little thing to your above comment (since I'm out of my league in this discussion): LBP does input/logic checks in 50ms intervals. So there shouldn't ever be a +/- 10 ms popping up anywhere. Interesting that emitters are "instantaneous". but anything that has to physically move into a region to activate a switch cannot do it more quickly than 50 ms (that is to say that the switch won't recognize it for 50 ms).

2010-03-02 14:55:00 Author: comphermc Posts: 5338

---

I made it: directional conectors 50ms / 100ms (depending on mag key config) oneshot flipper connectors: 50ms Dissolve: 50ms emitters 0ms. Well, my testing method was to set up long chains of each switch (about 1000 100 makes the math easy), time how long it takes for the signal to propagate through the chain, and divide by the number of switches. A simple piston-operated directional mag key/switch pair seemed to take about 70ms to turn on, but only 30ms to turn off. I didn't think to test a flipper motion one, but I didn't really see the point. An inverted dissolve p-switch style arrangement came in at around 25ms, but I need to make a longer chain to get a more accurate reading. I'm wondering if it's actually the same as the switch-off time for the piston results, i.e. that moving a key out of a switch's radius is always the same speed, and is always faster than moving it into the radius. It could also depend on the switch radius, though. I'm mostly happy with the 0ms delay on emitters - you can make the game freeze to catch up depending on how you set up your test. I noticed this too. That freezing is why I thought it might actually be 0ms, and not just a very low number, i.e. it's having to do a large number of simulation calculations in a single 'tick' of the engine. However I tried to use that in an application and it slightly failed on me - I had to add in shorter paths for the propogation to get remove visible ripple on my 24hour timer - which should have been fine as it was updating using 1-shot emitter triggers. Ah. Is that your copyable level with various clocks and whatnot? I'll take another look to see if I can work out exactly what you mean. Instant propogation will ruin feedback loops though. The simple fact that your emitted object will still be there from the previous loop around should be enough to stop it working. Well, since zero-latency switches don't exist in the real world, what with that annoying speed of light limitation, it's quite a unusual concept to comprehend if your knowledge is based on practical electronics. I suppose some theoretical physicists would argue that there's some funky sub-atomic particles which react in a zero-latency fashion, but I've yet to see any practical applications. My suspicions were initially based on my emitter-based NAND gate being unable to reproduce a D-type latch, as per the above diagram, but it's also possible that I just messed up the wiring. I will have another go at some point. Don't worry man, I got the humor. I was being cheeky myself. Thought so, but I wasn't 100% sure, and I thought it best not to alienate one of the mods on my first post. LBP does input/logic checks in 50ms intervals. That's what I thought at first, but my piston-based experiments seem to disagree.

2010-03-02 16:07:00 Author: Aya042 Posts: 2870

---

I noticed this too. That freezing is why I thought it might actually be 0ms, and not just a very low number, i.e. it's having to do a large number of simulation calculations in a single 'tick' of the engine. Never tried chaining emitters. Do you just have emitters tripping more emitters by emitting keys? ..in a big long chain? Color me intrigued. Well, since zero-latency switches don't exist in the real world, what with that annoying speed of light limitation, it's quite a unusual concept to comprehend if your knowledge is based on practical electronics. I suppose some theoretical physicists would argue that there's some funky sub-atomic particles which react in a zero-latency fashion, but I've yet to see any practical applications. *pushes up non-existent glasses* Well, I'm studying physics, so I'm not the go-to source on the matter, but I'm willing to believe that the speed of light really is a ceiling. When talking about quick enough speeds, we have to concern ourselves with relativity and time dilation and length contraction. This is where it all gets really weird. The laws of physics seem to "bend" to adhere to this ceiling, but do so more as a way to amend expected discrepancies. For all intents and purposes, zero latency is a pipe-dream. Funny, then, for zero latency to be simulated by "freezing" in LBP. That's what I thought at first, but my piston-based experiments seem to disagree. Very interesting. We've always been of the mind that 50 ms intervals ruled LBP. This is exactly why incremental bolts work as well as they do, even without super precise tweaking of trigger areas. Activate and deactivate a mag key switch as quickly as possible (i.e. a flipper piston, set to .1 timing), and it will turn the wheel on for 50 ms. By choosing the speed of the motor bolt carefully, you can force it to turn a pre-described angle each time it is activated. I had problems trying to make incremental bolts work with emitters. It worked sometimes, while not other times. And to further complicate things, these problems only arose when the emitters were switch activated. If I have emitters just emitting at assigned intervals with a lifetime of 100 ms, and then just move the emitter so it emits into the area I want, then it all seems to work. I'm sure that was a bit convoluted, but check out my 12-hour clock level. It's not as good o' design as rtm's, but it displays, hopefully, what I'm talking about here.

2010-03-02 16:25:00 Author: comphermc Posts: 5338

---

Well, my testing method was to set up long chains of each switch (about 1000 makes the math easy), time how long it takes for the signal to propagate through the chain, and divide by the number of switches. A simple piston-operated directional mag key/switch pair seemed to take about 70ms to turn on, but only 30ms to turn off. I didn't think to test a flipper motion one, but I didn't really see the point. Hmmmm... I was only using 40 in the chain, so it could be a rounding thing, but I doubt it. Even with only 40 in sequence, you are talking over a second between 70-100ms, which is actually a significant amount of time. This is a weird discrepancy. BTW: the on vs off time is based upon your mag key setup rather than anything to do with on vs off and you can get it to switch at the same speed (quickly) in both directions if you tweak the radius carefully Flipper piston testing was significant to test whether flippers would switch instantaneously like emitters do (they look like they do, but they don't).

2010-03-02 16:29:00 Author: rtm223 Posts: 6497

---

Do you just have emitters tripping more emitters by emitting keys? ..in a big long chain? Pretty much. As far as I can tell, as long as the mag switch exists at the point where a key is emitted into its radius (i.e. you can't emit the key and the switch at the same time), then it switches in the same simulation tick as the key's emission. Similarly, if that switch is attached to an emitter in a one-shot configuration, then the emitter will fire on that same tick. For all intents and purposes, zero latency is a pipe-dream. I was referring to the theoretical properties of the tachyon (http://en.wikipedia.org/wiki/Tachyon), and I'm sure I recall another instance where some physicists claim you can screw over relativity with some sort of sub-atomic particle spin (http://en.wikipedia.org/wiki/Spin_(physics)), but I forget what it's called. As I said, it's all academic until some sort of practical application demonstrates that it's not just another physicist trying to get rich by exploiting the ignorant. Activate and deactivate a mag key switch as quickly as possible (i.e. a flipper piston, set to .1 timing), and it will turn the wheel on for 50 ms. I saw the thread on it (and a similar one on LBW), although perhaps it's the flipper motion which gives a different timing to a simple directional piston. The other thing to bear in mind is that the existence of the 'Sync' setting on moving connectors implies that, excluding one-shot systems, connectors will always begin to move on specific multiples of the simulation clock, and that that synchronization also affects the switching speed to some degree. ...check out my 12-hour clock level. It's not as good o' design as rtm's, but it displays, hopefully, what I'm talking about here. I already have, but I'll take another look later on. I was only using 40 in the chain, so it could be a rounding thing, but I doubt it. I fixed my typo. I was using 100, not 1000. BTW: the on vs off time is based upon your mag key setup rather than anything to do with on vs off and you can get it to switch at the same speed (quickly) in both directions if you tweak the radius carefully Ah. It could be that, but bear in mind, if my measurements are accurate, and you were to use two mag switches, either side of the key, with larger radii, then you could use a combination of both switches in order to get a faster switching time in both directions... if that makes sense. Flipper piston testing was significant to test whether flippers would switch instantaneously like emitters do (they look like they do, but they don't). I suspected as much. I guess it's just emitters which can break the laws of physics then.

2010-03-02 17:14:00 Author: Aya042 Posts: 2870

---

woah this has turned into a very interesting introduction thread

2010-03-02 17:20:00 Author: Fenderjt Posts: 1969

---

...I need to make a longer chain to get a more accurate reading. FWIW, I just hooked up a 500 unit dissolve chain which took 17.2 seconds to fully dissolve. Allowing for a 500ms margin of error (which is quite high), that would place dissolve latency somewhere between 33.4ms and 35.4ms. Slightly higher than my initial estimate, but still well below the 50ms average of moving connectors.

2010-03-02 19:42:00 Author: Aya042 Posts: 2870

---

http://www.armycadethistory.com/Vernon%20photo%20gallery/VACSTC_2005/Aug1_Tug-of-War3.jpg Come on non logikeers pull!! PULL!! We have to get this thread back!! Oh wait I'm a logikeer, See ya ;p

2010-03-02 20:06:00 Author: Kern Posts: 5078

---

WAZZA!? Welcome to LBPC, enjoy your stay! If you need any creative assistance just call my crew!

2010-03-03 02:48:00 Author: PoD CREW Posts: 268

---

Welcome aboard!

2010-03-03 06:06:00 Author: M_R_Enigma Posts: 161

---

Of course, in the 'olden days', you'd've used a number of ^H symbols to pretend it was a failed backspace attempt, but even an old(ish) git like me has moved on from the traditions of the 80-column dumb-terminal days - just about. Yeah, us young'ns use ^W, much faster. Anyway, welcome!

2010-03-03 16:19:00 Author: Rogar Posts: 2284

---

Ah. It could be that, but bear in mind, if my measurements are accurate, and you were to use two mag switches, either side of the key, with larger radii, then you could use a combination of both switches in order to get a faster switching time in both directions... if that makes sense. No need, you just need a well-tweaked mag switch radius on one side and you can get the fast switching time in both directions. There is also some winch trickery (of course) that can be done to ensure it's not reliant on ever-so-careful tweaking. Plus, I checked the directional propogations and indeed it is < 0.05s. Not that you needed me to tell you, but I have to go check these things myself, y'know Very strange indeed.

2010-03-03 16:42:00 Author: rtm223 Posts: 6497

---

No need, you just need a well-tweaked mag switch radius on one side and you can get the fast switching time in both directions. There is also some winch trickery (of course) that can be done to ensure it's not reliant on ever-so-careful tweaking. I've just had a play with this, and I'm not sure I believe it. If the disparity between the switch-on and switch-off times is solely based on the radius of the magnetic switch, and assuming the hysteresis time is constant, then for a piston with a cycle time of T... t(off->on) + t(on->off) = T + t(hysteresis) ...which is very apparent for large values of T. Still, maybe you're doing something a bit funkier- I can't be sure without seeing it.

2010-03-03 18:09:00 Author: Aya042 Posts: 2870

---

t(off->on) + t(on->off) = T + t(hysteresis) I'm not even gonna pretend I know what that's supposed to mean! Think of it in these terms: Time for piston to move out = 0.05s Mag key is in dead centre after 0.025s Centrepoint of the hysteresis band is at dead centre of mag key movement Magnetic switch samples at 0.035s (give or take) If the extra 0.1s is enough to make the key go beyond the hysteresis band, then you will switch in 0.35s Because all things are equal now in both directions, both directions will switch in 0.35s Plus I can show you

2010-03-03 22:17:00 Author: rtm223 Posts: 6497

---

Plus I can show you No need. I get what you mean. My formula was essentially correct - I just missed out a divide by two. Oh, and my assertion that hysteresis was constant was also incorrect. Let's take a simpler example:- Imagine the piston cycle time is set to 20 seconds, and that the mag key has to move 10 mag-key-sized squares to get from one extent to the other. The piston time from one extent to the other is 10 seconds, therefore it's moving at 1 square per second. Now, if your mag switch's radius places the dividing line exactly halfway between the two extents, then the key will be exactly halfway between the two extents 5 seconds after activating it. If we assume that the hysteresis is such that the entire key must cross the line in order to activate the switch, then that will take an extra 0.5 seconds, making a total of 5.5 seconds latency. Since the dividing line is halfway, the same should be true in the opposite direction, so your average switching time is 5.5 seconds. However, if the mag switches radius is three-quarters the length of the piston, then the activation time is 2.5 seconds to reach the line, and 0.5 seconds hysteresis, making a total of 3 seconds. The deactivation time is 7.5 seconds + 0.5 seconds hysteresis, making a total of 8 seconds. With the dividing line at this point, the average time is (3+8)/2 == 5.5 seconds. Exactly the same as the first case. The point is the radius of the mag switch makes no difference to the average switching time. The only way to improve it is to make the mag key smaller, or the piston longer, thereby reducing the hysteresis time relative to the total time, and even then the best you could do would be 5 seconds, exactly one quarter of the piston cycle time. The point I was referring to earlier was that by having two mag switches with two different radii, one would always trigger faster than the other in each direction. If there were some way to exploit that to use a different switch in a different circumstance, then, with proper tweaking, your average latency would tend towards zero. However, in retrospect, I can't think of a practical way to do that, so this is perhaps moot.

2010-03-03 23:03:00 Author: Aya042 Posts: 2870

Posts: 1077139    Threads: 69970    Members: 9661    Archive-Date: 2019-01-19

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.