Archive: 119 posts

---

I've started a series of blogs relating to logic (http://www.lbpcentral.com/forums/blog.php?u=4072) in LBP. I'm not pushing either piston logic or wobble logic (it's all logic in the end), but how to get from an idea to a finished product. Along the way I will build all sorts of parts, many which may not seem useful at first, to the ultimate "Grand Logic Unification" or GLU. Although I may forget and call it something else. "Is that Logic There? Or are You Just Glad to See Me?" (http://www.lbpcentral.com/forums/blog.php?b=411) is a basic tutorial of AND, OR, and XOR gates that everyone should be able to understand. "The Logic of Equivalent Exchange" (http://www.lbpcentral.com/forums/blog.php?b=400) is a tutorial on how to make a Toggle Switch using pistons. "Wobbly Logic" (http://www.lbpcentral.com/forums/blog.php?b=404) is, of course, nice clean wobble bolt logic. "Evolution of a Bad - VERY Bad - Idea" (http://www.lbpcentral.com/forums/blog.php?b=406) is a discourse on how a bad idea for an wobble bolt RS Latch turned into a good idea that actually works. "Son of a Bad Idea?" (http://www.lbpcentral.com/forums/blog.php?b=412) is short article on how to make a toggle smaller, faster, stronger for only $6 million. And it's possibly a bad idea. "My RS Latch Can Beat Up Your P-Switch!" (http://www.lbpcentral.com/forums/blog.php?b=418) is an article on why it a RS Latch can be better than a P-Switch. It also shows a simple example of how to use one. The goal of the blogs it to eventually lead up to a real project. It will show step by step how we solve the problems and will give tips on how to go about defining and creating your own logic for your levels. This should be a lot of fun! I know I'm having a blast!

2009-05-05 16:52:00 Author: feloneouscat Posts: 89

---

I'm so going to check these out. I get some of the logic stuff I've seen on LBP but I'm not logic minded so sometimes the why and how it should be used eludes me. Great idea - looking forward to it.

2009-05-05 16:55:00 Author: Morgana25 Posts: 5983

---

I'm so going to check these out. I get some of the logic stuff I've seen on LBP but I'm not logic minded so sometimes the why and how it should be used eludes me. Great idea - looking forward to it. I've been doing this since the mid-70's and it wasn't until Fjonan mentioned something to me that I went "oh, wow, that's right -- not everyone knows this like the back of their hand". Logic is pretty darn simple, you just have to learn to break it out into steps. That is part of what this tutorial will be about. Teaching folks how to break things up and put them together. The final tutorial will have all sorts of AND's, OR's and RS Latch's and will look mind boggling complex -- until we break it into how we solve each problem. Then in the end you will go "wow... I didn't know it was that easy!" If you can turn a light switch on and off, then you know binary logic!

2009-05-05 17:02:00 Author: feloneouscat Posts: 89

---

And if you can simultaneously turn 8 light switches off and on, and at the same time calculate the XOR decimal equivalent in your head.... you REALLY know binary logic (at least 8 bit....) You're gonna have these folks building machine code logic into their LBP levels in NO time! (just messing - this looks like a great topic.... it's kind of funny, though, that sometimes it's easier to ACTUALLY program than to build a binary logic contraption)

2009-05-05 17:23:00 Author: CCubbage Posts: 4430

---

I'm pretty much a novice when it comes to this so I'll check it out and see what it does Thanks

2009-05-05 17:44:00 Author: Coxy224 Posts: 2645

---

Logic is pretty darn simple, you just have to learn to break it out into steps. That is part of what this tutorial will be about. Teaching folks how to break things up and put them together. Cool - that's sort of how i'm doing my wiring right now. I'll ask, what do I want this to do, in what order, and what does the player need to do to start it or affect it. Trying to figure out how to make the switches actually DO what I want is where my failings tend to be.

2009-05-05 18:00:00 Author: Morgana25 Posts: 5983

---

I will be reading these promtly...I think I know about some of what your going to say...I think That is why I will show up for class Teach!

2009-05-05 18:30:00 Author: AJnKnox Posts: 518

---

I will be reading these promtly...I think I know about some of what your going to say...I think That is why I will show up for class Teach! If you know what I'm going to say, then you are WAAAY ahead of me! I don't even know what I'm going to say until I write it (I keep telling people that I'm not a planner, but an agent of chaos). But it should be interesting. I look forward to writing it... then reading what I wrote!

2009-05-05 18:39:00 Author: feloneouscat Posts: 89

---

I just got finished reading these topics, and they're definately well-written. Nice job! There's definately a lot to developing logic in LBP. Every time I've worked on a new level, I've had to invent new logic switching systems. One of the most interesting lately was the Tiger Woods Mini Golf switch. The longer you grab, the more it charges - and when you let go it had to immediately hit the ball based on how long you held the material (and reset for the next hit), which ended up being an interesting trick. Definately the key to cool logic is thinking up and charting the entire logical flow - which you show how to do pretty well. Just takes practice.

2009-05-05 18:41:00 Author: CCubbage Posts: 4430

---

I just read your blog posts. It was a very good read! I'm definitely going to reference them often.

2009-05-05 18:55:00 Author: StrayFelisCatus Posts: 178

---

feloneouscat, do you have any plans on doing a tutorial on boolean algebra? The reason I ask is because I've developed a VERY thermo efficient canonical device, which will evaluate a complete sum of products expression, including any negated terms, in 0.1 seconds. I haven't bothered to unleash this on the LBPcentral world as I doubt many people have the theoretical background to convert their logic to canonical form.

2009-05-05 19:00:00 Author: rtm223 Posts: 6497

---

feloneouscat, do you have any plans on doing a tutorial on boolean algebra? The reason I ask is because I've developed a VERY thermo efficient canonical device, which will evaluate a complete sum of products expression, including any negated terms, in 0.1 seconds. I haven't bothered to unleash this on the LBPcentral world as I doubt many people have the theoretical background to convert their logic to canonical form. I probably don't have the theoretical background! My goals tend to be far more pedestrian - to show how anyone can take a design and implement it. Basically, it will be very rule driven and probably create inefficient devices. However, the goal is NOT efficiency, but actually getting something out the door. Now, that doesn't mean that I am not interested in it. PM me and we'll talk.

2009-05-05 19:20:00 Author: feloneouscat Posts: 89

---

I love logic. It's so awesome in its awesomeness. Up until LBP, I'd had little prior contact with it, but with LBP I've found I can make 'most any contraption I wish via logic. I really want someone to set a challenge that is something new with logic, something REALLY complex.

2009-05-05 19:22:00 Author: dawesbr Posts: 3280

---

I really want someone to set a challenge that is something new with logic, something REALLY complex. I have a couple of state machine design textbooks on my shelf, it has questions in. Don't know how complex they are or how complex you're looking for...

2009-05-05 19:32:00 Author: rtm223 Posts: 6497

---

I love logic. It's so awesome in its awesomeness. Up until LBP, I'd had little prior contact with it, but with LBP I've found I can make 'most any contraption I wish via logic. I really want someone to set a challenge that is something new with logic, something REALLY complex. We're going to do some fun stuff. We're going to simulate a LOT of "real world" objects with LBP - as well as the "TUTORIAL" (echos). It will be a something that is useful but HAS to be resettable (sackpeople die SOOO easily). We'll make what are called "ripple counters" and see why they are called that. And, of course, the monostable multivibrator (you gotta love the engineers that came up with those names!).

2009-05-05 19:32:00 Author: feloneouscat Posts: 89

---

I have a couple of state machine design textbooks on my shelf, it has questions in. Don't know how complex they are or how complex you're looking for... Yah, I've considered state machines in LBP - unfortunately, I fear they will chow down on the thermo (after all you have to maintain state). Then, again, my latest toy uses a state machine... Hmmm... mebbe the grand TUTORIAL will be a state machine... we just won't call it that...

2009-05-05 19:36:00 Author: feloneouscat Posts: 89

---

It will be a something that is useful but HAS to be resettable (sackpeople die SOOO easily). I worked out a way of resetting anything by re-emmitting the whole room, logic and all. When the sack dies, you emmit it elsewhere ( I call this demitting ) and then re-emmit it back where it is supposed to be. Works if you set the emmitter to max existing at once=1, and because of that 1, it doesn't chew up your thermo (further testing may be needed on that). As for state machines, I've found with LBP a LOT of digital logic can be created in far simpler ways than the standard gate-level designs (flip-flops and keeping state are prime examples). Although if you look at my previous post about canonical form, that could also seriously reduce the thermo useage, although I don't think I have the concentration span to wire up a full state machine in one go!!

2009-05-05 19:46:00 Author: rtm223 Posts: 6497

---

I dunno. But difficult. I was thinking of ways a PIC may be made, with something akin to a beat sequencer mixed with paint counters mixed with many other components. Would chew the thermo up in no time though

2009-05-05 19:59:00 Author: dawesbr Posts: 3280

---

As for state machines, I've found with LBP a LOT of digital logic can be created in far simpler ways than the standard gate-level designs (flip-flops and keeping state are prime examples). Although if you look at my previous post about canonical form, that could also seriously reduce the thermo useage, although I don't think I have the concentration span to wire up a full state machine in one go!! I've no doubt that your are correct that canonical form is superior to gate-level design. It is just not something I've worked with and therefore know little about. It is far easier to show some simple, if inefficient, ways of designing logic than trying to teach someone boolean algebra. Most people aren't looking to lower their thermo because they built this huge logic monster - most are chewing up thermo because they didn't tie things down to the floor or dark matter. Perhaps you should start a blog to teach us noobs how to do canonical form? That would be terribly interesting to me!

2009-05-05 22:00:00 Author: feloneouscat Posts: 89

---

Fantastic job. Added to the Tutorial Spotlight (https://lbpcentral.lbp-hub.com/index.php?t=t=7260).

2009-05-06 03:43:00 Author: ConfusedCartman Posts: 3729

---

I've no doubt that your are correct that canonical form is superior to gate-level designNormally, no. It kind of expands your logic into a complex, but easy to read, form, which can then be easilly be reduced down. It's more a means to an end in the real world. Comes down to lots of signals fed into lots of AND gates, then all the ANDs are fed into a single OR (with optional NOTs before and after each AND). But you are probably right, it's not the most useful of things in LBP, and not that easy to teach. I also forget how naturally this stuff comes when you've been doing it a few years. I'll shush now!

2009-05-06 10:57:00 Author: rtm223 Posts: 6497

---

One PROBABLY obvious suggestion for amatures when putting together some of this logic - if you're building feloneouscat's logic gates directly from the schematics, they CAN be fairly efficient. If you use square shapes instead of circles to draw your "wheel" that the switches and keys sit on, it will be more efficient on your "angular" thermo. You can place the square at a 45 degree angle and place the switches on the corners of the squares.

2009-05-06 13:13:00 Author: CCubbage Posts: 4430

---

Normally, no. It kind of expands your logic into a complex, but easy to read, form, which can then be easilly be reduced down. It's more a means to an end in the real world. Comes down to lots of signals fed into lots of AND gates, then all the ANDs are fed into a single OR (with optional NOTs before and after each AND). But you are probably right, it's not the most useful of things in LBP, and not that easy to teach. I also forget how naturally this stuff comes when you've been doing it a few years. I'll shush now! (techy talk here - so for those who don't understand, it is like the buzzing of a mosquito) Okay, you are talking about what I thought you were talking about - this is what is used to optimize the logic for FPGA's and some of the more complex CPLD's. Which a) works really, really good for those devices b) but actually entails MORE work if you are building something small -- which would be the majority of the cases on LBP. Sorry, I'm in the middle of a LOT of things and I wasn't thinking clearly yesterday. Still, it might be interesting if you wrote up a "Beginners Guide" - I'm lazy and use the tools and really don't spend much time figuring out the math

2009-05-06 13:25:00 Author: feloneouscat Posts: 89

---

One PROBABLY obvious suggestion for amatures when putting together some of this logic - if you're building feloneouscat's logic gates directly from the schematics, they CAN be fairly efficient. If you use square shapes instead of circles to draw your "wheel" that the switches and keys sit on, it will be more efficient on your "angular" thermo. You can place the square at a 45 degree angle and place the switches on the corners of the squares. If you are concerned about vertices, then use triangles - one less vertex. As for being "more efficient" I would have to do some tests. A wheel uses more vertices, but in terms of computation, rotating a square and rotating a circle aren't significant (basically array multiplication). As for tests, I've put 1000 squares with wobble bolts on a level before overheating. I must confess, however, I have not tested this with either circles are triangles. I'll have to give that a go today.

2009-05-06 14:22:00 Author: feloneouscat Posts: 89

---

Yeah, ignore the buzzing people. It does work well for those specific devices, and does involve more effort, I suppose the big advantage in LBP is getting the whole CPLD-type device switching in 0.1s, as nested logic in LBP takes a while to propogate through. As for beginners guide to algebra, it might be useful, I suppose as long as I prefix it by saying it's easier than normal algebra, some people might take interest... Of more use might be some tips and tricks to strip down LBP logic in a very practical sense, as I've found a lot of NOT and OR gating can be shoehorned together, which reduces complexity and propogation times. A wheel uses more vertices, but in terms of computation, rotating a square and rotating a circle aren't significant (basically array multiplication). but more vertices means much more complicated collision detection, which the thermo has to consider as a potential, even if you know nothing is going to hit your "wheel"?

2009-05-06 14:23:00 Author: rtm223 Posts: 6497

---

If you are concerned about vertices, then use triangles - one less vertex. As for being "more efficient" I would have to do some tests. A wheel uses more vertices, but in terms of computation, rotating a square and rotating a circle aren't significant (basically array multiplication). As for tests, I've put 1000 squares with wobble bolts on a level before overheating. I must confess, however, I have not tested this with either circles are triangles. I'll have to give that a go today. I totally agree.... A triangle is one less, I just figured the edges of a square would be easier for logic because they're right across from each other. And from a CPU perspective, I agree with rtn223 - definately more complicated collision detection with circles. No biggee.... I see where you're coming from on the whole exercise. The shapes are less important than the lesson. Just throwing it out there for people who are actually putting it in their level. If they needed the logic lesson at all, chances are they may also be inexperienced with the thermo. Wyth and I did a number of efficiency experiments a few months ago, and definately a circle shape takes up far more vertices thermo than squares or triangles. Regardless, I'm really digging your lesson approach. You're a good teacher. I would strongly suggest, however, that creators not get too worried about the info in this thread and go read your blogs. The thread has gotten kind of overly-complicated, but your blogs are really good learning tools.

2009-05-06 14:30:00 Author: CCubbage Posts: 4430

---

I totally agree.... A triangle is one less, I just figured the edges of a square would be easier for logic because they're right across from each other. Software really doesn't care. The concept of "across" is nebulous to code - it is human being that put interpretation on things. A cube in code is represented by points in 3d space (which, again, is an interpretation) and something that indicates linkage between points. I've actually done the math to create a rotating cube from scratch. It was not pleasant (that was 30 years ago on an Apple II!). And from a CPU perspective, I agree with rtn223 - definately more complicated collision detection with circles. No doubt. But I have 1000 circles running just like I had 1000 squares. Is the collision detection method even called? Dunno. I hesitate to jump into speculating. But in terms of thermo, testing shows them to be equal. Now which should you choose? Whatever makes you and your level happy. Much in the same way that my testing showed pistons to be FAR more thermo hungry than wobble bolts. Again, why? Perhaps pistons have more mathematics behind them now? Dunno. Again, hesitate to speculate. No biggee.... I see where you're coming from on the whole exercise. The shapes are less important than the lesson. Exactly. Nor will the amount of logic most people put into LBP even be affected whether they use squares, circles, hexagons, or triangles. Wyth and I did a number of efficiency experiments a few months ago, and definately a circle shape takes up far more vertices thermo than squares or triangles. Yes, Mikey-Flies and I did as well over at LittleBigWorkshop. You'll find a lot of good info there. My testing, however, post-Yarg shows no difference in squares or circles. You can get 1000 of each. Whether that is the wobble bolt, the shape or both, I dunno. Only Mm can answer that one. Regardless, I'm really digging your lesson approach. You're a good teacher. Thanks!

2009-05-06 15:05:00 Author: feloneouscat Posts: 89

---

Software really doesn't care. The concept of "across" is nebulous to code - it is human being that put interpretation on things. A cube in code is represented by points in 3d space (which, again, is an interpretation) and something that indicates linkage between points. I've actually done the math to create a rotating cube from scratch. It was not pleasant (that was 30 years ago on an Apple II!). Keep in mind, I'm also a professional programmer (and have been doing it probably as long - I go back as far as z-80 video game machine coding in the late 70's and developing video games in 6502 assembly in the early to mid 80's). Across IS nebulous to code, but this is not code - it's LBP logic, and across means something if you're placing a magnetic switch on an object. In all honesty I wish it was code, because I can write logic MUCH faster than I can throw wobble bolts on objects suspended with dark matter.... No doubt. But I have 1000 circles running just like I had 1000 squares. Is the collision detection method even called? Dunno. I hesitate to jump into speculating. But in terms of thermo, testing shows them to be equal. I'm gonna have to take another look at this one with Yarg. I was not able to place nearly the amount of circles as squares in thermo testing originally. The "edge" thermo was eaten up much faster when placing more complex shapes such as a circle. Also, if I were to mix glass, lighting, and more edges I was able to create slowdown which I could solve with less-complex shapes, so in personal experience I'm not speculating. Does it have ANY effect at all in a logic shape moving off-screen with simple materials? This I have no idea.

2009-05-06 15:23:00 Author: CCubbage Posts: 4430

---

Keep in mind, I'm also a professional programmer (and have been doing it probably as long - I go back as far as z-80 video game machine coding in the late 70's and developing video games in 6502 assembly in the early to mid 80's). (laughs) Also a professional programmer! We're probably about the same age! I also did z-80 assembly and 6502 assembly (though mine were for consumer goods - floppy drives, hard drives, etc.). Oh, and can't forget my favorite - the 6809... killed because an executive at Motorola didn't like another executive... (sigh) Across IS nebulous to code, but this is not code - it's LBP logic, and across means something if you're placing a magnetic switch on an object. In all honesty I wish it was code, because I can write logic MUCH faster than I can throw wobble bolts on objects suspended with dark matter.... I've had it in the wish list for logic gates for some time because it would reduce thermo and allow for substantially faster logic (.1 second is for the birds). I'm gonna have to take another look at this one with Yarg. I was not able to place nearly the amount of circles as squares in thermo testing originally. The "edge" thermo was eaten up much faster when placing more complex shapes such as a circle. My tests were pretty darn simple. A large square anchored by dark matter. Then slapped on squares with wobble bolts. Put 100 per cube and dup'ed each one. I did the same thing with the circle. In both I could only get 1000 before it topped thermo. I have not done a plain circle vs. square test - so I defer to your tests on that. Also, if I were to mix glass, lighting, and more edges I was able to create slowdown which I could solve with less-complex shapes, so in personal experience I'm not speculating. Does it have ANY effect at all in a logic shape moving off-screen with simple materials? This I have no idea. You would (and this is speculation) have less because there would be no render time involved. However, the physics engine should still get called for each object. I agree that my tests for simple and I do not disagree that simpler shapes SHOULD present a smaller compute time. However, my testing showed little if any difference. I may try triangles next. I'm curious as to the result. What I found puzzling is why I could only get a little over 790 pistons... Perhaps the fact that they now have droop? Dunno. Very odd.

2009-05-06 16:00:00 Author: feloneouscat Posts: 89

---

Definately - pistons with material on them seem to be incredibly complex on the physics engine. It was kind of funny - several months ago I was suggesting a simple logic gate to someone that consisted of a few emitters instead of piston logic pushing a key. I got a bunch of people really mad at me because the assumption was that emitters were heavy on thermo, whereas pistons were light. I replied that based on my tests, pistons were really not necessarily the best choice because they created a lot of complexity in the physics engine, and therefore dropped thermo. But a 1-at-a-time emitter using a simple object seemed to be REALLY efficient, and since the object didn't exist until it was emitted, it SHOULD be really efficient on CPU (since the object doesn't have to react to the physics until its emitted). But on the other hand, I've found that wobble bolts, spin bolts, pistons, and emitted logic all seem to have a place depending on the type of logic you're trying to create. I actually have one object that uses ALL of them at once in order to make decisions. I try not to get too much into logic creation with LBP planet, because then its too much like my job.

2009-05-06 16:10:00 Author: CCubbage Posts: 4430

---

I try not to get too much into logic creation with LBP planet, because then its too much like my job. Oh, I LOVE this kind of stuff. My degree is Computer Science but I've been playing with hardware since I was in my teens (best Christmas ever: a bunch of 7400 series chips from Radio Shack). I do that low-level software, mostly interfaces with hardware. FPGA are FUN city - except VHDL is horrid (it is a dreadful clone of Ada which is in itself a dreadful language). MEANWHILE, I did some testing and making flat rectangles I got 1399 on an empty stage. Flat circles I got 1388. I know that Yarg changed a lot of how thermo was calculated, but this seems to indicate that it goes beyond just emitters... Very interesting results...

2009-05-06 16:18:00 Author: feloneouscat Posts: 89

---

CCubbage, I spent a little while playing with emmitted dark matter with keys on, I especially like the way you can add all kinds of timing effects onto it easily as well. I also found it seems to (understandably) do little to the thermo, but that idea got slated and it nearly scared me off (I was a creator / thermo noob at the time). Wobble bolts on the other hand didn't occur to me until reading those blogs.

2009-05-06 16:52:00 Author: rtm223 Posts: 6497

---

Wobble bolts on the other hand didn't occur to me until reading those blogs. FWIW, I didn't come up with wobble logic, piston logic, or emitter logic or any other kind of logic (Boole did the heavy lifting in that area). My dabbling was coming up with the most efficient (as in number of parts, not thermo) way of doing logic that was understandable - to me as well as the masses. BTW, I THINK I came up with a Toggle that only uses two wobble bolts. I'm thinking of calling it "Son of a Bad Idea"...

2009-05-07 00:03:00 Author: feloneouscat Posts: 89

---

feloneouscat - Great stuff. It will definately help if the thermo gets calculated differently with shapes. I need to re-run a lot of earlier tests. rtm223 - Totally agree. I think feloneouscat has done a great job in showcasing less-used additional options that will react more consistently than devices most creators are using. I've personally been using just about EVERYTHING as logic in the background, depending on what I need things to do. Many different techniques are appropriate for different reasons. The cool thing is when you master this stuff and end up combining all the different techniques into a background cause-and-effect machine to select different outcomes. Neat stuff. It's actually kind of satisfying when practically no one can figure out how you did certain things in your level.

2009-05-07 00:03:00 Author: CCubbage Posts: 4430

---

BTW, I THINK I came up with a Toggle that only uses two wobble bolts. I'm thinking of calling it "Son of a Bad Idea"... **** you, I was just onthe way to bed and I'm gonna be up all night thinking about it. Actually, wait... might it have something to do bolt A having a 1-shot input , which triggers a on/off mag switch connected to the second, relying on the timing of the first one's 1-shot motion to move the second exactly half a cycle? I now have to work out if this beats my 1 piston (or wobble bolt) / 1 emmitter toggle switch

2009-05-07 01:07:00 Author: rtm223 Posts: 6497

---

Saw your blog post. Thought I'd copy my idea over: "So you're doing it 2 wobble bolts? Why not do this: One-shot switch (by which I mean just have the output as 1 shot) This triggers a wobble circle to go once. As it leaves the area of detection for a switch on the other circle, that circle then activates its wobble bolt at 1/2 the speed. The first circle return to normal, but the top would only have moved 1/2 a turn. Each time you press the switch, it'll only move 1/2 of a turn - ie, toggle switch. No?" Seems a bit more reliable and without the "one-shot" section needed in between.

2009-05-07 03:03:00 Author: dawesbr Posts: 3280

---

Dawsbr, I think thats what I was saying... I'm pretty sure you would just have to set both to a 0.2s timing. Could also be extended to a 3-wheel RS flip-flop, which would be nice as I'm currently using a 2-chain implementation of a flip-flop which I don't really like (or trust 100%)

2009-05-07 08:27:00 Author: rtm223 Posts: 6497

---

Well, I played with "Son of Bad Idea" for a few minutes and it is a real PITA. I still don't have it working yet ::grr As for the "one shot" and why I don't use that: the goal of this series is to create interconnectable parts, NOT the most efficient devices part-wise. Once the logic works as you want, you can always go back and clean it up. So I will be sticking with <-/-> inputs and outputs (the one shot device that I show as a block creates an output that is <-/-> but only a pulse -- it is important for later tutorials - VERY important). Truly, it actually makes things easier than trying to remember which lines are one-shot and which are <-/-> and which are ON/OFF. If I had been part of Mm team from the start I would have pushed for ON/OFF as the signaling method, with edge triggers and one shots. BUT, instead got to work with what I'm given

2009-05-07 17:02:00 Author: feloneouscat Posts: 89

---

Dawsbr, I think thats what I was saying... I'm pretty sure you would just have to set both to a 0.2s timing. Could also be extended to a 3-wheel RS flip-flop, which would be nice as I'm currently using a 2-chain implementation of a flip-flop which I don't really like (or trust 100%) What do you mean by "two chain implementation of a flip-flop"?

2009-05-07 17:04:00 Author: feloneouscat Posts: 89

---

**** you, I was just onthe way to bed and I'm gonna be up all night thinking about it. Actually, wait... might it have something to do bolt A having a 1-shot input , which triggers a on/off mag switch connected to the second, relying on the timing of the first one's 1-shot motion to move the second exactly half a cycle? I now have to work out if this beats my 1 piston (or wobble bolt) / 1 emmitter toggle switch You've delineated exactly why I call it a "bad idea" - it relies on inherent timing that may or may not change in a future patch (not to mention lag may or may not affect it... dunno). There are some bothersome aspects about it. Is this the "crush the object that is emitted" toggle? Seen it. I see three objects the physics engine has to get called on (max) where with this (if I can get it working) the physics engine (max) only gets called twice. Or so I am assuming...

2009-05-07 17:12:00 Author: feloneouscat Posts: 89

---

2 chain flip flop = a set / reset circuit which has 2 chains connected to either side of a block of glass with a mag switch on it. Chain one pulls the glass left (set), chain 2 pulls the glass right (reset). I've never seen it fail, I can't make it fail and I know other people are using it happily too, but I can imagine the glass bouncing off the side and for this reason alone I don't trust it. The 3-wheel flip flop would actually be a JK flipflop with directional inputs, i.e if you hold set AND reset high it will oscillate back and forth and be nicely deterministic about the whole thing. Which pleases me. The emmitter and piston toggle is not a crush the emmitted object. It emmits a block of dark matter that exists for 0.1s, which makes a piston move 1/2 a cycle. I would normally agree with your inherent timing views, although I don't think this applies to immobile piece of DM existing for 0.1 seconds - even if the sample period is reduced down, 0.1s is still 0.1s, even if it's 2x0.5s! And if the sample period goes up... Well, lets not think about that. As for one shots, I could be wrong (it occasionally happens) but I'm not convinced you can make a proper toggle without one-shots, the input to a traditional toggle flipflop is actually the clock signal to a JK flipflop so it's got to be edge trigger. If you want a directional input to it then you will need a translation component in the middle to give that 1 shot effect. From a tutorial POV I fully understand that you want all directionals, it makes all your tools slot together. What is your design, because I don't get how you want to do direction inputs to toggle.

2009-05-07 17:43:00 Author: rtm223 Posts: 6497

---

As for one shots, I could be wrong (it occasionally happens) but I'm not convinced you can make a proper toggle without one-shots, the input to a traditional toggle flipflop is actually the clock signal to a JK flipflop so it's got to be edge trigger. If you want a directional input to it then you will need a translation component in the middle to give that 1 shot effect. From a tutorial POV I fully understand that you want all directionals, it makes all your tools slot together. What is your design, because I don't get how you want to do direction inputs to toggle. Agree about the chain. Not a clean method. Agree about the emitter/piston toggle - tho my tests have shown that pistons are more thermo hungry than wobbles (little over 750 pistons vs. 1000 wobbles before overheating). Depends on where you put the one-shot (grin). Go to my blog regarding the toggle latch. All inputs and outputs are directional. Any one-shottedness is built entirely WITHIN the toggle. As such, externally, it appears as if the one-shot is edge triggered (heh). Granted, it is FAKE edge triggering, but that's all we need. BTW if I can get "Son of a Bad Idea?" working then I'll HAVE to put another wobble bolt in to create the fake edge trigger. But that's okay. A three wobble bolt toggle would be pretty slick. There are methods to my madness... or I might just be plain mad...

2009-05-07 19:00:00 Author: feloneouscat Posts: 89

---

BTW if I can get "Son of a Bad Idea?" working then I'll HAVE to put another wobble bolt in to create the fake edge trigger. But that's okay. A three wobble bolt toggle would be pretty slick. See my last post about the translation component. And three wobbles isn't the same as two wobbles now is it? I might do a little test on 1 shot pistons verses 1 shot wobbles vs 1 shot DM emmitters. 1 shot moving parts seem to be more thermo hungry because they move faster, but DM doesn't move... might be interesting

2009-05-07 19:09:00 Author: rtm223 Posts: 6497

---

See my last post about the translation component. And three wobbles isn't the same as two wobbles now is it? I might do a little test on 1 shot pistons verses 1 shot wobbles vs 1 shot DM emmitters. 1 shot moving parts seem to be more thermo hungry because they move faster, but DM doesn't move... might be interesting The third wobble is purely to keeping in the <-/-> of normalizing the signals. 99.99% of all logic in LBP doesn't need to be efficient - but it does need to work. Now, after you get it working, from my point of view at least THAT is when you set about making it efficient. For example, I've seen a lot of people try to make their code efficient while they were writing it and creating unholy messes that at best were cryptic and at worst non-supportable. And it IS two wobbles - just not when normalized to directional. As I say, there really, REALLY, is a madness to my method...er... method to my madness... DO let me know the results of your tests: as CCubbage and I have discovered, to his chagrin happy dancing, and to my surprise, is that Yarg has changed a lot - and not just pistons. As I keep saying to myself, "everything we know about LBP is now wrong!"

2009-05-07 20:01:00 Author: feloneouscat Posts: 89

---

Actually, it's not really to my chagrin . I love it when things improve and I don't have to worry about it as much. If edge thermo is more efficient than it was, I'm a happy camper. I have noticed on Splat Invaders II that the constant nagging that I need to simplify my shapes is no longer happening, and I have about 10% left on my thermo now.... whereas before I was hitting the thermo limit. BUT... exactly how its working is an unknown again. Did they make the thermo buffer for edges bigger, or did they totally change the algorithm?, or are they treating unchanged circles as an actual shape rather than storing the individual vertices?? Knowing exactly how they're calculating this stuff would make decision making much easier. The interesting thing is, we talk about creating thermo-lite logic, but for the VAST majority of levels the shapes we need to use to create logic are the simplest shapes in the level, and usually the logic gates are the least of our worries when it comes to thermo. The thing that worries me as much as you is the logic that counts on timed reactions. This is illustrated in my Tiger Woods Mini Golf, where it's almost unplayable with lag because of the network of little timed logic events happening behind the scenes.

2009-05-07 20:16:00 Author: CCubbage Posts: 4430

---

Okay, I struck the chagrin... but am imagining you doing a happy dance I think it is more a refinement of the thermo algorithm which, to be frank, tended to throw the baby out with the bathwater. Ideally, thermo should be a good indication of performance when it runs, but the old thermo allowed you to create conditions that were at run time were horrible. As an example, pre-Yarg and in PAUSE I created 1400 emitters that emitted nothing. Topped my thermo. Changed 100 of them to emit something at .1 seconds. Still 100%. Now, you can guess where THIS is headed! Took it off pause and I believe it either froze my system or made it run really, really, slow (hard to tell when nothing moves!). Thermo reminds me a lot of "top" under Linux - although top is telling you (sorta) what is happening, whereas thermo is just a guesstimate.

2009-05-07 20:46:00 Author: feloneouscat Posts: 89

---

I was kind of picturing them creating a signed short integer counter for vertices, and then saying "oh crap! levels can only have 32765 edges or we wipe out the LBP profile!.... Oh well, too late now... send it out!" Then, in Yarg changing it to an unsigned integer.... Non-programmers ignore this because it's either going to sound a) stupid or b) nerdy.

2009-05-07 21:01:00 Author: CCubbage Posts: 4430

---

I was kind of picturing them creating a signed short integer counter for vertices, and then saying "oh crap! levels can only have 32765 edges or we wipe out the LBP profile!.... Oh well, too late now... send it out!" Then, in Yarg changing it to an unsigned integer.... Non-programmers ignore this because it's either going to sound a) stupid or b) nerdy. Oh, great, only 64K? Might as well use ints - the compiler is just going to align it on dword boundaries anyway or it segfaults. Aha... yah, we do sound nerdy. http://i207.photobucket.com/albums/bb140/feloneouscat/IMG_1651.jpg (more buzzing of mosquitos...)

2009-05-07 22:38:00 Author: feloneouscat Posts: 89

---

[QUOTE=CCubbage;197860]I was kind of picturing them creating a signed short integer counter for vertices, and then saying "oh crap! levels can only have 32765 edges or we wipe out the LBP profile!..../QUOTE] Has someone been teaching you to count from 1? I can squeeze an extra edge into edges[0]. And that's how I mastered thermo. The end. edit: does anyone else even read this thread now do you think?

2009-05-08 00:13:00 Author: rtm223 Posts: 6497

---

[QUOTE=CCubbage;197860]I was kind of picturing them creating a signed short integer counter for vertices, and then saying "oh crap! levels can only have 32765 edges or we wipe out the LBP profile!..../QUOTE] Has someone been teaching you to count from 1? I can squeeze an extra edge into edges[0]. And that's how I mastered thermo. The end. edit: does anyone else even read this thread now do you think? PFFT! I can squeeze even MORE in if I use the entire range of 0-32767! BTW, "Son of a Bad Idea?" is now up. Search @feloneouscat and it is the "Logic Blog" level. It has a 5 stage ripple counter using, yes, 2 wobble bolts for a toggle and one wobble for a one-shot. Downside, it was a FREAKING pain in the hindquarters to get to work. I'm not sure this is something even usable. If anyone cares to copy (yes, the level is copyable) and tell me how to EASILY recreate it, I would appreciate it. I suspect there is math involved and some geometry. Although... there is something beautiful about it's ugliness... (laughs) P.S. I read it... now whether I am "anyone" or not is purely a matter of interpretation...

2009-05-08 00:24:00 Author: feloneouscat Posts: 89

---

Good topic. I'm enjoying RS Latch process. I think there's an easy way to make it with 3 pistons though that doesn't rely on inertia. Place three horizontal pistons end to end (each attached to its own piece of dark matter. []----K []--S []-----K The key switch (S) is of course directional and controls its own (center) piston as well as serving as the output. The leftmost piston is the set. The rightmost piston is the reset and is set to backwards. What's the trick? Just make the center piston shorter than the other two. When the set is triggered it moves into position, activating the switch. The radius is large enough that the set key stays within the switch's radius for the entire move. If the set goes away it stays put due to the reset key. Once the reset key is activated, it moves out of the range of the switch, causing it to reset to the original state.

2009-05-08 02:02:00 Author: dcf Posts: 468

---

I meant besides the three of us, and I will admit to being embarrased about the whole numbers thing, but in my defense it was gone midnight here when I wrote it. Anyhoo, I made a stable of your son of a ***** and found it quite a pleasant, stable little critter. So I copied the level I know where you went wrong: I'm pretty sure you would just have to set both to a 0.2s timing. Your bolt with the one-shot input was set to 0.1s. Only other difference I can see is that I was using 180 degree rotation, but that's just about accuracy of your placing (I was being lazy, plus the 180 degrees is pleasing to my eyes). The 0.2s timing on the 1 shot is because of the way flippers behave on a 1shot and what happens when you try to sample them - if you set the bolt to 0.2s with rotation range a, then input a 1-shot: At t=0: 1-shot signal goes in wheel is at 0 degrees At t= (0 + delta) seconds: wheel is at a degrees but nothing samples at (0+delta) at t = 0.1s Wheel is at a/2 NOTE: the mag key radius must be large enough that it samples this halfway point - this makes 180 degrees a lot easier. at t=0.2s you are at 0 degrees again So the output signal from this is on for 0.1s, giving a half cycle on the output. When trying to sample a flipper moving at 0.1s the entire movement should be completed inbetween sample points (i.e at both t=0 and t=0.1, the wheel should be a 0 degrees and so the the wheel should be deemed to have never moved according to the samples), but the sampling part seems to have some notion of movement but can't handle it properly just goes off on one. Rather than a stable output for a whole 0.1s interval, it just seems to give a little pulse, which is against everything I know about sampling in LBP. It's strange and I don't fully understand but I think thats what is going on. This is the best I can do with a black box scenario like this. @dcf: Is this your own design? I tested it but modified it so that all three pistons are connected to the same piece of DM and I didn't invert the reset signal (I'm not sure where that idea came from). It works great. It also has the behaviour that with S and R both high, it stays at stable S state, which is far more deterministic than most designs I've seen. I think I have a simpler design than this, based on the strong chains / weakish pistons combo, which allows for multiple set and reset signals without separate external OR gating. Will have to have a go tonight and compare these two designs, along with a wheel implementation of your one, along with the three wheel JK FF. Should have a candidate for simplest stable set-reset circuitry after that

2009-05-08 02:18:00 Author: rtm223 Posts: 6497

---

When trying to sample a flipper moving at 0.1s the entire movement should be completed inbetween sample points (i.e at both t=0 and t=0.1, the wheel should be a 0 degrees and so the the wheel should be deemed to have never moved according to the samples), but the sampling part seems to have some notion of movement but can't handle it properly just goes off on one. Rather than a stable output for a whole 0.1s interval, it just seems to give a little pulse, which is against everything I know about sampling in LBP. It's strange and I don't fully understand but I think thats what is going on. This is the best I can do with a black box scenario like this. The problem is that there appears (in my most humble opinion) to have been two authors on the key switch - or the author forgot what he did on it originally. The original keyswitch (sans adjustable arc) has some dead space in it or conversely, acts a lot like a phase locked loop (i.e. when it enters by X amount only THEN does it trigger and when it exits by X amount does it untrigger). In other words there is some fuzziness. You have to do this on real-world devices - if you do not and the sensor is JUST ON THE EDGE, you can get non-deterministic blips. When I was working on "Son of a Bad Idea?" I originally designed it as if it worked on the sides of the arc as it did on the arc itself - au contraire! The sides of the arc do not have this little bit of filtering. So even at 4 seconds (yes, four seconds) if it was on the edge I entered into an unstable state - it was neither on nor off. As you say, that little pulse turned a simple idea into a horrible exercise. Worse, turning the sensor turns the entire arc - okay, you make it unrealistically large - well, that didn't help because you then run into the issue of it moving your "hit" location (for my design). Also, the graphics of the sensor do NOT seem to match up to the internal logic - i.e. it looks like (to me) that it is all the way in sensor range, but the sensor is outputting random blips (which turned into annoying oscillation). As a consequence it was very difficult to align the key and switch because although it looked "perfect" to me, LBP had far different criteria. This is probably what gave me fits. I kept fighting "what I saw" vs. "the result". @rtm223 "where you went wrong" - actually, I think that's a little harsh. When I got it working - as designed - it was actually quite stable. Please publish your version. If it is easier to build, then I will use it and put it in a future version of the logic series. The one shot was only added for signal homogeneity - my test rig used a push button switch set to one-shot.

2009-05-08 14:18:00 Author: feloneouscat Posts: 89

---

OK "where you went wrong" was a very bad choice of words. It was 3am when I wrote that and I certainly didn't mean it to be derogatory. I still think this is part of the reason it was difficult though. I've been thinking of the fuzziness as hysteresis, and I have observed it too. I've also observed it on the hard edges of angle switches, which annoyed me because (due to the graphics) I was hoping it wouldn't exist there. It's less pronounced there than at the rounded edge, or maybe it's relative to the distance from the switch, I don't know, whatever. I built the design from the ground up, without looking at the diagrams in your blog, or the example you made, based purely on the text in this thread and it was stable within about 5 minutes. I then looked at yours to understand why you had difficulty and noticed the 0.1s timing. If I alter my design to this then it becomes unstable. Can you explain why you would want the wheels to move such a small angle? I moved mine larger angles so that passing through the hysteresis zone is completely outside of sampling, if you move fast. This completely removes the need to match up any edges perfectly. I will post my version when I get home, expect it in around 4 hours.

2009-05-08 14:49:00 Author: rtm223 Posts: 6497

---

@dcf This is a piston version of my RS Latch that uses wobble bolts (please see Evolution of a Bad - Very Bad - Idea (http://www.lbpcentral.com/forums/blog.php?b=406)) which in nice technicolor COULD look like the following: http://i207.photobucket.com/albums/bb140/feloneouscat/lbp_piston_rslatch.jpg OR by putting the right piston on the OTHER side of the wall, you don't have to invert it at all. Pretty much everything I have detailed for wobble bolts in this series can also be applied to pistons - tho' not sure about the toggle... I will let rtm223 work that one out

2009-05-08 14:55:00 Author: feloneouscat Posts: 89

---

@dcf: Is this your own design? I tested it but modified it so that all three pistons are connected to the same piece of DM and I didn't invert the reset signal (I'm not sure where that idea came from). It works great. It also has the behaviour that with S and R both high, it stays at stable S state, which is far more deterministic than most designs I've seen. I think I have a simpler design than this, based on the strong chains / weakish pistons combo, which allows for multiple set and reset signals without separate external OR gating. Will have to have a go tonight and compare these two designs, along with a wheel implementation of your one, along with the three wheel JK FF. Should have a candidate for simplest stable set-reset circuitry after that Yep, it's my own improvement to feloneouscat's evolution of a bad idea. I've been doing a lot of LBP logic. I was originally averaging 100-200 logic gates a level. So I enjoy the stuff. I've been learning to do it a little bit more clever though because of thermo limits. The advantage of the mechanism, as you've figured out is that when the set and reset are both true it stays set, rather than being undefined. Oh, and the reset signal wasn't meant to be inverted (it's just a key after all), the piston the reset key was on was meant to be set to backwards. That way the reset key would remain close to the dark matter until the reset signal was received, at which point it would move away from the dark matter enabling the switch to reset if the set is also off. I was also considering using just one piece of dark matter in the final build, but it was easier to explain this way. It think it can be expanded to utilize parallel AND/OR logic internally (on the set and reset keys). @dcf This is a piston version of my RS Latch that uses wobble bolts (please see Evolution of a Bad - Very Bad - Idea (http://www.lbpcentral.com/forums/blog.php?b=406)) which in nice technicolor COULD look like the following: http://i207.photobucket.com/albums/bb140/feloneouscat/lbp_piston_rslatch.jpg OR by putting the right piston on the OTHER side of the wall, you don't have to invert it at all. Pretty much everything I have detailed for wobble bolts in this series can also be applied to pistons - tho' not sure about the toggle... I will let rtm223 work that one out Yep, that's what I was picturing. Good diagram simplification by flipping around the reset so it doesn't require a backwards. The big difference between pistons and wobble bolts is it is easier to time pistons. I tend to use these things to control gameplay mechanisms and sometimes don't want them to be instantaneous. For example, when I'm creating boss AI's I slow certain pistons down to make the boss less aggressive/accurate. However, despite that the big improvement on this design over the one in the blog is that the SET+RESET is not undefined. This is because the center piston is shorter than the other two. This can also be done using wobble logic with a smaller wheel. However, I think the inclusion of the shorter piston/smaller wheel in the middle is a key feature to make it operate without "fuzziness."

2009-05-08 15:05:00 Author: dcf Posts: 468

---

the piston the reset key was on was meant to be set to backwards. I misread your picture is all, and as I had all connected to a single piece of dark matter, it became redundent. It think it can be expanded to utilize parallel AND/OR logic internally (on the set and reset keys).Yeah if you make the set and reset pistons out of the multi-input AND/OR gate I designed. What I was refering to was an SR with only one moving part, where multiple set / reset signals could be ORd (but not ANDed) into the design. Anything you can do with just pistons can be achieved with just wobbles and vice versa (as they are analagous, just a curve path to a straight one). You can't replicate chain&piston logic with wobbles and emmitters are a whole other kettle of fish, even when using one shot, because the timing issues are different. I tend to design logic on the fly, so interchangeability is less of an issue for me, but i'm happy to design with it in mind for these more academic conversations

2009-05-08 15:16:00 Author: rtm223 Posts: 6497

---

OK "where you went wrong" was a very bad choice of words. It was 3am when I wrote that and I certainly didn't mean it to be derogatory. Well, you DID make me cry... but after that... I still think this is part of the reason it was difficult though. Perhaps. I reserve judgement on the 0.1 - as it is obvious (by the fact that it works) that the sensors are capable of it. NOW, that said, this may PURELY be a function of an incorrectly designed hysteresis program and may FAIL in future patches. I'm not married to my design. Heck, I would DISOWN it if I didn't think there was some merit to the original idea. Brilliant? Absolutely! The stuff that causes man to bend his knee and acknowledge one as the sole benefactor to sackpeople-kind? Of course! The thing that turns people into zombies in "Resident Evil"? ... well... uh... does owning a controlling interest in Umbrella Corp make me a bad man? How does that do for covering all bases as well as exposing my ego? BWAHAHA!!! BTW, I'm never one for dismissing better designs. "Son of a Bad Idea?" was to get the ball rolling. It makes me happy (seriously) that someone modified the concept to something that is far easier to build. I've been thinking of the fuzziness as hysteresis, and I have observed it too. I've also observed it on the hard edges of angle switches, which annoyed me because (due to the graphics) I was hoping it wouldn't exist there. It's less pronounced there than at the rounded edge, or maybe it's relative to the distance from the switch, I don't know, whatever. Oh, it is hysteresis - or lack of on the hard edges. As software/firmware/everything engineer I deal with this a lot (I do a LOT of software involving sensors - a lot a lot). It annoyed the hell out of me! (laughs) I built the design from the ground up, without looking at the diagrams in your blog, or the example you made, based purely on the text in this thread and it was stable within about 5 minutes. I then looked at yours to understand why you had difficulty and noticed the 0.1s timing. If I alter my design to this then it becomes unstable. That's good you based it off the post and not the blog - it allowed you to design without preconceptions. My blog entry WAS a bad idea. Although I vehemently disagree that the 0.1s timing is the issue - the sensors had no trouble detecting it, it's that I never had the angle right. I wish you could turn on the sensor so you could see the angle displayed while you muck with the motors. But I will acknowledge yours is a superior design - it took me about an hour to get mine working like I wanted. Can you explain why you would want the wheels to move such a small angle? I moved mine larger angles so that passing through the hysteresis zone is completely outside of sampling, if you move fast. This completely removes the need to match up any edges perfectly. Well, the idea came as I was driving to a Dr's appt and not seeing it a GREAT time to sketch it down, I committed it to memory (a feat in itself!). The original idea was that in the starting position, the sensor wouldn't be seen. Then it only had to move enough to be seen (that's where the lack of hysteresis killed me) to activate the toggle - at which point it would move back in position and TADA - the sensor would now be in the zone. To reset you just move it out of the zone to the dead spot and TADA you get another toggle. Now, granted, it was a bad idea - remember I called it "Son of a Bad Idea?"? I knew it was flawed and had quite a few dependencies. BUT for the most part, it should work. And does it just is a PITA to build. THAT'S why I would prefer to use your design. Now, I will admit that had I know that there was little to no hysteresis on the hard edges I would have rethought the entire project. But the goal was to implement the design (remember, even the first "Bad Idea" worked - it was nigh impossible to build). I will post my version when I get home, expect it in around 4 hours. Works out perfect. That would be my lunch hour (close) (I'm in the States). I look forward to it!

2009-05-08 15:29:00 Author: feloneouscat Posts: 89

---

I've been learning to do it a little bit more clever though because of thermo limits. I've been moving to wobble bolts because in terms of thermo, Post-Yarg, they seem to consume slightly less thermo (750ish pistons vs 1000 wobble bolts on a bare stage). The big difference between pistons and wobble bolts is it is easier to time pistons. Ah, then you will love it when we build a timer out of a wobble bolt! However, despite that the big improvement on this design over the one in the blog is that the SET+RESET is not undefined. I believe, but haven't tested, that this could be done with a wobble bolt as well. Tho' for this series, we will continue to go with "UNDEFINED" as it is the standard definition for an RS Latch (actually in LBP it goes into oscillation - but again, for this series I plan to stick with standard definitions). Makes it easier to google!

2009-05-08 15:49:00 Author: feloneouscat Posts: 89

---

I believe, but haven't tested, that this could be done with a wobble bolt as well. Tho' for this series, we will continue to go with "UNDEFINED" as it is the standard definition for an RS Latch (actually in LBP it goes into oscillation - but again, for this series I plan to stick with standard definitions). Yeah, you don't wanna be telling people you are making JKs and then have to explain to them that J="set" and K="reset" and Q gets not Q when J=K=1. Stupid JK. I still think we should push the term "flipflop" over latch though. As for hysteresis, I work in Mil/Aero Embedded, mostly BSPs and Drivers for VxWorks and recently wrote our temperature sensor API, so hysteresis came up a fair bit.

2009-05-08 15:57:00 Author: rtm223 Posts: 6497

---

Ah, then you will love it when we build a timer out of a wobble bolt! Wobble bolt timers are fairly straight forward. However, building it directly into circuits can be a little difficult due to the curved versus straight path. I can build timers directly into the circuit with pistons, instead of adding a second part, which is incredibly useful. I can also adjust the timing of pieces independently. So for this particular application, I prefer pistons. I will agree that thermo can make the wobble bolts more appealing for straightforward wiring. However, with the parallel piston/chain techniques the thermo drops considerably. I believe, but haven't tested, that this could be done with a wobble bolt as well. Tho' for this series, we will continue to go with "UNDEFINED" as it is the standard definition for an RS Latch (actually in LBP it goes into oscillation - but again, for this series I plan to stick with standard definitions). Makes it easier to google! It can definitely be done with a small wobble bolt. No question about it. By the book, yours is definitely the way to go. I just don't like undefined states for general use pieces. I may, for example, place this circuit in a boss fight where a special attack that can be activated repeatedly but once activated, continues until sackboy does something to make it stop or dies. I would also consider making one that worked in the opposite manner. When both the set and reset are active the reset takes preference forcing the circuit down. Regardless of this difference of opinion, well done on your circuits! I look forward to seeing what you play with next.

2009-05-08 16:30:00 Author: dcf Posts: 468

---

Regardless of this difference of opinion, well done on your circuits! I look forward to seeing what you play with next. That should be "Why a RS Latch is Better Than a P-Switch -- And Worse" or something like that. My titles have this bad tendency to change (mood? low oxygen in the room?). Then, hopefully, the monostable multivibrator (as opposed to the bistable multivibrator) - also known as a one-shot. And yes, there are reasons why we are re-inventing the wheel.

2009-05-08 17:27:00 Author: feloneouscat Posts: 89

---

Consider nephew of bad idea published, along with: DCF's RS, my RS design with 1 moving part AND deterministic behaviour (prototype) My Carlsberg AND gate* My Carlsberg OR gate* *Carlsberg is a registered trademark of the Carlsberg Group of Breweries. These logic circuits are in no way endorsed by, or affiliated with, the calsberg group or an of it's representatives or subsiduaries. That should be "Why a RS Latch is Better Than a P-Switch -- And Worse" What is a P switch? I don't know what it is and my friend Wikipedia dosn't either. What wiki don't know, ain't worth knowing! But seriously, what other names does it have? Then, hopefully, the monostable multivibrator I'll do my 1-shot emmitter vs piston vs wobble test soon as I hoping the emmitted dark matter could be a contender for best option in this project (I really want to get him accepted into the mainstream, cause he's taken so much flak ) Also, on a side note: All of this wheel based logic circuitry is going to cause some confusion when I debut my "Wheeley Good Switches" tech demo, which has almost nothing to do with logic and even less to do with wobble bolts. I'm not happy about this scenario.

2009-05-08 17:58:00 Author: rtm223 Posts: 6497

---

What is a P switch? I don't know what it is and my friend Wikipedia dosn't either. What wiki don't know, ain't worth knowing! But seriously, what other names does it have? AKA Permanent Switch - basically it's a key on a blob of dissolve and a mag switch set to invert. When the dissolve goes away, so does the key and mag switch outputs a permanent high. Please make your "nephew" copyable... thanks!

2009-05-08 18:31:00 Author: feloneouscat Posts: 89

---

It is now copyable, I believe. interesting results on the 1 shot tests: Pistons overheat at 788 Wobble bolts overheat at 788 (serious) Emitters (drum roll please) 932 Woop Woop

2009-05-08 18:37:00 Author: rtm223 Posts: 6497

---

I've got a logic project I'm working on if anyone wants a challenge. I can easily make this work with a circuit but would like to find a simple build. Here's the concept. I want a switch with three separate timing mechanisms which can be independently altered. Set Time: This is the length of time that the switch must receive a set signal for it to activate. Dwell Time: The is the length of time that, once the switch has been activated, it remains activated. Reset Time: This is the length of time, after the dwell is completed, before a new set can be applied. Caveat: Set signal received during the dwell and reset time must be ignored. For example, let's say that the set is a proximity switch. Sackboy remains in an area for 10 seconds to activate the switch. It then remains active for a dwell time of 20 seconds. It then shuts off and remains inactive for the reset time of 30 seconds. At the end of the reset time the switch must remain off unless sackboy spends an additional 10 seconds in the proximity switch to set it again. This is much more challenging than a switch that simply cannot activate again until the reset is complete. Previously I did a piston based timer on the set switch, with an AND(input,NOT(OR(DWELL,RESET)) with the dwell and reset being controlled by emitted keys. This is one I really want to get back to because it is hugely useful for making boss attacks which are activated by proximity switches. Sackboy stays in the proximity switch for too long and the boss does an attack sequence. Often the attack sequence will be longer than the set time. The reason the reset is required is so the attack sequence doesn't go into a repeat loop. This can happen quite frequently when people tackle a boss multiplayer.

2009-05-08 20:15:00 Author: dcf Posts: 468

---

It is now copyable, I believe. interesting results on the 1 shot tests: Pistons overheat at 788 Wobble bolts overheat at 788 (serious) Emitters (drum roll please) 932 Woop Woop I also have some interesting news: on your "Nephew of a Bad Idea" I found that if I modify the second wobble's sensor THEN try to put it back - if I'm just a TINY TINY bit off, the last wobble gets wonky. : I wish they would put numbers on range like they did with angle. I THINK I have yet a THIRD iteration of your idea... but I will have to work on that later Interesting results on the pistons and wobbles. BTW, I currently writing a Linux version of our environment control software (which normally runs on a micro) - so, yeah, I am intimately familiar with the stuff. Fortunately, I don't have to write API's because no one else in the company wants to deal with it! (laughs)

2009-05-08 20:19:00 Author: feloneouscat Posts: 89

---

Previously I did a piston based timer on the set switch, with an AND(input,NOT(OR(DWELL,RESET)) with the dwell and reset being controlled by emitted keys. This is one I really want to get back to because it is hugely useful for making boss attacks which are activated by proximity switches. Sackboy stays in the proximity switch for too long and the boss does an attack sequence. Often the attack sequence will be longer than the set time. The reason the reset is required is so the attack sequence doesn't go into a repeat loop. This can happen quite frequently when people tackle a boss multiplayer. I'm confused. If you've solved it, why reinvent the wheel? I mean, my life HAS been reinventing the wheel (after writing the fourth floating point package I said "please let this be the last one!"). Then again, here I am reinventing the flipflop (sigh). Never mind, move along, old man rambling...

2009-05-08 20:25:00 Author: feloneouscat Posts: 89

---

Yeah, you don't wanna be telling people you are making JKs and then have to explain to them that J="set" and K="reset" and Q gets not Q when J=K=1. Stupid JK. I still think we should push the term "flipflop" over latch though. Well I was getting annoyed people were calling them state switches and said "no, we have a word for that - flipflop". Then someone with a little later knowledge than myself (been in the biz for about 30 years) came along and said "no, if it is asynchronous it is a latch, if it is synchronous it is a flipflop"... (rolls eyes) I think I'm going back to calling it a flip flop. After it is synchronous with the processor clock! ... and RS Latch sounds stupid...

2009-05-08 20:36:00 Author: feloneouscat Posts: 89

---

I've been calling them state switches since I got the game. So

2009-05-08 20:40:00 Author: ARD Posts: 4291

---

I'm confused. If you've solved it, why reinvent the wheel? I mean, my life HAS been reinventing the wheel (after writing the fourth floating point package I said "please let this be the last one!"). Then again, here I am reinventing the flipflop (sigh). Never mind, move along, old man rambling... For fun Seriously though, I'd like a simple and compact version as this would be a very useful tool for programming bosses. The one I have right now isn't particularly user friendly. I'm thinking with the state switch discussion there might be a way to make a really simple one. For example, using piston/winch strength to override the original input during the sequence might make the whole thing more manageable. However, if someone has a brilliant way of doing it along the lines of the simplified latch switch that would be perfect. Oh, and I now realize I was wrong about the "backwards" several posts back. My bad. Thanks for catching my error.

2009-05-08 21:02:00 Author: dcf Posts: 468

---

It is now copyable, I believe. interesting results on the 1 shot tests: Pistons overheat at 788 Wobble bolts overheat at 788 (serious) Emitters (drum roll please) 932 Woop Woop I got 905 wobble bolts set to flipper mode (0.1 second) on a level before it overheated. Not set to flipper mode I've been able to get 1000. Not sure of the difference. So I'm puzzled why/how you only got 788? That sounds right for pistons, but not for wobble bolts...

2009-05-08 21:08:00 Author: feloneouscat Posts: 89

---

Only could get 466 emitters that actually emitted something on a bare level. Now, I do know that if you place emitters down that aren't set to emit anything (rather useless), then you can get more.... Find the wobble bolts under "905 Wobble Bolts" if you search @feloneouscat. I'll post the emitters there as well. Just to make sure we are doing apples to apples.

2009-05-08 21:19:00 Author: feloneouscat Posts: 89

---

What were the emitters emitting? Doesn't the object that the emitters emitted determine the number of emitters you can place in a level emitting things? This is what emitters emitting emitted objects is all about. Of course, since there are technically different thermos, which thermo does the emitters emitting fall under, and does that make a difference as to how efficient emitting emitters will be in an actual level containing emitted objects from emitters? Hmmm....

2009-05-08 21:58:00 Author: CCubbage Posts: 4430

---

Sorry for the delay, just got back in. Quick question. When placing objects, have you been spacing them evenly and making them the same size and spacing them the same regardless of bolts vs pistons vs emmitters? I have a feeling this makes a difference. Ok, full details of my tests were: Pistons: 10x10 square of dark matter 10x10 square of basic card with a green key on piston connects the two with stiff = yes range = 5-10 timing = 0.2 Flipper = out Wobbles: 10x10 square of dark matter 10x10 square of basic card with a green key on Wobble bolt through the centre of the two with range = 90 timing = 0.2 Flipper on Emmitters: 10x10 square of dark matter Emmits a 10x10 square of dark matter with a red key on Emmiter settings lifetime = 0.1 timing = 0.1 max emmitted = infinate max at once = 1 In all three tests the spacings were 12.5 horizontally and 25 vertically and arranged in a grid 10 high and as far to the right as I could go. Only difference between the three tests is the lack of a second material in the emmitters test. Would that account for the extra thermo?? in terms of putting the sensor back slightly wrong. 1 are you using the grid? 2 The angle is actually way tighter than it needs to be on all three sensors. Can expand that and the range and i'd expect it to be fine. If we keep passing designs back and forth we might eventually end up with something that's trustworthy out of this! Edit - no i just tried it and you are right. I now officially renounce trying to sample one shot pistons. Try replacing the 1 shot piston with a 1 shot dark matter emmitter, and it looks to become stable again (but I said THAT last night). Edt - scratch that. I'm now renouncing sampled flippers AND on off switches in all digital systems. "no, if it is asynchronous it is a latch, if it is synchronous it is a flipflop"... Well the textbooks agree with him, but they also say that there is not really a clear definition and this is a convention used in the book. Then it speaks of "synchronous latches"...

2009-05-08 23:10:00 Author: rtm223 Posts: 6497

---

Set Time: This is the length of time that the switch must receive a set signal for it to activate. Dwell Time: The is the length of time that, once the switch has been activated, it remains activated. Reset Time: This is the length of time, after the dwell is completed, before a new set can be applied. What happens if you get halfway through the set time then cancel then press set again, does it restart, start from the same point or subtract the time you were away rom the time you were there then add on more time after you press the set again.

2009-05-08 23:13:00 Author: rtm223 Posts: 6497

---

What happens if you get halfway through the set time then cancel then press set again, does it restart, start from the same point or subtract the time you were away rom the time you were there then add on more time after you press the set again. Subtracting the time is acceptable (which just means a directional switch based). Ideally it would reset to zero if the set is released but I haven't found a satisfactory way to do that with LBP just yet. You can almost do it with flippers but not quite. That might be a project in and of itself.

2009-05-08 23:26:00 Author: dcf Posts: 468

---

Subtracting the time is acceptable (which just means a directional switch based). Ideally it would reset to zero if the set is released but I haven't found a satisfactory way to do that with LBP just yet. You can almost do it with flippers but not quite. That might be a project in and of itself. I can do it. It involves my favourite of all LBP constructs. Can you guess what it is yet? Strong chain weak piston!!!! Yay. piston is set as normal to do your timing, with strength 5. Chain is set to 0.1s and strength 10. Connect them both to the same directional input. Slow out, quick back in.

2009-05-08 23:32:00 Author: rtm223 Posts: 6497

---

I can do it. It involves my favourite of all LBP constructs. Can you guess what it is yet? Strong chain weak piston!!!! Yay. piston is set as normal to do your timing, with strength 5. Chain is set to 0.1s and strength 10. Connect them both to the same directional input. Slow out, quick back in. I think that will do it! In that case I think the rest can be made easily. Just use this device with the piston as the input. The magnetic key switch is set to once instead of directional and is attached to two emitters that emit keys. One of the emitter keys is the output and the other one is the reset. The reset gets wired to the winch preventing the device from activating again for its lifetime. I think that's simple enough for the mechanism.

2009-05-09 01:32:00 Author: dcf Posts: 468

---

Wobbles: 10x10 square of dark matter 10x10 square of basic card with a green key on Wobble bolt through the centre of the two with range = 90 timing = 0.2 Flipper on Emmitters: 10x10 square of dark matter Emmits a 10x10 square of dark matter with a red key on Emmiter settings lifetime = 0.1 timing = 0.1 max emmitted = infinate max at once = 1 In all three tests the spacings were 12.5 horizontally and 25 vertically and arranged in a grid 10 high and as far to the right as I could go. Only difference between the three tests is the lack of a second material in the emmitters test. Would that account for the extra thermo?? Dunno... I'm truly at a loss. in terms of putting the sensor back slightly wrong. 1 are you using the grid? 2 The angle is actually way tighter than it needs to be on all three sensors. Can expand that and the range and i'd expect it to be fine. If we keep passing designs back and forth we might eventually end up with something that's trustworthy out of this! Edit - no i just tried it and you are right. I now officially renounce trying to sample one shot pistons. Try replacing the 1 shot piston with a 1 shot dark matter emmitter, and it looks to become stable again (but I said THAT last night). Edt - scratch that. I'm now renouncing sampled flippers AND on off switches in all digital systems. Good. I'm reasonably confident that on/off will not work right (except if you are lucky You apparently are very lucky. Will you pick a lotto ticket for me? Well the textbooks agree with him, but they also say that there is not really a clear definition and this is a convention used in the book. Then it speaks of "synchronous latches"... I deny the existence of those books!!! Yah, and actually I DO understand why there is a difference - but it seems like one of those academic differences and probably will take at least a generation to cleanse peoples minds... ****, I hate the reeducation camps!

2009-05-09 02:13:00 Author: feloneouscat Posts: 89

---

What were the emitters emitting? Doesn't the object that the emitters emitted determine the number of emitters you can place in a level emitting things? This is what emitters emitting emitted objects is all about. Of course, since there are technically different thermos, which thermo does the emitters emitting fall under, and does that make a difference as to how efficient emitting emitters will be in an actual level containing emitted objects from emitters? Hmmm.... On a related note: How much wood could a woodchuck chuck if a woodchuck could chuck wood... Sorry... couldn't resist...

2009-05-09 05:16:00 Author: feloneouscat Posts: 89

---

I think that will do it! In that case I think the rest can be made easily. Just use this device with the piston as the input. The magnetic key switch is set to once instead of directional and is attached to two emitters that emit keys. One of the emitter keys is the output and the other one is the reset. The reset gets wired to the winch preventing the device from activating again for its lifetime. I think that's simple enough for the mechanism. yup. Seriously the weak chain strong piston is so unbelieveably useful. Also nearly as useful is the 0 strength stiff piston. @feloneous Emmitted golf balls are clearly going to take up more thermo than emmitted dark matter! I went for the emmitted object i would actually use in a logic system lol.

2009-05-09 10:35:00 Author: rtm223 Posts: 6497

---

@feloneous Emmitted golf balls are clearly going to take up more thermo than emmitted dark matter! I went for the emmitted object i would actually use in a logic system lol. I'll have to go back and redo it. I do everything in pause and forgot they redid the emitter calcs on thermo...

2009-05-09 16:41:00 Author: feloneouscat Posts: 89

---

I've also have one more suggestion regarding emmitters. emmitting P switches. Not because I have an odd bias for emmitters and I don't know what the thermo implications are but: 1) if you accidentally trigger it, there is no rewiring to do* 2) It doesn't make that dissolve sound! Emmitting is silent. *I regularly trigger mine without realising and find I've made a whole bunch of changes since and have to decide whether to rewire, or whether to undo.

2009-05-09 17:33:00 Author: rtm223 Posts: 6497

---

Tutorial on RS Latches is up. BTW, Admins - 10000 chars may not be enough... I had to go and chop a lot of explanatory text out (grrrr). Is there a way to get this expanded?

2009-05-11 00:18:00 Author: feloneouscat Posts: 89

---

Tutorial on RS Latches is up. BTW, Admins - 10000 chars may not be enough... I had to go and chop a lot of explanatory text out (grrrr). Is there a way to get this expanded? My best suggestion is to make a thread in Site Feedback about such- that would be the best way to draw CC's attention. Also, you know these are in the Tutorial spotlight, right? I got them up there... >_< Anyway, yeah, these are all in blgos? Well, I suppsoe that's good enough

2009-05-11 00:30:00 Author: RockSauron Posts: 10882

---

My best suggestion is to make a thread in Site Feedback about such- that would be the best way to draw CC's attention. Also, you know these are in the Tutorial spotlight, right? I got them up there... >_< Anyway, yeah, these are all in blgos? Well, I suppsoe that's good enough Yes. The format of a blog is actually a far better way for me to keep these separate lessons intact than having each lesson interspersed by other subjects. To make it easy, I've even provided links (see the first post in this thread). Rather than a hodge-podge of lessons (which it might seem at first) there actually is an overall goal - to teach enough logic that ANYONE, yes you the lurker over there, can design logic into their LBP level. And since it's been indicated that I will be teaching you how to go from idea to complete design (certainly surprised me when I read CC post!), I guess I have to follow through on it!

2009-05-11 14:49:00 Author: feloneouscat Posts: 89

---

Tutorial on RS Latches is up. BTW, Admins - 10000 chars may not be enough... I had to go and chop a lot of explanatory text out (grrrr). Is there a way to get this expanded? As the Professor from "Futurama" would say: "Good news, everyone!" The max level has been bumped for 10000 to, hold on to your hats, 50000!!! That means more words, longer posts, more jokes and vague culture references that may not fit the time period ("Prithee, do tell? Twas that a bodkin, or art thou overjoyed at seeing me?"). So expect longer, better, faster, stronger (with EXTRA punctuation!!!) blog posts!

2009-05-12 18:19:00 Author: feloneouscat Posts: 89

---

Back onto the (slightly off-topic) topic of logic thermo testing. A clear differece between my ~700 vs your ~900 wobble bolts is that each of mine is on its own piece of dark matter, so there are a lot more objects. Whilst this isn't realistic, I did this for the sake of fair testing (each wobble bolt and piston had exactly the same objects associated with it), so I'm leaning towards the view that unless you can use objects more efficiently in one set up or another, the connectors themselves are idnetical in their thermo useage. Ccubbage, I'm a little sceptical about the "multiple thermos and only the most full one shows up" theory; do we have any evidence that the different tpyes of thermo are independent? I.E can you hammer one of them, and then hammer a separate one in the same level, with no noticeable increase in "overall" thermo?

2009-05-13 12:20:00 Author: rtm223 Posts: 6497

---

Back onto the (slightly off-topic) topic of logic thermo testing. A clear differece between my ~700 vs your ~900 wobble bolts is that each of mine is on its own piece of dark matter, so there are a lot more objects. Whilst this isn't realistic, I did this for the sake of fair testing (each wobble bolt and piston had exactly the same objects associated with it), so I'm leaning towards the view that unless you can use objects more efficiently in one set up or another, the connectors themselves are idnetical in their thermo useage. Ccubbage, I'm a little sceptical about the "multiple thermos and only the most full one shows up" theory; do we have any evidence that the different tpyes of thermo are independent? I.E can you hammer one of them, and then hammer a separate one in the same level, with no noticeable increase in "overall" thermo? Re: Multiple thermos: I have tested this extensively PRE-Yarg. Now, that said, POST-Yarg, things are different. Everything (from circles vs. squares to emitters vs. pistons) is different. So much of the long -- several months -- and tedious effort that has gone into reverse-engineering can be pitched. It is no longer valid. Re: "making things the same" - I strongly disagree that this shows anything remotely close to being realistic. People who are using wobble bolts for logic (hopefully) are not plopping them on their own piece of dark matter. Worst case, realistically, would be two wobble bolts per dark matter. I'll redo my tests again (at some point). I still maintain that a) wobble bolts are cheaper and in the long run b) less prone to breaking. Now, that all said, I have yet to redo the emitter test Seems people keep distracting me from things (oh, yeah, and there was the eight hour chunk spent in doing the last lesson!)

2009-05-13 14:47:00 Author: feloneouscat Posts: 89

---

Back onto the (slightly off-topic) topic of logic thermo testing. A clear differece between my ~700 vs your ~900 wobble bolts is that each of mine is on its own piece of dark matter, so there are a lot more objects. Whilst this isn't realistic, I did this for the sake of fair testing (each wobble bolt and piston had exactly the same objects associated with it), so I'm leaning towards the view that unless you can use objects more efficiently in one set up or another, the connectors themselves are idnetical in their thermo useage. Ccubbage, I'm a little sceptical about the "multiple thermos and only the most full one shows up" theory; do we have any evidence that the different tpyes of thermo are independent? I.E can you hammer one of them, and then hammer a separate one in the same level, with no noticeable increase in "overall" thermo? That's EXACTLY what we did. Pre-yarg, absolutely this was proven. Wyth (Jack McSetback) and I did a TON of testing in this area. Being also a software engineer, I definately know how to test resources. I have not done the post-yarg testing. In my prior tests, I could create tons of complex shapes with a single material and fill up the thermo... then start changing the different material. The thermo would not rise at all until I had used up enough different types of material to use more thermo than the complex objects. The same was true the other direction - I could put a ton of simple shapes with different types of material and get way up on thermo. Then, I could start drawing complex shapes and the thermo would not go up at all. We did many hours of every different combination to prove it out. I used these techniques extensively in building my Splat Invaders II and it always proved true. By the way, the messages that appear when you're overloading your thermo relate directly to the specific thermo that is getting too high. (such as "use less materials" or "use less complex shapes") I have a feeling, based on my post-yarg creating, that it works in a similar way but certain thermos are more efficient (such as complex shapes). In Splat Invaders Saga in the last couple weeks I've been updating visuals. I just started using tons of different types of materials, but since the separate objects thermo (used up by about 150 emitters) used up the thermo, no matter how many types of different material I used the thermo would not go up even a bit.

2009-05-13 15:20:00 Author: CCubbage Posts: 4430

---

That's EXACTLY what we did. Pre-yarg, absolutely this was proven. Wyth (Jack McSetback) and I did a TON of testing in this area. Being also a software engineer, I definately know how to test resources. I have not done the post-yarg testing. In my prior tests, I could create tons of complex shapes with a single material and fill up the thermo... then start changing the different material. The thermo would not rise at all until I had used up enough different types of material to use more thermo than the complex objects. Coolio. Should have guessed you'd done this exact test - I knew you did a lot of testing on this and it's great you're sharing quality research. I've also found the different materials doing nothing to my thermo, maybe (?) they are now grouped as categories (metals / woods / etc.) as to the physics engine 2 types of metals should be identical. This would give about 5/6 different materials maximum.

2009-05-13 16:01:00 Author: rtm223 Posts: 6497

---

That's EXACTLY what we did. Pre-yarg, absolutely this was proven. Wyth (Jack McSetback) and I did a TON of testing in this area. Being also a software engineer, I definately know how to test resources. I have not done the post-yarg testing. In my prior tests, I could create tons of complex shapes with a single material and fill up the thermo... then start changing the different material. The thermo would not rise at all until I had used up enough different types of material to use more thermo than the complex objects. The same was true the other direction - I could put a ton of simple shapes with different types of material and get way up on thermo. Then, I could start drawing complex shapes and the thermo would not go up at all. We did many hours of every different combination to prove it out. I used these techniques extensively in building my Splat Invaders II and it always proved true. By the way, the messages that appear when you're overloading your thermo relate directly to the specific thermo that is getting too high. (such as "use less materials" or "use less complex shapes") I have a feeling, based on my post-yarg creating, that it works in a similar way but certain thermos are more efficient (such as complex shapes). In Splat Invaders Saga in the last couple weeks I've been updating visuals. I just started using tons of different types of materials, but since the separate objects thermo (used up by about 150 emitters) used up the thermo, no matter how many types of different material I used the thermo would not go up even a bit. I've seen you mention this quite a few times on the forum. Is there a place where you did a clean write-up of your findings? I'm very interested in knowing the details.

2009-05-13 17:06:00 Author: dcf Posts: 468

---

Same here, even if it is pre-yarg and slightly dated, it would still be good. I was thinking of starting a thread to collect test results for thermo impact of anything, where no data would get on unless there was a decent test methodology, quantified results and test dates / software version numbers.

2009-05-13 17:23:00 Author: rtm223 Posts: 6497

---

I did SOMEWHERE but I honestly don't remember where... it was a few months ago under some good creating practices thread (I may have started the thread). It all started when a creator said it was a good idea to only use a few pieces of material so it didn't take up too much of your allotted thermo. Wyth put a reply that said "I think the thermo used by the material is totally separate because when I was building Jack McSetback" and the thermo was pretty high, I was able to suddenly do tons of material changes without it affecting the thermo at all". I got really excided because this opened up a whole new world of thermo usage, so I went home right after work and played with it for about 8 hours and tried all different scenarios. (I had initially gone home during lunch and tried some basics to verify it). This has actually had a HUGE impact on my creation flow. Ever since then I've been picking the thermo that means the most to me (such as a lot of angles in a cave-type level for instance) and developing in a way that uses that up first (such as using very few materials or loose objects to begin with). THEN, at the tail end I start using more types of materials, adding emitters and switches, and such. That way I always know how much thermo I REALLY have. In Splat Invaders II this was really useful, because its a fairly complex level. The thermo never went up another bar from the time I finished the basic design and started decorating, adding music, incorporating new materials, and adding emitters. It has pretty much stayed the same ever since. When Yarg came out it suddenly dropped about 10%, so I'm pretty sure yarg allows more complex shapes, since this was the peak display of the thermo.

2009-05-13 17:54:00 Author: CCubbage Posts: 4430

---

Same here, even if it is pre-yarg and slightly dated, it would still be good. I was thinking of starting a thread to collect test results for thermo impact of anything, where no data would get on unless there was a decent test methodology, quantified results and test dates / software version numbers. Pre-Yarg would only be good as a comparison, but I can assure you I can now (post-Yarg) put the same (okay one off) number of circles on a stage as squares. Emitters, pistons, how vertices are calculated in heating - all has changed under Yarg. Posting OLD info is like incorrect comments in code: is just confuses people. No, the tests need to be re-run. All, of course, in my very humble opinion.

2009-05-14 13:18:00 Author: feloneouscat Posts: 89

---

I re-ran quite a few combinations last night and it appears to still work the same way, however a few of the individual thermos seem to be more efficient. The complex shapes appears to be different. I don't have the time right now to figure out what kind of algorithm they are using for this (and they probably aren't going to let me look at their code), so I'm probably not going to go into it in that much detail personally, however I'm at least satisfied that the foundation seems to work similarly, and I'm not inaccurate. However, that makes sense because I can't imagine them totally re-engineering the entire way thermo is calculated with hundreds of thousands of existing levels out there.... it would probably cause really wonky results (not having ANY 1-to-1 comparison) But... based on that you can probably figure the thermo usage by the logic switches would only matter under specific circumstances.... it really depends on the level.

2009-05-14 13:27:00 Author: CCubbage Posts: 4430

---

Cat, agreed pre-yarg may be confusing, but I think people are already waaay confused as it is. In the sense of a collection of verifiable test results, out-dated tests might be useful because: 1) It can highlight that these are outdated tests, so the info is there with less confidence. 2) As Ccubbage says, they can't really do major overhauls in updates because levels would break. 3) If the methods are documented, people can duplicate tests in newer versions, and proper comparisons could be made. Obviously, outdated test results would be superceded by tests in a new version. Anyway, this is straying well off topic, so I'll leave it at that and maybe start this other thread at some point over the weekend.

2009-05-14 14:02:00 Author: rtm223 Posts: 6497

---

1) It can highlight that these are outdated tests, so the info is there with less confidence. 2) As Ccubbage says, they can't really do major overhauls in updates because levels would break. 3) If the methods are documented, people can duplicate tests in newer versions, and proper comparisons could be made. 1. Perhaps. I fear that is will just add to the confusion to publish old numbers rather than cut your losses and just say "here are the new and improved numbers, forget about the old and lousy ones". 2. Not to be argumentative, but the DO keep internal track of objects created pre-Yarg and post-Yarg. I saw it myself: a piston created Pre-Yarg holding a large metal block horizontally worked fine Post-Yarg. When it was modified (or something that caused it to be modified) it affected the pistons, which then began to act like a post-Yarg piston. We (the company I work for) puts version numbers in communications to objects so that we can be assured to react one way if it is version X and another way if version Y. I see no reason that Mm, who is far more clever than me and my group, could not do the same. Now, that said, the THERMO was probably calculated differently (although to be honest, I saw no difference and I suspect they may have run thermo the same on old parts -- bleah). But I didn't have a slew of regression tests from pre-yarg to test... (sigh) 3. I agree with documenting your work. That probably has been the weakest part of most of the testing that I and others have done (although to be fair, I've published a fair number of levels with TESTS - which usually get a "THIZ LVL SUKZ!!!" LOL -- never mind I say "THIS IS NOT A GAME" in the comments... (sigh) Oh, dear... I've wandered off topic... Okay, I'm working on the next lesson on one-shots (monostable multivibrators) and why they are so darn useful (esp. if you are using a normalized signaling system). I'm having a particularly ugly time getting a good way of presenting them - people are not going to see why they are helpful... Bleah... I have to admit the RS Latch example I managed to pull out of my butt at the last minute... Any suggestions would be, well, helpful!

2009-05-14 15:18:00 Author: feloneouscat Posts: 89

---

I've noticed that some of my old levels which had full thermo pre-yarg now have a couple bars remaining at the top. I think one of the changes was to the thermo calculation, not the objects themselves. However, as was discussed, this would only apply to certain thermometers. So some people would notice the difference and others would not. In particular, the one I noticed had a direct impact on my piston logic gates, which were the cause of the maxed out thermo.

2009-05-14 15:34:00 Author: dcf Posts: 468

---

So, I was playing around with the RS Latch today (the version I described earlier without an undefined state). At any rate, the one I described previously in the thread looked like this: []-----K []..........---S [].................------K Where the Ks are magnetic keys and the S is a magnetic key switch. All are on pistons, attached to the dark matter block on the left. The movement of the pistons is shown by -----. The key thing to note is that the S piston is shorter than the other two. Set is hooked via a directional switch to the left most key and reset is hooked via a directional switch to the right most key. The key switch is set to directional and is hooked to its own piston in addition to serving as the output. This set-up avoids the undefined state when both set and reset are both active. In this case the set overrides the reset, rather than having an oscillation occur. http://www.lbpcentral.com/forums/picture.php?albumid=448&pictureid=3829 At any rate, now that the review is over, here's what I figured out. You can take the same basic set-up and easily create a RS Latch that favors the reset, rather than the set! You use the same basic scheme, but you invert the switch and set that piston to backwards. You hook the set up to the right key and the reset to the left key (the reverse of what was done before). This very easily achieves a RS latch that favors reset. http://www.lbpcentral.com/forums/picture.php?albumid=448&pictureid=3830 I was originally playing around with these to make a directional to 3 way switch using RS Latches that favored resets so I could hook the two inputs together and force a neutral state if both switches were activated. This proved to be a dumb approach and I found a much better way of doing it using weak pistons and strong winches. http://www.lbpcentral.com/forums/picture.php?albumid=448&pictureid=3831 Oh, and for completeness here's the "time out" switch I was talking about earlier that once activated cannot be activated again for a set period of time. http://www.lbpcentral.com/forums/picture.php?albumid=448&pictureid=3832 These last two are easily combined to make a cool boss attack with a sight that seeks sackboy. If sackboy stands in the crosshairs for too long an attack occurs (but does not repeat immediately).

2009-05-15 06:06:00 Author: dcf Posts: 468

---

Hehe, I like strong wenches, and flaggons of mead. Sorry.

2009-05-15 09:06:00 Author: rtm223 Posts: 6497

---

Hehe, I like strong wenches, and flaggons of mead. Sorry. HAHA. It was late, I will go back and edit the post.

2009-05-15 12:56:00 Author: dcf Posts: 468

---

For those who care: I can VERY easily send anyone who wishes a copy of the templates I use for my tutorial. Downside: they are only for OmniGraffle for the Mac. Upside: I'm working on templates for Dia (a freeware Visio program). Other Upside: I'm looking into Visio for templates as well. BTW, Dia runs on both Linux and Windows. It takes some getting used to, but I have used it successfully for work.

2009-05-15 14:35:00 Author: feloneouscat Posts: 89

---

Oh, and for completeness here's the "time out" switch I was talking about earlier that once activated cannot be activated again for a set period of time. Heh... In the old days we called these "one-shots" aka "monostable multivibrator". I knew of a IBM circuit for some communication (lost in the fog of time) that relied HEAVILY on timing using one-shots. It... was... horrible. Or as Comic Book Guy said: "Worst... design... EVER!" (sigh) Actually, I've seen worse, but that was because the engineer didn't understand the concept of "race conditions" (sigh)... No... seriously. I think he redesigned this circuit five times and each time it had almost the same identical race condition. Kinda sad, really...

2009-05-15 14:43:00 Author: feloneouscat Posts: 89

---

I released some code with a race hazard in it last month. the hazard is so unlikey to occur, but means once in a blue moon you might lose an interrupt. Ho hum. I patched it before anyone else noticed. And DCFs switch includes a monostable, but it's a little bit more than that as well. Does dia support the visio file format?

2009-05-15 15:11:00 Author: rtm223 Posts: 6497

---

Heh... In the old days we called these "one-shots" aka "monostable multivibrator". I knew of a IBM circuit for some communication (lost in the fog of time) that relied HEAVILY on timing using one-shots. It... was... horrible. Or as Comic Book Guy said: "Worst... design... EVER!" (sigh) Actually, I've seen worse, but that was because the engineer didn't understand the concept of "race conditions" (sigh)... No... seriously. I think he redesigned this circuit five times and each time it had almost the same identical race condition. Kinda sad, really... While I would not run a computer in this manner, such a switch is perfect for LBP. It serves as a "call function" command, rather than a logic circuit. Basically, you build your logic circuit so under the correct set of conditions this switch is activated. It then remains active for a set period and prevents the process from being started again for a set period. The reason this is really important is for boss special attacks. In my first boss, Icarus, I have a special attack that occurs when sackboy stands on one of the top platforms for too long. Basically, the boss flies up off the screen and drops a big bomb on the platform. Seems straight forward. However, there was a huge flaw in the system. Sackboy could jump off the platform, dodging the bomb and then jump back onto the platform. The directional switch that controlled the attack would not have reset and the attack would be called a second time without the boss coming back down. This wasn't a huge problem until you tried playing it with two or more players. With more than one player you were almost constantly activating the special attack and the boss would almost never appear. I ended up going back as a quick fix and making it an "all" proximity switch. This isn't totally satisfactory because then the attack almost never occurs with a large group of players, unless they all stand together. This circuit, which has an activation time, a call time and a reset time, is really needed to avoid this problem (without building an enormous logic circuit that takes up a huge amount of thermo).

2009-05-15 16:50:00 Author: dcf Posts: 468

---

Does dia support the visio file format? At the moment, Dia does NOT support Visio. http://projects.gnome.org/dia/ They would be keen on someone writing a converter, but so far it hasn't happened. Let me know if you need Visio and I will load up the demo...

2009-05-15 17:03:00 Author: feloneouscat Posts: 89

---

So, Mr Cat. As "son of a bad idea" turned out to be a bad idea, I ressurected my concept for a 2 component toggle switch. It use an emmiter and a wobble bolt and is stable from all I can tell about it (theory and empirical evidence). If you are interested let me know. I also came up with a slight mod on your (already fantastic) flickering lights which looks ever so slightly better. "Ever so slightly" meaning no one but me will ever notice the difference. Also up for grabs if anyone cares.

2009-05-18 21:21:00 Author: rtm223 Posts: 6497

---

Holy cow... How did you get 2 inputs on a single wobbly bolt? That's fantastic! I want to know how you did that!

2009-06-12 17:02:00 Author: Recurracy Posts: 166

---

Holy cow... How did you get 2 inputs on a single wobbly bolt? That's fantastic! I want to know how you did that! Which logic gate are you referring to? There are many of them The trick is to hook up the inputs indirectly. You use combinations of magnetic keys and switches and then hook a single magnetic switch to the bolt. This indirectly creates multiple inputs.

2009-06-12 18:24:00 Author: dcf Posts: 468

---

So, Mr Cat. As "son of a bad idea" turned out to be a bad idea, I ressurected my concept for a 2 component toggle switch. Darn... looks like my reply to this never got posted... grrrr... Actually, "Son of a Bad Idea" DID work. The problem I ran into is that it is INCREDIBLY TRICKY to build it. Now, once it is built, it works like a champ. Solid as a rock. (Don't try this at home kids! I'm a professional!) It is both kinda' cute and kinda' creepy at the same time. The fact that it works is cool. The fact that it works is also creepy. It's two...two...two adjectives in one!

2009-06-12 18:44:00 Author: feloneouscat Posts: 89

---

The trick is to hook up the inputs indirectly. You use combinations of magnetic keys and switches and then hook a single magnetic switch to the bolt. This indirectly creates multiple inputs. ...I don't get it... Sorry, but I really don't understand you there. Could you post some pics somewhere...? Via PM or we'll hijack this thread :kz: I've seen it before with Luchador (you know that wrestler guy), there were several grab switches connected to a single speaker. Sorry for breaking this forum. I'll stop now.

2009-06-12 19:02:00 Author: Recurracy Posts: 166

---

Here's a very basic example. The permanent switch. http://www.lbpcentral.com/forums/picture.php?albumid=448&pictureid=4129 Instead of hooking the button to the light, we instead hook the button to a piece of dissolve material with a magnetic key on it. The adjacent magnetic switch is hooked to the light. Please note that the magnetic switch is inverted in this example, so it is off when a magnetic key is present and on when there is no magnetic key. http://www.lbpcentral.com/forums/picture.php?albumid=448&pictureid=4130 So when sackboy steps on the button the dissolve goes away, taking the magnetic key with it. http://www.lbpcentral.com/forums/picture.php?albumid=448&pictureid=4131 When sackboy steps off the button the light stays on. If we had hooked the button directly to the light, it would turn off when sackboy stepped off. ********************** This is the basis for hooking up multiple inputs to a single item, whether its a bolt, light, rocket, sound, emitter, etc. The most basic multiple inputs (which I unfortunately do not have a picture of readily available) work just like the permanent switch except the magnetic key and magnetic switch are placed on wooden blocks that move on pistons. Switches that are set to directional control the pistons so only the correct combination of inputs moves the switch and key close together. Here's a more complicated one we discussed earlier in the thread for RS latches: http://www.lbpcentral.com/forums/picture.php?albumid=448&pictureid=3829 Don't fret the details right now. Just focus on the basic concept. That magnetic switch in the middle controls the wobble bolt that is making the crescent turn up, like a smiley face. The movement of the keys and the switch is controlled by the two levers you see on the screen. Certain combinations of pulls will bring the switch close to a key and certain combinations will move it away from a key, thereby switching the smiley face to a frown. The two logic gates that beginners should focus on (in addition to the ever useful permanent switch featured at the start of this post) are the AND and OR gates. These operate by using pistons to move magnetic keys and magnetic switches. (There are also other versions that use wobble bolts or emitters, but I find the pistons are the easiest to visualize conceptually.) A very simple OR gate works by placing a magnetic switch on a piece of dark matter. Then you make a block of wood nearby and place a magnetic key on it and use a piston to control its movements. When the piston brings the key to the magnetic switch the magnetic switch activates. When the piston brings the key away from the magnetic switch it turns off. Now you just make more than one of these keys on wood on piston items. So now, if any of them go near the switch, the switch activates. An AND gate can be built much the same way by inversing the behavior of the switch and setting the pistons backwards. So the switch is looking for all of the keys to move away before it activates. Each time you activate a piston one key moves away from the switch. When all are gone the switch is activated. If any return the switch turns off again.

2009-06-12 19:15:00 Author: dcf Posts: 468

---

Darn... looks like my reply to this never got posted... grrrr... Actually, "Son of a Bad Idea" DID work. The problem I ran into is that it is INCREDIBLY TRICKY to build it. Now, once it is built, it works like a champ. Solid as a rock. (Don't try this at home kids! I'm a professional!) And I thought you just hated me Well that was the thing, when I made it it worked like a champ then but as soon as you touch it, it broke. Then I try touching it and it breaks. Not much use as a teaching tool if it's that difficult to make. The version I'm using does need 2 variations (depending if you want it initialised to a 0 or a 1) but they are very very similar either way. DCF - you can make P-switches with a strong chain - you know you wanna just have the input connected to a piston and the output connected to the chain.

2009-06-17 11:11:00 Author: rtm223 Posts: 6497

---

And I thought you just hated me Well that was the thing, when I made it it worked like a champ then but as soon as you touch it, it broke. Then I try touching it and it breaks. Not much use as a teaching tool if it's that difficult to make. The version I'm using does need 2 variations (depending if you want it initialised to a 0 or a 1) but they are very very similar either way. DCF - you can make P-switches with a strong chain - you know you wanna just have the input connected to a piston and the output connected to the chain. Yeah, I've taken to doing just that with my custom logic gates. I use chains to pull the things all over the place. Sometimes I combine these with dissolves and emitters to emit new keys as well. That's how I put so much into my boss rush 3 submission with just 4 bars of thermo. Did you see the post I made about putting up the aiming circuits?

2009-06-17 11:19:00 Author: dcf Posts: 468

---

I understand a bit of logic, but these blogs just simply confused me. The diagrams just screwed me up, because it doesn't show you how it should look in LBP. EDIT: Jeez, just noticed the post date of the post right before this one is back in 2009...

2010-06-19 01:01:00 Author: Prince Pixelton Posts: 286

---

Yup.... since a year ago there's been a little development known as..... the Logic Pack!

2010-06-19 03:35:00 Author: CCubbage Posts: 4430

---

I saw this thread and I was excited 'cuz I hadn't seen Feloneous around since forever ago and I was curious what he had that could add to the logic pack. But then I saw the dates and realized this was old stuff and most of the logic we have now (thanks to the logic pack and Rtm's blogs) is more advanced and/or more thermo efficient.

2010-06-19 07:01:00 Author: Sehven Posts: 2188

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.